if you split a brush in half, but the texture is the same and the sides are still coplanar, will they be split in game or will they be recombined by qbsp?

ie: you're using two sides of a brush for a wall, but one side has trim and the other doesn't, the trim side will obviously be split because the texture will be different, but what about the other side that has the same textures on both new faces? 

My next map will also have leaning crates, haphazardly abandoned bricks, and fallen beams, but unlike Mike it will not be on purpose. :( 

In general, they will be rejoined by QBSP if they are coplanar, have the same texture, and have the same texture stretch, shift, and rotation.

However, if you're just making a column in the middle of a room and split it horizontally so it has a cap with trim on one face, then it's quite possible that QBSP would go ahead and split all the other sides of the column, too. 

Marcher: The Compiler's Cut 

This is a shot of Marcher's geometry in hull 1 using the original brush expansion logic:

http://img214.exs.cx/img214/4742/oldhull1ri.jpg

This is the same area, in hull 1, using the new brush expansion:

http://img222.exs.cx/img222/4244/newhull9co.jpg

'nuff said o_O 

Thanks to aguirRe for the above screenshots :D 

I've tested last week a "beta" release of aguirRe's new TxQBSP tool, and I noticed some improvement in VIS process.
Accordig to aguirRe, it seems it was pure coincidence, but.. I'm not convinced... so I just would like to know if anybody noticed this kind of effect ?
I saw that with this new expansion logic, VIS runtime process was reduced... For long process, winning some few percents for the "base start value" is a real gain in global runtime... So anyone noticed something equivalent ? 

bloody hell! 

... 'kin' 'ell! 

Hmm. Surprisingly, that second one actually looks like it's built correctly by QBSP. Who'd have thunk it? 

yeah, I have yet to try this out on my own terrain map, but it looks very sweet. 

I've posed on a few sites and havent gotten anything helpfull, i pray you can help.
I'm trying to edit for jedi academy, got 1.5.0 but doesnt load everything... 1.3.12 is good on the textures, but i have a worse problem, i cant move around in the 2d/3d window using the right mouse button (whenever i click/hold it and try to manipulate ether view it ether goes straight down in the 2d view, or straight up in the 3d view.) the last place i posted i was told that its possible to change/swapp out a config file or something... sounded pretty halfbaked, but if anyone can help me i will be in your debt! thank you for tryin =) 

I've been trying to install the quakecapture_bin_20040801
This for making some demofiles editing.
I installed the programm, but when I touch glquake I enter an icy Quake world.
Only the sky texture comes through.

http://members.home.nl/gimli/quake12.jpg

Is there a way to get the texture back? 

adding option -no8bit. 

That works. 

and other engine problems are also listed in my latest ToolTips, Engine section. 

Just this on iddevnet.com, some doom3 mappers may have missed it? Anyway it explains all the doom3 compile vars and their effects, very handy to know...



glview Not implemented
v Print extra information as the map is compiling
draw Render the level as it's compiling (not sure if this works anymore)
noFlood Don't 'flood' the level marking outside surfaces invisible
noLightCarve Don't carve geometry based light volumes (default)
lightCarve Carve the geometry based on the volume of the lights that touch them
noOpt Don't optimize (merge and cut) triangles
verboseentities Print extra information about entities (more so than with just verbose)
noCurves Don't process patches
noModels Not implemented
noClipSides For debugging, don't clip the sides of a brush to other solid parts of the world
noCarve Don't cut up any surfaces (like adding noFragment to every surface)
shadowOpt <n> Set the shadow optimize level:
0 - No optimization
1 - SO_MERGE_SURFACES (default)
2 - SO_CULL_OCCLUDED
3 - SO_CLIP_OCCLUDERS
4 - SO_CLIP_SILS
5 - SO_SIL_OPTIMIZE
noTjunc Don't fix t-juctions. (Triangle optimization won't work without t-junction fixing)
noCM Don't generate .cm (collision) information
noAAS Don't generate .aas (pathfinding) information
editorOutput Pipe status messages to the editor window

Might look into the settings and perform some tests too see if the different ShadowOpt <n> settings and LightCarve actually are worth doing 

i was using your light util today and all of a sudden, it started making my map pseudo fullbright.

what i mean is that it's not a 'real' fullbright like when you compile a map with no lights or do r_fullbright 1 in the console.

not clipping outside the map turns the viewmodel dark like it normally does, and overbright lighting in winquake and fitzquake is visible, but everything lower than 100% light becomes 100% and everything above that (overbright) remains the same.
if i turn on r_fullbright in the console in fq, the overbright lighting goes away.

any ideas? 

yeah, never mind, ignore that post. >_< 

...we all want to poke fun. What "silly" mistake did you make? 

i set minlight to 260. O_o 

heeheeheehee 

classic. 

Might look into the settings and perform some tests too see if the different ShadowOpt settings and LightCarve actually are worth doing

Lightcarve is definitely useful - splits brushes along light volume edges, meaning that lights only increase passes on the the surfaces they include and nothing more. Would be even more useful if you could set it on a per-light basis instead of globally (often you'll want big fill lights to split geometry but not little footlamps).

As for the ShadowOpt settings, I have no idea. Nice of them to explain what things like SO_CLIP_OCCLUDERS actually mean. I get the feeling they aren't ranked in order of awesomeness, either - each one probably does some special thing that we can't fathom without more info. 

That using these new compilers, Marcher's #clipnodes dropped from around 32k, to 25k.

I'm tempted to restore all the stuff I had to chop out in the release version o_O

There is no reason why you shouldnt. :)