Page 2 of 4

Posted: Fri Aug 06, 2004 12:48 am
by monster
Is this a scene manager thing, or one of your own created classes.
It's one of my own creations!

It's independent of any scene manager or anything else, you just call the code from above to set up your GroundCover object, and call "update" every frame (or whenever the camera moves) to re-jig the culling and high-detail blocks. That's it. And, as I say, there's absolutely nothing to stop you having multiple GroundCover objects to display different things in different ways.
So Awesome, Want It
Thanks! I don't think it's quite ready for public consumption just yet, but soon.

Posted: Fri Aug 06, 2004 1:55 pm
by rzhou_sh
really nice work!

Posted: Mon Aug 16, 2004 11:48 pm
by Silent
Kencho wrote: Another interesting performance is to make them static geometry (trees don't use to change...)
I've heard this mentioned a number of times (i.e. using static geometry). It's probably obvious, but I appear to be overlooking it. How is a particular piece of geometry (say a tree) rendered as "static"?

Posted: Tue Aug 17, 2004 1:38 pm
by sinbad
'Static' just means that you pretransform the various instances (like the many trees) and save all the geometry in one buffer. In a sense, they don't have to be 'static', they could be moved around as a group, but the instances become static relative to one another since their individual positions are pre-baked.

Posted: Tue Aug 17, 2004 10:54 pm
by Kencho
Static is one of the hardware buffer usage options, that means that you don't plan to access the buffer content (for instance, a building -- you surely don't intend to add or delete vertices from it, right?)
The performance enhancement here is that you can take a bunch of objects you don't want to transform (relatively to each other -- the trees in a forest; if you move a tree, you move the whole forest) and "pack" them in a single buffer (treating the whole forest as a single object)

Posted: Fri Aug 20, 2004 6:28 am
by pingz
Speaking of lots of objects, the new instancing feature of DX9 is now supported for ATI cards: ... notes.html

Previously it was only a shader 3.0 feature, but it works great on my 9800. In the NovodeX Rocket "building explode" demo which has 4616 individual blocks in it i got 53fps without instancing and 240fps with it on (and with physics paused of course).

Basically what you do is pass a second stream with any per-instance data you need like world transforms, colors, or whatever. Then you can use that data in your shader. You can get some real low level detail on it from this nvidia technical report.

The question is how to shoehorn this into Ogre. Maybe some new options in RenderOperation and a new buffer object? Is there an equivalent in OGL?

Posted: Fri Aug 20, 2004 11:03 am
by tuan kuranes
A technical demo of instancing is here :

(with source code)

Posted: Fri Aug 20, 2004 2:15 pm
by sinbad
Now this is very interesting indeed. Ideally this would be implemented as an automatic aggregator - ie for every pass, you group up all the visible objects using the same combination of vertex data and issue them as an instance.

I'd love to know whether GL is going to support this too. I'll be keeping an eye on this one since it solves a serious issue with modern GPUs, ie that they hate lots of render ops.

Posted: Fri Aug 20, 2004 6:36 pm
by pingz
Ideally this would be implemented as an automatic aggregator
I think automatic is gonna be very tough to implement and potentially doesn't take full advantage of additional per-instance data like colors, scaling, etc. Also it would be inefficient... why have 10000 nodes/renderables when you can have one *special* renderable that knows how to instance itself?
I'd love to know whether GL is going to support this too.
I'm investigating this myself.

Posted: Fri Aug 20, 2004 6:57 pm
by pingz
I got a response from ATI on what cards support instancing and how to use it from OpenGL:
Works with all ATI DX9 cards and instancing available thru a FOURCC code.

Samples will be available soon.
I'm not that familiar with OpenGL and FOURCC, but i'm sure the samples will clear this up.

Posted: Mon Aug 23, 2004 8:14 am
by Robomaniac
I'm just wondering:

When :)

When will it be ready for public consumption :P Seems like a very useful thing (*cough*aka. one that i need*cough*). Any timeframe?

Posted: Mon Aug 23, 2004 9:21 am
by monster
It'll probably never be ready for proper public consumption! I was planning to release all the code from my current project when that goes live (1st October) since it contains all sorts of goodies. But I'll try and stick the raw source for this stuff up in the near future, when I get a minute.

