[bug 1.1a] Zones and Portals bugs - RESOLVED

#1 If you turned zone and portal visibility on in the visibility tab/button you could display the positions of them for a screenshot.

#2 Ok. There. (note: this map was only a test to demonstrate the bug)

(zone rendered through portal)

(zone rendered through portal from another angle)

(zone not rendered through portal)

(proof that they're connected)

(last, the position of me and my camera angle when bug occur with portals and zones visible)

Sorry for the image spam. If you need more proof, try it yourself.

#3 I getchya.

I think here's a clearer example.


Ignore the tree, forest editor placed shapes don't appear to cull - but it's a handy reference point in space/rotation though.

#4 Yeah, so is this a bug, or have i just done something wrong? And most important, can it be fixed?

#5 Most likely this is a bug in the zone code.

We'll be looking at it and see if we can patch it for 1.1 beta 2.

THREED-873

#6 Ok, finally getting round to this one. We have a whole bunch of reported issues tying in with the zoning code and I get the feeling it pretty much all boils down to issues caused by the Portal class.

I have yet to do quite a bit more reading and stepping through all the code but one thing I already found is that if you disable Portal's frustum generation code (i.e. make Portal::generatePortalFrustum always return the state's original frustum), then a major share of the magic disappearing acts seem to stop which points in the direction of the frustum adjustments done by Portal being incorrect.

But there's other things too. I'll keep you updated as I go.

#7 Awesome Rene!
Can't wait to see this bug get fixed (read: squashed) :D

#8 Great news.

While you are in this part of the code how about adding a zone parameter to allow us to use ambient light / not use ambient light within the zone? Easy to type, maybe not so easy to code!

Andy

#9

Quote:use ambient light / not use ambient light within the zone

That is a real nice suggestion. Or some ambient light modifier :)

#10 Really nice suggestion Andy

#11 I like the idea of being able to set the ambient light values within a zone independently of the rest of the mission.

#12 I doubt you're getting it ... though I'm surprised that no-one has come up with a cunning workaround (he says, narrowing his eyes and rubbing his chin ... and then realising that he really needs a shave ...) ... something about skinswap to a darker diffuse colour to fake ambient when moving inside an enclosed space ...

#13 yes I doubt we get it too , but doesnt mean we cant strongly suggest it too them and hope they put it in :)

#14 Ok, as far the core issue here goes, it's clear now that the problem comes down to the Portal class calculating incorrect view frustums and thus causing objects to incorrectly be culled out of the render list. Working on a fix.

Quote:While you are in this part of the code how about adding a zone parameter to allow us to use ambient light / not use ambient light within the zone? Easy to type, maybe not so easy to code!

It's a good idea and conceptually thinking, modifying the ambient contribution depending on which zone an object being rendered is in boils down to a few simple steps. Unfortunately, the way the whole rendering machinery as well as the zoning system is set up, it becomes a little more involved but I promise I'll at least take a look. I'm not so happy anyways how the engine handles the "special" (sun) light and has it affect things all over the place.

#15 Forest editor placed meshes culling? Not possible at all? This would increase a lot fps...
EDIT: don't forget to pass to Mich something for the docs about zones and portals when you get them fixed :-P

#16

Quote:Forest editor placed meshes culling? Not possible at all? This would increase a lot fps...

The forest rendering code already performs view frustum culling.

Quote:EDIT: don't forget to pass to Mich something for the docs about zones and portals when you get them fixed :-P

Mich is already going under but I will at least type a few quick things up in the script docs to flesh out the reference information for Zone and Portal a bit.

#17 It occurs to me that in a single-player game you could simply have the zone's ambient light values override the sunlight or other ambient value while the player is in the zone. For multiplayer games this is obviously not a workable solution -
"Hey, it's suddenly dark!"
"Oh, that's because Ted just went in that cave and that somehow turned off the sun."

#18

Quote:"Hey, it's suddenly dark!"
"Oh, that's because Ted just went in that cave and that somehow turned off the sun."

Lol :D!
It should work for multilayer, if they make the ambient switching client-side only :P

And btw. this is an awesome idea Andy, would solve some issues I'm gonna get.

Quote:I'm not so happy anyways how the engine handles the "special" (sun) light and has it affect things all over the place.

+1

#19

Quote:It occurs to me that in a single-player game you could simply have the zone's ambient light values override the sunlight or other ambient value while the player is in the zone. For multiplayer games this is obviously not a workable solution

Rendering is client-side only so it's actually not affected by what kind of client/server setup (local or remote) you are running.

What you suggest would be an easy hack around the current limitation but I'm not sure it would work very well since it means that ambient light in other zones will change in dependence on your current zone, i.e. the ambient lighting of a connected zone will be determined by the current zone.

#20 in singleplayer you can set up triggers to effect the ambient light when entering areas. its not a true elegant solution though