Pixel Perfect

The only time I've done anything like this two way casting is when passing generic type pointers to functions where I've used void pointers for the parameter and passed the type as a string. The void pointer is then cast back to its original type and this works well.

Yes, I hoping the water in LE3 will be better than anything we have seen so far. I still have all the previous versions of Leadwerks from its first release so I'm able to go back and use Sandbox and the terrain erosion tools and just export the height map. They really were useful tools and I never understood why they were removed. Thanks Richard, and that's very much the reason why I'm not keen to let that go! All of this is distracting me big time from continuing with coding for Kingdom Of Soul but worth spending some time on I think to try and understand what's producing this effect and why I can seem to replicate it exactly using framework. Moving to 2.42 has been successful so I do at least have everything that comes with that which isn't dependant on framework.

Thats fair enough, I guess that the export to b3D is setting something in the file. As that's obviously internal to 3D World Studio I think Josh will need to answer this. I had a quick look online at the b3d file format and the brush chunk appears to be the only place where this might be set: BRUS int n_texs { char name[] ;eg "WATER" - just use texture name by default float red,green,blue,alpha ;Blitz3D Brushcolor and Brushalpha: default=1,1,1,1 float shininess ;Blitz3D BrushShininess: default=0 int blend,fx ;Blitz3D Brushblend and BrushFX: default=1,0 int texture_id[n_texs] ;textures used in brush } I'm guessing the Brushblend and BrushFX would be the most likely canidates. Surely these must be switchable within blitz3D. I noticed you were using entityFX for switching modes but I assume it made no difference? It's a shame the export from Deled messes the normals up as that would have been a fairly easy workaround. I suspect I have reached the limit of my knowledge on this. Hopefully Josh will respond with more insight.

I believe I've got closer to identifying the issue. It appears the effect is caused by a combination of HDR and FarDOF. But the FarDOF settings seem to be behaving differently between framewerk and framework. I need to investigate some more before I can draw any firm conclusions but I have got the effect partially working now in framework, just nowhere near as strong as it is in framewerk.

I must admit I know nothing about Blitz3D, however as you say the lighting is vertex lighting (and I'm assuming the vertex data must be there or it couldn't render the geometry) I can't see how this is anything other than a Blitz3D issue. Are the cubes you are rendering and lighting sucessfully external objects too or primatives created within the engine? Puki professes to be a bit of an expert in Blitz3D ... maybe he might be able to answer this.

Thanks Red, good luck with your development too. I know the water one has been a real headache for you for some time. I'm sure someone with good shader knowledge could help move that on for you. I feel hampered at times through not having sufficient shader knowledge to design or modify them but there are only so many hours in a day for learning new tricks! I hate having to compromise but for just now I think I'm going to stick with 2.42 and framewerk as I have everything working nicely with that and I really don't want to lose this effect. Lua will have to go back onto the back burner for just now. I will also unfortunately lose the Saturation/Brightness/Contrast settings too which is a real shame. But life often is a series of compromises.

Hi Mike. Yeah, we have lost some nice things along the way. The terrain erosion tools in Sandbox come to mind too! The move to 2.42 from 2.31 was really to gain the advantage of Vegetation Collision and the move to framework to get the ability to play with the Saturation/Brightness/Contrast settings. It also gave me the chance to load Lua scripted objects for the first time and play around with those. Klepto's DayNight package is really nice (might have to convert that to C++). As I've not really needed to use Lua before I never really looked at how it's been implemented so I'm not sure if I can still do so whilst using framewerk or not. I was led to believe a while back that this wasn't possible, but without looking into it or someone knowledgeable telling me if I can or cannot then I'll keep an open mind on this. I don't know what if anything is embedded in the engine to facilitate this and if it's inherently dependant on framework. Although I'm not dependant on Lua scripted objects in any way it has been nice to have the ability to load them whilst using framework. The big issue I've always had with the existing implementation of Lua is it doesn't support the exporting of C++ class methods to Lua making it much less powerful than it otherwise would have been. That's why I have always envisaged I'd have to add my own implementation at some point in the future so I can script my AI in Lua (external from the engine). Version 3 will take care of this of course.

Ageed, looking cool afecelis

Well I'm not sure it's a bug ... just different. I can see the HDR working in 2.42 it just doesn't have this light leakage effect. As the shader code seems to be identical between the versions I can only assume its a difference in what's being fed into them. Framewerk produces the effect, framework doesn't. That's my findings so far anyway, I maybe mistaken and there is some other factor contributing to this which I'm currently unaware of. I guess only Josh really knows what's going on behind the scenes and he's not commented on this so far. As it's an asthetic thing some people may prefer it without this effect. I'm not currently using Lua so swapping back to framewerk isn't an issue for me and has some advantages as I've added some additional functions, that framework doesn't have, to give me access to the rendering buffers. At least I'm assuming I cannot use framewerk easily with Lua as I guess the Lua scripts are using the framework command set. Not having looked into it I'm not sure where Lua gets its engine definitions from. Maybe I could wrap the framewerk functions there so the same commands point to their framewerk equivalents. Either way, at some point I suspect I probably need my own implementation of Lua to expose my C++ classes so I can script my AI using Lua. That would be just perfect, although I do believe Josh has been doing a great job of keeping on top of the bugs in the current version which must be a huge distraction when trying to design and code a new engine!

