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)
First | Previous | Next | Last
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 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.