New Way of Clipping?
dat better title(voodoo, i not creative enough)
I think I may of thought of a way of pretty good clipping for mainly indoor engines. Also please tell me if this is known and used a lot, if not, Lets call it RJ Culling(or Sumtin wit RJ in itdat my name), Well, I was thinking,
Every ten frames or so why dont you do a QUIK search through the Z buffer, Find the greatest Depth in it, and if it is smaller than your Maximun Depth(whatever it is) then replace the far Z Clipping with that, And repeat every 10 or so frames, Wouldnt this Speed up the procces by A LOT
(if this is already being used, please tell me how, and forgive me, thanks)
Copyright(c)2000 RJ''s Games
(hehe)
PPPPPPPPLLLLLLLLLLEEEEEEEAAAAAAAAASSSSSSEEEEEEEEE!!!!!!!!!!!!!!!!!!!!HHHHHHHHHEEEEEEEELLLLLLLPPPPPP!!!!!!!!!1
February 05, 2000 02:46 AM
Pretty elementary concept, if I may say so myself. There really isn''t a need to get a copyright on that code idea, baby.
Hey, ya never know, It just a simple clipping, that has pretty much NO hit, so, jus bein safe

There are a lot of high performance culling techniques very similar to the one you''ve described. The problem with them is that they all rely on reading information back from the z-buffer. While this may work on some non-x86 architectures (like SGI) the AGP and PCI busses were designed to pass information very fast to the card but not the other way. The small amount of data that OpenGL/D3D will allow you to recieve back from the card will be very slow in coming. Those techniques should work fine for software-only implementations, but they just don''t work on hardware acceleated ones. It wuld be interesting to see Intel design the next version of AGP to have fast z-buffer reads, but I haven''t heard anything from them to suggest they might.
-Daedalus
-Daedalus
DM's Rules:Rule #1: The DM is always right.Rule #2: If the DM is wrong, see rule #1.
February 05, 2000 07:34 PM
Some thoughts.
Reading data from the z-buffer isn''t bad just because it has to be read over the PCI bus (which is relatively slow). It is bad because it stalls the 3D pipeline. That is, D3D will delay returning from surface->Lock() until it has finished rendering the frame. This gets even worse when you consider that some cards (such as the new ATI card) render a frame behind the one currentl;y beging rendered by the game.
Consider when you''re facing a wall with a door. The far plane will be just behind the wall. Now you walk forward a bit and the door opens. But the far plane will not be moved to make the room behind the door visible for upto another 10 frames.
The same might happen if you''re facing a wall in a corridor. You turn around by 90 degrees so you''re looking down the corridor. It may take 10 frames until the far plane is moved to the end of the corridor.
How about if you used a software renderer to render the scene into a small surface (maybe 80x60) every frame. Then look for the greatest Z in that. You won''t stall the 3D pipeline because its entirely in software. Its a small render target so it won''t take very long. You should still get enough samples of Z to place the far plane.
I don''t think this is really better than, for example, a portal renderer.
Lastly, you can''t copyright an idea.
Reading data from the z-buffer isn''t bad just because it has to be read over the PCI bus (which is relatively slow). It is bad because it stalls the 3D pipeline. That is, D3D will delay returning from surface->Lock() until it has finished rendering the frame. This gets even worse when you consider that some cards (such as the new ATI card) render a frame behind the one currentl;y beging rendered by the game.
Consider when you''re facing a wall with a door. The far plane will be just behind the wall. Now you walk forward a bit and the door opens. But the far plane will not be moved to make the room behind the door visible for upto another 10 frames.
The same might happen if you''re facing a wall in a corridor. You turn around by 90 degrees so you''re looking down the corridor. It may take 10 frames until the far plane is moved to the end of the corridor.
How about if you used a software renderer to render the scene into a small surface (maybe 80x60) every frame. Then look for the greatest Z in that. You won''t stall the 3D pipeline because its entirely in software. Its a small render target so it won''t take very long. You should still get enough samples of Z to place the far plane.
I don''t think this is really better than, for example, a portal renderer.
Lastly, you can''t copyright an idea.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement