Pixel Perfect

Thanks macklebee, thats exactly what I'm looking for but I'm not sure that's exposed in the C DLL. The ability to access all the properties of entities in BlitzMax is a big advantage! I wonder what the MeshName(TEntity mesh) returns. I'm at work at the moment so can't try it!

Is it possible to obtain the model / mesh file names from the Entity collection once loaded from an sbx file? Are these retained/exposed? I can do everything else I need to from the loaded scene without having to parse the sbx file and would rather not do so just to obtain the model file names if I could avoid it. This is so I can convert them to .obj files programatically and dump them into a common directory.

Agrees with Roland .... no way I'm taking that on

Your progress is really impressive Josh! Glad to see things are working out so well. The multi-platform nature of LE3 is going to make the engine so much more attractive to potential buyers.

That looks great!

That would explain it ... cheers Richard

I think you forgot to include the shaders.pak file as it wouldn't work without that. Very nice demo though

Where are you turning on Align To Terrain? I can only see this in the vegetation layer options. I did find this though ... previous report of same problem

Just something odd that happened. It was only with a few character models that I had. Whenever I parented a gun, which I had used with many other models successfully, to them then they (the parent character model) appeared in the render about 100 times the size they should be, absolutely massive! It just seemed to do weird things to the models scaling. As this was the minority not the majority I didn't bother investigating further, I just didn't use those models.

Same here. Just occationally in the past I have had issues with scaling where parenting a model to a particular parent model resulted in the parents scale being magnified many times. Never did figure that one out as it's perfectly ok with most I've tried.

That looks very nice. I'll have a play with your demo. Thanks!

I currently use your second method, that is I load all the parts and hide them then position, apply atributes and show them at the point of the expolosion/destruction so I can apply the forces to them. This works fine for me but I'm not using 1000s of destructible objects. Probably the most I have tried at any one time is 80. As I only have so many varients on destructible models there is a lot of instancing going on so I don't imagine the hit is that great. I guess you'll just have to experiment unless someone else can give you feedback on doing this with that number of objects. I do sometimes have issues with instability in the physics when lots of exploding objects interact with each other, as all my exploding objects propgate their forces to items within a given radius and will cause them to explode too. It can result in a lot of random jittery movement of parts long after they should have stopped moving. I intend at some point to modify the way I apply forces as I think this may be contributing to this. Removing these part objects, as you do, might be a solution too as mine remain as dynamic debris after the destruction.

I'll try this today as I don't think I've ever tried align to terrain on a group of objects outside of vegetation layers. I assume it works if you group copy but individually align them, the positions are retained?

Quick little conversion program and it's importing beautifully. I love it when a plan comes together

Is the raw file as exported from the terrain editor a 16 bit unsigned raw file format? [EDIT] I guess by the file size checks I've done it is. I think I've found my issue, the app I'm trying to import it into is expecting an ogre raw file which appears to have ((terrain size + 1)^2)*2 bytes. So a 512x512 terrain is exported as a 513x513 for some reason!

I can't see any reason why this wouldn't work although as you say probably more efficiently executed by a shader on the GPU, however as you point out you wouldn't be able to indiviually alter instanced models.

Vegetation collision works fine for me too. Be wary of using vegetation layers with patches (models made up of more than one tree) as align to terrain is only meaningful if the terrain angle is uniform over the entire area of the patch. As outdoor terrain is seldom like that you again end up with some trees in mid air. You need single trees which have the side effect of looking very uniform, ok for Pine forests but not much use for anything else. Hand placement is the way to go from my experience if you want realistic looking landscapes but tedious work on anything large scale!

milkshape has a similar util, only works on X file formats though, but likewise has the slider and realtime display of poly reduction. Great for static models but I'm not sure what it would do to models designed to be animated, you'd probably have to rework the joint areas again afterwards. I must admit, I have UU3D Pro and I'd never noticed this! There is so much in that app though, it's a voyage of discovery

My advice would be to forget the game for the first year and concentrate on the basics. Learn a programming language well; learn all about the basics of game creation including path finding, AI and game flow logic and how to implement it, asset creation and 3D modeling including animation techniques, textures and UV mapping (at least a basic understanding of the fundamentals to you can liaise in a meaningful way with modelers and asset creators), shaders and particle emitters. Whilst doing all this and experimenting with it you'll get a good grounding in the Leadwerks Engine API. Have a play around with level design but don’t waste too much time on this as just about anyone can do that and without the rest it will remain sat in your editor doing nothing other than looking pretty! It's hard to describe to someone new to game design just how much of a learning curve it is but it’s very exciting so if you’re motivated you can do it.

The original 2.0 version of Leadwerks Engine 2 supported loading 3DWS scene files via the LoadScene command and did exactly as you're suggesting as it set up all the lights too giving you dynamic lighting. Unfortunately this is no longer available and the only current support offered is the brush export to gmf facility. 3DWS does export the lightmaps but even if you could apply them it would only give you static lighting. Probably worth taking the hit and manually adding the lights in the Editor to get full dynamic lighting.

Hi quast: 1. Currently unspecified. I suspect the full engine release is still some way off, probably 2012 at some point. 2. I do not understand your question. 3. No, there will still be a charge, but buying LE2 and upgrading to LE3 will be less than purchasing LE3 on its own. 4. No, LE2 is a unique game engine. Its not designed to hack and edit other game engine games. 5 & 6. If you purchase the engine then you are free to negotiate with people over work you might require. 7. Not sure exactly what the question is but LE2 probably has some of the best dynamic shadow support of any engine today and if shinning looking is referring to specular then you have full control over this.

When a new user asks a question regarding what formats they can import into the engine they are quite naturally referring to what file formats can simply be loaded directly by means of either placement in a directory and subsequent recognition by the tools or via a file load dialog. To interpret that in any other way is simply ridiculous. Leadwerks supports loading of its own proprietary file format .gmf only and restricts textures to .dds only. There are, as people have pointed out, a series of converters to produce .gmf files from a range of popular file formats. Models for use in vegetation layers then have further restrictions placed on them by having to follow a formal naming convention as do textures used for terrain painting all adding to the work needed upfront to make these available to you the user in the editor. I personally believe it's worth this downside for all the benefits you get with this engine... and it is a great engine, but it’s never been popular with users of the engine be it artists or programmers.

That's pretty neat Deniz. Would look even nicer with a snow emitter! Nice work though.

I would 100% agree with Flexman's comments with regard to LE2 which is why I have pretty much ignored Lua. However, Lua in LE3 sounds much better supported and as all I would use a scripting language for is implementing game play logic and AI it matters little to me which language is used so long as it's a capable language and has full debuging support. I tend to agree with Josh when he says: If you intend writing your entire game engine in the scripting language then the choice of language might become more important, but I have never seen the point of doing this when LE3 will support multiple languages anyway. Keep the scripting language for scripting!

Thanks for the recommendation Fred