Google

[solved] Expansive, dense forests

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.

Moderators: OGRE Team, Moderators

Postby JohnJ » Wed Aug 15, 2007 5:15 pm

You can add grass areas to any degree of precision you want through a density map ( GrassLayer::setDensityMap() ). Just create a greyscale image file similar to a height map, where white means full grass density and black means no grass. For example:
Code: Select all
grassLoader->setWindDirection(...);

GrassLayer *grass = grassLoader->addLayer("GrassMaterial");
grass->setMinimumSize(2.0f, 2.0f);
grass->setMaximumSize(3.0f, 3.0f);
grass->setDensity(1.0f);

grass->setMapBounds(terrainBounds);
grass->setDensityMap("GrassMap.png");    //  <------
grass->setColorMap("LightMap.png");

grass->setSwayLength(0.5f);
grass->setSwaySpeed(1.0f);
grass->setSwayDistribution(10.0f);
grass->setAnimationEnabled(true);


Higher density map resolutions will give you more precision in grass placement, although even for a very large map a 256x256 grassmap is more than enough.

Remember to call setMapBounds() if you use setDensityMap() or setColorMap(), otherwise the GrassLoader won't know what region of space the map is supposed to affect. Normally you just set the map bounds to the same boundaries as your terrain.

P.S.: Click here and here setDensityMap() example screenshots.
Click here setColorMap() example screenshot.

Edit:
I believe the grassloader is an example, prebuilt PageLoader. You can use it as a guide and write your own to suit your needs.

That's true too, modifying the included page loaders is perfectly normal since a PageLoader is highly application specific. However, this doesn't mean the included ones aren't feature-complete (for the most part :) ).
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Jules Robichaud Gagnon » Thu Aug 16, 2007 2:00 pm

Thanks JohnJ, it makes everything clear now.

Maybe i should just have checked the examples instead of the source code. :roll:
User avatar
Jules Robichaud Gagnon
Regular
 
Posts: 227
Joined: Thu Jan 18, 2007 2:13 pm
Location: Chicoutimi, Québec

Postby JohnJ » Thu Aug 16, 2007 4:41 pm

Maybe i should just have checked the examples instead of the source code.

Actually the included example doesn't even use the grass system. A grass demo is kind-of a difficult issue since Ogre's scene queries are way too slow.

But in the final version I really want to include examples for everything, so I'm gonna have to find a way somehow.
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Jules Robichaud Gagnon » Thu Aug 16, 2007 5:07 pm

JohnJ wrote:
Maybe i should just have checked the examples instead of the source code.

Actually the included example doesn't even use the grass system. A grass demo is kind-of a difficult issue since Ogre's scene queries are way too slow.

But in the final version I really want to include examples for everything, so I'm gonna have to find a way somehow.


You mean like putting compilation flags which the user can activate if he wants grass or not?

What do you mean that Ogre's scene queries are way too slow? Is that about using rays to check the height of the ground?
User avatar
Jules Robichaud Gagnon
Regular
 
Posts: 227
Joined: Thu Jan 18, 2007 2:13 pm
Location: Chicoutimi, Québec

Postby JohnJ » Thu Aug 16, 2007 5:18 pm

You mean like putting compilation flags which the user can activate if he wants grass or not?

I was thinking I might have to make my own height function from scratch, or just using a flat terrain.

What do you mean that Ogre's scene queries are way too slow? Is that about using rays to check the height of the ground?

Well I originally used a RaySceneQuery with the default terrain scene manager, and it was way too slow. I think there's a bug in Ogre where a 10000 unit length ray will perform 10000 ray queries of 1-unit length each. When I switched to Ageia PhysX's terrain height function, the performance boost was amazing.
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Jules Robichaud Gagnon » Thu Aug 16, 2007 5:52 pm

JohnJ wrote:When I switched to Ageia PhysX's terrain height function, the performance boost was amazing.


How about just using a heightmap for the examples? (Btw, i use PhysX too)
User avatar
Jules Robichaud Gagnon
Regular
 
Posts: 227
Joined: Thu Jan 18, 2007 2:13 pm
Location: Chicoutimi, Québec

Postby JohnJ » Thu Aug 16, 2007 6:28 pm

How about just using a heightmap for the examples?

I was using a heightmap - with Ogre the only way you can get the terrain height is through a RaySceneQuery. Actually you might be able to link to the terrain scene manager and directly access it's height function, so that may be an option.

