If we try rendering 100000 grassholms(dunno how it’s written) something like instancing may be very usefull as it’s a simple and elegant trick.
u mean like
http://uk.geocities.com/sloppyturds/nelson/2005_01_12.jpg
unfortunatly as ppl are demanding more from apps, leaves blades standing up in the air, aint really as acceptable as they once were, so unless u do some non basic physics this will rule out the use of instancing for your grass
In a sample I wrote for work I get 108fps with real instancing, 103fps with shader constant based and 22fps with a naive one instance per call implementation.
Define “real instancing”. Did you write a D3D app that used D3D instancing, or did you use the GL hack? Unless you’re actually testing D3D instancing (and on hardware that supports it), we don’t know how fast this app truly can be.
unfortunatly as ppl are demanding more from apps, leaves blades standing up in the air, aint really as acceptable as they once were, so unless u do some non basic physics this will rule out the use of instancing for your grass
If you need moving grass (why, I don’t know, but if you do), it’s simple. Use 2 instance attributes: one on the ground and one for the stalk. Then generate the vertices in the vertex shader via a simple spline between the two points. This may make things vertex bound on modern cards, but on more advanced ones (with greater processing power), it will again be transfer bound.
Alternatively, instead of a spline, and doing vertex generation, you could also send a single-float parameter (coupled with the 3-vector blade position) that pushes the grass in a pre-defined direction (the direction of the wind). It just does a bias to the vertex coordinate based on the value of this parameter. It’d look very good, but not perfect. But, it’d be a much simpler shader as well as taking up fewer attributes.
Or, if you want to keep the shader simpler, just pass a direction for the up of the stalk, thus allowing you to create moving, but non-bending, blades of grass.
Oh, and we don’t have games nowadays that show decent quantities of grass. It always ends somewhere (even in your picture). Imagine having grass all the way out to the horizon. I would prefer static alpha-tested flatcards of grass that went on forever than highly-detailed physically based grass that stopped after 20 feet. Until we get grass going out to the horizon, physics should be far from our thoughts.
My point, Korval 
If you need moving grass (why, I don’t know, but if you do), it’s simple.
look at shrek etc the grass is typically animated, see how much better it looks than static grass, even grass demos eg speedtree (which looks better? with the grass moving or static) and speedtree does a really crappy job of its animation, imagine how much better it would look using proper bones!
the problem with lots of bones in the vertexshader (thats if it compiles under the limits) is u need to redo it for every rendering pass when u do it on the cpu u do it once and thats it.
the reason im insterested in instancing is, ive been working a lot with vegetation over the last couple of years and would have more than most to ‘gain’ from instancing, yet i dont want it!
Still don’t get the objections. I’ve always assumed it was a matter of ‘when’ the instancing mechanism is proposed rather than ‘if’.
It’s uses seem obvious. Saving memory, saving bandwidth, saving CPU overhead. Scale the performance benefits up to the demands in a few years and you see that it’s obviously going to be needed in the future, so why wait till it’s absolutely needed? Introduce it now, and lets play with it. The hardware’s there. Can’t one of the vendors expose it in an extension for now?
Stick shader attributes in the low frequency stream and interesting things become possible. Combine it with render-to-vertex array and bizarre ideas may emerge. But don’t introduce it now, and risk the same frenzy of demand that the ARB suffered when developers absolutely ‘needed’ render targets.
But don’t introduce it now, and risk the same frenzy of demand that the ARB suffered when developers absolutely ‘needed’ render targets.
I’m not going to argue for or against instancing. However, I do want to point this out as a crappy analogy. Render targets enable new functionality where as instancing enables new optimization. There’s a big, big difference.
look at shrek etc the grass is typically animated, see how much better it looks than static grass, even grass demos eg speedtree (which looks better? with the grass moving or static) and speedtree does a really crappy job of its animation, imagine how much better it would look using proper bones!
It’s window dressing; it is, by definition, unimportant. The reason we want to put it into instancing is so that we can spend as little time on it as we can get away with while still providing some visual quality improvement.
Unless, of course, you’d rather we just had a flat texture on the ground?
If you can spare the extra performance for moving grass in your application, sure. If not, don’t; it won’t kill anyone, and hardware will get to the point where it can handle it.
BTW, even with infinite performance, I would never apply skinning to blades of grass. At the most, I would use some kind of spline curve and generate the vertices in the shader.
the reason im insterested in instancing is, ive been working a lot with vegetation over the last couple of years and would have more than most to ‘gain’ from instancing, yet i dont want it!
That’s an interesting contradition. You’re interested in instancing, you acknowledge that it could help you, but you specifically choose not to want it. Well, that’s your perrogative, as long as you understand the inhierent irrationality of your position.
Render targets enable new functionality where as instancing enables new optimization. There’s a big, big difference.
The difference between functionality and performance is not as big as you might think. We would consider, say, rendering lots of grass to be “functionality”. That is, some kind of visual effect that couldn’t be done on earlier hardware. However, it is only made possible by performance; in this case, the performance of drawing massive quantities of instances.
What this means is that, eventually, only D3D games will see the kinds of visual quality that instancing will provide. Just like only D3D games can provide the kinds of visual quality that RTT provides.
Originally posted by idr:
Render targets enable new functionality where as instancing enables new optimization. There’s a big, big difference.
That seems quite narrow minded, no offense idr.
It’s late, I’m running out of steam…if you can render to a vertex buffer, then it seems odd to me that a mechanism for controlling the frequency at which that vertex buffer is sampled is not seen as providing additional functionality.
In addition - render-targets offer no new functionality, everything that can be done with render targets can be already be done with framebuffer copies…but obviously at a much greater cost. So it could be regarded as an optimisation too.
BTW, even with infinite performance, I would never apply skinning to blades of grass. At the most, I would use some kind of spline curve and generate the vertices in the shader.
perhaps ive explained it badly
the evolution of a grass field with computer hardware.
level0 - plain texture with grass on it
level1 - grass blades
level2 - basic animated blades
level3 - slightly more basic animated blades (due to instancing)
level4 - grass blades with a pretty realistic physics simulation
today im at level4 running on my computer in realtime with many thousands of blades, why on earth should should i step back to level3, ok the fps might go up but the visual quality will go down, hell if thats an excuss i might as well go back to level0 it might look like crap but it runs at 1000fps 
youre thinking to shortterm, remember 3-5years ago (i forget exactly when) stencil shadows were ‘the thing’ now look at them dead, im 99% suredoom3 would never of used them if it hadnt of been delayed until 2004.
today im at level4 running on my computer in realtime with many thousands of blades, why on earth should should i step back to level3
Because all you’re rendering is grass. When you’re running something that might like to have the lion’s share of the CPU, you’ll find that accurate physics simulations for things that, ultimately, don’t matter are irrelevant and inappropriate.
If you can spare your entire CPU and GPU to grass, great; you don’t need instancing. For those of us who would like to make things go faster so that we can do other things with out processor, we need instancing.
More importantly, you’re ignoring the fact that having the grass go out to the horizon is more important to the illusion than having 15 feet of moving grass.
youre thinking to shortterm, remember 3-5years ago (i forget exactly when) stencil shadows were ‘the thing’ now look at them dead, im 99% suredoom3 would never of used them if it hadnt of been delayed until 2004.
Your general lack of proper grammar, punctuation, and capitalization make this statement somewhat difficult to understand. Trying to find where sentences begin and end is difficult at best. Are you saying that stencil shadows are “dead” for some reason, and that there was a heyday of them 3-5 years ago? And that, if Doom3 had been released earlier, that it wouldn’t have used them?
I don’t understand how any of that makes sense.
In any case, long-term, instancing becomes more important, not less. Your “physics simulation” will eventually fully reside in the vertex shader (thus alieviating the CPU completely, which now makes it worthwhile from a game standpoint). And vertex shader performance increases much faster than bandwidth for transfering vertices and CPU performance. As such, the vertex shader will eventually not be the bottleneck, and it will go back to being the bandwidth and CPU cost of vertex transfer.
Nowadays, the limits on useful instancing tend to be around 100 vertices and maybe 6-opcode shaders. In the future, it could be 300 vertices and 12-opcode shaders. After that, maybe 500 verts and 24-opcodes. And so forth.
Originally posted by Korval:
Define “real instancing”. Did you write a D3D app that used D3D instancing, or did you use the GL hack? Unless you’re actually testing D3D instancing (and on hardware that supports it), we don’t know how fast this app truly can be.
Of course I’m talking about instancing in D3D using SetStreamSourceFreq() when I say “real instancing”. That compared to the alternative method I’ve described, “shader constant instancing”.
Originally posted by Korval:
Because all you’re rendering is grass. When you’re running something that might like to have the lion’s share of the CPU, you’ll find that accurate physics simulations for things that, ultimately, don’t matter are irrelevant and inappropriate.
If you can spare your entire CPU and GPU to grass, great; you don’t need instancing. For those of us who would like to make things go faster so that we can do other things with out processor, we need instancing.
http://steampowered.com/status/survey.html
the most compreshensive survey of user hardware on the net, ppl often have powerful cpu’s compared to their graphics cards
More importantly, you’re ignoring the fact that having the grass go out to the horizon is more important to the illusion than having 15 feet of moving grass.
there u go again making th same FALSE anology u made with the bricks,
say im drawing the grass to the range of 100m, now to reach the hoirzon 1km away, i need to draw 100X as much grass, are u saying instancing will help me do this, no it wont at most itll let me draw an extra 20m, ie bugger all.
Your general lack of proper grammar, punctuation, and capitalization make this statement somewhat difficult to understand. Trying to find where sentences begin and end is difficult at best. Are you saying that stencil shadows are “dead” for some reason, and that there was a heyday of them 3-5 years ago? And that, if Doom3 had been released earlier, that it wouldn’t have used them?
sorry unfortunatly(fortunatly) my mind is always ruuning as a thousand miles an hour, i find it very difficult to write easy to understand sentences, what i mean to say is basically stencil shadows were big a few years ago, lots of demos, new extension(s) for gl etc, now look at it, gone! never to be seen again, a passing fad.
In any case, long-term, instancing becomes more important, not less. Your “physics simulation” will eventually fully reside in the vertex shader (thus alieviating the CPU completely, which now makes it worthwhile from a game standpoint). And vertex shader performance increases much faster than bandwidth for transfering vertices and CPU performance. As such, the vertex shader will eventually not be the bottleneck, and it will go back to being the bandwidth and CPU cost of vertex transfer.
i recently removed all my vertex shader calculations to the cpu, why? it ran a lot quicker, u just need to calculate it once on the cpu, whereas with the vertexshader each time u render the geometry it needs to be recalculated again
Sorry for the off topic of this, but…
Originally posted by zed:
what i mean to say is basically stencil shadows were big a few years ago, lots of demos, new extension(s) for gl etc, now look at it, gone! never to be seen again, a passing fad.
Are they? why? I understand they were fillrate eaters and such, but… they had a big advantadge, in theory the method was robust. I havent seen a paper saying “Robust shadowmaps with _put_your_favourite_projection_here and paraboloid maps and whatever”
What i mean is, i still haven’t seen a method that guaranties no jaggies in shadowmapping shadows, for example (that is, a general and fast solution). But of course i can be totally wrong (wouldn’t be the first time hehe).
So if i am wrong, could somebody point me to those papers that are killing the stencil shadows? I was going to implement stencil shadows due the robustness as i can’t be tweaking with light positions and such to avoid aliasing, but if that
aliasing can be avoided (that is a general and robust solution for shadowmaps without aliasing), well, i would go the trough the shadowmap technic.
Thanx in advance
*note i never implemented stencil shadows (cause of there flaws) but this is my understanding
*stencil shadows require a lot more work per vertex, look at doom3, the models aint really more tesselated than quake3, now if shadowmaps were used then the number of polygons is not so important, ie if doom3 used shadowmaps then it wouldnt be known as the attack of the pointy heads, thus shadowmaps scale better
*stencil shadows require closed meshes thus u cant throw any mesh at it and expect it to work, with shadowmaps everything works
*stencil shadows dont handle allpha tested polygon eg a grill texture, shadowmaps do.
shadowmap cons,
- hardware support for shadowmaps is less than stencilshadows
- they require multiple renders to do pointlights (this scares a lot of ppl off i believe)
- these renders though are typically very quick cause practically everything is disabled, ie u only want to render the depth information. cards today handle many millions of triangles
- jaggies, can be lessened by upping the shadowmap resolution, also there are various methods proposed to get a better ratio of screen to shadowmap space, eg psm, tsm, lispsm. ive only tried to do the first one psm (gotta say i failed to implement it though)
an another method is to create soft shadow edges one way by combining offset shadowmaps
Of course I’m talking about instancing in D3D using SetStreamSourceFreq() when I say “real instancing”. That compared to the alternative method I’ve described, “shader constant instancing”.
So you have, in fact, written an app that tests D3D instancing vs. the OpenGL alternatives. I’d like to see this app.
Oh, and how does nVidia hardware perform on it?
say im drawing the grass to the range of 100m, now to reach the hoirzon 1km away, i need to draw 100X as much grass, are u saying instancing will help me do this, no it wont at most itll let me draw an extra 20m, ie bugger all.
It’s better than not having that extra 20m.
i recently removed all my vertex shader calculations to the cpu, why? it ran a lot quicker, u just need to calculate it once on the cpu, whereas with the vertexshader each time u render the geometry it needs to be recalculated again
Your application draws grass. In a game situation, grass is irrelevant; it’s a visual effect. It doesn’t deserve spending time on it, so nobody multipasses on their grass. It isn’t included in shadow volumes or shadow maps. As such, there’s no problem with putting it into the vertex shader.
[ OT ]
stencil shadows dont handle allpha tested polygon eg a grill texture, shadowmaps do.
I have yet to see an implementation of shadow mapping that would handle that either. Oh, it would in theory, with an infinitely large shadow map. But, in the real world, even a 2048x2048 or 4096x4096 shadow map doesn’t pick up details like grill textures and so forth.
this scares a lot of ppl off i believe
No, what scares people away from shadow maps is that nobody’s found a solution that makes virtually all cases look good. There are ways to make some cases look better, but there’s no known generic solution that you can plug in and have work.
I like the idea of shadowmaps. It scales better in the number of lights to stencil shadows. But, when it comes down to shipping a polished, professional product, you just can’t put up with the artifacts. So I don’t blame people for using stencil shadows.
Your application draws grass. In a game situation, grass is irrelevant; it’s a visual effect. It doesn’t deserve spending time on it, so nobody multipasses on their grass. It isn’t included in shadow volumes or shadow maps. As such, there’s no problem with putting it into the vertex shader.
following your schizophrenic reasoning, since grass is an ‘effect’ u dont need all the (*)grass blades in fact youre better off doing a grass textured quad, so why do u need instancing? youve dug yourself into a hole there korval. i dont expect u to admit youre wrong though bay, after 1991 posts if it hasnt yet happened it most likely wont happen
http://uk.geocities.com/sloppyturds/nelson/richmond.html
though its difficult to see from a static screenshot ( u can notice it a bit in the second screenshot) having moving grass etc adds so much more to a scene’s realism compared to static grass
I have yet to see an implementation of shadow mapping that would handle that either. Oh, it would in theory, with an infinitely large shadow map. But, in the real world, even a 2048x2048 or 4096x4096 shadow map doesn’t pick up details like grill textures and so forth.
check the screenshot 2005_01_05 on my page (256x256 sized depth texture), the dome is solid with a alpha texture on it
following your schizophrenic reasoning, since grass is an ‘effect’ u dont need all the (*)grass blades in fact youre better off doing a grass textured quad, so why do u need instancing?
If it takes only 5% of your overall performance (and as little precious CPU time as possible) to render large quantities of grass and other “window dressing” effects, then it is worthwhile to try. However, the problem is that, without instancing, it never will be (or it will be much later than it could). In the most optimal case, the hardware probably can render lots of grass in 5% or less. However, if we can’t access that hardware, if we’re forced to use brute-force methods, then we will take longer to get there.
No, you can still use just a flat texture. But if you can make more realistic representations of grass take up trivial quantities of performance, then it is no longer unreasonable to use those methods. After all, if real grass only took 2x the performance of flat textured grass, why not just do the real thing. Instancing is a mechanism for lowering the performance of such window dressing to the point where it becomes more reasonable to use.
The point my statement was trying to make was that, because it is an optional “effect”, because it is window dressing, you don’t apply things to it like shadowing (or, at least, rendering volumes or maps. They could still use the shadow texture to determine if they were in shadow) or anything that makes it take any longer than it absolutely needs to.
having moving grass etc adds so much more to a scene’s realism compared to static grass
I never said that having moving grass was a bad idea. Clearly, moving grass is preferable to static grass. It is simply a question of what one can afford. Instancing is a method for being able to make what was once unaffordable (but theoretically doable on the hardware) now affordable. Much like VBO’s allow you to now use bigger meshes, instancing allows you to use lots of small ones.
Can’t one of the vendors expose it in an extension for now?
I don’t know but maybe there are legal issues.
As far as what idr said, it’s better to argue that render targets is likely to be more needed than instancing.
PS: I’m not arguing against instancing. It would be nice to see it in action in GL.
>So? He still reached near theorethical maximum >performance with currently available APIs. What >more do you need? Instancing can’t make it go >faster than the hardware …
But it cleanning all this glBegin / glEnd / glPointer/ glArray* /glCallList / glVertex / glNormal / glTexCoord / glMatrix, glPush*, glPop*, glDraw*[Indexed], glShader, … (very complex and old) API stuff !!!
For the driver, the hardware, the devellopper and the final user, it is a good hack / optimisation / advance for the next generation …
And on my 400 Mhz PocketPC, this give me more time for raytrace the scene with more triangles 
I haven’t implemented the div/modulo great hack until now but this seem to be a cool thing for my gl2999 API
But it’s true, OpenGL is an HARDWIRED library …
Very good hardware, but badly used …
@+
Cyclone
Concerning instancing, NVIDIA’s SDK8.5 has an example and PDF discussing it. Here is the link:
http://download.developer.nvidia.com/developer/SDK/Individual_Samples/samples.html
(scroll down to Pseudo Instancing)
It seems that GL doesn’t need instancing after all.