Game Development Community

[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.
img715.imageshack.us/img715/5185/screenshot00100000.png
Then i turn my head slightly to the left, and...
img715.imageshack.us/img715/1531/screenshot00100003.pngIt's gone.

If anyone knows the fix, could u please post it here.
Thanks.
#101
03/14/2011 (9:14 am)
Please keep working to get it into the final release. There are a lot of us non-programmers that need a very simple way to put a darkened room into our games. It sounds like you are our only hope. Thanks in advance.
#102
03/22/2011 (9:39 pm)
Quote: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.

By this you mean that it would hide any objects behind it from the camera POV? That would be awesome :D
#103
03/25/2011 (12:26 am)
Sorry for the delay.

Quote:By this you mean that it would hide any objects behind it from the camera POV? That would be awesome :D

Yep.

It's a box-shaped object with no visible representation except when in the editor. When in view, it adds a "negative" frustum to the culling data and thus hides everything that is fully covered by that frustum.
#104
03/25/2011 (12:32 pm)
So, use it to outline buildings and such to help speed up cityscape rendering?
#105
03/27/2011 (2:17 pm)
Rene, will your changes that you made be presented in T3D 1.1 final, or its even not an option?
#106
03/28/2011 (8:38 am)
I surely hope these changes make it into 1.1 final. A working portal system is ESSENTIAL to the engine.
#107
03/29/2011 (3:37 pm)
Sorry for the silence.

Here's a quick and very crappy video (ok, I say "quick" and then I ramble on about stuff for 15 minutes; would have been way shorter if I had saved on all the "mmhs" too). Sorry for the erratic "camera work"--I probably should have had one less cup of coffee before recording stuff.

Quote:So, use it to outline buildings and such to help speed up cityscape rendering?

Not so much outline than rather fill, but yeah, that's one example where it would be useful.

The occluders are primarily there to help with scene culling in the outdoor zone where portals don't really help. So rather than determining where you can look through, they say where you cannot.

Quote:Rene, will your changes that you made be presented in T3D 1.1 final, or its even not an option?

It'll be part of 1.1 final--at least all the changes that by now are complete.
#108
03/29/2011 (4:24 pm)
How do occlusion blockers interact with zones and portals? For example, I'm looking at lots of levels that have large vision-blocking objects (buildings, essentially) that you can also walk around inside. So kind of like Tribes's model, but denser and with more objects and stuff outside the 'interiors' that it would be nice to cull.

I'm excited for 1.1!
#109
03/29/2011 (4:38 pm)
Quote:How do occlusion blockers interact with zones and portals?

Both occlusion volumes and portals cause frustums to be added to zones. For portals, these are "positive" frustums that cause objects to be included whereas for occlusion volumes, these are "negative" frustums that cause objects to be excluded. Disregarding details, that's pretty much all that happens here.

Since to the culling the outdoor zone is just another zone, portals and occlusion volumes work the same way with either.

Quote:For example, I'm looking at lots of levels that have large vision-blocking objects (buildings, essentially) that you can also walk around inside.

Right now, if you put both occlusion volumes and zones/portals in the same space in a level, the occlusion volume will get assigned to the interior zones as well. It probably wouldn't really do harm as the volume would get rejected while the viewpoint is moving inside of it, but still, that'd be a setup that's not as intended.

I'm thinking about restricting occlusion volumes explicitly to the outdoor zone since that's really what they are for. With that change, you can just place a large occlusion volume inside your portalized building and not have to worry about the two starting to interact with each other.

When looking at the building from outside, the occlusion volume would kick in and when moving inside the building, the portals would do the work.
#110
03/29/2011 (6:57 pm)
Looking infinitely improved, Rene! Also a nice explanation of what all the debugging and rendering stuff does.
#111
03/29/2011 (7:46 pm)
Renee, I am really anxious for what what you have done.. It looks really great, one thing that has me wondering. In the video you mentioned about the ambient effecting on a global setting.

does that mean if a player enters a zone with a darkened ambient light it will effect the whole map? so in a multiplayer map the other players will see the ambient change if they are outside the zone?
or did I misunderstand what was said
#112
03/29/2011 (7:54 pm)
Quote:does that mean if a player enters a zone with a darkened ambient light it will effect the whole map? so in a multiplayer map the other players will see the ambient change if they are outside the zone?
or did I misunderstand what was said

Ah, my awesome explanations :)

