Basically func detail brushwork is ignored by everything apart from the vis tool. So almost everything which isn't sealing the void or subdividing your level should probably be detail brushes - unless it's a func of course. 

And when the vis tool detects detail brushwork it doesn't include it in the vis calculation. 

And when the vis tool detects detail brushwork it doesn't include it in the vis calculation. 

Thanks 

 

A new version is out! 

1. The BSP compiler ignores func_detail brushes when calculating the BSP tree for the VIS compiler to use, then it removes the entity information from the brush(es) making just another solid brush.

2. The LIGHT compiler sees it as a solid, end of story.

3. The VIS compiler doesn't see it because the BSP compiler never included it in the BSP tree calculations that vis uses to do its thing.

Try using the skip texture on it just to see something "Special" (or rather not see it). You will get an invisible brush that will cast a shadow. 

light with _color property not lit. Why? 

try color without the underscore. 

No, it turned out a different format from 0 to 255. I used to use from 0 to 1 

light format "_color" "255 255 255" worked, but not compatible with NetRadiant. Light entity looks like white light. 

255 255 255 IS white. try 255 0 0, does that display red? 

I mean the format of the parameter. No, "255 0 0" display as white. NetRadiant worked for format "_color" "0-1 0-1 0-1" 

nt 

in documentation with underscore 

No joke. 

I am using Tyrutils-0.15 and both properties work for me to give colored light. That is, I can either write the word color with or without an underscore and the results look identical to me. The numbers have to be in range from 0 to 255.

I just tested this with this example line inside a light entity declaration:

"color" "255 10 10" // it's a red light now

The light program produces a .lit file when I use the color properties in a map file, and I need to copy the .lit file alongside the .bsp file into the same directory for loading into a Quake engine. If I omit the .lit file I still get the lights in the map, but they are always white.

I'm using the most recent release version of Darkplaces to test the map & the lighting. I hope this clarified things for anyone having issues. 

This is a problem aimed specifically at tyrqbsp, so I would assume only Tyrann would know the answer to it, but if anyone else ever experienced the same problem or have any info regarding it, feel free to chime in.

My current map in progress, when sealed, produces a bogus error at the TJUNC stage of compiling with the message of:

---- Tjunc ----
************ ERROR ************
Degenerate edge at (0.000 0.000 0.000)

I really don't know what to make of this error, since the origin 0 0 0 of the map is located in the void. Curiously enough, when the map is unsealed it compiles without any error.

So without knowing what and where to look for the problem, I've hit a roadblock. I have sent you, Tyrann, a much more detailed description of this problem several days ago, but haven't gotten a response back, and figured perhaps you might see it here first.

I am using the latest version of tyrqbsp, along with Jackhammer as my editor. I am more than willing to provide you the .map file so that you may take a closer inspection of what the problem might be.

Or I suppose you can do what TxQbsp does and treat degenerate edges as warnings instead of errors. But I'd first like to hear your thoughts on what this error might mean, and what steps I can take to fix it. 

If it's at the origin and you haven't placed any brushes in that area, my guess would be that it's a rogue brush with zero size generated by the editor by mistake. Most editors have something that will check for problems like this and allow you to delete the offending brush. 

Most editors have something that will create brushes like this. 

Here are builds with two experimental features - these are unofficial, not approved by Tyrann or anything :)
-dirt support
-0-1 color format support

Plus some older fixes that are already in tyrutils git:
-lightmap coordinates fix for 64-bit binaries (only affects mac or linux builds)
-fix for writing a corrupted bsp when using wad3 (halflife) textures

win32 osx source 

awesome! thanks ericw! 

But I have a question. There was a bit of talk about doing some sort of radiosity with light.exe in quake when you first came up with the -dirt idea and it got me to thinking. Is it possible to do one or more of the following:

1) An invisible "Light" brush. I get that it "Can" cause problems with multiple faces and light types if it gets too big and it probably shouldn't be used with anything but a solid light (no flickering, throbbing or maybe even switchable). It works with _sunlight so I was wondering if it was possible to translate that over to other textures or if because of how sky is displayed that's too far afield.

2) A sort of "Fake" radiosity tied to specific textures like *lava and *slime by default. The way most engines handles liquids makes it look a bit off when it's in a dark location. Maybe even instead of default textures (like *lava or *slime) a way to set up a user created data file.txt that specifies specific textures that act like a "Light" brush above during the compile process).

Only spitballing here so feel free to ignore it. 

specifying light emitting textures? Defined by a text file given to the commandline. With all wait/delay functionality. Would help making spotlights for example. Just an idea. 

sounds like a great feature idea.
I could see either a command-line flag like "-lighttexture {texture light r g b wait delay}" or something, or having a list of these in a text file.
The quake2 light tool has it, (I think it's set as a surface flag?), and at first glance it seems to be intertwined with the radiosity support. It'd definitely be a bigger project than adding the -dirt was, but would be cool to do (as well as having radiosity)