[bug 1.1a] Zones and Portals bugs - RESOLVED

#121 I like the new stuff so far Rene. Great work! Scared me the first time I placed a zone and the terrain vanished, though....

And then I didn't quite get my portal situated correctly and for a split second as I passed through it my terrain vanished again. But I moved things around and so far, it's awesome!

#122 Really glad you like the changes. You're probably also going to like this "teaser" then:



I haven't been happy with several aspects of the zones&portals stuff which resulted in a bunch of improvements and fixes.

//Edit
Ah, BTW, there is a bug in the terrain culling in the 1.1 preview which caused stuff to disappear when it in fact should not. I believe I have it fixed in the current code but need to test it more.

#123 farkin' A yes! thank.you.

#124

Quote:farkin' A yes! thank.you.

Hehe.

#125 Huzzar all round!

#126 Rene, since you seem restless... as said there...

How about adding "automation" of zone/portal into the collada pipeline?

Something simple as having a mesh with a special name automatically transformed into a zone or portal at .dae import stage.

Same way as we work with collision meshes...

That way this would pretty much replace the way people portalized with simplicity the interiors...

#127 How is it going? Are the occlusion meshes in? =)

#128 I like Giorgio's idea - if it's possible that'd rock!

#129 Things are looking pretty good. I'm going to record a new video soon--this time with less "mmhs" and more actual information on how to use the stuff.

While at the time I recorded the last video it seemed that things were pretty much reaching a finish line that ended up actually not being the case. When I started implementing the occluders for real (not just the object and frontend parts), I found a number of issues with the approach that the system had taken (building on how Torque used to do the culling). I had also learned a bunch of lessons and realized that a couple of things weren't optimal at all.

So, long story short, I did a second pass over the system switching a lot of the internal culling mechanics and adding a lot of new capabilities. Here's a rough summary of what changed:

• Support for arbitrary convex polyhedral spaces (zones, portals, occluders, sound spaces)
• Support for Ngon portals
• Much improved rendering and feedback in editor
• Vector light issue fixed that the 1.1 preview still had under AL
• Much more efficient and precise culling
• Zone grouping now works

At this point, only two tasks remain:

1. Add "steep angle optimization"; this greatly helps improving the efficiency of clipped portal polygons
2. Implement perspective-correct silhouette extraction for occluders

The second one is the only thing that remains to get occluders fully functional. ATM, they just about work in orthographic projections but that's really only of use for shadow passes.

@Richard
Possible, definitely! I'd say it's not in the books for 1.1 final but the infrastructure is all there so this is definitely within reach.

#130 Ehy... :-)

Quote: I'd say it's not in the books for 1.1 final but the infrastructure is all there so this is definitely within reach.

...Looking at a post from Tom :

Quote: For T3D 1.1 you will be able to convert a Convex from the shape tool to a zone, portal, or occluder and back to a convex.

That make me happy... Very happy! ;-)

#131 To continue to bore you all with irrelevant implementation detail, here is a shot demonstrating the current state with occluders. It shows how they essentially work but how the silhouettes not taking perspective into account leads to culling errors. Hope the window opens up to add that one last thing.

BTW, you probably also notice that very apparently the forest items are not getting culled. This is simply because at this point, while forests take zoning into account, they still cull only against the "root" culling volume (i.e. the view frustum). You can see, though, how the terrain already culls out. Problem with these subsystems is that they have their own internal subdivision and traversals and need to be integrated with the new stuff one by one.

Quote:Quote: For T3D 1.1 you will be able to convert a Convex from the shape tool to a zone, portal, or occluder and back to a convex.
That make me happy... Very happy! ;-)

Hehe. Yep, Tom requested that feature and it was real quick to implement. You can now easily go around and switch zones/portals/occluders/sfxspaces between editable and not.

#132 You'll never bore us of these updates. Looking forward to the fully functional occluders!

#133 can/will these be "mountable"?

like to vehicles, to keep things like groundCover and tree branches from entering?

or to a player?

#134 While the object itself could be mounted via the SceneObject mounting methods, doing so would not be useful.

Quote:like to vehicles, to keep things like groundCover and tree branches from entering?

The occluders work at somewhat of a different level. Like zones (mostly) and portals, they are purely a rendering optimization mechanism that works at the object culling stage, i.e. it rejects whole objects (or in the case of terrains, chunks of an object) when it can determine they are definitely not visible.

What you have in mind here would have to be achieved in a different way where, for example, special geometric objects such as the forest items, are made to react to collision volumes being swept through them.

#135 And voila (*), that's how it looks when it's working:



You can see the shadows and the icons of the shapes being culled away. Also, note that like zones and portals, this isn't just working with box-shaped stuff but with arbitrary convexes too--though you need to be pretty careful since every additional edge incurs an overhead. I'm going to say a bit more about this in the soon-to-be-posted video.

If you're wondering why the shadows are still there, that's actually an interesting problem. The AL shadows are rendered from the perspective of the light and since the sunlight can see those objects, they are rendered into the sunlight's shadow maps. Then, when the diffuse pass is rendered, there are no objects nearer to the viewer that are obscuring those shadows, so ergo, those pixels there get shadowed.

However, while correct, it is suboptimal as time is wasted on rendering stuff into the shadow maps that cannot affect the final render. Tom showed this to me and it turned out this is a tricky little thing to solve as it basically requires changing the shadow render's culling state based on the diffuse render's culling state.

But that's an optimization for post-1.1 times...


(*) French guys and girls, please excuse... no à on this forum :)

#136

Quote:The AL shadows are rendered from the perspective of the light and since the sunlight can see those objects, they are rendered into the sunlight's shadow maps.

The question is... Are the shadows culled from the perspective of the light? For example, let's say we place a occluder covering a building, and there is a man in the side that's opposite to the sun, covered by the shadow of the building. So from the perspective of the sun, the occluder covers the man. Does he cast any shadows?

I'm not sure if I'm clear, if not, I'll try to make some graphs showing it. Anyway, apart from that, awesome job, I can't wait for 1.1 =)

#137

Quote:The question is... Are the shadows culled from the perspective of the light? For example, let's say we place a occluder covering a building, and there is a man in the side that's opposite to the sun, covered by the shadow of the building. So from the perspective of the sun, the occluder covers the man. Does he cast any shadows?

Short answer: No :)

Long answer: For an object to cast shadows, it needs to render into the shadow pass. ATM, every shadow-casting object that is visible from the view of a particular light is rendered in those passes. However, the same culling system (including portal culling and occlusion culling) that is used for diffuse rendering is also used during shadow rendering so if, for example, the sun can't see into a particular zone, it won't render into the shadow pass. The same goes for objects that, according to the sun, are hidden by OcclusionVolumes.

Unfortunately, your example contains a bit of a catch. OcclusionVolumes are built to hide stuff *behind* them. However, in your example, the man is standing *inside* the OcclusionVolume. In that case, whether the man gets culled or not depends on whether he happens to be behind the "near capping plane" of the occluder or not. This cap usually starts somewhere inside the OcclusionVolume.

This is probably confusing but the easiest way to think about it is to picture OcclusionVolumes as being solid. If you place something inside the solid, things start getting ambiguous.

In fact, the setup in your example is probably better served by zones and portals.

#138 Addendum: While this really is nitpicking, even if *everything* would be rendered into the shadow pass, the man would still not cast shadows since the building is nearer to the light and covers all of the man's pixels. All this stuff here (zones, portals, occluders) is only there to speed up rendering, not to affect what's visible and what isn't. In fact, with a proper zone/portal/occluder setup, the only difference between having and not having it should be render time with no change on screen.

#139 Thanks Rene! Can't wait to try it, I'm doing a big optimization pass before the release of the demo of our game, and some more extra performance would be great =)

#140 Why not put a marker onto what is currently occluded? As in culling like previously mentioned, but mark each object that IS NOT visible as CurrentlyCulled. Then anytime a CurrentlyCulled is true during the shadow pass cull it from the shadow pass also. By checking this mark, one could skip occlusion calculation on a object for a number of frames, then after say 500 (whatnot) retest that shapes occlusion, to keep CurrentlyCulled as fresh as possible. One would be done with lights bleeding, odd shadows and perhaps an occlusion calculation time improvement... (hmm, perhaps even... now we can have sounds properly blocked by objects?)