Regarding GL profiling

Sage
Posts: 1,199
Joined: 2004.10
Post: #46
Frogblast Wrote: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.

Tomorrow I'll write up some OC code to better get an idea of what kind of overdraw I've got.

That being said, It's looking a lot like some sort of early z-pass/fail situation is being short circuited here and that's why my performance is tanking. I'm going to try depth sorting ( shudder ) and see how that turns out.
Quote this message in a reply
Member
Posts: 45
Joined: 2008.04
Post: #47
I note from one of your earlier messages you said "visibleDrawingPatches: 141".... sorting a mere 141 things isn't going to hurt performance :-)

In past grass implementations I've worked on, we sorted and drew blended(src_alpha,on_minus_src_alpa) with no alpha test... and performance didn't tank through overdraw until after the grass height was around 25% of the screen height - though our shaders were a lot simpler than yours.

ps I still haven't sorted out this mouse thing with your demo, even after pluggin my ol' mighty mouse back into the keyboard... puzzling..
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #48
aBabyRabbit Wrote:I note from one of your earlier messages you said "visibleDrawingPatches: 141".... sorting a mere 141 things isn't going to hurt performance :-)

In past grass implementations I've worked on, we sorted and drew blended(src_alpha,on_minus_src_alpa) with no alpha test... and performance didn't tank through overdraw until after the grass height was around 25% of the screen height - though our shaders were a lot simpler than yours.

Well, I gotta sort the quads inside each patch, too! But it's not going to be too bad.

Quote:ps I still haven't sorted out this mouse thing with your demo, even after pluggin my ol' mighty mouse back into the keyboard... puzzling..

I made some changes to my HID code to pretend all attached mice are one single mouse. For my tests ( a MBP with an attached mouse ) it worked. But, well, nothing's ever right the first time Annoyed
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #49
Good news, everybody!

I made some big changes.

First: I went to depth-sorted no-depth-writes rendering. I was able to turn off GL_ALPHA_TEST and in general it looks not just good, but better than before since I have proper alpha blending now.

Second: I had to break one of my rules for this codebase. I've strived for general purpose, flexible code since the start. No special case, etc. However, I can't do multi-pass lighting of the foliage if I'm not writing to the depth buffer, so I broke my own rules and special cased the foliage to only render for one light, and to perform lighting for that one light in one pass.

I still have some fill-rate problems, but they're independent of the texture being used. So I'm not seeing that wacko performance drop switching between the debug texture and the foliage. Hopefully, further streamlining of the GLSL will help here.

BTW -- & amazingly -- depth sorting has no performance hit for me. The patches only hold a few hundred quads each, which is quick to sort. And the patches themselves are coarsely depth-sorted by the scene graph since they're marked as non-opaque. So there's not that much sorting actually going on.

[Image: Terrain-2009-07-02-01.png]

NOTE: I need to come up with a better algorithm to pick random points on the surface of a triangle. The distribution has obvious artifacts.

Currently I'm using the following code to pick a random point:
Code:
inline vec3 randomPointOnTriangle( const physics::TrimeshTriangle &tri )
{
    vec3 v = lrp( _rng.rangef( 1.0f ), tri.b, tri.c );

    // NOTE: we're biasing the value towards 1 to prevent clustering at 'a'
    float r = _rng.rangef( 1.0f );
    return lrp( 1.0f - r*r, tri.a, v );
}

If anybody knows a fast way to get a robustly random point without clustering let me know!
Quote this message in a reply
Member
Posts: 45
Joined: 2006.07
Post: #50
http://mathworld.wolfram.com/TrianglePointPicking.html

Your triangle has vertices v0, v1, v2, with v0 equal to the origin. Pick 2 random numbers s, t in [0, 1]. Then your random point is
[INDENT]p = s*v0 + t*v1[/INDENT]
If p is not in the triangle, then you can discard it or mirror it about the line from v0 to v1. To sample over many triangles, sample from each triangle with propability proportional to its area.
Quote this message in a reply
Sage
Posts: 1,482
Joined: 2002.09
Post: #51
Although does that have a random distribution over the triangle if it's not a right triangle? It seems to me that it wouldn't but I'm not sure how to prove it.

Scott Lembcke - Howling Moon Software
Author of Chipmunk Physics - A fast and simple rigid body physics library in C.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #52
mattz Wrote:http://mathworld.wolfram.com/TrianglePointPicking.html

Your triangle has vertices v0, v1, v2, with v0 equal to the origin. Pick 2 random numbers s, t in [0, 1]. Then your random point is
[INDENT]p = s*v0 + t*v1[/INDENT]

Thanks -- this is exactly what I need.

mattz Wrote:If p is not in the triangle, then you can discard it or mirror it about the line from v0 to v1. To sample over many triangles, sample from each triangle with propability proportional to its area.

I already bias my sampling by triangle area! What do you take me for? LOL
Quote this message in a reply
Member
Posts: 59
Joined: 2007.12
Post: #53
Shouldn't it be

p = s*(v2-v0) + t*(v1-v0)

instead? Makes more sense to me. Also you can get new numbers if s+t>0.5.
Quote this message in a reply
Member
Posts: 45
Joined: 2006.07
Post: #54
yup. apologies. the linked article is much clearer than i was.
Quote this message in a reply
Member
Posts: 45
Joined: 2008.04
Post: #55
Looking good TomorrowPlusX, now any chance of another demo???

- we likes demos...
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #56
Sure -- I *may* have solved the input issue I was having, and as of this morning i have the distribution density modulated by 3d perlin noise, so it looks more "organic" and less like a carpet. Plus, I figrued out how to mix billboarded and crossed foliage into one shader so I can draw foliage and bushes in a single draw call. That's a performance boost.

I'll put up the binary when I get home.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #57
OK, the app is updated.

http://shamyl.zakariya.net/etc/gl/TerrainDemo.zip

I hope the crash ThemsAllTook saw is fixed. I updated to DDHidLib 1.1, and tried to make my usage of that lib more defensive. :/

Again, use arrow keys to drive. If/When you roll over, hit backspace to flip. Finally, a gamepad might work. Mine does, but I haven't written a fancy button configurator, so it's a crapshoot.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #58
Dunno what you are doing, but this seems worse than the last demo. http://monkeyinthejungle.net/stuff/tpx-screenie.png

Is that supposed to look like that? Also, the app now uses 100% CPU @30fps, but the GPU isn't even at 50% core utilization.
Quote this message in a reply
Sage
Posts: 1,199
Joined: 2004.10
Post: #59
Awesome Cry

What kind of hardware do you have? I rewrote my shader a bit from the last to this one, and, well, I must have done something that doesn't work on your GPU and instead runs on the CPU.

On my machine, a 2006 MBP, it runs between 50% and 90% CPU and a solid 30fps. I've got an ATI x1600.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #60
It's a 2007 MBP, 2.4GHz Core 2 Duo with a GF8600M
Quote this message in a reply
Post Reply