I was wondering if it was possible to cut not only rectangular areas of GL space like Kineme GL Scissor do? Also I recognized that it's rotation independent... Any ideas?
You can't do this using Scissor (GL defines Scissoring to only operate on axis-aligned rectangular regions). You can do it with a fragment shader though.
Using a gl triangle that's the same as whatever your background color is should be able to get the same basic effect.... the glsl route that cwright suggests is a good one as well.
What I mean is, if you use a GL Scissor, or GL Clip plane, it's the same visual result as it would be if you laid out a sprite (or multiple sprites) with no depth testing, on top of your geometry layers that comprise your scene.
So, if you put a triangle on top of your scene, no depth testing, then the triangle will always draw on top, and cut out the other stuff. If it's the same color as your clear, it should look like there's nothing rendering in that triangle area. At that point, it should look like you have a triangle GL Scissor working (with no rotation like GL Clip though).
The bad news about this approach is that it burns fillrate. Scissoring actually prevents per-pixel work from being done, so it's much more efficient than drawing everything and then drawing over the stuff you didn't want to draw in the first place. scissoring, viewport tweaks, and clip planes will prevent extra work from happening (clip planes have some overhead, but not as much as actual drawing).
Agree/absolutely. Scissoring and clip planes are better than drawing geometry. I see fps benefits when using them, whereas with drawing geometry, you're doing more, not less. My suggestion was from the standpoint of visual end result.
I think drawing geometry is probably equivalent to your shader suggestion, and better or worse of an alternative depending on context. What's your opinion on that one? How would one test that actually (the dif in performance)?
Yep, totally knew you were coming from the "gets the right output" camp :) Just filling in more details so people who are OCD about doing things nicely can be more informed :)
gtoledo3 wrote: I think drawing geometry is probably equivalent to your shader suggestion, and better or worse of an alternative depending on context. What's your opinion on that one? How would one test that actually (the dif in performance)?
Visually, the output should be the same.
Except for drawing more stuff, the shader culling method should be a last-resort. if you discard fragments, you prevent the data from being written, which is a tiny savings, but you still have to execute the shader for each eligible pixel to know if it should be discarded or not (still expensive). drawing geometry means the shader doesn't have to discard [it still can though, but if it did you wouldn't need the extra draw-to-simulate-clipping stuff] -- so you'll spend the write bandwidth, and whatever complexity the pixel shader incurs, plus the cost of to "clipping" geometry to hide the fact that you drew it.
Testing would require measuring performance; it's also highly driver/GPU dependent. Some drivers/GPUs will do clever stuff when you have a discard early in the shader (before the hard work -- texel fetches and whatever), so the discard trick will be a win. Others simply use the discard as an operation that gets passed to the ROPs (similar to other blend modes: over, sover, add, etc; discard just becomes "noop", so you pay for everything but the final write, which isn't a big savings).
ATI at one point had their fragment processors work in groups of 2x2 pixels (4 pixels at a time) -- if all of them did or didn't do discards, they'd be efficient, otherwise it'd do the full amount of work, and then manually mask the results in the ROPs, iirc. I don't know if that's still the case, or if there's a similar model still in use (and I have absolutely no idea how nvidia handles these things) -- in that case, clipping in the fragment program can be much cheaper (because huge regions of pixels will have similar paths).
Actually I can show what I've meant under it. This is a composition for a projection pyramid Cheoptics360. I want to get no intersections on different faces i.e. cropping of each 'teapot' on it's own projecting face.
You can't do this using Scissor (GL defines Scissoring to only operate on axis-aligned rectangular regions). You can do it with a fragment shader though.
Using a gl triangle that's the same as whatever your background color is should be able to get the same basic effect.... the glsl route that cwright suggests is a good one as well.
What I mean is, if you use a GL Scissor, or GL Clip plane, it's the same visual result as it would be if you laid out a sprite (or multiple sprites) with no depth testing, on top of your geometry layers that comprise your scene.
So, if you put a triangle on top of your scene, no depth testing, then the triangle will always draw on top, and cut out the other stuff. If it's the same color as your clear, it should look like there's nothing rendering in that triangle area. At that point, it should look like you have a triangle GL Scissor working (with no rotation like GL Clip though).
The bad news about this approach is that it burns fillrate. Scissoring actually prevents per-pixel work from being done, so it's much more efficient than drawing everything and then drawing over the stuff you didn't want to draw in the first place. scissoring, viewport tweaks, and clip planes will prevent extra work from happening (clip planes have some overhead, but not as much as actual drawing).
Agree/absolutely. Scissoring and clip planes are better than drawing geometry. I see fps benefits when using them, whereas with drawing geometry, you're doing more, not less. My suggestion was from the standpoint of visual end result.
I think drawing geometry is probably equivalent to your shader suggestion, and better or worse of an alternative depending on context. What's your opinion on that one? How would one test that actually (the dif in performance)?
Yep, totally knew you were coming from the "gets the right output" camp :) Just filling in more details so people who are OCD about doing things nicely can be more informed :)
Visually, the output should be the same.
Except for drawing more stuff, the shader culling method should be a last-resort. if you
discardfragments, you prevent the data from being written, which is a tiny savings, but you still have to execute the shader for each eligible pixel to know if it should be discarded or not (still expensive). drawing geometry means the shader doesn't have to discard [it still can though, but if it did you wouldn't need the extra draw-to-simulate-clipping stuff] -- so you'll spend the write bandwidth, and whatever complexity the pixel shader incurs, plus the cost of to "clipping" geometry to hide the fact that you drew it.Testing would require measuring performance; it's also highly driver/GPU dependent. Some drivers/GPUs will do clever stuff when you have a discard early in the shader (before the hard work -- texel fetches and whatever), so the discard trick will be a win. Others simply use the discard as an operation that gets passed to the ROPs (similar to other blend modes: over, sover, add, etc; discard just becomes "noop", so you pay for everything but the final write, which isn't a big savings).
ATI at one point had their fragment processors work in groups of 2x2 pixels (4 pixels at a time) -- if all of them did or didn't do discards, they'd be efficient, otherwise it'd do the full amount of work, and then manually mask the results in the ROPs, iirc. I don't know if that's still the case, or if there's a similar model still in use (and I have absolutely no idea how nvidia handles these things) -- in that case, clipping in the fragment program can be much cheaper (because huge regions of pixels will have similar paths).
Actually I can show what I've meant under it. This is a composition for a projection pyramid Cheoptics360. I want to get no intersections on different faces i.e. cropping of each 'teapot' on it's own projecting face.
You mean by adding a condition to draw only in definite area? Could you show an example code?