Rendering A LOT of things

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster » Fri Aug 06, 2004 12:48 am

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

rzhou_sh
Gnoblar
Posts: 10
Joined: Fri Aug 06, 2004 1:23 pm

Post by rzhou_sh » Fri Aug 06, 2004 1:55 pm

really nice work!
0 x

Silent
Kobold
Posts: 33
Joined: Sun Apr 27, 2003 6:57 pm
Location: New York, USA

Post by Silent » Mon Aug 16, 2004 11:48 pm

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

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

Post by sinbad » Tue Aug 17, 2004 1:38 pm

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

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 1
Contact:

Post by Kencho » Tue Aug 17, 2004 10:54 pm

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

pingz
Gnoblar
Posts: 10
Joined: Sat May 01, 2004 4:23 am
Location: Dallas, Texas
Contact:

Post by pingz » Fri Aug 20, 2004 6:28 am

Speaking of lots of objects, the new instancing feature of DX9 is now supported for ATI cards:

http://www2.ati.com/drivers/catalyst_48 ... 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?
0 x

User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
Contact:

Post by tuan kuranes » Fri Aug 20, 2004 11:03 am

A technical demo of instancing is here :

http://esprit.campus.luth.se/~humus/3D/index.php

(with source code)
0 x

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

Post by sinbad » Fri Aug 20, 2004 2:15 pm

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

pingz
Gnoblar
Posts: 10
Joined: Sat May 01, 2004 4:23 am
Location: Dallas, Texas
Contact:

Post by pingz » Fri Aug 20, 2004 6:36 pm

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

pingz
Gnoblar
Posts: 10
Joined: Sat May 01, 2004 4:23 am
Location: Dallas, Texas
Contact:

Post by pingz » Fri Aug 20, 2004 6:57 pm

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

User avatar
Robomaniac
Hobgoblin
Posts: 508
Joined: Tue Feb 03, 2004 6:39 am

Post by Robomaniac » Mon Aug 23, 2004 8:14 am

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

My Webpage

User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster » Mon Aug 23, 2004 9:21 am

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

User avatar
SpannerMan
Gold Sponsor
Gold Sponsor
Posts: 446
Joined: Fri May 02, 2003 10:05 am
Location: UK
Contact:

Post by SpannerMan » Mon Aug 23, 2004 6:05 pm

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

pingz
Gnoblar
Posts: 10
Joined: Sat May 01, 2004 4:23 am
Location: Dallas, Texas
Contact:

Post by pingz » Mon Aug 23, 2004 6:27 pm

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

AssiDragon
Greenskin
Posts: 145
Joined: Wed Apr 28, 2004 12:10 pm
Location: Hungary
Contact:

Post by AssiDragon » Mon Aug 23, 2004 6:50 pm

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)
0 x
Hope is the first step on the road to disappointment.

pingz
Gnoblar
Posts: 10
Joined: Sat May 01, 2004 4:23 am
Location: Dallas, Texas
Contact:

Post by pingz » Mon Aug 23, 2004 8:39 pm

Actually i do not believe the Geforce FX cards support it... only the new Geforce 6 cards.
0 x

User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster » Tue Aug 24, 2004 2:04 pm

For what it's worth, you can get the source code for this from here;
http://www.green-eyed-monster.com/GroundCover.h
http://www.green-eyed-monster.com/GroundCover.cpp

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!
;)
0 x

User avatar
psyclonist
OGRE Expert User
OGRE Expert User
Posts: 286
Joined: Fri Nov 01, 2002 3:54 pm
Location: Berlin & Nuremberg, Germany
Contact:

Post by psyclonist » Tue Aug 24, 2004 3:12 pm

Great work, monster! I'll definitely play around with that one!

-psy

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

User avatar
Robomaniac
Hobgoblin
Posts: 508
Joined: Tue Feb 03, 2004 6:39 am

Post by Robomaniac » Wed Aug 25, 2004 5:49 am

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 :\
0 x
phear hingo

My Webpage

nfz
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 1263
Joined: Wed Sep 24, 2003 4:00 pm
Location: Halifax, Nova Scotia, Canada

Post by nfz » Wed Aug 25, 2004 5:59 am

:shock:
0 x

User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster » Wed Aug 25, 2004 6:09 am

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

User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
Contact:

Post by Azatoth » Wed Aug 25, 2004 11:01 pm

Very, very nice Monster! I plugged it into Dime just to see how our grass would look. Not too shabby. :)
Image

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

User avatar
monster
OGRE Community Helper
OGRE Community Helper
Posts: 1098
Joined: Mon Sep 22, 2003 2:40 am
Location: Melbourne, Australia
Contact:

Post by monster » Thu Aug 26, 2004 2:17 am

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.

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

User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
Contact:

Post by Azatoth » Thu Aug 26, 2004 12:12 pm

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

User avatar
dennis
Gremlin
Posts: 154
Joined: Mon Nov 11, 2002 4:21 pm

Post by dennis » Thu Aug 26, 2004 5:21 pm

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

Post Reply