..LE source..

[Naughty Alien]

..all right..this is mainly message for Josh, but anyone is welcome to answer(eventual source owners are welcome)...im very much interested to purchase ready to compile soruce version of LE..many reasons for that..i really love this engine and im going to use it for quite few projects on sight already, but i would like to have access to its source because of some things i would like to do with PS3 port..so, is it still available (source) and is there any info about it..i couldnt find anything on site..thanks in advance..

[Canardia]

Yes, the source is always available. The pricing is like with the various team, group, coorporate, associate, etc... discounts: you need to ask Josh for the price.

The source is ready to compile, just one command from the command line will do it,

and another one to compile the DLL.

[Naughty Alien]

..thats sounds nice...Lumooja, are you source owner? if so i would like to ask few simple questions...

[Canardia]

Yeah, I am a happy source owner

[Naughty Alien]

..ahh..good ..hehe..is it entire source Bmax or C++/C mixed?? Also, what are prerequisites in order to properly compile, regarding eventual SDK's and stuff??

[Canardia]

It's compilable with BlitzMax, but of course it has C++ code also, and the compiler just compiles them along with the bmx code. I haven't noticed any prerequisites, or then I had them already (perhaps some Brucey's etc... mods).

[Flexman]

I'm trying to nail down a price for the source but need to nail down how we're going to mod the terrain system. I'm in Tuscany atm talking about different engines, mods, some new ideas for planetary rendering and what we can do.

 

I've just been shown some impressive terrain tech by Quadsoftware that was used in Blazing Angels 2. We'd love to add a new paged terrain renderer and mod the engine to translate entities relative to the camera instead of the other way around.

 

But if we end up going DirectX for the sequel I'll have to re-write all the rendering functions for the vehicles. Which frankly leaves me feeling MEH!. But I'll do whatever is necessary.

[Canardia]

I have to make some test with tesselated mesh terrain. I don't see actually any major disadvantages of using meshes over terrain, since the renderer puts them on the GPU anyway. Alpha blending is also no problem when you put the transparent parts into the foreground world.

 

It just needs to happen automatically, so some sort of class for the mesh terrain would be handy. And the engine needs to draw only to a certain range, so the seperate meshes will be drawn only within a certain distance. It's probably then even faster than the current terrain.

 

The mesh terrain class should be also able to read terrain heightmaps from Editor, and convert them into meshes. Then the terrain can be deleted from Editor and the corresponding meshes can be used instead. Converting back to Editor terrain can be done too, but I think people would prefer then to use Sculptris or Blender for further terrain editing once the base mesh has been done with Editor. With those sculpting editors you can then make any kinds of overhangs, caves, loops, and completely 3D terrain in all directions. Once you've tried that I think you'll never want the normal 2D terrain back.

 

I see also a huge improvement in loading times of big terrains, as only a small part of the infinite terrain needs to be loaded. The loading of the terrain will be handled by the meshterrain class too, so you only need to place the placeholders for them in Editor. You can also simulate in Editor the dynamic behaviour by using non-infinite viewranges for the terrain placeholders. Theoretically this would be sufficient for the class too, but there might be some problems with the 32-bit floating point accuracy, so to make sure it really works infinite, the positions for the meshes need to be 64-bit floating points, stored in a custom text file, which is then read into a STL map.

[Flexman]

That's quite interesting Lum.

 

It sounds like you've been doing some mesh > terrain work. Are you working on a paged terrain system?

The floating-point issue is as you say something that might be partially solved by changing positional values to doubles then converting back to 32s for sending to the GPU.

 

Ideally with a paged terrain system you can move everything relative to the camera, that way it shouldn't be a problem. Just trying to work out some options here.

[Canardia]

I'm not working on a paged terrain system, but trying to make everything streaming and 3D, you know kinda like a space game, but universally usable for cities and everything else too. AO did the same. So the conventional terrain, skybox and particles are the first victims to be replaced by real 3D. Right now I start implementing 3D rain and snow for the game I'm working on.

 

I've thought about the 32-bit float limits of the scene pivot range too. Basically you can move the camera normally until a certain range from the scene pivot is reached, then you use 1 frame time to move all objects to a new center. Moving all objects in each frame is too slow, but there should be no problem doing it on demand, which happens very rarely, and most frequently when the player moves at high speed for long a long period.