Is there a downside to tieing func_detail to a group of steps?

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
In the map I'm making, I made the steps first and am now going back and adding func_detail to them. But it seems that you can't just mass select and tie the entity. It makes all of the steps a single object with func_detail.

Studying Doublecross and Turbine I noticed that all of the steps are individual func_details. So I'm guessing this is the best way, if not the only way, to do it.

I have hundreds of steps and it's going to be a task to do them all individually. So, I'm wondering if it would work just as well to make each set of stairs a func_detail instead of all of the individual steps.

Edit:
Also, which DX level is best?
 
Last edited:

Ida

deer
aa
Jan 6, 2008
2,289
1,372
Yeah, I don't think there's a way to convert all of the brushes to individual func_details in one process. What the makers of Double Cross and Turbine probably did was make the first step, convert it to func_detail and then copy+paste that entity to make the stairs.

Either way, one func_detail for a group of brushes should make no difference to making them all individual func_details. In fact, if I were you I'd rather tie them all to one entity so it would be easier to select the entire staircase at once. If you want to select only one brush from the func_detail entity at once, just press ignore groups (ctrl+w).
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
When the compiler computes the BSP, func_detail's are worked out individually. Each brush retains it's individual origin. Thus, when you decompile the map, perhaps as a result of the decompile process or likely the fact that func_detail's retain their individuality, the func_detail's will be presented as individual entities.

There is absolutely no difference between tieing groups or singular brushes into a func_detail.
 
Apr 13, 2009
728
309
func_detail's aren't even real entities as far as the game is concerned. Just a convenient way to tell the compiler to ignore some brushes for visleaf computations.
 

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
Thanks to all.

I just went through and put them in. I had been putting off optimization till the end but then I put this big complex of stairs in and my compile time went through the roof. Before with the the six staircases I had, the visleaf count was four digits. When I entered a square it would say something like "cluster 3198". Now with the stairs tied to func_detail, I don't think I have more than 900. That still might be extremely high, but I was impressed at how low they got.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Saving optimisation until last is often more counter intuitive than it is in saving time releasing each test version of your map. It takes seconds to throw down some hints or func_detail a group of detail geomtry and the action is perminant. Everytime you compile with detail world geometry you can waste up to 20 minutes. Give or take computer specs.

Optimisation starts with the layout and this is a fundamental. From there you make future optimisation simpler to implement (and thus faster to complete) and with more effective results.
 

tyler

aa
Sep 11, 2013
5,102
4,621
Yeah, it actually doesn't matter what map you decompile and look at, func_details will never be grouped. Displacements are also cut strangely if I remember right and several tool textures don't convert to what they should be (blocklight turns into nodraw, for example).
 

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
This is a new problem I have, but I won't start a new thread.

I normally run the map with VIS and RAD set to Fast. I just decided to do it at Normal to see if there was anything I might be missing out on by doing it fast all the time.

On Fast, my compile times are always under three minutes. On Normal, after 35 minutes it was still compiling. I didn't know if Hammer had crashed or what, so I ctrl-alt-deleted out of it. My cores were stuck at 100% usage after shutting down Hammer and I had to restart the computer.

Does this sound like Hammer crashed or is the time to compile discrepancy between Fast and Normal VIS/RAD settings that huge and I was being impatient?
 

Wander

L3: Member
Sep 16, 2010
148
55
The compiling isnt done in the hammer/sourcesdk process but with vbsp.exe/vrad.exe/vvis.exe
When you closed hammer, one of those was probably still running on 100%

I doubt something crashed, you probably have a whole bunch of small or weird brushes that arent func_detail so they make vis take ages
 

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
Thanks. I wondered if that might be the case so I went through and made as much possible into func_detail. I had a whole bunch of doorways with little fill brushes on the tops and sides. Still afraid to try Normal again though.

What's the main difference between Fast and Normal? Does Normal on VIS make it produce better and more efficient visleafs than Fast? And RAD (for lights right?) produces better lighting detail on Normal?

I noticed all of my displacements were lit weird so that was one of the reasons I tried normal settings.
 

Sebi

L2: Junior Member
Aug 13, 2011
65
13
I don't know much about vvis on Fast because my maps are always so blocky that vvis laughs at them :D.
But you certainly see a huge difference whether lighting is set to fast, normal, or final.

I think vvis on fast just skips objects it consideres too complex to calculate, or just does not cut every edge it finds. But this is pure speculation.
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
To get it out of the way, a common misconception is that VVIS cuts up the map and makes, it does not, that is part of VBSP's job. The leaves are what make up the Binary Space Parition tree that is its namesake.