(Btw, i use PhysX too)

Good :), in that case you shouldn't have any trouble getting a fast height function.
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Jules Robichaud Gagnon » Thu Aug 16, 2007 6:36 pm

JohnJ wrote:
How about just using a heightmap for the examples?

I was using a heightmap - with Ogre the only way you can get the terrain height is through a RaySceneQuery. Actually you might be able to link to the terrain scene manager and directly access it's height function, so that may be an option.


I do not understand why using Ogre's heightfields with rays when it would be possible just to read the color manually and calculate the height. It would not be complicated to do that since you already do something like this with the density maps. Unless i do not understand the situation at all. :?
User avatar
Jules Robichaud Gagnon
Regular
 
Posts: 227
Joined: Thu Jan 18, 2007 2:13 pm
Location: Chicoutimi, Québec

Postby JohnJ » Thu Aug 16, 2007 6:47 pm

I do not understand why using Ogre's heightfields with rays when it would be possible just to read the color manually and calculate the height.

It's not quite as simple as reading the color to get the height. Of course you have to interpolate, but if you use the wrong method, it won't work right - you have to take into account how the terrain is tessellated.

Basically you end up doing one of these:
1. Asking Ogre for the terrain height
2. Duplicating the heightfield data and calculating it yourself (through PhysX or your own algorithm)

#1 would be preferred, but if it's too slow your only option is to use #2 (which is what I'm doing now).
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby JohnJ » Fri Aug 17, 2007 9:01 pm

Update:
- (Feature) Added GrassLoader::setRenderQueueGroup() in case you need to fix alpha ordering issues
- (Bug Fix) Prevented some possible material issues in GrassLoader

You can get the latest version from CVS, or as a downloadable archive:
Download PagedGeometry.zip
Download PagedGeometry.rar
Last edited by JohnJ on Sat Aug 18, 2007 12:28 am, edited 1 time in total.
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby JohnJ » Sat Aug 18, 2007 12:25 am

Update:
- (Update) Shadows can now be casted onto grass
- (Bug Fix) Fixed a problem where stencil shadows would cause rendering artifacts with the grass
- (Bug Fix) Fixed an issue where stencil shadows and impostors would crash

You can get the latest version from CVS, or as a downloadable archive:
Download PagedGeometry.zip
Download PagedGeometry.rar

This release basically fixes some issues with grass and shadows. Here's a video showing the grass system being used with dynamic shadows:
Dynamic Shadowed Grass Video (3.72 MB, WMV Format)
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Alexander » Sun Aug 19, 2007 10:12 pm

Awesome grass shadowing there! The only obvious giveaways that the grass isn't real is it's lack of interaction (perhaps a basic animation based on objects running over it) and those occasional angles where you see it intersecting the ground.
User avatar
Alexander
Regular
 
Posts: 175
Joined: Sat Aug 05, 2006 3:55 am

Postby tuan kuranes » Mon Aug 20, 2007 10:25 am

#1 would be preferred, but if it's too slow your only option is to use #2 (which is what I'm doing now).

Strange, it should be as fast as calculating it yourself.

Ogre basic terrain scene manager (like PLSM2) use a special case handling (if ray direction is Vector3::NEGATIVE_UNIT_Y) where it just compute results on heightfield instead of really launching a ray through all tiles (which is indeed slow, especially on highly scaled terrain.).
So TSM is correctly using this optimisation, It should be pretty fast.

You have to make sure scene manager use that optimisation, stop at first result, (otherwise it will pass the ray query on octree scene manager to launch rays).

search in terrain rayscenequery code, you'll see the special case (look for TerrainRaySceneQuery::execute). Perhaps try to put a breakpoint in TerrainRaySceneQuery::execute to see if your case goes trough that special case, and returns as soon it gets results (to make sure it does you can/should use a RaySceneQueryListener ).

And make sure you put all required flags on the ray scene query.
Code: Select all
_ray_query = mCamera->getSceneManager()->createRayQuery(ray);    _ray_query->setQueryTypeMask(Ogre::SceneManager::WORLD_GEOMETRY_TYPE_MASK );   _ray_query->setWorldFragmentType(Ogre::SceneQuery::WFT_SINGLE_INTERSECTION);
ray.setDirection(Vector3::NEGATIVE_UNIT_Y);


