Topic Title is a bit of a mouth full but thats the best way I can explain my renderer (coding it at the moment)
The main problem I saw with forward rendering is the amount of draw calls for rendering a model for each light. easily fixxed by introducing an uber shader, all the lighting in 1 pass.
But another problem arises there with the shear amount of information needed to be passed (the number of lights if you have many)
Fix that by only passing lighting information relatively close. This can still be a strain for scenes with many models or high amounts of geometry.
So cull objects outside of view using occlusion culling! fair enough but pixels are still drawn which will be overlapped by other models anyway.
My solution to avoid doing all the calculations for and then drawing pixels which will be drawn over with other models is during the occlusion culling to order the models front-to-back, based on their closest vertex. skip the pixels that are drawing on a spot with depth already draw closer. Thats not all pixels skipped, but in a lot of cases it will be most.
would this work as I imagine? or would it pose too much overhead?
Any and all help appreciated,
Thanks in advanced,
Bombshell
Front-to-Back pixel culling?
Yes, front-to-back sorting is recommended to take advantage of early-z tests.
However, another option is a "z-pre-pass", where you render all of your objects with color-writes disabled and depth-writes enabled. Then, when you render your normal forward lighting pass, the depth buffer has already been filled in, which also takes advantage of early-z tests.
However, another option is a "z-pre-pass", where you render all of your objects with color-writes disabled and depth-writes enabled. Then, when you render your normal forward lighting pass, the depth buffer has already been filled in, which also takes advantage of early-z tests.
Author
by the seems of it that should work out all the unwanted pixels. I would consider it a problem that the geometry is rendered twice, but with the Ubershader being the main problem I'm assuming its pro's can outweigh its con's. Only thing that's really an issue now then is ignoring partially transparent / transparent surfaces.
Thanks
Thanks
by the seems of it that should work out all the unwanted pixels. I would consider it a problem that the geometry is rendered twice, but with the Ubershader being the main problem I'm assuming its pro's can outweigh its con's.
Yeah you'd be surprised, modern hardware can be very fast at z-only rendering! Just make sure your meshes are optimized for vertex cache reuse and that vertex shader you used is as stripped down as possible, since you're much more likely to be vertex bound during z-only rendering. You can also be selective about what you render into a z-prepass...for instance it might be worth it to render all of your level geo but maybe not your skinned characters with 20k verts. Either way make sure you can easily toggle it on and off, so that you can easily test the performance in a variety of scenes and make sure that you're getting a performance gain. A very smart person once said that a z-prepass is a day-to-day decision, not a lifestyle choice.
Author
just a thought, in this case would it be worth doing something as intensive as occlusion culling, or would it serve me just as well doing some basic octree cone?
There is less need to work out every useless draw call when the culling is handled mostly by the Z-prepass
There is less need to work out every useless draw call when the culling is handled mostly by the Z-prepass
That depends on what you're drawing... If you're drawing Los Angeles from street-level, then you'll probably need some form of occlusion culling. If you're drawing a single football stadium, then simple frustum culling will probably be enough.
There is less need to work out every useless draw call when the culling is handled mostly by the Z-prepass
Unless you become CPU-bound, in which case you need something CPU-side to reduce draw calls.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
