News | Forum | People | FAQ | Links | Search | Register | Log in
Colored Light Support In Bjp/aguirRe's Light Tool
mh did the amazing job and added coloured light (.lit) support to aguirRe's LIGHT tool. He also added multi-threading!

His post:

(note: this is version 2, if you had the version from Nov 3rd, this has some bugfixes)
And Because You All Are Reading This: 
The tools have hint, skip and detail brush support!

Please test those features and report if and how they work. 
Extra text from spirit's original post:

In case you missed it, there also is a multi-threaded VIS tool. Willem did the hard work and Tuna made a bugfix.


<Vondur> hmm 7 minutes instead of 32, pretty nice!
this deserved a news thread. :)

i did find one thing that i guess is an oversight:
_sunlight2 has no color settings. _sunlight2 isn't actually a sun, but sort of adds outdoor minlight by creating an array of suns (i guess) in a circular pattern. it would be awesome if this got a color setting like _sunlight does.
you could set a nice bright yellow _sunlight and then a blue _sunlight2 to better simulate outdoor lighting.

tools have hint, skip and detail brush support!

where are these tools? i can only see a link to a custom engine or mod. and would i have to give up bjp_qbsp? 
Quite hidden on the downloads page (simply says "Tools"): 
Detail Support?! 
Is this true? If so no map will have a VIS compile time > 15 seconds anymore and a new era of Quake mapping has started I guess. :D 
> _sunlight2 has no color settings.

_sunlight_color2 ;) 
re: 5

thanks for the link. i still don't see it on the main page. just 'downloads' which links to the mod and 'developer tools' which links to some weird stuff that i don't understand. so yeah, pretty well hidden imo.

re: 7

ah ok, i tried _sunlight2_color :P thanks :) 
Direct link to binary and source of this skip/detail/hint brush capable version please. 
Thx Spirit, I'd Love It If Detail Caught On Oneday... 
Opened the quakeforge tools source, looked in map.c for "detail" to find my answer... The detail brushes are exposed to the mapper with an "am_detail" brush entity, in the same fashion as in the Quest Ed tools ( ), as well as pOx's Mac-Carbon tools ( ) It's probably the same codebase. The Mac tools are especially neat because the detail entities have extra flags to make them double sided and pass-through, i.e. func_illusionaries that don't take up entity count, or not detail at all, just inert brush grouping.

This tech came out 6ish years ago and the main reason it never caught is that, even then, the neat features were bolted onto primitive compilers. The Mac version is the most improved and was actually quite nice but still had some annoying aspects like a 5120 brush limit. 
I Already Wondered... 
how this is done because the fields in the map format of Q2/Q3A that hold the detail flag are missing in the Q1 format it seems.

So it works like triggers and other volume-based entities if I understand Grahf correctly. Anybody know what I need to do to get the option into NetRadiant? I guess clicking 'Brush > Make detail' won't magically do this, hehe. 
will have to make a small map to try this out... 
will detail brushes cast shadows? 
@dfsp: In most Radiant variants I have used, you can enter a nonstandard entity name in the entity name field, and it should create an entity with that name. Or you could add an "am_detail" entry to your quake.def.

@gb: The only thing these detail brushes do is cut down on VIS time, they do not alter bsp cuts like "real" q2/q3 detail brushes do (I did some tests a while ago to confirm this). They are created like entities, but are added to the world during qbsp. So yeah, they cast shadows.

@mh: back on topic... thanks! One of the last reasons to sometimes not use bjptools has been eliminated. ;) 
Thanks Mh For Coloured Lights ! 
mh you did a fantastic job.. I've just tried them in worldcraft.. setup of colored lights is a breeze with _sunlight_color.. Q1 maps now come alive !

One doubt: .lit file must be always provided with the .bsp?

Quake engine with all these features added daily has just reached HalfLife standard !
Seeing my map with colored light.. thought have launched hl.exe by mistake ! 
One Doubt: .lit File Must Be Always Provided With The .bsp? 
Correct, yes. It breaks the BSP format if you try to include the new lighting info in it. 
..why So Few Replies ? 
..for a really handy feature

...anyway coloured lights rock ! 
too busy mapping.

coloured lights .., great!
I was waiting a while, because I had this "exceeded to many packages for vis" error.
It seems to be my map has gone to big.

mh - good work!
why not called it version 1.4? 
Hurra' For Colored Lights! 
But who really created that ?
mh, aguirre, i'm confused about this..

Anyway my current outdoor map with such lights looks like Unreal (!) if someone could tell me how to add colored volumetric fog _ 
No Volumetric Fog! 
Heh - you need an info_command entity to make fog.

If you type "0.2" on the console you will get thick fog.

If you type "fog 1 0 0 0.2" you will get red fog (R G B Density).

(assuming you are using a suitable glQuake engine)

