[bug 1.1a] Zones and Portals bugs - RESOLVED

#81 Yeah, I know how to hunt elusive FUBARs! :P

Quote:
but an end finally seems to be in sight

Huzzar to that!

#82 Frustrum Frustration - you've just created a new game!

#83 I agree, that's the exact title that XBLA hits are made of!

#84 Any news?

#85 Sorry guys for the silence. Here's the current status.

A week ago, I had Zone and Portal running and doing their thing. However, there were still three issues:

• The system was keeping to its own and was only working within itself, i.e. it did not integrate with the zoning features that were defined at the SceneObject level. This, for example, meant that zones defined by interiors did not work anymore.
• The original system was created based on an assumption that was exactly detriment to what Zone and Portal do. The code was written to support very few zone managers each of which managed a whole complex of zones. However, both Zone and Portal are zone managers that each only define a single zone.
• 90% of the code in there is age old junk. It wasn't good when it was initially written (1997??) and it has never really been touched in all those years. There's crap like part of the zoning logic bleeding into the entire rest of the codebase and part of the culling logic being copied from object to object to object.

At that point, I made the fatal decision to clean all this up, kick everything that isn't working, and simplify things as much as possible. Now, a week later, things are finally coming together again but I'm still not sure whether I should have just left things where they were earlier. I like how things have turned out but it's really a whole bunch of changes--not the kind of stuff you do in a bugfixing rampage.

#86 " It wasn't good when it was initially written (1997??) "

tells me its a "bug" from 1997.....

"not the kind of stuff you do in a bugfixing rampage"?????

not to fix "90% of the code in there is age old junk"?????

would be an avoidance of bug fixing.........

continue Rene, its really interesting doing prehistoric code archaeology,

I'm curious how Moses ever got his raging Ark water game out, with all the bugs that where in the code when he got it back then, but at least now (2011 ano domine), a few of them are logged, for fixing, pretty soon they say too (before the next coming, I'm sure)....

#87 Deep; You'll just make the fanboi police upset.

#88 While huge, massive, enormous system design changes like the one you're undergoing with the zones/portals are scary before releases...they also are VERY NECESSARY. And frankly if you don't push through and do it now, it'll get pushed off for 1.2, then 1.3, etc.

Better to get it done now because if it doesn't get done now, it'll likely get done never. And that's not meant to be negative towards GG or T3D, it's just a reality in development. Something else "more important" can always crop up.

#89 Agree. I mean, there is the fact that changing a system always means introducing the potential for new bugs so when you want to stabilize something, it's usually good to change it as little as possible. But then, a huge part of Torque's legacy code has seen way enough "change as little as possible" and I'm kind of getting kind of sick of that.

Ok, back to trying to contain the fires I have started...

#90 Glad you're still behind recoding the whole zone thing Rene.

Quote:
a huge part of Torque's legacy code has seen way enough "change as little as possible" and I'm kind of getting kind of sick of that.

Totally agree with that sentiment too. A lot inside of Torque still needs work, some I would have hoped would have been taken care for Torque 3D. But some improvement is still an improvement :)

#91 agreed 100++

#92 Keep up the good work, Rene - my own bug-stomping frenzies have been known to stretch on for weeks (I create lots of bugs....). Hopefully this one won't take up too much more of your time so you can move on to other things.

#93 Great work, Rene. I can't wait to see this in the engine! =)

#94 Thanks for the encouragement, guys! Much appreciated.

So, one other thing (besides ambient lighting in zones) I kept thinking about was the need-for-non-box-shaped-zones thing that Dave brought up and I really couldn't make up my mind about it. In the code, the box-shaped zones work extremely well; it's lean, it's efficient. However, when you put it in real-world use with stuff that has rounded corners and non-square rooms, everything seems to devolve into a mess.

Then, in a conversation with Tom today, it hit me. I was thinking about it entirely the wrong way. It is important to keep in mind that zones are a scene optimization mechanism and nothing more, so it's not important for them to perfectly fit around stuff and completely correspond to your geometry. Whatever improves performance is the right thing.

So, to maybe illustrate this, here's a little picture:



There are other ways to zone up that space (probably more efficient ones too) and also other ways to tune things more, but it shows how it is important to keep in mind what zones are really there for.

Long story short, for now I'll keep things very simple and won't go into the ConvexShape stuff I mentioned above. Zones are boxes.

//Edit: Please ignore the grey horizontal above and below three of the rooms. That's a bug in Painter. Haven't noticed since it only showed in the downsized version.

#95

Quote:
keep things very simple

Considering how much of an issue zoning has been, I'd personally be happy for it to work as originally planned without going into any new and experimental funny shaped portalling.

#96 Yeah, I have to agree with Steve.

I'm looking forward to see it for real in my game;P

#97 Something that might be simpler to implement before delving into ConvexShape zones might be zone "groups". All zone boxes in the same zone group use the same zone index so if one zone in the group is visible, all of its siblings are visible too.

Of course, I'd rather have the basic boxes working first. ;)

#98 Ok, another quick update. I've completed my big refactor and am mostly debugging, testing, and refining things now. Things are looking good and the changes are stabilizing but more testing needs to happen before this can qualify for going on trunk. As for refactoring, there's more stuff I'd like to change but you have to stop somewhere.

For a rough breakdown...

• Lots of changes to how the high-level culling and render batching is set up. Much simpler than before.
• Completely refactored the old zoning code.
• Decals now respect zoning. Forests and terrains are next on my list of subsystems to get on board.
• I'm 50% of the way to have occlusion volumes implemented. They are a very natural extension of what's already there so I've taken them into the ticket.
• Kicked my initial approach to zone-based ambient lighting and am going for a very simple approach that overrides the global ambient color based on your current zone (want to get some blended transitions in place but might not happen for 1.1 final).
• Broke a couple of ties to the server/client scene setup. Lots more need to be broken. Ideally, after 1.1 final, there should be another refactor to finally get rid of all the hardcoded client/server scene setup so we can finally run single-player games in a pure non-networked mode. Torque does have well-designed networking, but the way networking bled into the entire codebase is a complete implemention fail IMO.

Quote:All zone boxes in the same zone group use the same zone index so if one zone in the group is visible, all of its siblings are visible too.

Interesting idea. Since it's a dead simple change in the current code I have implemented this but haven't got around to testing/evaluating it yet.

#99 @Manoel Neto:

Quote:All zone boxes in the same zone group use the same zone index so if one zone in the group is visible, all of its siblings are visible too.

Interesting idea. But i would go, as addition, also the other way around. Only the zones/portals in a activated zone-group should be considered by the zone-portal-algorithm. This way, the needed calculations can be limited.

@Rene Damm:

I am very pleased to see someone working on this must-have-feature.

#100 Keep hitting it with a big stick Rene!