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 

Hello,

In post #2055, MadFox gives me an example of "electric laser beam" use: it was the same used to kill Chtom into last level of Q1 first episode. This link seems to be no longer avalaible today...

I would like to use an "electric laser beam" in my new map (to create some electric effects into a power zone), and I would like to have some information about the use of event_lightning entity, or a map example like MadFox gave me there were few months..

Is there somebody who can help me please ??

Thanks... 

if Q1 detail can be done like in Q2, ie. not requiring any changes to the Q1 bsp format, then would it be possible to implement in your compile tools? 

Well, if you're going down that road, you might want to consider using some custom QC - the Scourge of Amagon mission pack has some excellent lightning effects. 

I will send you a zip file which may be of help to you. 

Rvis now reached 96.6% in 111h with still 12 to go (not very likely) ...

The crash wasn't reproducable, and since AutoSave was active, I just restarted and it appears OK now. My HD sometimes act up and slightly corrupt read/write operations and it can cause these anomalies. 

I've just read your e-mail, and it seems that it is exactly what I was looking for...
Thank you very much... 

I have actually investigated a bit into this issue recently. Unfortunately, it seems to require both qbsp and vis specific support (via a new prt file format) and adds quite a bit complexity to both tools.

Since it can't help any existing maps (you'd have to map explicitly for this format), I've decided against it for now. 

Have you received my email reply as of today? All my accounts seems to refuse to send it to you for unknown reasons. 

I haven't received it - hotmail tends to randomly bounce emails for no reason from time to time.

However, you can now send stuff to my original email address, as I have set up the account on my crappy computer. 

I've now managed to send [at least] one to each address, let's hope you get one of them.

Btw, I haven't been able to reproduce the abort you mentioned, no matter what I do.

I've uploaded yet a bit newer variant of WQ 1.22 to the same address as before. Please see if you still can reproduce the abort.