Quote:Also, GL Profiler shows you seem to have too many state changes, and a lot of glVertex calls which you should also get rid off.

I will have to look into the state changes; but I can say right now that I only call glVertex in my UI drawing. Everything else in the scene ( terrain, rubble, car, skydome, foliage ) are drawn via VBOs.

aBabyRabbit Wrote:Interesting demo, lots of "how does he do it questions", but first I have a more important dumb user question: how to change the two toggles at the top of the screen? When I mouse over I see a darker bar temporarily under the options, but no amount of mouse clicking or dragging lets me actually change them....

For me, and for the few computers I've tried this on, clicking on the text toggles them. The only thing I can imagine that's wrong is that for some reason the mouse position isn't being read correctly. The underline bar shows up when you mouse-over the text, right? And goes away when you mouse out? But nothing happens when you click? I've never seen that...

I thought alpha test was a given for performance speedup. Well, I turned it off and performance went up from 20's to solid 30. But the rendering output is not acceptable.

I tried throwing `discard` into the GLSL, but not surprisingly the performance tanked.

Quote:2) Can you use occlusion queries to count the total number of your pixels covered by the foilage? (disable alpha test and depth testing when performing this test). How does this compare to the number of pixels in the whole framebuffer?

DoG Wrote:I find it a bit odd that the performance on the X1600 and GF8600 is about the same. I have the impression that you are doing something very wonky syncing drawing to your physics simulation.

Here's my game loop.

Code:

void
DisplayDelegate::update( void )
{
if ( _animating )
{
//
// Update time and find out how much time
// has elapsed since last call to ::update
//
// Then add whatever was left over from last iteration.
//

TomorrowPlusX Wrote:For me, and for the few computers I've tried this on, clicking on the text toggles them. The only thing I can imagine that's wrong is that for some reason the mouse position isn't being read correctly. The underline bar shows up when you mouse-over the text, right? And goes away when you mouse out? But nothing happens when you click? I've never seen that...

Same problem here. It underlines when I roll onto it, but doesn't respond to clicks. I tried clicking around the bottom part of the window in case the coordinates were vertically flipped, but no luck there (and it wouldn't even make sense, since it's detecting the bounds on mouseOver). MacBook Pro (early 2008), 10.5.7, GeForce 8600M GT

TomorrowPlusX Wrote:EDIT: I switched to a 0.0 time interval for giggles, since 1/1000 seemed arbitrary and dumb.

Not to stray off-topic, because I know you're focusing on the issue at hand, but: According to Apple docs 1/1000 is one of the techniques recommended for that purpose. Also, after my own testing, switching to 0.0 yields 1 kHz regardless, so apparently that's what the timers are capped at. So yeah, I guess 0.0 makes no difference anyway. The only thing I'd stick to 1/1000 for is that if Apple for whatever reason decided to raise their internal cap to something higher, then 1 kHz works fine so why waste even more? (yeah, I know, like as if that's ever going to happen, but still, it's the thought that counts I guess...)

ThemsAllTook Wrote:Same problem here. It underlines when I roll onto it, but doesn't respond to clicks. I tried clicking around the bottom part of the window in case the coordinates were vertically flipped, but no luck there (and it wouldn't even make sense, since it's detecting the bounds on mouseOver). MacBook Pro (early 2008), 10.5.7, GeForce 8600M GT

I was just at the gym, thinking about this and it occurred to me that you might be using an external mouse connected to your MBP? Is this the case?

I switched from normal NSEvent filtering for input a while back to DDHIDLib; but and large it's been a real boon, but I only handle the zeroth input device of each type. E.g., the first mouse of N mice. The first keyboard of N keyboards, etc.

It occurrs to me that that might be what's going on here. The external mouse is moving the single global mouse cursor -- so I get the mouse over effects correctly -- but the button events are keyed to mouse #1, not zero, so I never catch them.

EDIT: I was -- sort of -- able to reproduce by plugging in an external mouse. In my case, however, the external mouse works correctly but the trackpad's motion is processed but not the clicks. So, I'm guessing you can unplug the external mouse to make the buttons work correctly. Meanwhile, I'll experiment with a best way to handle this situation.

@AnotherJake -- I recall now that that's why I was using 1/1000 -- I generally comment my code well, but I really should mark the reasoning behind magic numbers. Also, I've considered displaylink, but I'm concerned that it's running in its own thread. I don't want to have to worry about synchronizing between a render thread and the general game loop.

(Of course, I might be wrong about display link being threaded, but that's what I gathered from examination of the docs )

TomorrowPlusX Wrote:Also, I've considered displaylink, but I'm concerned that it's running in its own thread. I don't want to have to worry about synchronizing between a render thread and the general game loop.

(Of course, I might be wrong about display link being threaded, but that's what I gathered from examination of the docs )

You might be right about displaylink being on another thread. My game update is usually completely separate so I didn't have issues while testing, and it's been so long since I tested it that I don't recall... and too lazy to check the docs right now

Technically, rendering should be non-mutating so rendering in a dedicated thread should be fine.

But the trouble is that changes to game state -- such as a moving camera or moving entities -- would mutate the visibility set possibly while it's being iterated to render. And a million other things. So I've stayed shy of it...

That is very true. Definitely not a trivial task to keep everything synchronized correctly, and the stuff you've built up over the years is far more complex than what I've been doing graphically. There are only a few times when I've really seen multiple threads help anyway - physics being a good example (specifically the collision detection). But that's another subject for another day.

An interesting performance detail I just noticed. It's not disabling alpha test specifically, but rather, commenting out setting of the glAlphaFunc per draw-call that's the culprit.

EDIT:
I take it back, it's having a non-zero test which causes the performance hit.

So, per draw call I set the alpha func threshold as such:

Code:

glAlphaFunc( GL_GREATER, lrp( _visibility, 1.0f, AlphaFuncMin ));

This ramps from 1.0 to 0.8 as visibility goes from 0->1 -- allowing for slightly smooth transition from as foliage enters the visibility radius. I noticed that setting the func to (GL_GREATER, 0) gives me a rock solid 30fps! Setting it to (GL_GREATER, 0.5) gives me performance like what I'm seeing.

Out of curiosity, I tried dropping GL_ALPHA_TEST for calling 'discard' in GLSL, but as expected, the performance was terrible.

So, what are my options? I don't know that I want to depth sort my foliage...

I'd be interested in seeing the Occlusion Query results. It might be possible to use discard/alpha test, but if you're just drawing Too Many Pixels, then you're next course of action is probably to try to coalesce far-away pieces of grass into a single quad, so you can draw multiple neighboring pieces of grass with as little overdraw as possible.