You need a special custom entity to do it automatically in a level, called an "info_command". The easiest way is to use the Quoth mod. To make the entity for your own custom progs I wouldnt know where to start, but someone will ;) 
second line "if you type "FOG 0.2" on the console....... 
Or Just Add It To The Worldspawn. 
no info_command needed. 
hipnotic source should have that, iirc. Chapters, extras maybe as well. 
Ok.. I'll Go With Worldspawn Option 
It is no volumetric fog though, just plain fog that applies everywhere (depending on the engine). It also looks very different in different engine implementions. Can add a lot of atmosphere but don't rely do much on it because of those issues. Test your map in at least fitz, darkplaces and aguirre's glquake. 
no info_command needed

info_command can be used when you only want it foggy in certain areas - ie. turning it on & off as the player progresses through the map ('in vein' for an example) - which i think is what ricky meant. obviously doesn't work if you only want fog on the floor or in pits a la q3 
I stupid - I've been using an info_command for global fog! I used it with triggers in thehand.bsp go get red fog in an arena, and feint grey fog in the rest of the map ;)

My current project has some fog, and im using an info_command for global fog there too. Maybe I should change it to worldspawn 
volumetric fog, or something like it, should go on the list I think. Let's see how the bsp format thing ends up.

Not now, of course. 
has a colored fog in tree colours in the option console. 
Some Answers 
> But who really created that ?
> mh, aguirre, i'm confused about this..

As far as I'm concerned it remains primarily Aguirre's work; it is still his light tool after all; all I did was add colour support to it. But full credit for the original tool belongs to the original author.

> why not called it version 1.4?

I don't want to "take over" the tool (I'm not a tools guy for starters!); the original is still Aguirre's and if some day he releases an updated version then the next version number is his and his alone to take. This is release 2 of a fork of his 1.43, and nothing more. 
I think the tool's readme has a list of authors / inspirations. 
I'm No Biny 
I was just joking.

If i had been really smart, I would have wrote 1.44, or 1.5 or whatever.
I'm even not smart enough to get a coloured fog, or it would have been in worldspan with a colored light.

But that's not fog. Still fun to see it in Telejanos. 
What Happens If.. 
..I add worldspawn fog in a map and then a user play it in a no-fog engine ?

