empty space mayhem

(L) [2006/02/22] [Phantom] [empty space mayhem] Wayback!

I couldn't get a decent seat in the train back home, so I was forced to think. [SMILEY Smile]

First: My kd-tree compiler is having a major empty space problem. Image a situation where you have some big polygons in a branch, oriented in an L shape. If your compiler does not support flat cells, you're pretty much out of luck. SAH will say it can't do better than to put two polies on one side (one of which is a tiny slice) and one on the other side (the one that the slice was cut off of). So it won't split at all, as it has no notion of the importance of empty space.

So, I should support flat cells ASAP. What special provisions have you guys made to make those work?

Next, I was thinking it would be nice if I could help the compiler a bit. I know this is really dirty and all, but still I would like to know how much difference some human influence could make. Suppose I place a box in Sponza, right in the center, where all that void is. I could place and size it by hand, or I could place a rough estimate and let the program decide on the exact extends (growing until it's about to overlap geometry). Then, I would simply forbid the compiler to intersect that box with a split plane. That should be easy to test. There are two possible results: Either it gets the hint and cuts off empty space like I want it to, or it generates many slices of space just outside the box. Its simple to implement, so I'll place it on my todo-list, unless someone can tell me beforehand that the idea is crap. [SMILEY Smile]
_________________
--------------------------------------------------------------

Whatever

(L) [2006/02/22] [tbp] [empty space mayhem] Wayback!

Yesterday i've tried to track down what i think is my last remaining bug, but it's more elusive than ever. I do not lose triangles ever, splits are properly paired and exactly match scoring and clipping is sane etc. Yet, of course deep down the hierarchy, some pieces of triangles disapear on traversal.

So, right now, flat cells are disabled because of that (insert bird names) bug.

And i've produced a whole bunch of particularly annoying little scenes that none of my compilers get really right.

I see 3 options:

Some of those cases should be properly handled by a 'correct' SAH compiler.

Some of them are out of reach from said 'correct' compiler but could be automatically handled by some kind of pattern recognition, but that's at best a tactical fix (or put another way, local).

The remaining portion asks for non local adjustments (strategical adjustments i'd say), and that's where your untouchable box in the middle of Sponza stands.

I remember we've discussed that (heh, again) and at that time i was saying something about the user inputing split plane directives somehow.

But your untouchable box thing is way leaner and better fits within the SAH concept.

Addendum: Now, like you've said, i fear that freaking SAH is way too resilient, i've never been succesful trying to kludge/direct it unless that got integrated into scoring.

(L) [2006/02/23] [Phantom] [empty space mayhem] Wayback!

I just implemented that 'human interference empty space optimization' (HIESO (tm)) and it clearly shows how important empty space is: I got a solid 12% speed boost by placing a single block in Sponza... Obviously, it's a very simple bit of code: During tree construction, I first check wether or not the current node intersects any of the 'helpers', if it does, I check the split plane candidate positions against the blockers.

Easy win. [SMILEY Smile]
_________________
--------------------------------------------------------------

Whatever

(L) [2006/02/23] [Phantom] [empty space mayhem] Wayback!

Outsmart me? How do you mean?

I did get problems when I added more occluders by the way, and it's not too hard to imagine why: I added blockers on the balconies, but that doesn't work out. In that case I am basically making it impossible for SAH to come up with a good split, which results in some very bad nodes (lots of tris). Perhaps I should allow SAH to use the blocker boundaries as split plane positions, but I fear that this will negate the gains I got. I could do that by including the blocker as geometry, skipping the blocker tris when creating leafs. Perhaps I will try that later on.
_________________
--------------------------------------------------------------

Whatever

(L) [2006/02/23] [tbp] [empty space mayhem] Wayback!

I mean something like it would try furiously to stuff split planes around your blocker, because it feels the urge to cut the down the bloat at boundaries.

Even if that requires some trial/error/recompilation looping for the user it's quite handy. And in bigger scenes it should really really help.

empty space mayhem back