Quoth - make a func_wall, give it a texture called "skip" (Use newskip.exe after compiling), make a waterbrush in the same place as the func_wall, give it a water texture with a flat grey or white colour. Use a trigger_command to set "r_wateralpha 0.#" on mapload.

Cannot be done in vanilla progs without the player having to type a wateralpha value into the console. 

Will have breakable glass. func_breakaway FTW. 

On bmodels though. FitzQuake i think? Just set an "alpha" key on a func_wall - is the easiest way, and probably better than the water hack, because there is no waterwarp on a func_wall or other bmodel unless it has a water texture. GlQuake will do wateralpha, hence the water hack's universal compatibility. But you can have a nice glass texture is you use the alpha key.

RMQEngine
FitzQuake?
Darkplaces?
DirectQ? 

http://necros.slipgateconstruct.com/temp/split.jpg

i've mostly just ignored this kind of thing as down to the way bsp works... but is there any way to reduce or eliminate this seemingly needless poly splitting?
in the shot, the rock path is made up of 3 brushes per segment, the large center bit and the two small side bits, all 3 are split into tris. in theory, since none of the faces are larger than 240 in any direction, qbsp should have never split them at all, and just left them the way they were in the editor.
instead, you get that weird split in the center brush that runs up the slope until it meets the right-hand side where there are all these tiny little tris.

every compiler i've tried makes the exact same shape.
this is what it looks like in the editor, for reference:
http://necros.slipgateconstruct.com/temp/split_ed.jpg

am i just missing something? 

ok, in true necros fashion, i figured a little more out right after posting... -_-

it seems this has to do with how similar the planes are between those brushes. there's a setting in aguirre's txqbsp -epsilon that you can set to smaller to have more precision on identifying unique planes which reduces the unnecessary splits.
looks like if a plane is similar enough to another plane qbsp thinks they're the same plane(?) and tries to split it or somesuch.
unfortunately, even at smallest settings, it doesn't completely remove the extra splits. i think there must be a lower bound built into the compiler, since values smaller than 0.001 had no noticeable effect. 

.. you should directly contact aguirRe for this. He will certainly be really happy to help you ;)

It has indeed something to do with precision in clipping Hull (Hull 1 ?).. I've seen several test map compiled with different epsilon, and the lower it is, the better the rendering is (i.e smoother planes, less "corners").. though... it seems to not be valid for all maps..

Some quotes from aguirRe's TxQBSP readme file give a little bit more details


Improved handling of complex maps such terrain. This is done by increasing precision when identifying unique planes (faces) and modifying hull expansion logic. This reduces the risk of clipping errors and creates much smoother clipping hulls which can help player/monster movements.

All maps don't benefit from this, therefore two new options have been introduced; "-oldexpand" which just disables the new expansion logic and "-epsilon x" (default 0.01) which sets the plane identifying tolerance. To revert to previous compiler behaviour, just add options "-oldexpand" and "-epsilon 0.05".

The default settings have been chosen for overall best results. If you have a big map that still doesn't build correctly, you can try lowering the epsilon even more, e.g. 0.001. In most maps the default settings have little effect on # clipnodes, but some maps can see either a significant increase or decrease. Thanks to Tyrann for this one.

I hope it clarifies the stuff ;) 

you just cnped the text from his website. that's how i found out about -epsilon. :P 

... hence I suggested since the beginning of my post to directly contact aguirRe ;) 

If the -epsilon factor has to do with with monster/player clipping hull adjustment, then JPL's post makes sense. I think I now know why sometimes a player gets stuck on some brushwork ingame. It's sometimes not bad brush alignment, but maybe odd hull expansion the player gets caught up on. 

Personally I think what you're trying to do is overkill, to be completely honest. How many people are going to appreciate the little subleties of the corridor floor, especially when it's all plastered over by a low-res rock texture?

Maybe there's an easier way to get the same effect that uses less brushes and generates less splits.

Ideally you'd do this in a model editor and then import it into the map and fake collision somehow. 

You could make the floor-trim into a func_illusionary. This would make the floor a lot less complex, but there would be little or no visual difference because the floor trim cannot cast a shadow anyway. 