or much better if a user play it also adding a 2nd fog from options/menu in engines such TomazQuake/Telejano ?? 
Why did you cross post? 
Does using Fog do anything to engine performance? I'm guessing not, but would be fairly neat if it could make some larger areas run faster :E 
Normally fog has no effect on performance because the calculation of what is visible is performed by the VIS tool, which has no knowledge of fog levels. Somewhere (although I can't recall where) there is a version of VIS which you can instruct to mark everything beyond a certain distance as not visible, and this could be used in conjunction with fog in the way that you suggest. I'm hoping someone can fill in the blank of which version of VIS supports this. 
aguirre's vis has the -visdist # option that considers anything beyond that distance and invisible. 
Indeed.. It can be helpfull in huge map, unless the player decide to change the fog setting right ? 
I'd guess if they change the fog setting it'll just look cack as stuff will be cut off anyway, they can't change what the vis tells it to draw. 
i haven't really found it helpful at all. :(

i mean, on paper it sounds amazing but in practice, there's a lot more limitations to it.

first of all, it can't really be used for huge outdoor areas. if a visible face is disabled you see the void behind it. if a player hasn't turned off the old style glquake HOM void effect, that's what they'll see.
if they do have gl_clear on, stock glquake is birght red, iirc.
fitzquake and it's children have the r_clearcolor but this means your fog has to exactly match (or near enough) the palette colour.
also, when faces are enabled or disabled, it's instantaneous and quite jarring, even if the area is nearly fogged in. bits of the map just pop in and out.
finally, not all engines handle fog the same way, especially regarding density. so in one engine, you might have it set so you can't (or only barely) see geometry popping up but another engine the density might only be half.

mostly what i've found it useful for is when working on a map that isn't very vis friendly (semi outdoors, for example) so that a quick vis doesn't really change all that much. when you've got 20k wpoly, setting visdist to even a huge number like 2048 can still help out a lot. 
Well VIS times are still long but the multiple threads is awesome :D Wish I had a better CPU.

btw since this thread has some explanation stuff going, can someone explain the uses for 'Skip'? 
Any skip textured face gets removed by the skip tool, pretty much. It's useful with some hacks involving water etc. Unless that wasn't what you meant. 
Tricks And Rendering Savings 
Skip use falls into two categoies. One use is to reduce visible surfaces and so improve framerates. You would do this if there are surfaces that are always just out of view of the player but which vis decides need to be rendered. VIS always(bugs aside) errs on the side of rendering borderline cases. It's quite hard to actually find useful places for this - surfaces that are just touching the skybox but would never be seen by the player unless they cheat and fly is the closest I can think of a common use case.

Using it on func_wall (or similar) entities gives a better use-case as they don't have the 'outer-face-culling' that the world does. If you look at a hollowed out room in the world, the outside faces are removed because the player can never see them (assuming the world is sealed). However, if you build a door which opens vertically, the sides of the door are never culled even if they are hidden by the doorframe at all times. This is understandable because in general the compiler doesn't know anything about where your door will move to. You can put skip on those surfaces that you know you will never reveal.

You can also do this with the back faces of a func_wall embellishment which you embed in one of the walls of your level. Taking this idea to the extremes gives an idea I've never seen attempted but might be worthwile:
You want to connect two arched doorways by a section of 'trisoup' natural rock, but you find that the intersection of the curves and the rocks is creating far too many cuts and complex geometry which will be a nightmare to vis.

You then try the following: convert the entire rock section connecting the two arches into a func_wall, using skip textures employed in two complimentary ways to help you out. Firstly you create a simplified box outside your rocks, constructed of skip textures in order to seal the leak you just created without costing any polygons. Secondly you convert all the outer surfaces of your new rock tunnel func_wall to skip textures since they are no longer culled automatically.

Like I say, it's a speculative idea I've never seen employed. It would surely cut down on VIS time in that area. It might reduce polycounts in the area as the arches and rocks no longer cut each other up. However the func_wall construction would no longer have true visibility calculations, it would be rendered all-or-nothing which may cause overdraw in the areas where some rock was previously culled, so the saving depends on how much cutting used to occur. You might also get flicker and hall-of-mirrors if the func_wall is too large, which sometimes makes the engine too 'conservative' in rendering them. Lighting func_walls is also harder.

So that's the framerate saving it offers. There are also a number of gimmicks you can use it for. It can be employed in a similar way to clip brushes, but with the added effect of blocking projectiles as well as the larger objects clip blocks. This can help monsters walk over broken ground, but it stops grenades dropping through which can look odd. You can use it to create 'glass' as well, although it is probably best to do that with a func_wall rather than a world brush - VIS treats skip as if you can't see through it, and so might cull the other side of the glass as out of sight if you fully seal the pane with a world brush. 
and so might cull the other side of the glass as out of sight if you fully seal the pane with a world brush.

not only that, but it would remove the faces between the frame and the window brush so that there would be a band of void running around the inner edge of the window frame.

i've been using skip routinely in the bluelit map i'm working on. those 45 degree trim brushes are all func_wall with skip behind. sadly, i have forgotten to skip the backside of the func_walls so i will need to go back over them all.

sometimes, however, it's good not to skip an area. for example, if you had a flat wall with a func_wall covering only a small portion of it, it would be better not to skip the area behind the func_wall because it would cause the remaining bits of the flat brush behind it to be split up into multiple faces.

You want to connect two arched doorways by a section of 'trisoup' natural rock, but you find that the intersection of the curves and the rocks is creating far too many cuts and complex geometry which will be a nightmare to vis.

yes, this also has the bonus of sometimes getting rid of troublesome clipping problems.
brush expansion depends on the brushes next to the one being extruded. this can sometimes make a neighbouring brush to mess up the extrusion leading to invisible walls or just plain bumpiness.
the brush expansion is handled separately on a func_wall. if it was absolutely necessary, you could split up your trisoup into individual func_walls but usually it's enough to simply convert a small portion. 
Thanks for the explanation guys :)

I think I can probably find a fair few places to use such a feature around fiddly details that are behind clip brushes. 
Interesting idea, using skip like caulk basically. 
um, however, isn't that borderline obsessive - how much vis time will it really save? Also, mh's engine runs even the craziest maps at very good frame rates, so this might be unnecessary as engines evolve and computers / gpus become more powerful. 
Well my full vis time is getting over the 3 hours mark (not that my machine is particularly brilliant) and the map is barely half finished...

Well, my fault for going for a big outdoor area I suppose. Next time I'll just make isolated rooms and teleport the player between them! :p 
Put 90 Degree Bends In 
Your corridors ! That will help ;) 
Trying To :) 
I'm so used to Unreal 3, it's weird caring about line of sight so much :p 
Well my full vis time is getting over the 3 hours mark (not that my machine is particularly brilliant) and the map is barely half finished...

You think that is bad? 
I don't think the rock trick is that obsessive once you start calling it what it is - which is displacements in quake. The reason more modern engines can render these kinds of surface at higher framerates is because they keep them as separate meshes and lose all the baggage that the complex vis process in quake creates (long precomputation and unnecessarily high polycounts). It's not like it is a particularly arduous task either as long as you plan it from the start - just apply the textures once on the triangle you clone the whole mesh from. 
3 Hour Fullvis 
is perfectly fine. it's when it starts taking days you have to worry about optimising 
You think that is bad? 
hmm, I hit the wrong button there...

I already cut the map in half cause it was too big, so yea, I'm worried about just how bad it'll get :) 
Do You Want Me To Take A Peek At Your Source? 
I could tell you if there are any optimisations you could make which you didnt realise 
Nah It's Okay :) 
Hoping to release a WIP soon anyway as I've changed so many gameplay aspects since my old test. I expect people will point out plenty of flaws there anyway :D 
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.