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* 

Anybody ever see this?

http://img183.exs.cx:81/img183/3344/archdlg18ae.jpg

Doesn't work as expected though. I just thought you might want to know :) 

man, no real mappers use arch\shape generators - they create shite

(well, I did. But I cant map.) 

It's just weird how I got that funny dialog to pop up:

In Worldcraft 1.6a -- with a map open, of course ;) -- I selected the Block Tool and in the New Objects toolbar, in a Category other than Primitives, chose the last Object in the list. I then drew my rectangle and pressed ENTER to create the New Object. Next, I picked the Category Primitives. This time I left Objects blank and drew my rectangle. When I pressed ENTER, Viola, that odd little dialog appeared!

While it doen't seem very useful, it was fun to find at least :) 

not that hard to find. As already said though, it produces crappy off-grid rubbish. Just do the right thing and read czg's curve guide. 

vis froze again, this time at a different point.

Full: 50.43%, Elapsed: 27h 49m, Left: 18h 44m, Total: 46h 34m, 59%
Full: 50.45%, Elapsed: 27h 49m, Left: 18h 44m, Total: 46h 34m, 59%
----+----+
Full: 50.48%, Elapsed: 27h 53m, Left: 18h 43m, Total: 46h 37m, 59%
Full: 50.49%, Elapsed: 27h 54m, Left: 18h 43m, Total: 46h 37m, 59%
Full: 50.55%, Elapsed: 27h 54m, Left: 18h 42m, Total: 46h 36m, 59%
Full: 50.66%, Elapsed: 27h 54m, Left: 18h 39m, Total: 46h 34m, 59%^C (break)
H:\q1\maps>vis -level 4 -savetime 20 map
---- Vis 2.29 ---- Modified by Bengt Jardrup

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

Base:100.00%, Elapsed: 1:33

Full: 50.58%, Elapsed: 27h 54m
Full: 50.66%, Elapsed: 27h 54m, Left: 3h 23m, Total: 31h 18m, 89%

i think it's when i play games... i was playing a lot of vtm:b... i hear there some kind of memory leak in that game... maybe that's what's screwing it up? O_o

oh well, restarting again. :\ 

before the ^C break, it had been stuck on that one for 6 hours, then restarted and it was stuck again for about 10 hours.

also, note the wierd jump on that final percent value... O_o ? 

run another cpu-intensive app like a game in parallel, one might think that vis should get about 50% of the time. But because the game is in the foreground, usually Windows boosts its priority if you haven't explicitly told it not to. Also, there's a potential risk that the game sets its own priority higher than normal.

The jump in estimation is normal when you restart. The estimation is normally sliding to even out sudden jumps, but when you restart, it has to start all over again with fresh values. The estimation will slowly get back on track after a while if you leave it alone.

Btw, you are aware of that interrupting vis inside a slow portal will set you back to the beginning of that portal ...? 

i mean, it just freezes like that.

ie: no updates on the screen at all, even after the game is finished.

those 8 hours, i meant 8 hours not including time in the game.

it's not normal for vis to completly stop updating altogether so early in the process. whenever it would stay stuck at a particular place before, the screen would at least get updated to let me know that something was still happening. also, note that the place at which it froze the first time (30.xx%) didn't happen the second time. either the map is killing it, or running certain programs is breaking it. i've restarted this time and i'll not load up any games until it has paseed the previous point and then we'll see... 

are you using? You confirmed before that vis was still using >90% of the cpu, was this true also in the other cases when it seemed stuck?

As I said before, I've had cases when having absolutely no screen updates for up to 12h when it's been processing a slow portal. But of course, vis should behave the same way each time you run it on the same bsp+prt.

If you wish, you could send me the zipped map+wad and I'll see what happens. 

I wonder why I am mapping and after a while my
map goes down by a bug.
I use Texqbsp and Quark63. For some rooms it goes well, but then it strucks down for some
idiot reason. merged textures,holes that don't excist...

But then, when I use Tyrqbsp, I get some warnings but the map compiles fine.

Can't get it, what's the difference between the compilers. Or am I such a fool I just map the wrong things? 

First, switch to last QuArK release (6.4), or just change of editor (while QuArK works fine for me... there are no reasons to change... even if QuArK sucks regarding some other guy's opinion...)
Second, use aguirRe's tools... that's the better way to map "correctly"..
Third, what options are you using with your compile tools ?? I think each tools have their own options, which are not obviously compatible between each other... so just check it.. and choose the right ones ;) 

I just wondered why Texqbsp compiles without giving me a *.prt file.(bad mapping?)
Then the same file compiles right with tyrqbsp!(good compiler?)

Doesn't make it easier to understand the problem. 

It is a very difficult problem to understand, so don't worry.

I spent a long time trying to improve qbsp due to problems I was having with my own maps. You probably do want to use aguirRe's tools - his are a little better tested than mine, and he does tend to include any improvements that I make into his tools also.

Try some different tools and just use whatever works best for you. If that happens to be tyrqbsp, then that's fine.