 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
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 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
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.
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.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |