[bug 1.1a] Zones and Portals bugs - RESOLVED

#41 Okay, just let me cut out my spawning ai rubbish test area ..

#42 I need to make more streamlined test areas! But you know how you end up using these things for various junk ... anyhow, sent.

#43 Thanks a lot for the files Steve!

Confirmed as not fixed. Going to sleep now. Probably will have some freakish nightmare of a daemon with a giant-horned helmet (not sure where that's coming from...) that's disappearing and reappearing through a Torque 3D portal...

On to more zoning stuff tomorrow.

#44 Best of Luck on this Rene. We're pulling for ya.
(To add: I'll offer some models for your example game, as a token of my appreciation towards your fixing of many many bugs. Physics based items (chains, etc)is not a problem.)

#45 Actually, I am working on Acaster's Greathelm of Fury as we speak....

#46 Ok, got back to this and think I found it. The frustums generated for the portals now are correct (minus my clipPolygon still not being correct but that I have fixed), but there's actually another problem in Zone::_traverseZones where the code does something really stupid by stepping through one portal of a zone and then immediately stepping through another portal of the same zone but clipping that against the frustum of the first portal--which doesn't even remotely make sense. TBH, whoever wrote the portal code, that's really some piss poor piece of work.

I'll have a fix soonish. Pretty sure this is the final piece of the puzzle for this bug.

Quote:Best of Luck on this Rene. We're pulling for ya.
(To add: I'll offer some models for your example game, as a token of my appreciation towards your fixing of many many bugs. Physics based items (chains, etc)is not a problem.)

Thanks, eb.

Quote:Actually, I am working on Acaster's Greathelm of Fury as we speak....

Hehe.

#47 Only girly-men don't have the horn!


Moooooooooooo!

#48 Hmm, found two more issues, one minor and one major. Might take a while longer to fix.

For one, the frustum handed down to portals is always the initial frustum of the scene rendering state instead of the frustum that has been incrementally built up by the zone traversal. This means objects get rendered that are actually not visible through the portals.

More significantly, however, I found that the handling of the outdoor zone is wrong. If multiple portals lead to the outdoor zone, then the frustum built by the last such portal will overwrite frustums of all other portals to the outdoor zone.

Unfortunately, the way visibility culling is set up, this appears to be non-trivial to fix. Culling first does a complete zone traversal that retains all the frustums, then does a container query on the complete scene, and then culls the found objects against the results of the zone traversal. Only one frustum is retained per zone.

An easy fix would be to just merge the frustums for the outdoor zone but this can lead to *A LOT* of dead space making it into the visible objects list which is especially bad in this case since the outdoor zone may contain a great number of objects and thus requires precise culling even more than an interior zone.

@Steve
That picture is real silly... still liked that movie as a kid.

#49 Are you kidding? That movie is still hilarious! And The Destroyer is even funnier! I am having trouble reproducing the fur rim though....

#50 Destroyer is baaaad, Barbarian is great - best fantasy battle scenes ever!
And many awesome horned man-helmets.

#51 Yes, yes, Destroyer was horrible. But only as horrible as Krull and not quite as bad as Dark Star....

@Rene - on the up-side, the fix should improve overall rendering performance.

#52 (Prepare for lengthy post... :)

Ok, finally the pieces are coming together. I've spent the last days rewriting Zone and Portal almost from the ground up and have even re-architected a few things in the system. Need a couple more hours to proof and debug it all but I'll post the complete changes then (hopefully no more major stuff shows up past this point).

Torque's zone and portal system is extremely unorthodox--even more so in its current incarnation. Conventionally, portals are one-way "peek holes" into other zones that are exclusively defined by a polygon surface.

In Torque, however, a portal is not only bidirectional by default, it is also a zone! This means that a portal zone itself has volume in space in which the portal stands upright as a cross-section.

Also, most zoning schemes make zone distribution explicit and often manual meaning that you have to assign objects to zones. In Torque, however, zones are implicit, i.e. whenever your object's AABB intersects with a zone, it is considered to be in that zone. However, not only in that zone but in all other zones it intersects, i.e. objects can be in multiples zones at the same time which is a very powerful thing.

This makes zones and portals very easy and convenient to set up on the user side. You just place your objects where they should be, then just place zones to cover isolated spaces, and finally then place portals to cover the transitionary spaces between these zones. If you need to move some object, you just move it and the zoning changes automatically.

In the rewritten version, I have enhanced this setup (which I think is great) further so that now portals are full and complete zones in their own right that simply add the ability to connect to all other zones that they intersect--not only between two zones as before but really between all zones that cross into the portal space. You can even set up complex portalized spaces by just placing multiple intersecting portal zones.

Also, portals can now be dynamically shuttered and opened--on each side independently. This is useful, for example, if you have a passage with a door that leads from one room into another. You simply create a zone for each room and then create a portal zone that covers the doorway. Then, you set the initial state of the door to be closed and the portal to be impassable. Then, as the door opens, you make the portal passable.

There's other stuff, but that's the more significant portion of it.

Still have a bit of work in front of me but I'm pretty happy with where things are going.

//-------------

BTW, to give some comparison to a more "orthodox" portal system, here's what you would normally need to do in such a system to set up zones and portals:

• You have to place two portals to achieve bidirectional traversal.
• You need to explicitly and manually link a portal to a zone since there is no implicit zone/portal relation.
• You need to explicitly and manually define a portal's surface.
• Worst: you need to manually place objects in zones.

Of course, the manual linkage has the advantage that you can place remote portals but

• this is by far the rare exception of what you want to do with portals, and
• it can be easily added as an option on top of the portals that Torque has.

//Edit:
BTW, in case you're wondering about the scope of the rewrite, in the course of fixing the bug here I found a number of additional major issues like portal traversal being entirely wrong or network scoping of zones being broken. I ended up rewriting it all.

#53 Excellent news :D. Thanks for the hard work, and for explaining it in detail!

Question: if Portals are Zones, why use Zones? Instead of pure Portals.

EDIT: Also, do you think the zone system has potential applications in sound propagation?

#54

Quote:Question: if Portals are Zones, why use Zones? Instead of pure Portals.

Good question. One could indeed pack all the remaining functionality of Portal into Zone (or the other way round but this way makes more sense) and simply establish connectivity information between zones and if there is a connection, use the zone's cross-section as a portal surface.

This definitely is worth spending some thoughts on (the entire "portals are full zones" is a pretty recent thing). My spontaneous reaction would be that this would be kind of confusing. The way it is, it is still a zone and portal system that one can intuitively grasp ("areas and what connects them") and the notion of portals being zones themselves never needs to be fully realized by the user. But I may be totally wrong on that part. Worth a discussion.

Quote:EDIT: Also, do you think the zone system has potential applications in sound propagation?

Yep totally. With the SFX code in 1.1 I already went in that direction and there's already a SFX3DWorld system that is set up to track sound-related parts of the scene likes zones and portals. At the time, I had started on working 3D sound occlusion but then time ran out and I had to defer that part to 1.2.

//Edit:
BTW, one thing I was thinking about too was to do away with the way portal surfaces are currently defined and instead building true intersections between zones and using them as portals when traveling between zones. However, there's two reasons against that

a) it changes the system in a backwards-incompatible way and breaks existing scenes (not that they had working zones anyway :)
b) it's a more complex setup that requires more work at runtime for what seems like a limited gain in flexibility.

#55 Cool stuff, Rene!

#56 This sounds great Rene.

#57 Yeah, Rene, your work FTW!

#58 Thumbs up Rene - awesome work on your part :)

#59 In the zones/3d sound realm, zones can have audio properties assigned so that you have, for instance, a zone that represents a cave and uses an audio property that increases echo, etc as in a cave...? I'm sure I saw a drop-down in the editor with something along these lines for water blocks.

#60 Thanks guys :)

Quote:In the zones/3d sound realm, zones can have audio properties assigned so that you have, for instance, a zone that represents a cave and uses an audio property that increases echo, etc as in a cave...? I'm sure I saw a drop-down in the editor with something along these lines for water blocks.

Yep, that part is already there and should be working, though I think Steve found a bug that is still on my list to investigate for 1.1 final.

You can assign ambient audio properties to static objects and zones and the SFX system will activate and deactivate these audio spaces as the listener roams through the level.

The property on objects that drives this is "soundAmbience" which links to a SFXAmbience datablock.