Too much glass? Created 19 years ago2005-03-06 15:08:48 UTC by Patashnik

I'm in the process of making a short corridor framed by a series of arches (so it kinda looks like a tunnel) - but you can see the sky between all the arches.

Inbetween each arch there are 16 leaves of glass angled outwards like vents in a fan-like arrangement.

When I compiled the map with just one set of these vents between two arches, the map compiled just fine. But when I cloned all the glass leaves to fill up the gaps between the arches down the whole corridor, the compiler hangs at 'LeafThread:' for ages.

I don't suppose anyone knows why this is? Have I overcomplicated the map by using too many leaves of glass? Or could it be another problem entirely?

Can anyone explain what the 'LeafThread' bit in the compiling window actually does?

Many thanks...

It's calculating visibility things, determining what is visible from where to avoid having to draw everything all the time.

Are the glass panes entities? If they're not, I'm slightly suprised because entities usually aren't taken into consideration for visibility calculation.

If they're not entites, try tying them to func_walls.

Cheers for that seventh.

In the end I grouped all the glass together and tied them to func_walls and then did the same thing with all the arches and it compiled just fine.

Just out of interest, would you say it's good practice to tie all (structural/architectural) brushes to func_wall? What are the pros and cons of doing this instead of just leaving them as they are?

Thanks again...

Well, the pros and cons. Ok the pros is that the compile times will be quicker, the cons, is that the bigger the map, chances are that the func_walls will disappear, and reappear depending on the angle your looking at them from. The error "Short 55 Surfaces" will appear in the console. This also happens to rather larger, regular maps without func_walls considering the way it's compiled, so, this is rather undebatable, all depends how you compile

Anyone else like to add to that...?

Thanks Unbreakable, I think I get what you mean...

Would it be fair to say that (for example) the outer walls of your map, and the map's main structures, like arches, doorways, stantions etc should remain as normal, but any little miscelaneous details, like shelves, windows, fireplaces, pipes etc are better of being tied to entity like func_wall?

Does tying brushes to func_wall ever have any effect on the way the objects are lit by any chance?

oh, and sorry for all the dumb questions!

That would be a good practice, yes. However, func_walls do not block VIS so you cannot use them as brushes sealing a hull between the playable map and the void.

func_wall brushes do not block light by default, thus not casting proper shadows. In newer FGD and ZHLT builds there is an option field in their properties (under 'ZHLT Lightflags') for marking a func_wall to block light. This slows up your RAD process a bit but produces more natural and realistic lighting.

Pata, you shouldn't have problems with short x [surfaces/corners] unless you're running in the ancient Software rendering mode ? which you should almost certainly not be doing. Look in Options -> Video to change to OpenGL if you're not already using it.