Flexman

I'm really pleased to found something that works. Although the best sub-sim I remember playing used a waterfall display, don't think you got to ever see the sub exterior. SSN-21 Seawolf?

Best way was/is camera relative rendering, all objects are transformed around the origin. Ogre3D has such a mode (with problems at time of writing). This is not possible with Leadwerks Engine for the reasons I'll go into. Another technique is tread-milling. Microsoft Flight Simulator uses this technique, your position is reset as you cross the border of a terrain tile. This can be emulated at one level in Unity and Leadwerks by parenting objects to a tile-object and moving those tiles around the camera. In Leadwerks although you can't use the terrain or vegetation system with this technique so you need to build or load in your own terrain geometry. There's a book just been published which explores all these concepts 3D Engine Design for Virtual Globes now available in electronic format. It touches on precision and z-buffer antics. There's no magic bullet for precision, doubles instead of floats will get you a bit further but you need to be a bit radical. A lot of these off-the shelf 3D engines don't do radical well, they are so interconnected with physics, shaders and lighting. Quadtree software produce a terrain editor called Grome that's well suited to editing huge terrains and exporting individual tiles (they call zones) and has been used for numerous console flying games (e.g. Ubisoft's Blazing Angels). I'm experimenting with this one. The main problem is the pipeline from Grome to Leadwerks and poor threading (just because you can do it in language X doesn't make it good). I could write buckets on old simulations, some never did anything so fancy as the above. A lot didn't use heightmaps in the way they are often employed today as they pre-dated the hardware that heightmaps are optimised for. Constructing geometry on the fly from a dataset was the order of the day.

Before I filed a bug report I thought I'd post here. First... Vegetation LOD ranges ^^= View distance to... Currently, vegetation model LOD works by multiplying the editor Vegetation LOD distance * model LOD number. In the editor Vegetation settings: If you specify LOD distance = 100 And you have a tree model with 5 LOD models, this results in the following: vegetation_trees_oak_a.gmf ^^= 100 vegetation_trees_oak_aLOD1.gmf ^^=200 vegetation_trees_oak_aLOD2.gmf ^^=300 vegetation_trees_oak_aLOD3.gmf ^^=400 vegetation_trees_oak_aLOD4.gmf ^^=500 Which isn't a fine enough level of control for tuning. Especially if you only have 2 LOD models or very small ones. Ideally a command to set the LOD would be better, like thus... veglayer1.setLODdistance(lod0, 50) Billboard Normals These are reversed? Here are two screenshots, one is the same position but rotated about 180' to look in the opposite direction. Look in the distance (not the trees close to the camera but the middle distance where they transition from 3D to billboards). Screenshot A - 3D tree model is dark facing us. Billboards in the middle distance are lighter in colour. Screenshot B - 3D tree model is light facing us. Billboards in the middle distance are darker in colour. This makes blending near impossible for all lighting conditions. Collisions FIXED If I setting this to 5 in the editor then collisions are not recorded for some reason in code despite using the following code: Collisions(5, 1, True) ; Collisions(1, 5, True) ; Leave them at the default value and collisions work. It makes detecting collisions with different vegetation layers difficult. Macklebee sorted this one out. I had to edit COLLISION.LUA and COLLISION_CONST.LUA to set the values. Raycasting on vegetation returns type "1" every time regardless of the vegetation collision type. This can be a problem. Cabbage Patch Billboards An option to turn off the overhead billboards. This would eliminate the presence of cabbage patch doughnuts appearing when viewing at altitude. Presently the only workaround is to edit the billboard to cut and past over it with a flat image which doesn't work too well. BIG FEATURE REQUEST Which I suspect can't be done but would be a big help certainly in making our game a bit more polished: Fade-in vegetation billboards rather than a snap transition.

p.s. I had to add... #extension GL_ARB_gpu_shader5 : enable At the top of the file to get it to run on my video card otherwise I get the, "error C7532: global function textureGather requires "#version 400" or later" error.

Cheers Frank,

Check out some videos of what can be done with the engine. I think, regardless of the engine you will run into performance problems but Leadwerks is pretty good at culling, especially when it comes to vegetation. The other issue you might have when coming to Leadwerks is the art asset pipeline. I highly recommend you create documents covering what works for you. I have no doubt that you can put together a high performance racing game together with Leadwerks. But because of the deferred rendering nature the things that one might consider easy can be quite problematic, such as Transparency. Heaven help you if you want to make a submarine game though Physics, audio, a high performance veg system and a range of language choices. As the above poster said, Ogre is just a renderer, you'll need to do a lot of work before you even get to start on a game.

That's really useful. I made a very simple one for debugging but yours is much much better. Is it easy to create a new instance and stack them?

When you get to version 3.142 you can call it LeadwerksPI ( PI not like Magnum PI )

Game magic.

The particles rotate so you can't get away with simply using the texture co-ordinatess unless you unrotate the the 'uv' to compensate. If one did I'm guessing that might work.

I was having a quick play in particles.vert and particles.frag trying to tweak it so it graduate the diffuse intensity from top to bottom of an individual particle. The aim is to fudge some shaded smoke effects. Any ideas to do this in particles.frag? Graduated shade from top to bottom? Sphere shaded particles as simple as this would work well...

I've never used 3D World Studio but I'll take your advice and give it a go.

I presume the colour buffer for each window is available and a simple 2D DrawImage stretched to fill the new size while you reposition is possible. Personally, so long as I can position things fast an easy it's all good.

I'm not really sure what CSG really means for models. Does it mean I can take a small building or wall, then perform some logical operation on it to cut out a shape and then it becomes a new mesh which can be saved and re-used?

I love seeing stuff like this. Good work. A* (little pun there)

Your robots remind me of the TESCO supermarkets invasion of Denmark thanks to this video... http://www.youtube.com/watch?v=1IevLaMPaxM

You know. That might be why I had one hell of a problem trying to get landing gear articulating correctly. I spent a week trying different approaches :/ Somewhat frustrating.

Just add blend=alpha as Metatron posted and try it. If still no joy add an alpha layer to the texture. It shouldn't be difficult to do. Your setting of the alpha in code should work as you intend (it's multiplying that value with another). You should be able to control fade in and out by adjusting the alpha in SetColor() once you get the texture and blend sorted out.

MESH.FRAG takes the alpha of the model, so you've set it to 0.3 and later if you have LW_DIFFUSE defined it multiplies diffuse with the texture values. So possibly it's worth checking the models alpha channel and if it's pulling out a ZERO it's probably that. Materials are well worth checking here as your function (above) looks fine to me.

I'm genuinely excited to see this running. It's brilliant. One of the things I do to explore game rules is turn it into bits of paper and dry run it at a table, really scrappy rips with scribbles. One of the Harry Potter games had it's mechanics tested using cardboard, pencils and blu-tac, much cheaper the prototyping code and the sort of thing you can do it in an afternoon, beer garden optional.

Does the TCamera object maintain a list of entities previously rendered? I'm looking for a really FAST way to get a list of TEntities in the camera frustum. With the culling system this information might be available?

softparticles.frag You might have a material called "softdust.mat" or "smoke.mat" that uses it. I'm not clear what comes with the standard LE package anymore. But thats probably what you're after, particles that blend the edges softly with geometry.

An Identity Matrix is... mat.ix=1 ; mat.iy=0 ; mat.iz=0 ; mat.iw=0 mat.jx=0 ; mat.jy=1 ; mat.jz=0 ; mat.jw=0 mat.kx=0 ; mat.ky=0 ; mat.kz=1 ; mat.kw=0 mat.tx=0 ; mat.ty=0 ; mat.tz=0 ; mat.tw=1 Scale for XYZ is ix, jy, kz Position XYZ is tx , ty , tz The tricky part is rotation. I tried to write a quick function that I thought would demonstrate it but I kept getting an exception error LOL. I'll come back to it if I figure out why. I wonder if Leadwerks does something funny for rotations.

I've been coding since LE v2.21 on 3 monitors for a long time now courtesy of Maxtrox Tripplehead2Go. So long as Eyefinity works in a similar transparent way (a single virtual display device) it shouldn't matter. Just set your screen resolution and go. If it requires specific support then it's probably not worth the trouble unless you're doing OEM work or a simulation project which requires it. As far as I've been able to determine, ATI's Eyefinity SDK is mostly about pulling driver specific information about bezel management and aspect ratios. Aspect can be easily compute in leadwerks friendly format with: aspectratio = float(GraphicsWidth() / GraphicsHeight()) ; The bulk of the ATI docs on Eyefinity programming seems more "best practice". So Leadwerks should work out of the box with Eyefinity. Any special commmands for supporting it should come from using ATI's SDK which is a matter for the programmer. http://sites.amd.com/us/Documents/ADL_ATI_Eyefinity_SDK_Whitepaper_v1.0_FINAL.pdf Hope that answers your questions.

I wonder if anyone had any ideas on how to tell what terrain texture you might be walking on for doing the classic "footstep" audio effects? A function like int GetTerrainMaterialXY(x,y); ???