Holding shift and dragging LMB will create a selection area in the 2D views. Not exactly the same functionality as Select Complete Tall, Select Partial Tall, Select Inside, and Select Touching, but it's better than none. 

Thanks for the clarification. You can't use NT/2K/XP Task Manager for checking the thread priority; it only shows the process priority which is of a higher magnitude than the thread variant.

Changing the process priority is actually pretty dangerous if you make a mistake; setting the priority High or even worse Critical for a process like RVis and you'll most likely have to use the power off button to access your system again (or wait until RVis finishes).

Setting the thread priority like my utility does (or via the qbsp option), is much safer and most of the time gets the job done just as well.

Either you'll have to use another instrument for checking thread priority (e.g. TaskInfo http://www.iarsn.com/index.html ), start another CPU intensive process and confirm that it will now take over the CPU completely or just take my word for it.

Btw, in the upcoming versions of RVis/Light, there'll be a -priority option ... 

Just as a good example of Internet email reliability, I just received another copy of your Aug 4th email ... 

I'm not mapping, only testing a Q1 map for Kell. 78 hours is not that much; I've a personal record of 350h (2 weeks) on a P4 1.7GHz and Scragbait has run a 550h (3 weeks) session on an even faster machine.

Open maps are slow to fullvis ... 

lol.. i think thats why I didn't like Q1 mapping, spent longer compiling than mapping. I love me detail brushes, my current Q3 map which consists of about 3000 brushes and is of decent size currently fullvis is 19 seconds. :) 

didn't someone have some sort of experimental bsp compiler with detail brush type support for q1? Or am I imagining things... 

Yeah, just for kicks when you guys started mentioning this in here, I changed a running vis of sm82 to something ridiculous like high or realtime. Didn't make it go any faster, but rather sent my system to 100% cpu use rendering it unuseable until it finished. Won't be doing that anytime soon. 

See here: http://openquartz.sourceforge.net 

Heh, you just had to try it, right?

Task priorites are often a cause of confusion, some even seems to think it's some kind of gas pedal. For best results, always lower the priority of a process, especially if it's hogging the CPU, like RVis or Light.

Raising a priority should only be done for processes that often block on external I/O events, like disk or network. Most of the time it's also only useful to raise it just a little bit.

If you e.g. try running an RVis session in normal priority and at the same time copy a big file over the network, you'll probably notice that the copy process is much slower than usual.

In this case, it would significantly speed up the copy operation if that program/process/thread had a slightly higher priority than normal without the RVis session suffering much of a slowdown. 

For the record, I was pretty sure it would make no difference. Although if there was some internal thread-yielding, that would make more of a difference I'd imagine.

A question I've been considering for a while to you, mister aguire the quake tools master. What is the feasibility of making a networked vis tool? I know tools like netvis have existed for other games (halflife in particular), so I'm wondering if its possible for quake1. I don't know much of the mechanics of how visibility is processed but I've done enough tcp/ip programming that I think I could handle that side of things.

Note: I'm not talking about a cluster of computers sharing processes and memory and stuff, just N number of computers running a client, with one master initiating the process and handling dispatching data to be processed.

Thoughts/comments? 

It's certainly possible (most things are). Vis originally had a threading capability to utilize multiprocessor systems (I think id had dual Sparcs).

IMO, it would've been much more beneficial for most people if they'd concentrated more on the algorithms, memory handling etc. Qbsp had ridiculously many memory leaks and Tyrann has shown that the algorithms could be improved quite a bit, especially in worst case scenarios.

If id had implemented the "meta-leaf" (i.e. clustering small detail leafs into bigger ones) variant of vis, it'd would probably be a lot faster in big maps and most likely much faster than any parallel computing method with a lot less hassle.

Since most people don't have multiprocessor systems or even lots of LAN-connected machines, pretty few would benefit from multithread/netvis solutions. I even doubt that HyperThreading would help much. There are a lot of other factors (heap, disk etc) in the machine that serialize the processing.

In any case, it would add quite a bit of complexity to vis. 

esp. when you take in consideration the speed at which q2map2 can vis, and it does take advantage of the meta-leaf software architecture you mentioned.

Of course, you already know that given you are the Ydnar of Quake I.

Hey, what about pico-model in-map compilation. Now that is some sweet stuff. 

;) 

I don't think it would require as much overhead as you suggest, but its nice to know it may be possible. Again, I know not eveyone would even be able to use it, but I was thinking it would mainly benefit those vis killing maps that go on for days at a time. Did you remove the -threads option from your vis version(s)? That would be a good starting point should I decide to investigate this at some point in time. 

Yes, I've removed the -threads option from all tools since AFAIK, it never worked anyway in the Win32 version.

However, I don't recall having deliberately disabled any basic multithreading functionality, except that I'm pretty sure that the progress feedback wouldn't work. Not to mention AutoSave or ... 

I've a personal record of 350h (2 weeks) on a P4 1.7GHz and Scragbait has run a 550h (3 weeks) session on an even faster machine.

now thats committment to the mapping cause =)
can you remember which maps they were? 

Heh, it's actually the same map in different versions by Scragbait. He can probably tell you a tale or two about this map ...

It's actually not so very big, but he put a large amount of small detail brushwork into it and since it's rather open, vis runs amok. By turning most of these details into func_walls, the fullvis time will drop dramatically (usually 50-90%).

There are drawbacks with this though, mostly regarding lack of shadows and increased r_speeds. Please see my ToolTips for more info. 

Well, I know it would break a few things, and progress reporting still could be done, albeit a little differently. Although it would never be 100% accurate but would be close enough. But possible nonetheless, with a simple protocol between the master and client. 

for clearing up that little mixup. i hadn't realised there were different levels of priority like that.

i won't bother checking if it works for vis, i'll take your word for it ;) 

Just start vis in either normal or below priority and then start another heavy process (e.g. Light) in normal and check with Task Manager how much the 2nd process can get from the CPU.

If you want to really make it confusing, you can also put the different processes in foreground (focus with mouse), background or even both in background and see how the CPU load changes in each case.

There's a lot of code in the OS just dealing with this task scheduling and nearly all OS versions have different behaviour ... 

re: openquartz compiler - yeah that's the one. IIRC, it never really did catch on. 

Is there a reason it didn't catch on? The benefits of detail in Q1, considering the size of the last few SP releases, are obvious. I'm sure there are issues here of which I am utterly ignorant.

aguiRe: heh, email si teh awfull
78hrs, huh? That's pretty much around where I was expecting I guess. Though crashing your Rvis is a new event :( 

I've used the detail texture shader from rscript recently in a test of converted IKDoom textures (Ikka's textures ripped from the Reqiuem megawad), and the results were less than disirable. I used Tomaz Quake for my test. MrG has said before that RScript was a less than optimal solution (though it works perfectly fine with alpha channels and the like).

IMHO the custom engine whose shader suppot impressed me the most is QFusion which has no problem processing Q3 shaders for all the pretty things like detail, phong and the like. 

Works like detail in q2 and DOES NOT function like detail/structure in q3 since that depends on changes made to the .bsp format. If I don't remember it all wrong detail in q2 just aids the vis process a bit by first using all non-detail brushes to split up the world and then the detail last. The purpose of this is to simplify the vis data a bit but it's important to not forget that unlike in q3 detail brushes still affect the vis data and splits up faces. 

a more careful reading of your post would have made it obvious you meant detail brushes. My eyes are blurry from mapping -- apologies