A simple grass demo (wihtout PhysX) would really be great. (video is indeed very nice.)
User avatar
tuan kuranes
OGRE Moderator
OGRE Moderator
 
Posts: 3003
Joined: Wed Sep 24, 2003 8:07 am
Location: Grenoble, France

Postby tuan kuranes » Mon Aug 20, 2007 2:59 pm

Ok made up the changes, and got 200fps here with grass + tree using Ogre Ray Scene query, but the optimized way (good flags + query listener)

http://tuan.kuranes.free.fr/PagedGeometry.zip

(as usual with my builds, if you're not using a diff/merge tool to check differences mainly Application.h , you can just drop in the parent folder of ogreSDK and build it from there without needing to changes media/resources.cfg of main OgreSDK folder.)

btw, very impressive code you did JohnJ, bravo !
User avatar
tuan kuranes
OGRE Moderator
OGRE Moderator
 
Posts: 3003
Joined: Wed Sep 24, 2003 8:07 am
Location: Grenoble, France

Postby JohnJ » Tue Aug 21, 2007 1:33 am

Ok made up the changes, and got 200fps here with grass + tree using Ogre Ray Scene query, but the optimized way (good flags + query listener)

Nice, thank you! :). I admit I know almost nothing on scene queries since I use an external collision/physics library in my engine, and I'm really glad you could clear this up - it will really be useful to have a reasonably fast height check function so I can create demos of the grass system.

The only obvious giveaways that the grass isn't real is it's lack of interaction (perhaps a basic animation based on objects running over it) and those occasional angles where you see it intersecting the ground.

I've been thinking about a few techniques to animate grass being pushed aside / stamped down by multiple objects (including an 100% GPU powered one :) ), and I may try to implement them in the future, but I'm not sure if most of my ideas will even work (but I haven't even researched this area, so for all I know this is an easy task) :D

Regarding the ground intersections, that's usually fixed by using better colormaps - the one I used in the example was basically an unmodified terrain lightmap, so some pretty high grass/terrain contrast is to be expected.
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Praetor » Tue Aug 21, 2007 1:58 am

I believe there has been progress in vertex shader animated grass which can bend away from someone standing on it. You can even have it wave back into place when the object moves.
User avatar
Praetor
OGRE Team Member
OGRE Team Member
 
Posts: 3285
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US

Postby JohnJ » Wed Aug 22, 2007 10:40 pm

I've finally added fade transitions, and so far they're working perfectly. Fortunately I didn't encounter any unsolvable alpha z-order issues, so even with the full batching PagedGeometry uses, transitions work very smoothly.

The transition interface is really easy to use, and won't break any of your old code either (or slow it down). addDetailLevel() simply accepts a new optional parameter, transition length, for example:
Code: Select all
   trees->addDetailLevel<BatchPage>(200, 50);
   trees->addDetailLevel<ImpostorPage>(500, 100);

The above example would set a 50 unit transition between the BatchPage and the ImpostorPage, and a 100 unit transition between the ImpostorPage and nothingness (in other words it sets the ImpostorPage to fade out for 100 units beyond the 500 unit far range).

All I have to do now is finish up a few misc. things, and I can release version 1.0 beta tomorrow (hopefully).
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Proutix » Wed Aug 22, 2007 11:18 pm

Glad to read that, you're addon rocks!
You really do good work!
One question: did you plan to integrate a density map style interface for the treeloader, like the grass interface? it could be useful.
Proutix
Regular
 
Posts: 53
Joined: Thu Dec 11, 2003 9:51 am
Location: France, Nantes

Postby JohnJ » Wed Aug 22, 2007 11:34 pm

Proutix wrote:One question: did you plan to integrate a density map style interface for the treeloader, like the grass interface?

Yes, but it's planned for version 1.1.

I believe there has been progress in vertex shader animated grass which can bend away from someone standing on it. You can even have it wave back into place when the object moves.

That's interesting. Do you remember where I could find information on it?
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby JohnJ » Thu Aug 23, 2007 7:27 pm

PagedGeometry Version 1.0 Beta is now available!

Change Log:
- (Feature) Fade transitions are now supported!
- (Feature) GrassLayer now supports setFadeTechnique(), allowing you to choose from several fade-out styles
- (Feature) Added TreeLoader3D, which allows you to place trees using full 3D xyz coordinates
- (Update) Wrote a lightweight version of StaticGeometry from scratch
- (Update) Removed "using namespace Ogre;" from headers to avoid conflicts
- (Update) Dramatically improved compile speed by including only required headers
- (Update) Optimized STL usage
- (Update) General code clean-up
- (Update) Removed Timer.h in favor of OgreTimer.h
- (Bug Fix) Changed grid calculation to Math::Ceil() instead of integer truncation, possibly avoiding duplicate page rendering
- (Bug Fix) Misc. bug fixes

You can get the latest version from CVS, or as a downloadable archive:
Download PagedGeometry.zip

This is the beta release of PagedGeometry 1.0. Hopefully there won't be any problems upgrading to the new version, but if you find any bugs, please let me know so I can fix them before the final release.

Note: The final version will include tutorials and samples, but the Beta version doesn't include them because they haven't been written yet.
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Praetor » Thu Aug 23, 2007 8:00 pm

Awesome progress. This is a great project. Can you explain what you mean by a lightweight version of StaticGeometry and what it gives you over the normal version?
User avatar
Praetor
OGRE Team Member
OGRE Team Member
 
Posts: 3285
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US

Postby JohnJ » Thu Aug 23, 2007 8:15 pm

Can you explain what you mean by a lightweight version of StaticGeometry and what it gives you over the normal version?

The only advantage from the user's point of view is that paging occurs faster with LOD entities, since only one LOD will be used in the batch. This could be a disadvantage though since batched LOD no longer works, but I doubt anybody uses LOD on batched geometry (it would look strange unless you had a very small region size, in which case you might as well use entities).

I would have stayed with StaticGeometry if I could, but I really had no choice. To implement fade transitions I needed full control over StaticGeometry materials, and the only way I knew to get this control was to write a batching class from scratch.
User avatar
JohnJ
OGRE Expert User
OGRE Expert User
 
Posts: 967
Joined: Thu Aug 04, 2005 4:14 am
Location: Santa Clara, California

Postby Praetor » Thu Aug 23, 2007 11:05 pm

Just wondering if you discovered something that might be folded into the core StaticGeometry to make it better.
User avatar
Praetor
OGRE Team Member
OGRE Team Member
 
Posts: 3285
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US

Postby syedhs » Fri Aug 24, 2007 10:28 am

Great progress JohnJ as always :)