Instancing blows it completely out of the water though!

Posted: Mon Aug 23, 2004 6:05 pm
by SpannerMan
I for one am very keen to see your source, Monster :)

Hey, what if you were to combine your methods with instancing? Is that a possible scenario? Wouldnt we get an even more increase in trees?

Posted: Mon Aug 23, 2004 6:27 pm
by pingz
I would think that monster's code is something you would have to have in the case that the hardware doesn't support instancing. So it would make a great fallback for all nVidia cards before the Geforce6 and all ATI cards before the Radeon 9500. Remember that's *alot* of cards!

Posted: Mon Aug 23, 2004 6:50 pm
by AssiDragon
I'd think most people who have PCs doesn't have a card that supports instancing... not everyone has the money for a GF-FX or 9600PRO you know :P (like me for one)

Posted: Mon Aug 23, 2004 8:39 pm
by pingz
Actually i do not believe the Geforce FX cards support it... only the new Geforce 6 cards.

Posted: Tue Aug 24, 2004 2:04 pm
by monster
For what it's worth, you can get the source code for this from here;

It's far from commercial quality, but it works OK for my current needs.
The documentation's a bit sparse (i.e. non-existant!) but you should only ever need to call the constructor, "add" to add meshes to your world, "compile" to make those meshes static, "update" every frame to cull and re-jig the detail according to the camera's position, and the destructor.

You might also want to modify the culling parameters with "setCullParameters".

You can also register a DetailListener if you want to know when the high-detail blocks are re-jigged. For example, I use this to move (create, enable, disable) my collision primitives, so the car can run into the trees.

Have fun, please don't be too critical!

Posted: Tue Aug 24, 2004 3:12 pm
by psyclonist
Great work, monster! I'll definitely play around with that one!


( too bad I have to write an exporter for the tree generator I bought, before I can use those )

Posted: Wed Aug 25, 2004 5:49 am
by Robomaniac
Just a quick question...

Is Ogre::SceneManager::heightAt a valid function?! Has never shown up in the SceneManager class although it is in the terrain scene manager :\

Posted: Wed Aug 25, 2004 5:59 am
by nfz

Posted: Wed Aug 25, 2004 6:09 am
by monster
Is Ogre::SceneManager::heightAt a valid function?
(for about the 5,000,000th time)
No. Use a ray scene query.

Yes it's in the TerrainSceneManager because that's a specialised scene manager for which a single height value at a single point makes sense.

It's not in the generic SceneManager interface because that can be used for different scenes which might have many different "heights" at a given (x,z) point. Like a big BSP map for example.

Posted: Wed Aug 25, 2004 11:01 pm
by Azatoth
Very, very nice Monster! I plugged it into Dime just to see how our grass would look. Not too shabby. :)

I did some modifications, amongst them the change from Camera::getPosition to Camera::getDerivedPosition.
For grass to work one would have to add the ability to define rotations as well as orientation.

Posted: Thu Aug 26, 2004 2:17 am
by monster

Yep, baking the orientaion and scaling (and normal re-normalisation) into the big mesh, rather than just the position, would definitely be a worthwhile addition.

P.S. Is it the grass that's killing the framerate in that shot, or something else?
5.7fps with 19,072 tris isn't too good is it?

Posted: Thu Aug 26, 2004 12:12 pm
by Azatoth
It's probably not the grass. There's a lot of other stuff going on (it's a fully fledged MMORG client). Plus, I haven't done any optimizations anywhere. Though the use of scene_blend alpha on all of the grass polys is probably not that smart.

It would be nice with normal reorientation and readjustment to the ground of the meshes while still keeping the grass pointing upwards. I.e. even if you adjusted the mesh so it would fit the ground you would "shear" it so it pointed to the sky.

Posted: Thu Aug 26, 2004 5:21 pm
by dennis
monster wrote:Cool!
Yep, baking the orientaion and scaling (and normal re-normalisation) into the big mesh, rather than just the position, would definitely be a worthwhile addition.
Hmmm ... perhaps the baking could be integrated into the scenenode structure. Freezing all childnodes. Thinking about it ... that would probably only work for very specific cases.