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
 More Ogre3D Questions « View previous topic :: View next topic » 
Author Message
Jabberwocky
PostPosted: Thu May 06, 2010 4:18 am    Post subject: More Ogre3D Questions Reply with quote



Joined: 04 Mar 2008
Posts: 6
Location: Canada

Hi! I'm back with (lots) of questions!

First off, I downloaded the demo grome editor and played around for a bit. It is SLICK. Amazing job!

Ok, questions relating directly to the Ogre3D port:

Heightmap Interface for Physics
Does iTerrainQuery or some other interface provide access to all the heightmap verticies/positions, so I can feed them into a physics engine?

Water
I read this "No support for water surfaces until next version", but saw some water related files in demo OgreGraphiTE visual studio project, such as iWaterLib.h. Is there any support for water at this time?

Use of Grome Resources (textures, etc)
Can the textures that come with the Grome editor be used in a commercial project?

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.

Graphics Options
What sort of graphics options do I have control over, regarding the terrain? From the sample integration code, it looks like: pixel error, Geomorph distance. That's definitely a good start. What about the terrain materials - can I turn off spec mapping for example? Can these changes be made at runtime, or do they require a reboot?

Stitching / Skirts
Graphite looks great, and seems to perform quite well. But I did notice (within Grome) some slight cracks in the terrain along the borders of TerrainZones, as the LOD transitions from one level to another across the border. I can probably live with that, but just wanted to mention it in case you had any thoughts.

RenderSystem
Is DirectX / windows the only supported platform? Not a big deal for me, because that's what I'm targeting, but still I'd like to know whether ports to OpenGL-based systems are possible.

HmapImport tool
A lot of existing ogre projects use 16-bit raw heightmaps for terrain. I noticed that the HmapImport tool only accepts bmps. Is it possible to import a 16-bit heightmap into Grome? (not a deal breaker if I can't)

Detail Layers
So GraphiTE handles the rendering of detail layers such as grass and vegetation? What sort of graphical techniques are used to do this with reasonable performance? Is it rendered in GraphiTE exactly as it is in Grome?
Again, there is the concern for closed source shaders and implementing shadow techniques.

Lighting
Am I correct that the terrain supports exactly one directional light source, and nothing else (e.g. point lights)?

Integration into complex Ogre project
Here are some things that my Ogre3D-based game does:
- create and destroy cameras
- switch between different cameras
- creating and destroying different terrain scenes
- creating and destroying different ogre SceneManagers as I switch between different scenes/levels

I notice from OgreGraphite.cpp, that the Camera and SceneManager are specified in an init() call
Code:
gte::t_error Graphite::init(Ogre::SceneManager *sm, Ogre::Camera *cam, Ogre::RenderWindow *win)

Does this mean I cannot change the Camera or SceneManager after initialization?

-------

Apologies if I'm focusing on potentially problematic issues with the integration. All middleware has certain constraints, and if Grome isn't a match for my current project, I'll still certainly consider it for future ones.

I guess the other possibility is just to use Grome as an editor, then use a different terrain renderer to overcome the above issues. Can Grome be used just to export heightmaps, splat maps, and object data (name, position, orientation, properties)? I'm fine with a Grome-specific format, I can always preprocess the data if necessary for my engine.

Thanks, and again awesome job on Grome. It's really great!
_________________
The Salvation Prophecy
Space Combat. Planet Exploration. Strategic Domination.
Back to top
View user's profile Send private message Visit poster's website
ALicu
PostPosted: Thu May 06, 2010 7:43 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hi,

Quote:
Heightmap Interface for Physics
Does iTerrainQuery or some other interface provide access to all the heightmap verticies/positions, so I can feed them into a physics engine?


Yes, the query interface offers fast ray pick and heightmap get that you can used for various tasks.

Quote:
Water
I read this "No support for water surfaces until next version", but saw some water related files in demo OgreGraphiTE visual studio project, such as iWaterLib.h. Is there any support for water at this time?


Water rendering is present in the Graphite library and one can make integration with Ogre by encapsulating the water reflection function and the water rendering into Ogre scene graph as the terrain was. Other tasks in hand prevent us for doing this but we are more than happy to offer you guidance in case you need it right away.

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.

Quote:
Graphics Options
What sort of graphics options do I have control over, regarding the terrain? From the sample integration code, it looks like: pixel error, Geomorph distance. That's definitely a good start. What about the terrain materials - can I turn off spec mapping for example? Can these changes be made at runtime, or do they require a reboot?


Most (I think all) parameters from terrain don't require a reboot. You can enable / disable layers (at least in the last version), change the resolution of the baked textures, their distances, affect various LOD parameters (as you've pointed out).

Quote:
Stitching / Skirts
Graphite looks great, and seems to perform quite well. But I did notice (within Grome) some slight cracks in the terrain along the borders of TerrainZones, as the LOD transitions from one level to another across the border. I can probably live with that, but just wanted to mention it in case you had any thoughts.


