[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.
#62
02/10/2011 (4:47 pm)
@Rene Damm: This T3D system sounds much like the very old BSP portal system. Are they related? 
#63
In terms of the way they actually work at runtime, no.
The setup procedure for zoning a world in Constructor is similar to what you have with the zoning system here, but the legacy interior code itself actually uses a classic portal system with one-sided Ngons--portals in the interior code aren't zones. All the magic of going from one to the other probably happened in map2dif.
02/10/2011 (4:59 pm)
Quote:@Rene Damm: This T3D system sounds much like the very old BSP portal system. Are they related?
In terms of the way they actually work at runtime, no.
The setup procedure for zoning a world in Constructor is similar to what you have with the zoning system here, but the legacy interior code itself actually uses a classic portal system with one-sided Ngons--portals in the interior code aren't zones. All the magic of going from one to the other probably happened in map2dif.
#64
02/10/2011 (6:04 pm)
It sounds like a brilliant zoning system. I am looking forward to level design with it. 
#65
Awesome work on the portal/zone system. I look forward to using it for my own game. I especially like the idea of being able to actively disable portals.
Would it be possible to modify the system to use any convex volume rather than just cubes? That would make it easier for me to follow the contours of my walled town, rather than attempt to flood-fill the area with a bunch of cubes. I'm not suggesting that you expand the scope to include this, just to keep it in mind during your rebuild. :)
- Dave
02/11/2011 (8:17 am)
Hey Rene.Awesome work on the portal/zone system. I look forward to using it for my own game. I especially like the idea of being able to actively disable portals.
Would it be possible to modify the system to use any convex volume rather than just cubes? That would make it easier for me to follow the contours of my walled town, rather than attempt to flood-fill the area with a bunch of cubes. I'm not suggesting that you expand the scope to include this, just to keep it in mind during your rebuild. :)
- Dave
#66
Thanks Dave!
That's actually pretty easy to add. It needs two things:
That's not a lot of work at all.
Editor support is a different thing but there's a very straightforward way for that: just allow a Zone to reference another SceneObject that defines its shape. This could be a TSStatic then or even a ConvexShape. You can either use a shape that is visible and used for level geometry or use a shape for zoning only and hide it from rendering.
Rezoning for these kind of zones potentially becomes quite a bit more expensive as the collision system will have to be utilized here.
Still, all in all, this should be pretty straightforward.
//Edit
Another way would be to derive Zone from ConvexShape but this has a lot more profound implications than just linking a Zone to a shape.
02/11/2011 (8:30 am)
@DaveThanks Dave!
Quote:Would it be possible to modify the system to use any convex volume rather than just cubes?
That's actually pretty easy to add. It needs two things:
- Zones must allow to attach a custom shape to them that defines their volume.
- The rezoning code must be adapted to allow a zone to extend its containment test to more than just overlapping AABBs.
That's not a lot of work at all.
Editor support is a different thing but there's a very straightforward way for that: just allow a Zone to reference another SceneObject that defines its shape. This could be a TSStatic then or even a ConvexShape. You can either use a shape that is visible and used for level geometry or use a shape for zoning only and hide it from rendering.
Rezoning for these kind of zones potentially becomes quite a bit more expensive as the collision system will have to be utilized here.
Still, all in all, this should be pretty straightforward.
//Edit
Another way would be to derive Zone from ConvexShape but this has a lot more profound implications than just linking a Zone to a shape.
#67
I've slated tonight for trying to wrap up the zoning work but I will definitely give this a look too and see whether this comes as a very straightforward extension to what is already there.
//Edit
BTW, with Zone being a ConvexShape, one could in practice have Portal define non-rectangular portal shapes but I don't like this idea at all. I like the simplicity that stems from portals always being rectangular and its important to keep in mind this is just visibility culling--worst thing you get by having portals that are supersets of the actually passable geometric region is rendering a couple more objects here and there than you actually need to.
02/11/2011 (8:42 am)
Actually, the more I think about it, the more I like the idea of turning Zone into a ConvexShape subclass. It's a pretty natural solution that pretty much covers the editor problem too.I've slated tonight for trying to wrap up the zoning work but I will definitely give this a look too and see whether this comes as a very straightforward extension to what is already there.
//Edit
BTW, with Zone being a ConvexShape, one could in practice have Portal define non-rectangular portal shapes but I don't like this idea at all. I like the simplicity that stems from portals always being rectangular and its important to keep in mind this is just visibility culling--worst thing you get by having portals that are supersets of the actually passable geometric region is rendering a couple more objects here and there than you actually need to.
#68
Unfortunately, it would only affect meshes and not any other kind of renderable object though for some other kind of objects like particle systems, it would be very straightforward to add something similar.
Note that since objects may belong to multiple zones in Torque, there must be some way to resolve ambiguous cases. Just letting the zone that is nearest to an object's center take precedence would be one way.
02/11/2011 (8:59 am)
BTW, while I need to be careful not to let this ticket spin totally out of control (well, ok, it already has), I've also found a very easy and straightforward solution to setting custom ambient light scale factors on zones and have them affect meshes rendered in the zone.Unfortunately, it would only affect meshes and not any other kind of renderable object though for some other kind of objects like particle systems, it would be very straightforward to add something similar.
Note that since objects may belong to multiple zones in Torque, there must be some way to resolve ambiguous cases. Just letting the zone that is nearest to an object's center take precedence would be one way.
#69
- I feel that a check for a zone_dummy node in the model would be ideal, otherwise default to the center.
I have seen situations where generic points cause issues. ..it's better to allow the artist control of such things. thx for the ear time.
(P.S. the 'over the top ideal way' would be; create a dummy node class at which to point/pair models. Then the multiple models would take on the ambient setting from the zone of which the node resides. Rendering lines to show the connections would be added greatness.)
02/11/2011 (11:05 am)
My 2 cents;- I feel that a check for a zone_dummy node in the model would be ideal, otherwise default to the center.
I have seen situations where generic points cause issues. ..it's better to allow the artist control of such things. thx for the ear time.
(P.S. the 'over the top ideal way' would be; create a dummy node class at which to point/pair models. Then the multiple models would take on the ambient setting from the zone of which the node resides. Rendering lines to show the connections would be added greatness.)
#70
02/11/2011 (1:20 pm)
We probably won't get to see this until next release, huh? It sounds totally awesome! I have to say that I've never imagined being so jazzed about zones....
#71
That's a damn good idea. Gives the option of manual control and an automated fallback.
It will be a rare case, though. Especially with zones being more than just cube shapes, problems resulting from zone overlaps will not be frequent.
I think that would be somewhat disproportional to the problem at hand.
Well, I definitely want to at least try to pack this into the current zone system overhaul. I will dedicate time on this weekend to both the ConvexShape zoning and the ambient light scale factor ideas and see if I can get them in quickly.
Hehe.
They're still addressing a pretty mundane problem really but yeah, must admit that I've turned from disgust to excitement on this ticket too.
02/11/2011 (1:35 pm)
Quote:- I feel that a check for a zone_dummy node in the model would be ideal, otherwise default to the center.
That's a damn good idea. Gives the option of manual control and an automated fallback.
It will be a rare case, though. Especially with zones being more than just cube shapes, problems resulting from zone overlaps will not be frequent.
Quote:(P.S. the 'over the top ideal way' would be; create a dummy node class at which to point/pair models. Then the multiple models would take on the ambient setting from the zone of which the node resides. Rendering lines to show the connections would be added greatness.)
I think that would be somewhat disproportional to the problem at hand.
Quote:We probably won't get to see this until next release, huh?
Well, I definitely want to at least try to pack this into the current zone system overhaul. I will dedicate time on this weekend to both the ConvexShape zoning and the ambient light scale factor ideas and see if I can get them in quickly.
Quote:I have to say that I've never imagined being so jazzed about zones....
Hehe.
They're still addressing a pretty mundane problem really but yeah, must admit that I've turned from disgust to excitement on this ticket too.
#72
This sounds pretty interesting Rene. Can't wait to use the new system on my dungeon level.
02/11/2011 (2:04 pm)
Quote:I've also found a very easy and straightforward solution to setting custom ambient light scale factors on zones and have them affect meshes rendered in the zone.
This sounds pretty interesting Rene. Can't wait to use the new system on my dungeon level.
#73
02/11/2011 (4:41 pm)
Quote:Note that since objects may belong to multiple zones in Torque, there must be some way to resolve ambiguous cases.Average them? This might ease the transition between zones with different ambients - though it does pose a problem for larger objects (i.e. rooms modeled as meshes) that overlap multiple zones (or even zones and portals).
#74
It also might cause problems where an object's bounding box just happens to intersect another zone but the mesh of the object itself isn't actually visible in that other zone. Here, the object's ambient factor will nonetheless be affected by that other zone.
In general, I'd prefer for the engine to not mess with user defined scale factors and a solution where you can resolve ambiguities by manually determining the zone an ambiguous object has its ambient factor decided by appears ideal to me.
02/11/2011 (5:25 pm)
Quote:Average them? This might ease the transition between zones with different ambients - though it does pose a problem for larger objects (i.e. rooms modeled as meshes) that overlap multiple zones (or even zones and portals).
It also might cause problems where an object's bounding box just happens to intersect another zone but the mesh of the object itself isn't actually visible in that other zone. Here, the object's ambient factor will nonetheless be affected by that other zone.
In general, I'd prefer for the engine to not mess with user defined scale factors and a solution where you can resolve ambiguities by manually determining the zone an ambiguous object has its ambient factor decided by appears ideal to me.
#75
Sorry....
02/11/2011 (8:13 pm)
Oooh, yeah, but can an object be assigned to one, the other, or both (or all) zones that it overlaps as desired? That way the builder can manually pick which zones will affect the object.Sorry....
#76
(This is something I've wanted to ask about for ages - general ideas for preserving object references across mission loads, etc.)
02/11/2011 (9:18 pm)
Quote:where an object's bounding box just happens to intersect another zone but the mesh of the object itself isn't actually visible in that other zoneYep, that's what I was ineloquently trying to get at ;P.
Quote:manually determining the zoneThat does sound ideal - but how would the designation method work? Unless all zones are named, you can't guarantee object IDs will be the same every mission.
(This is something I've wanted to ask about for ages - general ideas for preserving object references across mission loads, etc.)
#77
Right now, this process is entirely automatic--which I think is where a lot of the convenience and power of this comes from--and usually there it's neither necessary or even desirable to manually affect assignments. It's just that for things like adjusting ambient factors based on zoning that the ambiguity needs to be resolved. Ideally, that would work in a way that still leaves the automatism fully in place.
@Daniel
Hehe. Reading it again, it's obvious I restated what you already said :)
One way would be eb's idea above which, however, will work only on a per-model basis and not on a per-instance basis. Still, in general I think the simpler the better here.
Ambiguities are totally fine except in a few edge cases.
Since 1.1 there is a new mechanism on SimObject for generating persistent IDs. These are UUIDs that are saved with the object can be used to persistently refer to objects that are not named and not in the same serialization.
It has its pitfalls but it's one way to persistently link objects.
//Edit:
Take a look at SimPersistSet for an example. It can reference a set of objects even when they are not loaded. Then, as you load the objects, they automatically appear in the set.
02/12/2011 (8:05 am)
@RichardQuote:Oooh, yeah, but can an object be assigned to one, the other, or both (or all) zones that it overlaps as desired?
Right now, this process is entirely automatic--which I think is where a lot of the convenience and power of this comes from--and usually there it's neither necessary or even desirable to manually affect assignments. It's just that for things like adjusting ambient factors based on zoning that the ambiguity needs to be resolved. Ideally, that would work in a way that still leaves the automatism fully in place.
@Daniel
Quote:Yep, that's what I was ineloquently trying to get at ;P.
Hehe. Reading it again, it's obvious I restated what you already said :)
Quote:That does sound ideal - but how would the designation method work?
One way would be eb's idea above which, however, will work only on a per-model basis and not on a per-instance basis. Still, in general I think the simpler the better here.
Ambiguities are totally fine except in a few edge cases.
Quote:(This is something I've wanted to ask about for ages - general ideas for preserving object references across mission loads, etc.)
Since 1.1 there is a new mechanism on SimObject for generating persistent IDs. These are UUIDs that are saved with the object can be used to persistently refer to objects that are not named and not in the same serialization.
It has its pitfalls but it's one way to persistently link objects.
//Edit:
Take a look at SimPersistSet for an example. It can reference a set of objects even when they are not loaded. Then, as you load the objects, they automatically appear in the set.
#78
02/12/2011 (3:34 pm)
Did you say that the zones work with AABBs? in that case, it should be fairly easy to figure how much each object intersects a zone, correct? Could the amount of intersection be used to determine the correct zone? So in cases where you have a large room that's pretty much entirely inside one zone, but has a corner overlapping another zone, the amount of overlap would dictate that the room fall within the first zone.Quote:Take a look at SimPersistSet for an example.Will do - thanks!
#79
Yep, indeed.
Interesting idea really. Given that the cases where resolving to a specific single zone is necessary are rare, this could really be all that's needed.
//-------
There's a bad bug in the current code that wrecks havoc on the scene traversals. Not sure yet whether this is within the new code or a problem that existed previously. Can't quite make sense of it yet. Losing time on this. Argh.
02/12/2011 (3:43 pm)
Quote:in that case, it should be fairly easy to figure how much each object intersects a zone, correct?
Yep, indeed.
Quote:Could the amount of intersection be used to determine the correct zone? So in cases where you have a large room that's pretty much entirely inside one zone, but has a corner overlapping another zone, the amount of overlap would dictate that the room fall within the first zone.
Interesting idea really. Given that the cases where resolving to a specific single zone is necessary are rare, this could really be all that's needed.
//-------
There's a bad bug in the current code that wrecks havoc on the scene traversals. Not sure yet whether this is within the new code or a problem that existed previously. Can't quite make sense of it yet. Losing time on this. Argh.
#80
Quick update just to let you know this hasn't fallen to the wayside.
While the whole ticket has drawn out way beyond what I would have liked and has caused me quite some frustration, things are finally going somewhere. There's still a couple of issues and a lot of testing going on but an end finally seems to be in sight. Tom helped me greatly today in tracking more stuff down.
By now, I'm pretty used to finding my frustums all over the place. Like this one here that's totally in the boonies and that I still haven't managed to recover.
I hope to have a version to post real soon so you can try out the changes and help beat down any remaining issues as this has grown into a rather large change.
@Steve
Your level is still serving us extremely well. Usually, if something *appears* to work just fine, I load up your level and it soon shows whether there might be merit to that or whether it's just that--an appearance.
02/18/2011 (7:10 pm)
Hey guys,Quick update just to let you know this hasn't fallen to the wayside.
While the whole ticket has drawn out way beyond what I would have liked and has caused me quite some frustration, things are finally going somewhere. There's still a couple of issues and a lot of testing going on but an end finally seems to be in sight. Tom helped me greatly today in tracking more stuff down.
By now, I'm pretty used to finding my frustums all over the place. Like this one here that's totally in the boonies and that I still haven't managed to recover.
I hope to have a version to post real soon so you can try out the changes and help beat down any remaining issues as this has grown into a rather large change.
@Steve
Your level is still serving us extremely well. Usually, if something *appears* to work just fine, I load up your level and it soon shows whether there might be merit to that or whether it's just that--an appearance.
Torque Owner Richard Ranft
Roostertail Games