[bug 1.1a] Zones and Portals bugs - RESOLVED
by Marcus L · in Torque 3D Professional · 01/30/2010 (11:29 am) · 161 replies
I'm having issues with portals and zones. I searched for the fix but both this and this is already applied in alpha 1.1. My issue is that when I'm inside a portal thats linked to a zone, then if i look in a certain direction (usually a random direction), the content of the zone is unrendered (btw. i think this is the same issue as Joshua Halls is/was having trouble with).
To make it easier to understand my problem I'll post some pictures.
Here i am inside a portal, liked to a zone.
Then i turn my head slightly to the left, and...
It's gone.
If anyone knows the fix, could u please post it here.
Thanks.
To make it easier to understand my problem I'll post some pictures.
Here i am inside a portal, liked to a zone.
Then i turn my head slightly to the left, and...
It's gone.If anyone knows the fix, could u please post it here.
Thanks.
#142
And a stupid question for Rene... what about prefabs? Are they culled as a whole or the code consider the single objects inside them? (I'm pretty sure it's like the second I said but just wanna ask to be sure...)
05/11/2011 (1:23 am)
@Caylo:Quote: Why not put a marker onto what is currently occluded? As in culling like previously mentioned, but mark each object that IS NOT visible as CurrentlyCulled. Then anytime a CurrentlyCulled is true during the shadow pass cull it from the shadow pass also.Look at examples shown by Rene... I think with this approach a problem would rise when there are objects entirely behind the occlusion volume (and as such they must be culled) but projecting shadows entirely or partially not behind the occlusion volume (and as such they must be still visible).
And a stupid question for Rene... what about prefabs? Are they culled as a whole or the code consider the single objects inside them? (I'm pretty sure it's like the second I said but just wanna ask to be sure...)
#143
That would be a nice solution but unfortunately, it's too simple. If you look at the shot there in post #135, you can see that the second shape from the right is culled by the biggest occluder there. However, you can also see that its shadow is still visible.
So, unfortunately, it's not just whether the object itself gets culled in the diffuse pass or not, it's actually whether its shadow volume might protrude into the player's view or not that must be used to decide whether it can be culled or not. This makes it quite a bit trickier.
The whole algorithm is operating in world space, so it is true 3D volumes. If you used a simple 2D polygon, you would have to project all the 3D bounding volumes to the screen and then test for intersection. Also, while sufficient for portals, occluders would need an extra distance test since they must not occlude anything that, from the current viewpoint, is actually in front of them.
In general, doing this kind of culling operations in world space instead of screen space is both faster and more robust. Plane/AABB intersection tests are extremely fast whereas for 2D, in addition to having to project stuff, you would either end up having to do more expensive polygon/polygon intersection tests (since the world-space AABBs are no longer guaranteed to be axis-aligned in screen-space) or lay screen-space AABBs around the projected world-space AABBs thus making culling vastly more imprecise.
However, there are some interesting ways to do occlusion culling in screen-space by actually rasterizing the data but that's a pretty different approach altogether.
05/11/2011 (2:30 am)
Quote:Why not put a marker onto what is currently occluded? As in culling like previously mentioned, but mark each object that IS NOT visible as CurrentlyCulled. Then anytime a CurrentlyCulled is true during the shadow pass cull it from the shadow pass also.
That would be a nice solution but unfortunately, it's too simple. If you look at the shot there in post #135, you can see that the second shape from the right is culled by the biggest occluder there. However, you can also see that its shadow is still visible.
So, unfortunately, it's not just whether the object itself gets culled in the diffuse pass or not, it's actually whether its shadow volume might protrude into the player's view or not that must be used to decide whether it can be culled or not. This makes it quite a bit trickier.
Quote:Why is this a 3d 'volume', and not a 2d sheet? Seems extra complex to my ignorant understandings.
The whole algorithm is operating in world space, so it is true 3D volumes. If you used a simple 2D polygon, you would have to project all the 3D bounding volumes to the screen and then test for intersection. Also, while sufficient for portals, occluders would need an extra distance test since they must not occlude anything that, from the current viewpoint, is actually in front of them.
In general, doing this kind of culling operations in world space instead of screen space is both faster and more robust. Plane/AABB intersection tests are extremely fast whereas for 2D, in addition to having to project stuff, you would either end up having to do more expensive polygon/polygon intersection tests (since the world-space AABBs are no longer guaranteed to be axis-aligned in screen-space) or lay screen-space AABBs around the projected world-space AABBs thus making culling vastly more imprecise.
However, there are some interesting ways to do occlusion culling in screen-space by actually rasterizing the data but that's a pretty different approach altogether.
#144
Sorry Giorgio, missed your post.
Like you suspect, it's indeed that single objects are culled. In fact, while the scene management subsystem in Torque had traditionally been labeled "Scene Graph" there is no hierarchy whatsoever in Torque's scene representation--it basically is a flat list of objects even though its stored in a grid for faster spatial queries.
As such, a prefab is nothing more than a special type of reference to a file containing SceneObjects which, when loaded, it just inserts into the scene.
05/11/2011 (2:38 am)
@GiorgioSorry Giorgio, missed your post.
Quote:And a stupid question for Rene... what about prefabs? Are they culled as a whole or the code consider the single objects inside them? (I'm pretty sure it's like the second I said but just wanna ask to be sure...)
Like you suspect, it's indeed that single objects are culled. In fact, while the scene management subsystem in Torque had traditionally been labeled "Scene Graph" there is no hierarchy whatsoever in Torque's scene representation--it basically is a flat list of objects even though its stored in a grid for faster spatial queries.
As such, a prefab is nothing more than a special type of reference to a file containing SceneObjects which, when loaded, it just inserts into the scene.
#145
05/11/2011 (2:58 am)
Thanks Rene ;-)
#146
because of the nature of this scene optimization, I think the occlusion volumes should cull other occlusion volumes first and foremost.
Im starting to like the idea of occlusion volumes. torques finally gonna have outdoor culling. :)
05/17/2011 (5:32 pm)
Is every object in a zone always tested against every occlusion volume in the zone since theres no hierarchy? or is there some kind of optimization or grouping mechanism in place? I assume culled objects would no longer be tested anymore.because of the nature of this scene optimization, I think the occlusion volumes should cull other occlusion volumes first and foremost.
Im starting to like the idea of occlusion volumes. torques finally gonna have outdoor culling. :)
#147
it can be a thin sheet, but it would still need to be a 3d object. you could use 4 thin sheets for occlusion culling everything outside of a room for instance.
05/17/2011 (5:45 pm)
Quote:
Why is this a 3d 'volume', and not a 2d sheet? Seems extra complex to my ignorant understandings.
it can be a thin sheet, but it would still need to be a 3d object. you could use 4 thin sheets for occlusion culling everything outside of a room for instance.
#148
Culling volumes for each zone (including the outdoor zone) are sorted by decreasing probability of causing rejections. So, as soon as an object is determined to either be rejected or definitely accepted, it will early out.
Yep. If some criteria (including stuff like terrain occlusion, if enabled) causes an object to be rejected or accepted, that's good enough and no further testing is done.
They do. Also, there are other optimizations, like occluders that are too small being rejected or the maximum number of occluders per zone being restricted (if exceeded, the smallest occluder is dropped). All of these parameters can be tuned from the console.
Yep. I still see countless possibilities on improving on all of this but can't really say this wasn't the case with anything I ever worked on. Guess it's the nature of the thing.
05/17/2011 (5:49 pm)
Quote:Is every object in a zone always tested against every occlusion volume in the zone since theres no hierarchy? or is there some kind of optimization or grouping mechanism in place?
Culling volumes for each zone (including the outdoor zone) are sorted by decreasing probability of causing rejections. So, as soon as an object is determined to either be rejected or definitely accepted, it will early out.
Quote:I assume culled objects would no longer be tested anymore.
Yep. If some criteria (including stuff like terrain occlusion, if enabled) causes an object to be rejected or accepted, that's good enough and no further testing is done.
Quote:because of the nature of this scene optimization, I think the occlusion volumes should cull other occlusion volumes first and foremost.
They do. Also, there are other optimizations, like occluders that are too small being rejected or the maximum number of occluders per zone being restricted (if exceeded, the smallest occluder is dropped). All of these parameters can be tuned from the console.
Quote:torques finally gonna have outdoor culling. :)
Yep. I still see countless possibilities on improving on all of this but can't really say this wasn't the case with anything I ever worked on. Guess it's the nature of the thing.
#149
Part 1:
Part 2:
Much shorter video about occlusion volumes will follow shortly.
BTW, you may notice that the shadows in the video look slightly different from what they normally do in Torque. Tom recently gave me his implementation of a shadow filtering technique that he evaluated before deciding on the technique currently in Torque (usually referred to as "Exponential Shadow Maps" or ESMs). The technique, based on a gaussian filter, has the downside of being more prone to shadow acne (that problem where you see the shadow go into and out of the surface), but it suffers a lot less from light bleeding at contact points and I must say I very much like the shadow edges it produces. Much less fizzle than with the ESMs, though at low sampling settings, the shadows get a bit blocky--which I still prefer to fizzle, though.
In the video, I've actually cranked this up to a crazy 144 samples per pixel which is unrealistic for actual use in a game (the current ESMs do a max of 16 samples/pixel), but I do like the results :)
Still, both techniques have their trade-offs and given that my test settings were mostly unrealistic ones, Tom certainly made a wise choice there for Torque going with the ESM technique, but it's pretty fun playing with this. If you're interested in the technique, feel free to bug Tom a little to push him towards releasing this as a resource :)
05/26/2011 (6:05 pm)
New video is up. This time focusing on stuff that is actually of interest to those wanting to use these features :)Part 1:
Part 2:
Much shorter video about occlusion volumes will follow shortly.
BTW, you may notice that the shadows in the video look slightly different from what they normally do in Torque. Tom recently gave me his implementation of a shadow filtering technique that he evaluated before deciding on the technique currently in Torque (usually referred to as "Exponential Shadow Maps" or ESMs). The technique, based on a gaussian filter, has the downside of being more prone to shadow acne (that problem where you see the shadow go into and out of the surface), but it suffers a lot less from light bleeding at contact points and I must say I very much like the shadow edges it produces. Much less fizzle than with the ESMs, though at low sampling settings, the shadows get a bit blocky--which I still prefer to fizzle, though.
In the video, I've actually cranked this up to a crazy 144 samples per pixel which is unrealistic for actual use in a game (the current ESMs do a max of 16 samples/pixel), but I do like the results :)
Still, both techniques have their trade-offs and given that my test settings were mostly unrealistic ones, Tom certainly made a wise choice there for Torque going with the ESM technique, but it's pretty fun playing with this. If you're interested in the technique, feel free to bug Tom a little to push him towards releasing this as a resource :)
#150
05/26/2011 (7:13 pm)
Looking very good. Thanks for the your efforts on the coding and on the videos. Can't wait to start using it. I use a large DNA molecule in my game and it really hits the frame rate when looking in that direction, even though you are inside a building. You are the -Frame saver-. Forget the title of Mr. Rene Damm, your new title is: Fs. Rene Damm. Thanks again!
#151
Also nice easy to understood explanation of how to use it all.
:D
05/26/2011 (7:15 pm)
That's awesome!Also nice easy to understood explanation of how to use it all.
:D
#152
05/27/2011 (2:24 am)
Now THAT is a feature i want to see. Very good. 
#153
05/27/2011 (10:04 am)
Nice videos, now I have a much better understanding of zones and portals. Thanks and keep up the good work, Rene! 
#154
05/27/2011 (10:53 am)
Rene, in the second video I saw a section in the zone properties about mounting. What's the story on that piece?
#155
Hehe. The real frame saver is Tom, though. He put a lot of optimizations into 1.1 that bring FPS up a lot with AL. This is the primary reason why 1.1 performs so much better than 1.0.1.
That's actually a generic set of mounting abilities inherited from SceneObject, i.e. every object has them. For zones and portals, using them wouldn't really make sense.
05/27/2011 (12:35 pm)
Thanks guys :)Quote:You are the -Frame saver-. Forget the title of Mr. Rene Damm, your new title is: Fs. Rene Damm.
Hehe. The real frame saver is Tom, though. He put a lot of optimizations into 1.1 that bring FPS up a lot with AL. This is the primary reason why 1.1 performs so much better than 1.0.1.
Quote:Rene, in the second video I saw a section in the zone properties about mounting. What's the story on that piece?
That's actually a generic set of mounting abilities inherited from SceneObject, i.e. every object has them. For zones and portals, using them wouldn't really make sense.
#156
05/27/2011 (12:43 pm)
Cool stuff! I can't wait to see the video about occlusion volumes =)
#157
05/27/2011 (1:09 pm)
Thanks for taking the time out to make the videos Rene. I'll be watching them tonight. 
#158
05/28/2011 (3:47 am)
Real nice Rene. It's looking great. 
#159
05/28/2011 (7:27 pm)
Quote:For zones and portals, using them wouldn't really make sense.But do they work? Could I, for example, mount several zones and portals to something like a pathed 'interior' that moves about the scene but has quite a lot of internal detail that players will be moving about in? That seems like a lot to ask, but it would be really awesome ;P
#160
Coming soon :)
Yep, that will work. While zones and portals will generally be static objects, technically there's nothing preventing you from mounting them or moving them about however you want.
One thing to be aware of here, though, is that because zoning is fully automatic, when you move zones and portals around, some rezoning needs to occur. Especially if you'd be moving a complex interior around with lots of geometry and lots of zones, that could actually amount to a bit of processing time.
05/28/2011 (7:36 pm)
Thanks for the kind words guys :)Quote:I can't wait to see the video about occlusion volumes =)
Coming soon :)
Quote:But do they work? Could I, for example, mount several zones and portals to something like a pathed 'interior' that moves about the scene but has quite a lot of internal detail that players will be moving about in? That seems like a lot to ask, but it would be really awesome ;P
Yep, that will work. While zones and portals will generally be static objects, technically there's nothing preventing you from mounting them or moving them about however you want.
One thing to be aware of here, though, is that because zoning is fully automatic, when you move zones and portals around, some rezoning needs to occur. Especially if you'd be moving a complex interior around with lots of geometry and lots of zones, that could actually amount to a bit of processing time.
Torque 3D Owner Caylo Gypsyblood
Why is this a 3d 'volume', and not a 2d sheet? Seems extra complex to my ignorant understandings.