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. :) 

anyone knows if you can make doom3 lights affect only specified objects\faces (flags \keys for geo or lights) ? 

H:\q1\maps>vis map
---- Vis 2.25 ---- Modified by Bengt Jardrup

File: map.bsp
3654 portalleafs
12249 numportals
Loading state file: map.vis
testlevel = 4

Base:100.00%, Elapsed: 1:23

Full: 30.72%, Elapsed: 52:16

(continuing from a previous vis session)
this has been like this for about 3 1/2 hours... usually isn't there the +---+---+ thing that shows up to let me know that it's just taking a long time to vis one portal or something like that? is it frozen? 

try inserting giant brush in the complex area of the map and let qbsp, cut it off the level and see what happens 

that it gets stuck in one portal already at 30%. The portal progress bar can be extremely non-linear, so not showing anything for 3 hours isn't strange (only discouraging ...).

I've seen one portal going for 12h without any feedback and another for 5h with only two updates.

To make sure it's still running, confirm with Task Manager that vis is hogging the CPU. 

it's still using up 90% of the cpu... i did switch it's priority manually via task manager to 'belowaverage' so it wouldn't slow down games and such, but i left the machine alone for those 3 1/2 hours so it should have been able to make full use of the processor.
does switching the priority do anything to it? 

a newer version of vis (2.29) where I've tried to improve on the linearity of the portal progress bar. Expect no miracles though ...

As for priority, there's not much to do if it's already hogging the cpu. Normally, priority is lowered for hogging, lengthy processes (like vis) or raised for non-hogging, brief processes (e.g. copying a file over the network).

Raising priority for a process like vis will only make the whole OS unresponsive or even completely blocked, requiring power cycling to regain control. Changing priority often have unexpected results.

If two or more processes are fighting over a single cpu, the total time will be a lot more than running the processes one by one. 

yeah, i know that. i was asking if lowering the priority has bad effects on vis.

anyway, i'll restart vising with the newer version... maybe it will work a little better... 

is my dream. 

does both already :) 

something in there is messing up the vis... it got frozen at the same percentage with the new vis program too:
...
...
Full: 30.63%, Elapsed: 51:20, Left: 8h 58m, Total: 9h 50m, 8%
Full: 30.68%, Elapsed: 51:34, Left: 8h 58m, Total: 9h 49m, 8%
Full: 30.72%, Elapsed: 51:56, Left: 8h 57m, Total: 9h 49m, 8%

there is a lot of complex brushwork... would that cause a freeze with no error messages like this?

(also, i'm pretty sure it was frozen before because it was still stuck at 30.72% 4 hours after i posted... O_o) 

any software can theoretically get stuck, I've yet to see vis doing it. If you don't want to wait, I'd suggest doing what Vondur said; put in one or more solid brushes over the most complex areas and see if you can get a change in behaviour.

Lowering priority for vis only tells the OS to prioritize other processes, but since all of them should be blocking (waiting) for most of the time, vis will still hog the cpu. If you start another cpu hogging process (e.g. a game), vis will yield almost completely until the other process finishes. 

wow, it took a long time (4hours) with the new vis.

but now it's going on it's happy way towards completion. i'm just surprised that it did it so early on (barely an hour into vis). usually that kind of stuff is at the end. *shrug*