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) 

 

I think i used that on my first map.. but it's old, the source isn't available, and the readme says it's derived from Valve's q1rad so it woudn't be possible to combine with a modern gpl quake1 tool anyway.

The quake2 qrad3 is GPL'ed though: https://github.com/id-Software/Quake-2-Tools/tree/master/bsp/qrad3 

I implemented this in the last version of MHColour, but instead of emitting light the radiosity was used to tint the already existing light data. It's easy enough to do and you can just butcher the code and get something that works up and running quick enough. 

I looked at that and while it sort of does the job there is no control over it (re specific textures for example) specifically because it "Does" use pre-existing lights. The user also can't specify any textures to ignore or add.

It worked pretty well for generating .lit files for .bsps where the source files weren't available but quite honestly the hues and intensity of the colors weren't really to my liking about 80% of the time. Too much like Q2. As I've said before with Quake and colored lights, less is almost always more. It ain't the Las Vegas Strip. It's what you might find deep underneath the Las Vegas Strip after a bad night out.

I was thinking of something that didn't use a light entity (in the traditional sense) at all but turned the top face (or any face exposed to "Air" I suppose) of a brush into a light all by itself. 

In fairness that's all it ever really set out to do. The last version was a good deal more subtle than earlier versions, but I'd guess about 50% of users preferred the stronger colouring.

In general I agree - mapper control of lighting in the tools and at the compilation stage is the correct way to go, and MHColour was never meant to be a replacement for that.

Despite all the above the theory is still applicable - it's just tracing the BSP between points, then checking distance and facing, after all. 

I'm pretty sure nobody's mentioned this yet.

So I tried out the fancy hacked dirtmapping and got this:

http://lunaran.com/pics/fitz0061.jpg

That's looking at the corner of a room. The diagonally opposite corner looks correct, and the two remaining corners are wrong on one plane or the other, almost as if the sample points are off by one in a positive-axis direction. 

 

I also get some problems with a box map:
-lit -dirty -dirtdebug: http://i.imgur.com/q6ggYIe.png
-lit -dirty -dirtdebug -extra4: http://i.imgur.com/mmEszwv.png
Quakespasm is hacked to show lightmaps with nearest-neighbour filtering.

One issue is, even with extra4, the left and right walls don't get any significant dirt applied at the edge with the back wall. Will look into it.. 

This might be related to some other problems I've been having for a while with tyrlight. Here's just sunlight, no dirt:

http://lunaran.com/pics/fitz0063.jpg

Opposite corner from my previous screenshot. Note that those blocks are not floating.

I would really like to say when I started seeing this kind of thing, because I know it happened after I tried to get the latest compilers six or eight months ago, but I've tried to reproduce the collection I had before that and I still get those gaps and bleeds, so I can't actually prove it's a change in some compiler that's done it.

eric, what are you BSPing with? Do you think it matters? Utter conjecture here, but could some subtle difference in point quantization or double rounding in the BSP phase cause the lightmap sample origins to fall on the wrong side of a face or become coincident with an edge in a microscopically unhealthy way? 

p.s. the poorly shadowed corner in 0061 is the -x,-y corner, and in 0063 it's the +x,+y corner. 

I think I understand the dirtmapping glitches on my box room, at least. The problem seems to be the raytracing code in tyrutils is unreliable when sample points lie exactly on a plane separating the void from the map interior. (but unreliable in a consistent way, so in some directions it works) Unfortunately, you get these quite a lot of these void-straddling points with the way the sample points are positioned:
The sample points for the west wall of a box room, for example, are distributed in a grid that's pushed 1 unit into the middle of the room, so most of the points are free-floating in the map interior as desired. The problem is, the columns of points on the north and south edges lie exactly in the plane of the north and south walls, and same goes for the row of points along the floor and ceiling.

The one thing I tried as a fix, which is admittedly a coarse-grained fix, was replacing the trace code with LordHavoc's from his hmap2 compiler, which seemed to magically fix the dirtmapping glitches. It seems it can consistently deal with sample points straddling the void and treat them as within the map, which would be good.

Could you send me the map for 0063.jpg? (or just that section of it?) I'd like to see if I can fix that bleeding is the same way as the dirtmapping glitches.

For bsp I'm using snapshot I posted in #113, osx version. I don't think that's a factor, though I can double check on windows. 

Looks like that glitched shadow in fitz0063.jpg was introduced in TyrUtils 0.7, in commit cc36d8e. I reverted part of that commit and it seems to have cleared up the holes in sunlight shadows as well as fixed up the AO.

win32 osx source

The dirtmapping looks way better in this snapshot than the previous ones! It looks reasonable now without -extra4. 

https://www.dropbox.com/s/5hmx6nortmhkksb/fixed.jpg?dl=0 

God, OUTSTANDING.