Best way to use Zones?

[PaulWeston]

Hello all,

First time posting at this new forum, have been a long time user of the garagegames.com forums/resources... Great to see so much action here!

Anyhow, I am having some issues lately with the new Torque versions, and I'm hoping somebody can shed some light for me...

In a nutshell, we have built the complete Star Trek original series Enterprise in T3D, and we give it away for free on our web site for fans. It was originally created in T3D 1.1B3, then migrated up to 1.1 Final, and a year or two ago we migrated again to 3.0 in order to integrate Oculus Rift support. Things were more or less fine, and the current download of the game is using that 3.0 build without any major issues.

However, now I am trying to bring the code up to the latest version 3.6, to take advantage of the new features. Was able to merge everything together (an arduous task because we also use AFX and many other mods/resources), and it compiles and runs, but whenever I switch zones in the ship by moving from one deck to another, the game will crash 80% of the time when transitioning zones.

The zones were never an issue before, we need them because the ship is so big and so full of stuff that the engine will crash on load if we do not zone the decks. But now they seem to be causing problems.

Cannot 100% confirm it is the zones, because we also integrated the old Male Advanced Character kit into our project, which required some porting and hacking to make it work with a newer version of T3d than it was ever intended for. So it could be something with that engine code that is messing things up... But our characters all animate properly and look great and have the melee functionality, so I'd like to think the ACK is working fine.

My question about the zones is this: Is there an optimal way to use them? We currently have large horizontal zones, one per deck, for 24 decks. Each zone encapsulates the entire deck's width and height, so that only the deck floor/walls of the current zone are visible at any one time. Sometimes they are not perfect and the entire deck/walls do not disappear, but everything within does. I have been tweaking the zones to try and get them all to fully make their deck disappear when not inside, but this is not always possible because of the close proximity of each zone one on top of the other. I am trying to avoid zone overlap.

Have placed portals at all staircases and elevator shafts, etc, so you can see through to the next zone, and am very happy with how it is all laid out, but I'm just wondering if having 24 zones stacked on top of each other is maybe not the best way. Would it be better to have fewer zones, say one for the saucer section, one for the neck, and one for the lower hull? To give the engine a break in terms of calculating zone contents visibility all the time?

Just looking for some help/ideas, because at this time we are stuck with our old 3.0 version and I would really like to bring it up to date and be able to walk the whole ship again.

Thanks in advance!

Paul

[JeffR]

As far as I know, that setup sounds like it SHOULD work, though obviously things may have been tweaked or broken over time.

Any chance of a video showing off the weird behavior so we have a better idea of what's happening?

[PaulWeston]

Thanks Jeff...

Sure, I could try and make a video, but it wouldn't really show much.

Basically, when I take the stairs down from the bridge to deck 2, I am transitioning from one zone to another. When I do so, I can see the deck2 stuff pop in as it should, and 20% of the time it will be fine. But other times, just because of the particular direction or angle I am facing perhaps, I immediately get the crash popup "NCC1701-3D has stopped working", with no noticeable errors in the console.log.

Tried to debug this using a debug build, but that has never worked well for me... It points me to generic spots in the code that could be being called from anywhere. It's really hard to trace line by line exactly where it is having a problem.

The only thing in console.log that I have noticed, which did not seem to appear in our 3.0 version or prior, is various shader compiler errors. I get a lot of "cannot compile shader, out of memory" errors as I move through the ship. It doesn't crash immediately after those errors, but they are there a few dozen lines before each crash in console.log.

Have made sure I have latest shader code, latest engine code, and latest game/core code. The only thing that is saved from our old 3.0 is all the scripts, because they were so heavily customized. Would not want to have to try and merge our custom scripts into the latest scripts, unless absolutely necessary for some reason.

Are there any known issues with the zones, or guidelines as to best practices? I'm wondering what the deal is with whether they can overlap or not, how that impacts things, and if the zone does not completely encapsulate everything (ie. if it is off by a few points in vertical scale, so the ceiling/floor above intermittently appears/disappears based on viewing angle) does that cause problems?