Anyway, I am thinking of two things here:-

1) FrameListener in the PagedGeometry may or may not introduce memory leakage, because when you do this assignment 'frame->quit = true', it may/may not execute the next frameStarted. So in this case it will introduce memory leakage due to undeleted frameListener.

2) Please correct me if I am wrong, GrassLoader is using Math::UniformRandom to decide whether to place grass in a particular dot in the terrain but this is not done once, but maybe done twice,thrice etc depending on the camera's position right? (Camera may visit the place A.. and then go far awar to place B and then back to place A). So in this case, the grass' position are not the same between the visits. I am not looking into the code carefully (yet), as I am doing other stuffs but I sort of notice this to happen - grass which was not there suddenly is there when I revisit the place. Maybe the solution is to feed the same random seed (the seed is maybe the grid corrdinate) prior to using random functions.
User avatar
syedhs
Silver Sponsor
Silver Sponsor
 
Posts: 2044
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia

Postby Shadow007 » Fri Aug 24, 2007 11:10 am

regarding 2), I agree with Syedhs, seeding with a Hash of the grid's coordinates would allow to get the same results at the second time ...

I also had a look of the code, and it seems to me the algorithm to generate grass coordinate to be inefficient : in a low density layer, lots of computed locations will be thrown away due to the UnitRandom test, which will give a GrassCount inferior to what it would be otherwise ...

As an option, you could invert the layer's computations : instead of using X,Z to get the density and reject using the density,
you could build a list of 'value --> locations' index. Then, using the UnitRandom into the index, it gives you the area where the grass will be. You can then randomize the exact location of the grass inside the subgrid.
You get the exact GrassCount this way ...

The index could be built from the density map at runtime, or stored in an other type of layer...

I hope I'm understandable :). If I had time I would tr to implement this, but I don't :-(
Shadow007
Regular
 
Posts: 185
Joined: Sat May 07, 2005 3:27 pm

PreviousNext

Return to Using OGRE in practice

Who is online

Users browsing this forum: No registered users and 2 guests