Thanks Vetal, I was considering doing that, simply replacing the 2.42 shader pack with the 2.31 one (if it's indeed possible to do that) however I have since discovered something else. If I use the 2.42 engine with my original 2.31 build which still uses the framewerk then I get the same effect. So this seems to be telling me that is framewerk itself as opposed to framework that is producing this! Maybe a difference in the use / blending of buffers or something. This now leaves me in a bit of a dilemma. I really like this effect so do I go back to framewerk and abandon framework

Up until very recently I have been doing all my development in version 2.31 with C++. Wanting to take advantage of some of the later features I recently upgraded the engine to 2.42 modifying my code where necessary. I also at this point decided to ditch the original (open-source) framewerk and recode the engine to use the embedded framework. On the whole this has been very successful, however I now notice that a graphical effect I really liked in 2.31 no longer seems to manifest itself and I'm really not sure why this is. It appears in 2.31 when you use HDR combined with Bloom and its a kind of light bleeding or leakage that you get round objects. This looks really natural when walking through brightly lit trees and I think is a really impressive effect. However, this does not appear when using 2.42 with framework and as I can see no differences between the Bloom and HDR shaders I'm at a loss as to why this should be. If anybody can reveal any insight into this I'd be grateful. This demonstrates the effect in 2.31 I'm talking about, it's a lot more noticable in motion but this still picture still shows it: This is the same scene in 2.31 with HDR switched off: This is the same scene in 2.42 with HDR: This is the same scene in 2.42 with HDR switched off:

I agree, I recently tried an old version of Sandbox in order to play around with the erosion and deformation type functions and I really liked them, got very realistic results. I'd love to see these type of functions re-instated.

What's your intended approach regarding additional terrain textures Josh. I find this is the most limiting factor in the current engine and can't begin to think how fantastic levels would start to look if we were able to use say 30+ textures.

Well these are top of the range cards so yes they would be suitable but expensive. Make sure you leave some money to buy the Leadwerks Engine

We can play with words and descriptions all day however we all know that both Josh and Admin could have moved this and have for whatever unspecified reason chosen not to, in the same way as one of them removed the previous thread associated with this in Off-Topic without any public explanation! That's ok, it's their choice and forum and if they want to exercise double standards and censorship we cannot stop them. I personally think it sucks but that's just my opinion. I'm not going to lose any sleep over it. I'd just like to know why people who advertise third party assets which could equally well be used with Leadwerks Engine and have artistic merit too are immediately moved. The reason cited to some of these in the past was that the Leadwerks Showcase was only for showcasing things made with Leadwerks. I rest my case.

That's true but then the pipeline becomes more involved which seems to be what Koan is trying to avoid. I guess what I'm trying to say in a long winded way is that although the initial gains in using something like Poser appear to the novice to be great there is always a price to pay for this. Although initially you appear to get a lot, for little to no investment of your effort, in time I suspect you'll find yourself held back by the the lack of professional features. If you are serious about having good animated models in your games then you are either going to have to team up with a good animator/modeller or learn the basics yourself using a good modelling/animation app or apps. Brent previously summed it up:

I always thought the poly count for exported poser models was far to high for game use as they stand. Maybe that's changed recently I don't know.

Congratulations on getting your game published, I wish you luck!

Poser Pro 2010 allows full import and export of COLLADA files. So if this is your animation tool of choice then tools exist to convert collada file formats to gmf. Job done! You can hardly expect Josh to write an entire Poser clone so he can make animation simpler for you. I don't know anyone who has tried the conversion yet but in theory it should be straight forward so long as Poser exports a valid COLLADA file.

This I like a lot, should make life very easy

That sounds like a very nice implementation.

So what are the flowgraphs going to be used for? Used in moderation they are a nice feature but tend to become completely unwieldly over a certain size and complexity

It was, he had written his software with a level of abstraction from the actual game engine, so he could port it easily to Leadwerks or Phyre from what I remember.

Chris Paulson has been working with Unity for a while now and the ease at which he has integrated a nav mesh editor he's written (his own this time ... not Recast) with the Unity Editor speaks volumes. This is one of the great strengths of their editor and the framework they provide as it enables non trivial functionality to be seamlessly integrated and applied as a simple drag and drop item. Others have previously alluded to this and in my opinion that type of system really encourages community development of the type that the Unity Forums are full of. It's a vibrant happening place. Never ignore the competition ... learn from them and take their best features and use them to enhance the many commendable features of Leadwerks Engine. If this is built on top of the code base and the full API is still exposed then there are no constraints placed on us programmers should we not wish to use the provided frameworks. Effectively we can have the best of both worlds!

I just got round to trying your latest version and I have to congratulate you on a brilliant job! Many thanks klepto2