i experimented with -epsilon more and the original change i saw didn't have anything to do with it, but rather some change in geometry in another place that affected the spot i was looking at.

from what i can tell, -epsilon does absolutely nothing! i tried with settings of 0.5 and 0.0001 with absolutely no change in geometry.

i think the changes are very subtle and will only show up on a large, completed map.

hence I suggested since the beginning of my post to directly contact aguirRe ;)

yeah, i think i will now that i've had more time to look at it. :)

Personally I think what you're trying to do is overkill, to be completely honest. How many people are going to appreciate the little subleties of the corridor floor, especially when it's all plastered over by a low-res rock texture?

/shrug this is what i appreciate in maps, so it's natural that i'd do it in my own mapping process. subtleties, for me, is what makes a map great. if you walk up to a cliff and you see the edge has been beveled and there are chips taken out of it, that, to me, is far far more impressive than someone just making a flat cliff with a 1024x1024 texture. 

Is there a command to force VIS to cut off at a certain distance (which would be hidden by fog)? Can't find my copy of the tools readme :( 

hmap2 has -farplane 

tuna's fixed version of willem's modified version of aguirre's vis has -visdist #.

yeah, i totally just wanted to type out that line. ^_^ 

And everything seems to be going well except for the old "no textures in game" crap. Yes, I've got a worldspawn key for the texture wad, and I've put the damn wad in the id1 directory, the id1/tools directory (with the compile tools) and in the /id1/maps directory (with the maps) -- no dice. Any flashes of wisdom would be appreciated. 

Which compilers are you using? 

Using Tyrann's stuff at the moment. 

Turns out I just didn't have the entries to the used textures in the wad. Feel free to throw stones or other heavy objects. 

not stones or heavy objects, and not to belittle tyrann's tools, but there's really no reason not to use aguirre's stuff.
they are the most up to date.

http://user.tninet.se/~xir870k/txqbspbjp.zip
i have yet to see a more robust bsp compiler.

http://www.quaddicted.com/tools/wvis_20100119.7z
it has multi threaded vis thanks to willem's and tuna's tweaks.

http://www.quaddicted.com/tools/BengtLightColouredR2.zip
mh tweaked aguirre's light to have colour and multi threading while still keeping all the things that made it great like sunlight2, _anglesense, _softangle and delay 5. 

 

I'm glad you solved the issue because I think I was going to be useless in this case. 

_anglesense controls how much light lights up a surface depending on the angle it is hitting it.

for example, if you have an omni directional light placed 16 units away from a flat surface, only a small area around the light will be lit up with the light intensity attenuating quickly as you get further away.

reducing _anglesense will make the light care less about the shallow angle it's hitting the face on and light up the surface farther out.

conversely, bringing _anglesense up will make it affect surfaces less unless the light is almost hitting perpendicular to the surface.

this is useful if you have, for example, a spot light that you want to make look 'fatter' but need to keep close to a wall. setting _anglesense low will make it light up a lot more area.

it also makes faking nice ambient occlusion shadows easier.

_softangle is a spotlight setting. essentially, you get more control over spots.
'angle' sets the max cone angle of the light, but _softangle sets the area that will be 100% light (not counting distance).
so you set 'angle' to 90 and '_softangle' to 30 and you get a spot that's very wide, but with only a small bright area in the center with a nice smooth gradient, as opposed to completely blanketing everything in light.

these two settings alone make it impossible not to use the tool for me. i find them way too useful! :) 

Hopefully somebody can clear this up. I am familiar with how the event_lightning entity works, as explained on the forge here http://www.quakewiki.net/archives/worldcraft/entity/standard/std2.shtm#1

What I want however, is to have four lightning bolts go off at the same time. So I simply tried setting it up the same way as the first one I made which works fine, however only the first lightning bolt goes off, the other 3 that are triggered to go off, do not.

What am I doing wrong, or what is the trick with the event_lightning entity that I can have four go off at the same time? 

The chthon lightning is hard coded for one use only. If you want multiple bolts you might have to use the hack detailed here:

http://www.celephais.net/board/view_thread.php?id=37116&start=11&end=11