Also, if I am on the bridge and turn around to face the rear of the ship (where there are many objects hidden within variouos zones) the engine totally chugs for a few seconds when facing that direction. But there is a wall between me and the rest of the ship, as well as the fact that the bridge is a self-contained zone, so why would facing the rear be any more taxing than facing the front, unless it is somehow still rendering that stuff even if I am in a zone. There are also a lot of portals back there, which open up the view to even more zones, and it looks as if the walls of the ship are not blocking my "view" through those portals. Which doesn't make sense - shouldn't a DAE object, like a set of walls, act as a culling block or something? It shouldn't be trying to render stuff behind that that I can't see, right?

[PaulWeston]

Looks like I'm not set up to make videos right now, my kids borrowed my webcam lol...

However I did manage to draw up this VERY crude scribble stick-man drawing that shows the issue (see attachment).

I am wondering why, when looking back and down (which is in the direction of many other zones/portals), that the engine totally chokes for a few seconds, as if it is trying to render everything that is back there, even though A) everything back there is encased by other zones, and B) there are physical walls between me and the next zone, in addition to the zone itself. Do the DAE walls not do any sort of culling at all?

Anyhow, sorry for the crudeness of the drawing, but it will give you an idea.

Thanks again!

hand drawing of ship layout with zone anomalies

[Gibby]

@PaulWeston:

Are you 64-bit or 32? I've had issues with zones/portals/occluders in 64-bit that worked perfectly in 32-bit.

That being said, placement of portals / overlapping of zones can effect performance. I usually end up tweaking their positions/size quite a bit 'til I get the desired result...

[PaulWeston]

We are 32 bit... would love to go 64 but we use awesomium extensively and it only works in 32 bit.

I'm intrigued by your comment about placement and overlaps... how have you found is the best way to do them, and what should I try to avoid?

Also, I have never checked out occluders, is that something I should try?

Thanks :)

[PaulWeston]

OK, wow, I think i just solved my problem...

Just as a test, I removed all the portals and the crashes stopped. I'm guessing that when turning around to face aft, even though there are walls between me and those portals, the engine is still trying to calculate what I can see from my viewing angle as I look towards those portals.

Now, without portals the zones are kind of useless, as when looking down a staircase you now don't see the deck below until you enter the zone... and if I try to load everything in the ship without zones it will choke out and sometimes crash.

So, I came up with a solution where instead of a zone I have a trigger for each deck, and when you enter the trigger I load in all the objects for that deck. Then I remove when you go to next deck, and so on. I load the main deck models at startup, the floors walls and ceilings, just not the objects until I need them.

I can now run at a full sprint from the bridge all the way down to deck 24 in about 3 minutes with no crashing.

So, to sum up, f**k portals lol.

P

[rlranft]

Have you tried recreating those portals? Perhaps something was just munged in one of them somewhere...

[buckmaster]

So, we should look long and hard at portals to see if we can find bugs?

[PaulWeston]

Yes, I think the portal and zone code could benefit from some TLC :) If I remove all the portals and keep the zones I don't get the crashes as much, but there are still random anomalies now and then.

However, with my new loading/unloading scheme using the triggers, everything is flying... I can run deck to deck, and the objects all pop in and out without issues. The main decks are not bound by any zones anymore, so there are no random rendering anomalies from overlapping zones or portal viewing angles.

Removing the zones and portals entirely looks like it will work fine, they are not needed anymore if I can just load one deck's contents at a time as needed. I just need to have the deck floors and walls in place at all times, and that runs fine without zones thankfully :)

Was simply a matter of taking each deck and pulling out all the objects and saving them to separate files. Then I include the appropriate file when entering the deck trigger, and delete that simgroup when i exit the trigger. In a multiplayer situation, I don't delete a deck's objects if there is currently another player still in the trigger.

So far this is working, fingers crossed.

[buckmaster]

Where's @Rene Damm haha. That workaround sounds frustrating and it would be great to get this stuff working again. I wish I could promise my time on it. We'll see how we go.

(I don't expect you to fix it, Renee, just hoping you might remember something from back in the day that might have messed up, heh.)

[PaulWeston]

Yeah, Renee was definitely the guy for this back in the day... our original version of the Enterprise built in 1.1 final relied heavily on the stuff he worked to get in that release :)