VVIS performs two tasks, the second of which is the actual calculation process of determining what portals can see other portals, and that is what is skipped for fast mode. The first task is just a very rough basic vis setup that is enough for VRAD to do light bounces and for stuff that is completely on the other side of the map to not render. You will always want to compile on normal for releasing a map.

For VRAD you also always want to do normal for a release. The most obvious effect fast has is it doesn't refine displacement lighting and there is a black shadow along every single displacement seam. In general, I've found fast rad doesn't cut out enough time to really be worth it to me, as if I want to see how my lighting is I want it done right and if I don't care about light I simply don't run it.
 

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
From what I understand, displacements don't cast shadows. So I'm making a "skeleton" inside them with nodraw. Some of them look like good candidates for func_detail because they are cut funny and jut out. Does func_detail work on nodraw brushes?
 

A Boojum Snark

Toraipoddodezain Mazahabado
aa
Nov 2, 2007
4,775
7,669
Yes you can func_detail a nodraw, but if your only purpose is to make shadows using blocklight is better (it is a nonsolid material that casts shadows). However, displacements do block light that hits their visible side, so you shouldn't need to be doing that in the first place.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
You shouldn't really worry about the detail level of shadows, especially TF2 which will have many dynamic objects with their shadows disabled. At most, blocklight is utilised in areas where skybox brushes intersect geometry that should be casting significant shadow volumes.

If you want more accurate shadows then up/down the lightmap resolution. Default is 16, but you'll see 8, 4 and 2 in various places. Bare in mind that this increases VRAD times and light data so it should be used sparingly. On the same note, faces that are in total shadow can have their lightmap resolution set to something low like 64. With the face in total shadow, there's no point in having a high-resolution lightmap applied to said face; the primary execution of lightmaps is for crisp shadow shapes.

See existing sdk .vmf examples for... examples.
 
Last edited:

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
I guess I worded that wrong. I wasn't looking for accurate shadows. The reason I was looking for shadows is because it seems the displacements bleed light underneath and above. So I wanted something to block the light and in some rooms they also need to seal them.

When I focus on lighting, I'll be filling it with lights to avoid harsh shadows. It seems most TF2 maps do this. But my displacements that sit next a regular brush glow around the edges.
 

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
The thing is, displacements don't bleed light unless they aren't aligned at the seems. Light will not pass through the front or back of a displacement. If it was that way, making caves would be a bitch!
 

Robot3x

L2: Junior Member
Sep 8, 2011
51
3
These are some of the weird things the lighting is doing.

AlClp.jpg


In the above image, whether I have nodraw skeletons behind the glowing displacements or not they still glow.

6T3hs.jpg


iRkQW.jpg


In the above two images, when I have a nodraw behind it, nothing bleeds light. With out it, even the normal brush two the right bleed light.

Sw92h.jpg


I have a three sided displacement and the center is dark.

qPBrD.jpg


This door bleeds for some reason.
 
Last edited:

grazr

Old Man Mutant Ninja Turtle
aa
Mar 4, 2008
5,441
3,814
Displacements are vertex lit and world geometry are lightmap based shadows. This means that a lot of the time the shadows wont sync as their lighting is worked out seperately (They wont auto-blend). As far as i'm aware and this is of personal experience too, you can add displacements to smoothing groups but this wont work unlike with brush based geometry, which can focre shadows to sync/blend. But as long as you have aligning displacements and direct light sources displacements will 99% of the time have decent shadows calculated for them.

The light bleeding under the displacement is because of your lightmap resolution being so low that more of the lightmap under the wall recieves light than not; so the lightmap is assigned no shadow and this bleeds. IE the world geometry is bleeding light, not the displacement.

As for your door, light will do this because there is no geometry blocking light. That prop will not cast lightmap shadows because it is dynamic, so it casts a dynamic shadow, which is pretty buggy and looks ugly. Lighting in Source isn't that great to be honest, the game is very old and we're all waiting on Ep3 to come out with massive engine improvements.

The kind of work you're doing here, such geometry is better made out of models, where the shadows will also be automatically assigned to a smoothing group by the model author.
 
Last edited:

Psy

The Imp Queen
aa
Apr 9, 2008
1,706
1,491
Displacements are vertex lit

Yeah...no. They're lightmapped.

The most likely cause of the problem is the fact that the textures are not aligned, therefore, the luxels at either edge of the texture do not perfectly align with each other which can cause jarring transitions in lighting.

Also, make sure the lightmap scale is to a power of 2 (4, 8, 16, etc).
 
Last edited: