www.quadsoftware.com
FAQ  FAQ   Search  Search   Memberlist  Memberlist   Usergroups  Usergroups
Register  ::  Log in Log in to check your private messages


Post new topic  Reply to topic
 yet another question on very large terrain rendering « View previous topic :: View next topic » 
Author Message
captain_deathbeard
PostPosted: Fri Nov 12, 2010 2:40 pm    Post subject: yet another question on very large terrain rendering Reply with quote



Joined: 12 Nov 2010
Posts: 4

I am thinking of buying a grome license, but I have a couple of questions:

1- How does graphite (ogre specifically) handle extremely large terrains? Does it automatically page zones in and out as the camera moves (or option to do so manually)?

I have to ask this because of the number of terrain solutions I have tried that look good in pictures but in reality only handle a tiny little square of terrain. The ogre graphite demo only demonstrates a small terrain. My game is currently using a 16,385 x 16,385 height map at a resolution of 11m per pixel.

2 - Can I sell my game commercially using ogre grome indie licence? In one place it says I can, in another it says I can't.

3 - I notice Anti-aliasing is disabled in the ogre demo, is this a limitation of graphite?

4 - On from a previous question by someone else:
Quote:

Quote:
Modifying Terrain Shaders
One potentially serious issue is that I suspect that the Grome terrain shaders are closed source. Is this true? The reason I ask is because my project (and many Ogre3D projects) use integrated shadow techniques, such as PSSM (parallel split shadow maps), which require specific modifications to the terrain shaders in order to cast shadows on the terrain.

Also, I notice normal mapping is not listed in the list of supported features. This is another candidate for modifying the terrain shaders.


There are several methods to change Graphite terrain shaders. One is to change the iTerrainShading module all together (provide your own version of shaders). Another is to add custom rendering passes on top of terrain or to instead of normal passes. I will go into details once you decided to do this with more technical information.

Important thing to be noted here is that Graphite was designed so various modules can be changed with user's implementations. Terrain LOD and the shading are two separated modules. One can change the LOD and keep the shaders in place or vice-versa.

To be noted that next version of Graphite has PSSM, normalmapping (global and per layer), parallax mapping and other more advanced shaders.

my question is, will PSSM and normal mapping still be added, and if not and I want to add them myself, will graphite make things more complicated for me? (rendering is not my strong point)

5 - ogre graphite has not been updated for almost a year and has no water support. Is it still being worked on, and will it work with the latest ogre 1.7?
Back to top
View user's profile Send private message
ALicu
PostPosted: Fri Nov 12, 2010 6:59 pm    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hi,

1 - Graphite can be adapted to support background streaming. So I think you can adjust your application so, at least from Graphite terrain point of view, you can stream in and out of memory data as the player moves around. I cannot speak for Ogre background streaming. I don't know their

But your scene should be ok without background streaming. 16.385 at 11 m per pixel would mean a heightmap of approx 1500 x 1500 tiles. From my experience, for the current video cards, you can go with 2048 x 2048 tiles in Graphite without problems (medium card and 1 GB of RAM).

2 - Current Ogre/Grome license you can use for commercial projects without any additional fees. Grome free license (alone, without Ogre) you cannot use for commercial projects.

3 - Antialiasing can be applied externally without any modifications to Graphite. You can even change them from your video driver panel and force it for the Ogre/Graphite demo.

4 - Next version of Graphite will support shadowmapping, dynamic lighting and other features. Next version would be out at the beginning of the next year. It will maintain 100% backward compatibility and you will be able to add the new features in Ogre yourself (if we are not doing them right away). As with any other features of Graphite they are exposed to the user and are customizable (you can add your own geometry to cast and receive shadows for example).

5 - We do plan to update it once the new version of Grome and Graphite will be out (at the beginning of the next year).

Let me know if I can provide more information.

Best Regards,
Adrian L.
Back to top
View user's profile Send private message
captain_deathbeard
PostPosted: Sat Nov 13, 2010 2:20 pm    Post subject: Reply with quote



Joined: 12 Nov 2010
Posts: 4

Thanks for your reply
ALicu wrote:

1 - Graphite can be adapted to support background streaming. So I think you can adjust your application so, at least from Graphite terrain point of view, you can stream in and out of memory data as the player moves around. I cannot speak for Ogre background streaming. I don't know their

But your scene should be ok without background streaming. 16.385 at 11 m per pixel would mean a heightmap of approx 1500 x 1500 tiles. From my experience, for the current video cards, you can go with 2048 x 2048 tiles in Graphite without problems (medium card and 1 GB of RAM).


You misunderstand, my map size is 16,385 x 11 meters, so I would need a total of 16385 x 16385 tiles. I could make it a little smaller and work on it in chunks.

My question was not so much about streaming (I will have pauses for load times anyway), but whether graphite is limited to a max amount of terrain. eg in grome I can manage a max of about 4096x4096 tiles, can I have more than this in graphite by only loading a portion at a time?

I think then that I will have to manually call to load and unload tzones? But if I do this how will I know which tzones to load next? how will i know for example that canyon12.tzone is the one to load next to canyon 34.tzone? Or will graphite handle this automatically?
Back to top
View user's profile Send private message
ALicu
PostPosted: Sat Nov 13, 2010 6:24 pm    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hi,

Quote:
My question was not so much about streaming (I will have pauses for load times anyway), but whether graphite is limited to a max amount of terrain. eg in grome I can manage a max of about 4096x4096 tiles, can I have more than this in graphite by only loading a portion at a time?


In Grome you can manage only 4096x4096 if you are not using the swap system (which is disabled in the demo version). The swap system lets you temporarily send zones to disk and leave in memory only the zones you are working on. You can see it in action in the first video from here:

http://www.quadsoftware.com/index.php?m=section&sec=product&subsec=editor&target=Editor/features_video

and in some other video tutorials from our site.

Without streaming, in Graphite you can load as many terrain zones as your memory allows you (which are between 25 and 50% more than in Grome since it has optimized data: packed masks, compressed images etc), then you can delete the ones far away and load others. Loading and deletion is very optimized (compared with Grome swap for example which is an editing application so has some overhead) and for a detailed zone of 1024x1024 with 7-8 texture layers in average you have around 1 sec loading time.

Quote:
I think then that I will have to manually call to load and unload tzones? But if I do this how will I know which tzones to load next? how will i know for example that canyon12.tzone is the one to load next to canyon 34.tzone? Or will graphite handle this automatically?


There are many ways to determine what zones to load and unload: a naming convention, by distance etc. The actual strategy is very much game dependent.

Graphite has some examples (with source code) that load and unload terrain zones as the player moves around using a grid naming convention (TerrainZone_xx_zz). One of the examples even uses a local coordinate system (centered on the zone the players is in while the surrounding loaded zones are relative to this) which is changed as the player moves. This is necessary for very large scenes where floating point precision may create round-up errors when the player moves very far away from 0,0,0 origin.

Regards,
Adrian L.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Based on a template by Dustin Baccetti
Powered by phpBB © 2001, 2005 phpBB Group