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

A place to show off your latest screenshots and for people to comment on them. Only start a new thread here if you have some nice images to show off!
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
Posts: 975
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Re: Planet Rendering Engine preview

Postby JohnJ » Sun Jul 19, 2009 7:06 am

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 :)
0 x

User avatar
Sovaka
Greenskin
Posts: 109
Joined: Sat Dec 20, 2008 6:26 am
Location: QLD, Australia
Contact:

Re: Planet Rendering Engine preview

Postby Sovaka » Sun Jul 19, 2009 7:53 am

Awesome stuff! Can't wait to play with it :P

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 ;\
0 x

User avatar
JohnJ
OGRE Expert User
OGRE Expert User
Posts: 975
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Re: Planet Rendering Engine preview

Postby JohnJ » Tue Jul 21, 2009 6:02 am

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.
0 x

User avatar
Sovaka
Greenskin
Posts: 109
Joined: Sat Dec 20, 2008 6:26 am
Location: QLD, Australia
Contact:

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

Postby Sovaka » Tue Jul 21, 2009 6:19 am

Awesome!!

Cheers for this JohnJ, remarkable work!


What's your new PC setup?
0 x

James Proctor
Orc
Posts: 406
Joined: Fri May 16, 2008 7:33 pm

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

Postby James Proctor » Tue Jul 21, 2009 8:34 am

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.
0 x
Follow me on Twitter - https://twitter.com/EmpireGames
Follow my Blog on Blogger - http://empiredevelopment.blogspot.com/

User avatar
Sovaka
Greenskin
Posts: 109
Joined: Sat Dec 20, 2008 6:26 am
Location: QLD, Australia
Contact:

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

Postby Sovaka » Tue Jul 21, 2009 10:23 am

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?
0 x

User avatar
RedEyeCoder
Gnome
Posts: 344
Joined: Sat Jun 16, 2007 7:29 am
Location: Brisbane, Australia

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

Postby RedEyeCoder » Tue Jul 21, 2009 1:37 pm

Great work, compiled fine and ran beautifully!
0 x

User avatar
DanielSefton
Ogre Magi
Posts: 1235
Joined: Fri Oct 26, 2007 12:36 am
Location: Mountain View, CA
Contact:

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

Postby DanielSefton » Tue Jul 21, 2009 1:52 pm

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?
0 x

James Proctor
Orc
Posts: 406
Joined: Fri May 16, 2008 7:33 pm

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

Postby James Proctor » Tue Jul 21, 2009 2:07 pm

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.
0 x
Follow me on Twitter - https://twitter.com/EmpireGames
Follow my Blog on Blogger - http://empiredevelopment.blogspot.com/

User avatar
DanielSefton
Ogre Magi
Posts: 1235
Joined: Fri Oct 26, 2007 12:36 am
Location: Mountain View, CA
Contact:

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

Postby DanielSefton » Tue Jul 21, 2009 2:17 pm

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.
0 x

User avatar
JohnJ
OGRE Expert User
OGRE Expert User
Posts: 975
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

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

Postby JohnJ » Tue Jul 21, 2009 3:37 pm

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.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

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

Postby sinbad » Tue Jul 21, 2009 6:19 pm

JohnJ wrote: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.
0 x

User avatar
JohnJ
OGRE Expert User
OGRE Expert User
Posts: 975
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

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

Postby JohnJ » Tue Jul 21, 2009 6:57 pm

sinbad wrote: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).
0 x

User avatar
tretle
Gnoblar
Posts: 5
Joined: Thu Apr 23, 2009 8:03 pm
Location: Ireland

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

Postby tretle » Tue Jul 21, 2009 9:03 pm

Thanks for releasing the code JohnJ.
0 x

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19261
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
Contact:

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

Postby sinbad » Tue Jul 21, 2009 11:17 pm

JohnJ wrote:
sinbad wrote: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.
0 x

User avatar
JohnJ
OGRE Expert User
OGRE Expert User
Posts: 975
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

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

Postby JohnJ » Tue Jul 21, 2009 11:38 pm

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 :)
0 x

James Proctor
Orc
Posts: 406
Joined: Fri May 16, 2008 7:33 pm

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

Postby James Proctor » Wed Jul 22, 2009 1:16 am

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
0 x
Follow me on Twitter - https://twitter.com/EmpireGames
Follow my Blog on Blogger - http://empiredevelopment.blogspot.com/

User avatar
Quorthon3D
Greenskin
Posts: 100
Joined: Fri Aug 08, 2008 8:06 pm
Location: Belo Horizonte - Brazil

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

Postby Quorthon3D » Wed Jul 29, 2009 1:03 pm

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.
Last edited by Quorthon3D on Wed Jul 29, 2009 1:06 pm, edited 1 time in total.
0 x
Sorry for my fail english, I'm studing, I swear! =]

User avatar
DanielSefton
Ogre Magi
Posts: 1235
Joined: Fri Oct 26, 2007 12:36 am
Location: Mountain View, CA
Contact:

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

Postby DanielSefton » Wed Jul 29, 2009 1:05 pm

Quorthon3D wrote:This release was build in 1.6?

Yup.
0 x

User avatar
Quorthon3D
Greenskin
Posts: 100
Joined: Fri Aug 08, 2008 8:06 pm
Location: Belo Horizonte - Brazil

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

Postby Quorthon3D » Wed Jul 29, 2009 1:11 pm

damned!anybody made in ogre 1.4?
0 x
Sorry for my fail english, I'm studing, I swear! =]

User avatar
DanielSefton
Ogre Magi
Posts: 1235
Joined: Fri Oct 26, 2007 12:36 am
Location: Mountain View, CA
Contact:

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

Postby DanielSefton » Wed Jul 29, 2009 1:37 pm

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

User avatar
Quorthon3D
Greenskin
Posts: 100
Joined: Fri Aug 08, 2008 8:06 pm
Location: Belo Horizonte - Brazil

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

Postby Quorthon3D » Wed Jul 29, 2009 1:56 pm

I'm making this now. but where I work, is 1.4, them don't will has the engine.
0 x
Sorry for my fail english, I'm studing, I swear! =]

michaelg1987
Halfling
Posts: 71
Joined: Sat Mar 10, 2007 5:14 pm
Contact:

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

Postby michaelg1987 » Sun Aug 02, 2009 8:24 am

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?
0 x

User avatar
JohnJ
OGRE Expert User
OGRE Expert User
Posts: 975
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

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

Postby JohnJ » Sun Aug 02, 2009 5:50 pm

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 :)
0 x

User avatar
petrocket
Gremlin
Posts: 178
Joined: Tue Mar 20, 2007 3:29 am
Contact:

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

Postby petrocket » Tue Sep 15, 2009 2:51 am

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)
Image
0 x
Ogre API & Manual | Ogre Wiki

blog | website | work

Follow me on twitter @ twitter.com/petrocket


Return to “Showcase”

Who is online

Users browsing this forum: No registered users and 4 guests