The effect is only global in so far as the entire scene is rendered with the changed ambient rather than only those objects that are local to the given zone. It does not, however, actually alter the scene and is thus not visible to other players.

To put this into context, what basically changed is that where previously every bit of code that needed an ambient light color directly went to the sunlight and queried it, the ambient light color is now a property on the dynamic rendering state and is initialized from the current ambient light color in the scene. This color is dynamically changed as the viewpoint moves around in the level and it defaults to whatever ambient you have set on the sunlight.
#113
03/30/2011 (12:26 am)
Rendering happens on the client - so only the client in the darkened zone sees the darkened ambient. But to them, the whole scene appears darkened. Right?

And thanks for that explanation - this is all very exciting :).
#114
03/30/2011 (5:22 am)
thanks for the explanation. clears up a few things and I cant wait to see this in action


#115
03/30/2011 (7:15 am)
Quote:...I cant wait to see this in action

I can't wait to use it.... ;)
#116
03/30/2011 (8:35 am)
Quote:Rendering happens on the client - so only the client in the darkened zone sees the darkened ambient. But to them, the whole scene appears darkened. Right?

Yep, exactly.

Quote:Quote:...I cant wait to see this in action

I can't wait to use it.... ;)

And I can't wait to finally be done with it :)

But it's cool to see you guys care and I want this to be solid. It's always possible for adjustments and extensions being needed once something is put into real-world use, but the core must be sound and solid.
#117
03/30/2011 (12:15 pm)
After the core is in place, it should be possible to make the ambient light be constrained into each zone in Advanced Lighting. We just need to create a new type of deferred light:

- Renders before other light types;
- Renders as a box which matches the zone;
- Doesn't use blending: it just writes the ambient color into the light prepass;

I've been toying with the idea of crafting new deferred ambient lights (and other deferred light types, like capsule lights), but I was afraid how to deal with it in BL where those lights are impossible.
#118
03/30/2011 (12:47 pm)
Yep, perfect outline. Tom has the exact same plan.

I definitely didn't want to touch the rendering, though, as the culling changes are already pretty extensive and the current solution stayed within the bounds of the current rendering pipeline and is something that a number of games out there do as well (just noticed the same thing in Gothic 3 Enhanced Edition the other day).

But yeah, totally agree, that's the next step.
#119
03/30/2011 (9:07 pm)
@Manoel

Quote:We just need to create a new type of deferred light

Right... making an ambient light for the deferred renderer would take a day or two, but right now we have much higher priority issues to deal with. I worry a bit about the usefulness of only box shapes... but its totally doable and for BL you would get this cross fade.

Also while i was at it... i would add a checkbox to point lights to allow them to just cast ambient light. Very useful to dress up an area... but of course no support in BL.

If i get all my other stuff done and have very low priority bugs left... i'll kick and scream and see if they'll let me spend some time on this.

Quote:other deferred light types, like capsule lights
What i want to do is what Wolfgang did for the Rawk demo... ellipsoid lights. I think ellipsoids would be more flexible than capsules and much simpler to generate shadow maps for. Its basically just having an x/y/z scale on your point light with some tweaks to the shaders and shadows.

Also i *may* be able to squeeze ellipsoids into the forward rendered lighting where as capsules would be much harder, but we have to get used to the fact that BL will never have great fallbacks for AL features.

Anyway... thats yet another project i want to find time for soon.
#120
03/30/2011 (9:19 pm)
Oh, ellipsoid lights would be really sweet :D