Occlusion Culling Status
by Dark Tengu · in Torque 3D Professional · 03/14/2013 (11:45 pm) · 27 replies
Several years ago I started a thread about occlusion culling in Torque3D and Tom Spillman had mentioned that it was a priority, does anyone know what happened to that or are we stuck with frustrum culling?
#23
05/08/2014 (10:04 pm)
How to works with Basic Lighting, do you fix it ? 
#24
My to-do list at the moment is a mile long, but it is my intention to revisit this code and improve it when I get time.
05/09/2014 (8:25 am)
I'll be honest I don't remember if I fixed basic lighting or not. I remember I had to scrap how the system worked and redo it to get it working properly in advanced lighting, with the intention of rewriting the old method to support basic as well. I don't, however, recall if I completed that work.My to-do list at the moment is a mile long, but it is my intention to revisit this code and improve it when I get time.
#25
06/18/2014 (7:34 am)
@Andrew How is this code as of now? Would it be possible to merge it into my own project and it be usable? I'd just be using the advanced lighting. The project I'm currently working on would require this feature(for destruction purposes).
#26
1) The list needs to be prefiltered so it's not testing every object. It should be determined every couple of frames or every tick whether or not it's worth doing occlusion tests on certain objects based on their position, etc.
2) Shadows are not part of the occlusion test so when an object gets occluded it's shadow will disappear and though you can't see the object, you may have seen the shadow which will disappear in front of you.
The first one I'm not entirely sure about. There's been a lot of papers written on the subject. Lots of different methods to determine what's worth it and what's not.
The second one could be solved by just hacking it to allow the shadows to always render even if the object doesn't. The actual drawing of the shadows is not expensive so it's not really a concern.
If you expand a bit more on what you need it for I may be able to come up with a solution for your specific situation.
06/18/2014 (7:51 am)
If you have any knowledge of the subject and/or C++ you could turn it into a working solution. It's not far off and it serves as a good example but there's a number of issues with it. 1) The list needs to be prefiltered so it's not testing every object. It should be determined every couple of frames or every tick whether or not it's worth doing occlusion tests on certain objects based on their position, etc.
2) Shadows are not part of the occlusion test so when an object gets occluded it's shadow will disappear and though you can't see the object, you may have seen the shadow which will disappear in front of you.
The first one I'm not entirely sure about. There's been a lot of papers written on the subject. Lots of different methods to determine what's worth it and what's not.
The second one could be solved by just hacking it to allow the shadows to always render even if the object doesn't. The actual drawing of the shadows is not expensive so it's not really a concern.
If you expand a bit more on what you need it for I may be able to come up with a solution for your specific situation.
#27
As for #1, do you mean every object in the scene, or every object within the frustum?
Also to expand upon what I'm doing, I'm doing something like Destruction 2.0, like in Battlefield: Bad Company 2, which involves blowing holes in building walls, that could be expensive to draw without any occlusion, but portals probably wouldn't work, either, I'd have to either add portals for each hole, which would slow the rendering down, defeating the purpose, or just expand the portal to encompass all the holes, which if they're spaced out enough, would intersect with the entire side of the room, defeating the purpose. Hardware occlusion, should, hypothetically, rectify these issues by rendering only what's visible. Also if you're interested, the way I was gonna blow holes in walls was gonna be similar to how valve does zombie wounds in Left 4 Dead 2, paper here: http://www.valvesoftware.com/publications/2010/gdc2010_vlachos_l4d2wounds.pdf
06/18/2014 (10:08 am)
Well, I am a bit familiar with C++, I can write the code, but I'm not sure I'm fluent, and I don't know much on doing engine graphical stuff... As for #1, do you mean every object in the scene, or every object within the frustum?
Also to expand upon what I'm doing, I'm doing something like Destruction 2.0, like in Battlefield: Bad Company 2, which involves blowing holes in building walls, that could be expensive to draw without any occlusion, but portals probably wouldn't work, either, I'd have to either add portals for each hole, which would slow the rendering down, defeating the purpose, or just expand the portal to encompass all the holes, which if they're spaced out enough, would intersect with the entire side of the room, defeating the purpose. Hardware occlusion, should, hypothetically, rectify these issues by rendering only what's visible. Also if you're interested, the way I was gonna blow holes in walls was gonna be similar to how valve does zombie wounds in Left 4 Dead 2, paper here: http://www.valvesoftware.com/publications/2010/gdc2010_vlachos_l4d2wounds.pdf
Torque Owner Stefan Lundmark