func_detail vs func_brush

[Psy]

A glimmer of hope

Down from 3% to 1.5%.

 

[JoshuaC]

Is this the only section of the map with these details? Surely it'd take alot more than that to max it out.

 

[Psy]

Of course not. Don't be silly.

I have quite a lot of similar details around the map and I'm going around reducing the amount of t-junctions. The entire middle section of Stage 2 has a whopping 30% of the total allowed water indices and having a run around I can see why.

 

[Psy]

Wow. I've just compared my newly optimised version to the previous version that was causing problems and within the exact same volume of space I've managed to cut down water indices from 32.4% to 18.7%.

<yayface>

 

[Owlruler]

congrats, I expect better framerates therefore in the next version

 

[Sgt Frag]

Yeah, I was pretty suprised when I figured out you can acutally get more details and better performance.

Glad it helped that much, now you can add tons more detail

 

[Psy]

I've done a little experiment comparing a normal compile to a compile with the -notjuncs switch.

Here's some images.

Without fixed t-juncs
Normal
Wireframe

Normal compile (with fixed t-juncs/waterindices)
Normal
Wireframe

What's interesting is that fixing t-junctions is done in order to eliminate cracks between faces but when I had a look around the map without any fixed t-junctions I couldn't see any cracks at all.

Not to say I will compile my map without fixing up t-junctions but I thought it was worth posting.

 

[Terr]

I'm curious whether running in super-low resolution with no antialiasing would exhibit cracks.

 

[Psy]

Apparently not.

Hmm.

 

[UKCS-Alias]

Why dont you make all vertical beams world brushes. They also provide some optimization for you. And as they are vertical they often dont couse a massively longer compile. Diagonal ones better remain func_brush though.

Terr's displacement idea is fine also, makes it look better also.

 

[JoshuaC]

Using displacements on a beam like those is a bad idea due to the fact displacements use slightly bigger lightmap scales than regular geometry. Also displacements usually contain more polygons per face due to their nature.

 

[Psy]

If you're coming up against the t-junction limit I assume the map is either very large or densely populated with world geometry (converted to func_detail). Goldrush came up against this limit after final art pass.

There's no single way to resolve the t-junction issue. I'd recommend starting by removing some of the func_details (either deleting or converting to world geometry) to see if that helps fix the error. This will of course increase compile times and lose some of the benefits that func_details give you at run time (not directly cutting up world geometry and creating less vis leaves). This can be done in combination with func_visclusters to help keep compile times down by merging vis leaves within their volume.

It may be worth considering performance optimizations at this point if there are areas with a lot of func_detail work that run slower on low end machines. Pruning some of the detail here may just give you the head room needed to sneak under the limit.

If that's still not enough consider turning some of your geometry into models. Especially if you have a lot of repeated func_detail work that can be modeled. Models generally render faster than world geometry with the caveat that too many meshes isn't good either.

Straight from the mouth of Valve.

 

[Swordz]

When i got the t-junction, i deleted some func details. Worked, then i changed then back to func details, no errors, lol

 

[re1wind]

@ your original post about func_brush casing lightmaped shadows but ignoring vertex lit models: Try placing a world brush with texture block light over the func_brush.

 

[grazr]

Using displacements on a beam like those is a bad idea due to the fact displacements use slightly bigger lightmap scales than regular geometry. Also displacements usually contain more polygons per face due to their nature.

Do you mean bigger, or smaller? Because bigger shouldn't be a problem, especially if we're talking about small details like trims. As for displacement alternatives. We're talking about compromise to get a valid compile here, not an outright solution. But as the Valve quote says, if it's really that bad. You'll want to convert stuff to models. most of 2fort's support beams are actually models.

 

[psihomir]

I've done a little experiment comparing a normal compile to a compile with the -notjuncs switch.

Here's some images.

Without fixed t-juncs
Normal
Wireframe

Normal compile (with fixed t-juncs/waterindices)
Normal
Wireframe

What's interesting is that fixing t-junctions is done in order to eliminate cracks between faces but when I had a look around the map without any fixed t-junctions I couldn't see any cracks at all.

Not to say I will compile my map without fixing up t-junctions but I thought it was worth posting.

The cracks are most obvious in spots where there's strong light behind them, but this picture should've showed some. They come up as tiny dots forming a line, if you haven't seen them. They were common in the GoldSrc engine.