Graphite and Grome geometry LOD is quite different. The shaders and visual results is similar for texturing but Graphite because it is only a run-time rendering engine have more freedom to apply more aggressive culling and LOD and to do proper stitching. Grome is an editing application and can expect the terrain data to be changed at any time. Graphite on the other hand does proper stitching at the borders for both geometry and texturing (for example it does pixel padding so bilinear filtering doesn't create seams). It also uses geomorphing for heightmap for smooth transitions.

Quote:
RenderSystem
Is DirectX / windows the only supported platform? Not a big deal for me, because that's what I'm targeting, but still I'd like to know whether ports to OpenGL-based systems are possible.


OpenGL is in work (as it is DirectX11). We already have a base OpenGL implementation running. We also have clients that ported Graphite to Xbox and PS3.

Quote:

HmapImport tool
A lot of existing ogre projects use 16-bit raw heightmaps for terrain. I noticed that the HmapImport tool only accepts bmps. Is it possible to import a 16-bit heightmap into Grome? (not a deal breaker if I can't)


You can import 16bit raw using the raw importer (if you have a demo version of Grome the plugins are disabled). You can do lots of things with the plugins and the SDK (create new import/export plugins, new mesh formats etc). We are also preparing the quick import tool to accept more formats directly in the tool.

Quote:

Detail Layers
So GraphiTE handles the rendering of detail layers such as grass and vegetation? What sort of graphical techniques are used to do this with reasonable performance? Is it rendered in GraphiTE exactly as it is in Grome?
Again, there is the concern for closed source shaders and implementing shadow techniques.


It is rendering the detail elements grouped together in chunks and streams them out and in video memory as the player moves around. Exactly the same rendering technique is used in both Graphite and Grome. For now you cannot change the shading to them but we are preparing a way to apply your own shaders.

Quote:

Lighting
Am I correct that the terrain supports exactly one directional light source, and nothing else (e.g. point lights)?


For the current public version, yes, you are right. The next version will support one directional light but this would apply per pixel lighting and dynamic shadows. We are also thinking of a deferred lighting method to allow multiple light sources without performance drops. We will clearly evolved more in this direction since it is an important feature.

Quote:

Integration into complex Ogre project
Here are some things that my Ogre3D-based game does:
- create and destroy cameras
- switch between different cameras
- creating and destroying different terrain scenes
- creating and destroying different ogre SceneManagers as I switch between different scenes/levels

I notice from OgreGraphite.cpp, that the Camera and SceneManager are specified in an init() call
Code:
gte::t_error Graphite::init(Ogre::SceneManager *sm, Ogre::Camera *cam, Ogre::RenderWindow *win)

Does this mean I cannot change the Camera or SceneManager after initialization?


No, you can easily change the camera. That was just a way to send a pointer to the current camera. One can easily set a function Graphite::SetCamera to change the pointer without any additional modifications. We can modify the standard integration with various additions if our clients request it so everyone can benefit from these modifications.

You can also load and delete Graphite zones at any time.

Quote:
I guess the other possibility is just to use Grome as an editor, then use a different terrain renderer to overcome the above issues. Can Grome be used just to export heightmaps, splat maps, and object data (name, position, orientation, properties)? I'm fine with a Grome-specific format, I can always preprocess the data if necessary for my engine.


You can use Grome SDK (not present in the demo) to export all the scene elements: terrain heightmaps, textures and their masks, layers mapping, object placements, detail and water coverage masks and their parameters. You can also create import plugins, new formats of objects, attach custom properties to scene entities, create trigger plugins (called when certain editing events happen) and utilities (generic plugins that are present in Grome menu). What you cannot do with the SDK is to create Grome tools but we may offer this in the future.

Let me know if I can offer you additional information. I am more than happy to assist you.

Best Regards,
Adrian
Back to top
View user's profile Send private message
Jabberwocky
PostPosted: Thu May 06, 2010 4:46 pm    Post subject: Reply with quote



Joined: 04 Mar 2008
Posts: 6
Location: Canada

Thank you. This is extremely useful information. I'll post a link to this thread over on the Ogre3D forums. A few of us are discussing Ogre+Grome over there.

Using Graphite terrain LOD, with a custom iTerrainShading module seems like a very flexible solution that may allow me to accomplish what I need.

I am guessing it is not quite as simple as providing iTerrainShading an Ogre::Material pointer to replace the default graphite terrain shaders. What exactly is the interface? How can terrain materials and shaders be communicated to Graphite? What about providing shader parameters, such as WorldViewProjection, light direction, depth shadow maps, and various other PSSM-specific parameters?

Can the shaders be anything (cg, hlsl, glsl), or is a specific shader language and version required?

If there's any way I could see iTerrainShading.h, that might be helpful.

One of the many things I really like about Graphite is the vertical mapping. If a custom iTerrainShading module is provided, is it still possible to achieve vertical mapping?
_________________
The Salvation Prophecy
Space Combat. Planet Exploration. Strategic Domination.
Back to top
View user's profile Send private message Visit poster's website
Jabberwocky
PostPosted: Fri May 07, 2010 7:12 am    Post subject: Reply with quote



Joined: 04 Mar 2008
Posts: 6
Location: Canada

In case my last post was a little confusing, I guess what I'm asking is this: inside of iTerrainShading, are we interfacing with DirectX directly, using ogre-based materials, or some kind of Graphite-specific rendering interface?
_________________
The Salvation Prophecy
Space Combat. Planet Exploration. Strategic Domination.
Back to top
View user's profile Send private message Visit poster's website
ALicu
PostPosted: Fri May 07, 2010 7:13 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

Hi,

iTerrainShading is just an interface (table of virtual functions) used by the current terrain visibility algorithm (by default geomipmapping) to shade (apply rendering states and shaders) the terrain by calling the functions from it. The actual rendering of the terrain geometry is done by the visibility algorithm (he knows how to render the chunks) while this module does all the preparation of shaders and rendering states.

The current shading module (interface) can be changed with a call to iTerrainLib :: SetSubModule (C_TERRAIN_SHADING_MODULE_SZ, &my_current_shading) where my_current_shading should be your class implementation of iTerrainShading interface.

If you look at this shading interface it has the following important functions:

CreateZoneShading = called by the system to create per terrain zone shading specific data. Here you can allocate your custom data that needs to be kept per terrain zone.

BeginZoneShading = called by the visibility module when it starts rendering a visible terrain zone. Must return the number of rendering passes your terrain shading consider necessary to render that specific terrain zone. This number usually depends on the texture layers present on the zone and the current hardware (if it can collapse the layers or have one rendering pass per layer).

EndZoneShading = called after the visibility module rendered the zone geometry. Here you should restore any rendering states, perform clean-up etc.

In between BeginZoneShading and EndZoneShading the visibility algorithm calls the rendering of terrain geometry for each rendering pass, encapsulated with the following functions:

BeginZoneRenderPass / EndZoneRenderPass mark the beginning and end of a rendering pass. Between these the visibility algorithm renders the chunks of geometry and send LOD specific parameters to your shading module (like the SetGeomorphFactor function).

There are other details to consider (like the baked texture which is a shading optimization by using a layer collapsing texture in the distance) but these are the main ideas.

You can also add custom rendering passes on top of terrain and the shading module will be called with BeginCustomRenderPass / EndCustomRenderPass functions to shade those.

Of course you can change terrain visibility algorithm also and use the built-in shading, or change both. The entire library was designed with this extensibility / changeability in mind (you can change any submodule: memory allocator, console, texture manager, geometry manager etc).

If you have a source code license you can use one of the built-in modules as starting point for customizations (but the source code license is not indie oriented, we license those with special contracts to professional studios). Anyway I am more than happy to provide details of the existing built-in modules for any indie client, too.

You can code your shaders in any format as long as it is matching the existing rendering module (which can also be changed, for example to use the Ogre rendering API directly). You can use HLSL if you are using DX, GLSL if you are using OpenGL, special GLSL or CG if you are on PS3 rendering module etc.

Vertical mapping states are setup by the shading module by the information provided from the zone layers. Basically the simplest shading module would do the following:

- return the number of texture layers per zone at BeginZoneShading as it will use one layer per pass.

- for each pass, takes the index of the pass as the layer index, takes the mapping settings from that zone layer (orientation planes, tiling, rotation as inputted in Grome and also the final texture matrix corresponding to these) and set them on the proper texture units (set texture matrix), bind the layer mask and diffuse textures, set the vertex/pixel shader corresponding with the pass and the rendering states.

- the visibility module then renders the geometry with the states as set by the shading module.

- repeats the process for each pass (layer in this case).

Let me know if I can provide more information.

Regards,
Adrian L.
Back to top
View user's profile Send private message
ALicu
PostPosted: Fri May 07, 2010 7:16 am    Post subject: Reply with quote



Joined: 12 Feb 2007
Posts: 1326

About your other post:

Quote:
In case my last post was a little confusing, I guess what I'm asking is this: inside of iTerrainShading, are we interfacing with DirectX directly, using ogre-based materials, or some kind of Graphite-specific rendering interface?


I am using DirectX9 calls directly. One can change the rendering or shading module to call Ogre3D API calls so a tighter integration exists with Ogre materials. I am using the Ogre3D texture manager for textures though (to use the engine searching paths) by providing a special iTextureManagerInterface implementation to the Graphite iTextureManager submodule.

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