Bad light faces with columns Created 9 years ago2015-01-15 12:14:56 UTC by Kaner

Hello,

I got this light result with some columns and it looks so bad

http://s7.postimg.org/wsb6nia2z/cs_gregorimaians0000.jpg

Does anyone know if there is any compiling parameter or something to improve it?

I'd appreciate it

Hi Kaner,

There are a couple of things I'd recommend here to avoid unwanted results like this. You may already have some of these applied, but perhaps one will be the golden ticket to fixing this.

Firstly, make sure you're compiling with the best compile tools available. At the moment, it doesn't get any better than Vluzacn's tools. I expect simply switching to these tools will fix your problem.

Secondly, try tying the pillar to a func_detail. If that doesn't work - try a func_wall. This will prevent the cylinder from cutting into the floor during the compile which is potentially what's causing your hard edges.

Thirdly, I'd always recommend compiling your radiosity with a few bounces for more even, natural lighting.

'-bounce 3 -extra'

is a good starting point, but you can ramp that number up and down to achieve different results depending on the scene. A higher number will produce smoother lighting, but will take the definition out of your shadows which is not always desirable.

Lastly, make sure all the faces on the cylinder are mapped to 'World' in the texture application tool (shift+a). 'Face' will sometimes produce odd results if you don't use it deliberately.

Hope that helps!

Really great information Archie! Maybe crank out some super-deluxe GS tutorials, while the all the info is fresh in your brain from working on The Core

If VHLT doesn't help then make the pillar with less edges or of larger diameter or scale down the texture, because lightmap grid size is 16 units for texture with scale of 1 so you want faces no smaller than 16 units to avoid smoothing bugs

anyway better not map your school u can get arrested ^^

There's no func_detail in goldsource, so it'll have to be func_wall (or func_illusionary with a simple square-section clip brush around it).

anyway better not map your school u can get arrested ^^

I don't think such a thing would be possible unless he lived in North Korea or something.

There's no func_detail in goldsource

Yes there is Stu, it's available with the new VHLT tools

Bruce
Didn't notice those pillars are like 14 sides, which is a lot for them being so small, nice catch 12 sides are the maximum I ever use for 95% of my cylinders and arches

That's new to me.

The Core literally wouldn't exist without func_detail.

If it does exist, why aren't we seeing any of it?

Actually, my works are full of func_detail, SugarMan.

If you download my only uploaded work here on TWHL, you will clearly see that I've used a lot of func_detail brush entities.

Without them, as Archie said for The Core, my prefabs and maps wouldn't exist without func_detail and VHLT tools. Literally.

Firstly, make sure you're compiling with the best compile tools available. At the moment, it doesn't get any better than Vluzacn's tools. I expect simply switching to these tools will fix your problem.

Secondly, try tying the pillar to a func_detail. If that doesn't work - try a func_wall. This will prevent the cylinder from cutting into the floor during the compile which is potentially what's causing your hard edges.

Thirdly, I'd always recommend compiling your radiosity with a few bounces for more even, natural lighting. '-bounce 3 -extra' is a good starting point, but you can ramp that number up and down to achieve different results depending on the scene. A higher number will produce smoother lighting, but will take the definition out of your shadows which is not always desirable.

Lastly, make sure all the faces on the cylinder are mapped to 'World' in the texture application tool (shift+a). 'Face' will sometimes produce odd results if you don't use it deliberately.

I'm using the latest vluzacn's tools, version 33.
I use func_detail and func_wall for pillars, and I also tried normal solid with 1 unity separated from the floor and ceil and it gets the same light.

I didn't notice before about the face/world kind of faces, but I checked all of them and they have already turned to world.

In addition I compile the radiosity with this:
hlrad.exe -texdata 524288 -lightdata 524288 -ambient .001 .001 .001 -extra -bounce 16 -estimate -verbose %mapName%

And I also tried with the -smooth parameter but I get fix some pillars but I get other errors in other many places.

If I fix it, I'd write here about it

BTW, the pillars are 16faces.

If VHLT doesn't help then make the pillar with less edges or of larger diameter or scale down the texture, because lightmap grid size is 16 units for texture with scale of 1 so you want faces no smaller than 16 units to avoid smoothing bugs

anyway better not map your school u can get arrested ^^

get arrested, why?

Offtopic: There has been a story that a guy got arrested for mapping his school in US i believe, charged with helping terrorism or something similar like that. This happened 4-5 years ago if i recall.

Offtopic: There has been a story that a guy got arrested for mapping his school in US i believe, charged with helping terrorism or something similar like that. This happened 4-5 years ago if i recall.

[OFFTOPIC]
Here in Spain, like student, I mapped my school, my high school, and 12years after, this time like a teacher, I map the high school where I work... no problem, it s just a game

Edited: Furthermore, the first school I mapped when I was a child was a catholic nun school xD

Yeah its a game, but that is a tiny chance someone might take it seriously somewhere.

hlrad.exe -texdata 524288 -lightdata 524288 -ambient .001 .001 .001 -extra -bounce 16 -estimate -verbose %mapName%

Just for my curosity, can you try duplicating your compile profile and simplifying your RAD settings to just bounce and extra? Also take bounce down to 3 and see if that improves anything.

What does the 'func_detail' entity really do in Half-Life 1? In Half-Life 2 (and other source games) I know it works as a non-visclip brush. But it doesn't even exist in the engine of HL1. It's only processed by the compile tools. Where I would have used a func_detail in source, I use a func_wall in GoldSrc. I do in fact use the VHLT compile tools, but I just want to know, what makes the func_detail superior to func_wall in HL1 GoldSrc?

