Planet Rendering Engine preview (released Jul/20/2009)

[JohnJ]

Sorry about the delay, I just got my computer up and running tonight (my case was bent up so badly I had to order a new one, thanks to newegg.com it arrived very quickly) - and fortunately all my data appears to be intact so I'll be zipping up the engine soon

[Sovaka]

Awesome stuff! Can't wait to play with it

Sucks to hear about the case but consider yourself lucky... I once lost a hard drive due to a slight speed bump when transporting my computer ;\

[JohnJ]

Sorry about the delay, here it is:
Galaxy Engine open-source release (32.8 MB ZIP)

I'm releasing it under the zlib license, so it's basically free for anything - credit is technically optional but always appreciated . Disclaimer: This code should not be taken as an example of perfect design! Consider it a working prototype which should hopefully have some useful bits and pieces for a game. Also this code is over a year old, so it's certainly not the most technologically advanced planet rendering technique out there, though I don't know of many open-source engines to compare with.

Sucks to hear about the case but consider yourself lucky... I once lost a hard drive due to a slight speed bump when transporting my computer ;\

Yeah it was amazing that both hard drives survived. I must have done a full proper shut-down which parked the read/write heads, otherwise they would certainly have been destroyed as well. Anyway it wasn't too bad, now I have a really nice "new" computer (new case, new motherboard, new video card, new CPU heater) which should last me a good while before I need to upgrade again.

[Sovaka]

Awesome!!

Cheers for this JohnJ, remarkable work!


What's your new PC setup?

[James Proctor]

Thanks so much for releasing this! I can't wait to get it compiled however I am getting some compile errors.

Error 2 error LNK2001: unresolved external symbol _FreeImage_Save SpritePlanet.obj GalaxyEngine

There are 8 of these errors. I downloaded FreeImage and setup where to find the lib and include files.

[Sovaka]

Woah...

Just started to play around with it and when I linked FreeImage.lib, on compile I get 266 errors :S

Would you be able to post your FreeImage.lib?

[RedEyeCoder]

Great work, compiled fine and ran beautifully!

[DanielSefton]

Compiled and running great for me.

Btw, with regards to the technique, I believe Infinity Universe uses a Chunked LOD/GeoMipmapping variant... So I wouldn't disregard it?

[James Proctor]

Could one of you who have it working upload your FreeImage lib for us who can't get it working? I just downloaded the latest version today and I even downloaded a older version thinking maybe it was made with the older version still getting those same 8 errors.

[DanielSefton]

Uhh, if you would have looked at the include directories, you'd see that it's pointing to the Ogre dependency package... If you don't have it, it's on the downloads page, but that also means you haven't compiled Ogre yourself, which you really should do.

[JohnJ]

I used an Ogre source build which is why SDK users are getting errors related to FreeImage. Downloading the dependencies package might work if you don't have the source build.

Also as you can see this version doesn't do procedural terrain, or at least not very well. With some modification it could be fairly easily adapted to a fully procedural approach if you like, provided you have a way of generating normals correctly.

Btw, with regards to the technique, I believe Infinity Universe uses a Chunked LOD/GeoMipmapping variant... So I wouldn't disregard it?

I wouldn't disregard it completely, but I'd be interested to see how Infinity solves the problem is seams between different LOD chunks. When a chunk can have any number of neighboring chunk configurations, it's tricky to update the normals because you have to match the normals of the edges otherwise you'll see lighting seams. I think Infinity uses some sort of GPU normal map regeneration scheme (not sure), but in any case I've noticed that Infinity's terrain engine, while it looks amazing, does take quite a bit of resources on it's own.

The terrain engine in my rewrite should (hopefully) run at 500+ FPS on a 7800GT easily, to allow for all the other things like forests, ships, etc., etc.

[sinbad]

I wouldn't disregard it completely, but I'd be interested to see how Infinity solves the problem is seams between different LOD chunks. When a chunk can have any number of neighboring chunk configurations, it's tricky to update the normals because you have to match the normals of the edges otherwise you'll see lighting seams. I think Infinity uses some sort of GPU normal map regeneration scheme

My new terrain component uses a global object space normalmap per page precisely to get over the problems with chunking and normals.

[JohnJ]

My new terrain component uses a global object space normalmap per page precisely to get over the problems with chunking and normals.

Hmm.. I'm not quite sure I understand how that solves the problem though. How do you deal with one quadtree node with neighboring nodes containing multiple levels of detail? The nice thing about GPU geometrical clipmapping (not geomipmapping) is the neighbors / LOD transitions are constant and simple (nested grids), which makes transitions between LOD and normals easy. With chunked LOD, you would have to update the normals every time neighboring nodes change as far as I can tell (the normals themselves don't have to be recomputed but the edges of a chunk can't have higher res normals / vertexes than the neighboring chunk(s) otherwise there will be a seam).

[tretle]

Thanks for releasing the code JohnJ.

[sinbad]

My new terrain component uses a global object space normalmap per page precisely to get over the problems with chunking and normals.

Hmm.. I'm not quite sure I understand how that solves the problem though. How do you deal with one quadtree node with neighboring nodes containing multiple levels of detail? The nice thing about GPU geometrical clipmapping (not geomipmapping) is the neighbors / LOD transitions are constant and simple (nested grids), which makes transitions between LOD and normals easy. With chunked LOD, you would have to update the normals every time neighboring nodes change as far as I can tell (the normals themselves don't have to be recomputed but the edges of a chunk can't have higher res normals / vertexes than the neighboring chunk(s) otherwise there will be a seam).

Because the tesselation of the node is irrelevant - all the normals are used on a per-pixel basis. Normals are always held at the highest possible detail level, and sampled according to the pixels displayed regardless of what LOD is being used. You generate the normal map from the highest tesselation and the lighting is constantly at that fidelity regardless of the geometry. Changes to the terrain are similarly processed (in terms of the normals) at that fixed resolution regardless of what LOD is being used. So I decouple my vertex resolution from my lighting resolution.

[JohnJ]

Ah, I see what you're saying. That's actually exactly how the planet demo here works for the low res non-procedural terrain data. The problem I've been dealing with is introduced when you need multiple levels of detail for normals due to the massive size of a terrain, for various reasons. For example with a 3,000,000 square mile planet at 2 foot resolution that's about 20,000,000,000,000 vertex normals to store. Not exactly practical, especially with multiple planets

[James Proctor]

Well I have already had the planet destroyed twice. One time jumped the living day lights out of me. The first time it happened I was just exploring the surface of the planet and all of a sudden I look up and theres a moon or another planet almost right on top of me. It crashed into the planet, the whole screen went black and I ended up back by where you first start. The second time it was destroyed I raised the mass of the planet to 200,000 and as soon I started it up the moon or planet was back on a collision course with the planet and crashed into it! lol

[Quorthon3D]

This release was build in 1.6? Because I try build in 1.4.x, and i get 69 errors, like:

Code: Select all

c:\Documents and Settings\Visual Virtual 5\Desktop\GalaxyEngine\Engine\include\Atmosphere.h(35) : error C2039: 'Visitor' : is not a member of 'Ogre::Renderable'
1>        c:\ogresdk\include\OgreRenderable.h(57) : see declaration of 'Ogre::Renderable'
1>c:\Documents and Settings\Visual Virtual 5\Desktop\GalaxyEngine\Engine\include\Atmosphere.h(35) : error C2061: syntax error : identifier 'Visitor'
1>.\source\Atmosphere.cpp(39) : error C2259: 'GalaxyEngine::Atmosphere::AtmosphereRenderable' : cannot instantiate abstract class
1>        due to following members:
1>        'const Ogre::Quaternion &Ogre::Renderable::getWorldOrientation(void) const' : is abstract
1>        C:\OgreSDK\include\OgreRenderable.h(95) : see declaration of 'Ogre::Renderable::getWorldOrientation'
1>        'const Ogre::Vector3 &Ogre::Renderable::getWorldPosition(void) const' : is abstract
1>        C:\OgreSDK\include\OgreRenderable.h(101) : see declaration of 'Ogre::Renderable::getWorldPosition'
1>.\source\Atmosphere.cpp(40) : error C2259: 'GalaxyEngine::Atmosphere::AtmosphereRenderable' : cannot instantiate abstract class

and, where i get ddraw.h, it is missing.

[DanielSefton]

This release was build in 1.6?

Yup.

[Quorthon3D]

damned!anybody made in ogre 1.4?

[DanielSefton]

I don't think it's worth downgrading the code, just download the 1.6 SDK, hook it up, and hey presto.

[Quorthon3D]

I'm making this now. but where I work, is 1.4, them don't will has the engine.

[michaelg1987]

I have a question or two about dealing with the physics using a system like this. I'm not terribly knowledgeable on the topic of physics engines, but a few things come up in my mind that I'd like to clarify. Doesn't something this big create issues because of floating point precision, or if it were used in like a game, the sheer number of objects that collision would have to be calculated for? Also, once you're talking about managing multiple planets and possibly the space between them, wouldn't the floating point issue become more exaggerated?

[JohnJ]

Yes, floating point precision is definitely an issue that needs solved in one way or another with an engine like this. With the engine I uploaded, planets use floating point precision and are always centered at (0,0,0), even with multiple planets. It uses a form of shifting origin system, but IMO it's kind of messy and didn't really work very well. A better approach is to use double values for all coordinates, etc., and use camera-relative rendering so it can be rendered on video cards (which only support 32-bit floats) correctly.

Another interesting fact is, with standard 32-bit floating point values, you can only maintain 0.1mm precision up to 0.8km, which isn't much at all. The farther beyond that the less precise the coordinate system will get, which is something you must avoid at all costs. Double (64-bit) floating point precision on the other hand, can maintain 0.1mm precision up to 450 million km, which from negative limits to positive limits gives 900 million km of range.

900 million km isn't nearly enough though to represent a full 1:1 scale galaxy, and if you want a hardcore insanely realistic simulation with proper galactic scales, etc. you'll need double double precision using 128bits at least for every scalar value in one way or another - but I think this is crazy and unnecessary. 900 million ^3 dimensions provides more than enough space for up to a billion stars if you use non-realistic scales, and even then it's still massive and vastly empty space.

As to collision, that's another issue I struggled with for a while as to various solutions, but in theory it's pretty simple: You certainly can't render each and every object on a planet without level of detail reduction, so you definitely can't simulate them physically all the time either. Terrain will need LOD-based collision data streaming, and you'll need to load and unload objects into the physics system dynamically.

Another issue you'll encounter is the topic of rotating planets in a physics system. If you actually rotated the planet collision data along with the objects on the planet's surface in the physics system, even using all double precision values it would become incredibly numerically unstable - objects jittering all over the place, stacks collapsing and jumping, objects sliding around on surfaces, etc. Physics simulations just aren't accurate or stable enough to simulate such a diverse range of scales with constantly moving objects involving centrifugal forces, etc. The solution is of course to simply not rotate the physics world yet simulate the forces such as centrifugal force (which is required to maintain geostationary orbits within a planet's physics scope), and manage transition points to keep it synchronized. Another related issue is interaction inside ships which are moving and maneuvering at high speed. I'll leave the actual implementation though as an exercise to the reader

[petrocket]

Has anyone managed to get this solution to load into VC 2008 Express Edition?

I'm so excited to try this out!

I've been working on a similar approach (just like everyone else it seems) only my frame rates are more like 120fps on a good day
Mine generates all the data procedurally and uses RTT to generate the textures for the terrain (ALA infinity) Also it generates normals on the fly. Unfortunately, I haven't gotten the loading/unloading from files working just yet so sometimes there is noticeable stuttering.

Here's a small video. The blog has more info (it's an exaggerated planet and only 6 levels deep)