It doesn't clip surrounding brushes, doesn't count towards the entity limit (func_wall does) and still casts shadows (func_wall doesn't).

But does func_detail still seal up world space to prevent leaks, like the func_detail in Source does not? Also, if you have ZHLT or any tools based on it, you can set any func_ entity to cast shadows.

It doesn't clip surrounding brushes, doesn't count towards the entity limit (func_wall does) and still casts shadows (func_wall doesn't).

Now func_wall and func_illusionary cast shadows with vluzacn tools, I also use this cs_expert-tom793c_wcModels.fgd

I will test the bounce when I get home

But does func_detail still seal up world space to prevent leaks...?

No entity will seal a level. Only world brushes will do that.

func_detail is not an entity, it just instructs compilers which faces not to contribute to visibility calculation

well i told you how to fix it. the only other way is to light it well from all sides

compiled with bounce 3 and same errors, I will do what Bruce said and I scale less than 1 the faces to consider the grid size of the lightmap

or try having like 8 edges instead of 16, then if smoothing works itll look even smoother than 16 god damn it lol

No entity will seal a level. Only world brushes will do that.

And yet, someone said it doesn't count towards entity limit:

It doesn't clip surrounding brushes, doesn't count towards the entity limit (func_wall does) and still casts shadows (func_wall doesn't).

And since it only exist with ZHLT or any tools built on that technology (VHLT), it doesn't exist as an entity in-game.
Can anybody please explain properly?

And yet, someone said it doesn't count towards entity limit:

If I'm not mistaken, it's still an entity as far as BSP is concerned, it just doesn't count towards the entity limit. Only world brushes (brushes not bound to any entity at all) can seal the world, end of.

i explained it ^

I'm pretty certain func_details in GoldSrc is only processed at compiletime by HLBSP, and then deleted (as an entity). Look through ALL of the HL1 source code, and tell me if you find anything that makes the func_detail exist in the engine. Becuase it doesn't. In Source, the func_detail entity is implemented by Valve, and therefor exist in-game.

thats what i said

No, you said func_detail is an entity, but it's not. Func_detail is not an entity in any way... Oh, before I forget, this is how I define an entity:
"A defined c++ clas linked to an in-game existing object with a classname."

No, he specifically said,

func_detail is not an entity, it just instructs compilers which faces not to contribute to visibility calculation

which is what you said.

func_detail is not an entity

you said func_detail is an entity

I mean, what can you say about this?

func_detail is an entity but its not an entity but it is an entity!

...but its not.

func_detail is treated like an entity in valve hammer/world craft but not by the goldsrc engine, so it does not count as model. It just a way to say the engine to don't cut the adjacent world solids.

https://developer.valvesoftware.com/wiki/Func_detail

func_wall is an entity and it also does not cut the world brushes because of its entity feature.

entity is not an entity because whore is not a virgin because gabe is not carmack and carmack is not dmr

Kaner, did u fix it?

woaw such c+++++ classes and phases god damn phrases but cant read simple letters!>_<

Finally I fixed it scaling the faces to 0.6 and the light went right on pillars

Glad you fixed it, and thanks for letting us know your solution What was the original texture scale btw?

The original scale was 1.0.
When you decrease the scale of a texture, allocblock increases.

I also reduced the texture size of the pillars to decrease the allocblock, original texture size was 64x64, and now is 16x16.

In my experience, there is no light difference between func_wall, func_detail and normal solid (normal solids with 1 u separeted from adjacent solids, if you don't do this, in this case, the pillar would cut the floor and the ceiling making in them wrong light results).

There is light difference between "face" and "world" mapped texture. I recommend "world" as Archie said before.

func_detail is treated like an entity in valve hammer/world craft but not by the goldsrc engine, so it does not count as model. It just a way to say the engine to don't cut the adjacent world solids.

https://developer.valvesoftware.com/wiki/Fu
nc_detail

func_wall is an entity and it also does not cut the world brushes because of its entity feature.

All articles on the VCD applies to Source.
It also doesn't tell the engine, it's the compilers that recieve the non-cut thing.
I think of brushes in a binary way. Either they are an in-game entity, or they are worl-brushes. Since func_detail doesn't exist in the engine, it's a world brush. So the func_detail must seal up World space and prevent leaks.

And yet it doesn't.

Or does it?

Seriously, if this is still being debated, why doesn't someone just test the damn thing?

It's already been tested, both here on Twhl and Sven-Coop, where Vluzacn himself is an active member. I still think they should of named the thing func_sadpanda; maybe then people would stop comparing to it's SDK name-fellow

wow orange youre such an idiot. thats the whole point of func_detail - not to contribute to visibility/not to seal maps. do you know why maps have to be sealed? so visibility can be calculated lol

Pretty much every one here has enough level design experience to know the ins and outs of func_detail, Orange. It's beginner stuff. Your silly, arbitrary understanding doesn't change fact no matter how much you don't want to admit it or understand it. They don't seal the world.

tl;dr: If a brush is anything but a world brush, it will not seal the level.

There's no need for personal attacks, Bruce & Crypt. Keep it civil, please. If you can't have a discussion without resorting to insults, you shouldn't be posting.

Sorry, not trying to come off as personally insulting, but the issue is entirely in the understanding, here.

It doesn't matter how one defines an entity in general, that doesn't change the fact that func_detail's behavior is perfectly observable in practice. It's arguing a point based on an incorrect understanding of something, completely ignoring what's actually happening.

Did someone just say Sad Panda?

Just... Don't call it an entity unless it's an actual entity in-game, okay?
Coming to think of it, what happens if you assign a brush to a non-existent entity? For example: func_sadpanda

you realize you misread what i wrote :z

I feel like I should point out that by that definition, info_nodes and unnamed lights are also "Not entities"