|
.
#2338 posted by necros on 2004/08/13 21:36:55
i wrote a little guide a while ago that should have everything you need to map for q1 with gtkr1.4
since you're using 1.5, you can still download the .def file from there.
http://www.planetquake.com/necros/gtkrq1.html
Direct Link:
#2339 posted by necros on 2004/08/13 21:41:38
Necros
#2340 posted by aguirRe on 2004/08/14 05:59:27
What do you mean by "didn't seem to do anything", didn't it run the vis program with its parameters %1 %2 %3 etc at the specified thread priority? Maybe you forgot adding the parameters to the batch file command?
It's not hard to implement, but I see no reason since this utility does the same job without any cost at all.
If you still can't get it to work, please send me the batch file and a description how you call it.
Heretics
#2341 posted by truskoski on 2004/08/14 07:43:23
are there any fgd files for worldcraft 2.0 or maybe hammer that would let me map for heretic2? im so used to worldcraft im too lazy to learn the one that comes with the game, and i have no idea how to make a fdg for worldcraft. :(
Stone That Heretic
#2342 posted by VoreLord on 2004/08/14 08:15:20
Yay!
#2343 posted by truskoski on 2004/08/14 08:42:35
i'd kiss you... but i dont know if you like aids. :(
AguiRe
#2344 posted by Kell on 2004/08/14 12:31:19
Yeah, I got your original mail. Please note that I have very limited net access and I'm a bit snowed under with content, so I tend not to reply instantly to emails.
Light Shader Problem
thought I would post this here too, can't figure this out. Didn't feel like reformating this post, go to the link below.
http://www.quake3world.com/ubb/Forum6/HTML/028166.html?
Kell
#2346 posted by aguirRe on 2004/08/14 13:02:41
No problem, I just don't trust Internet email much anymore. To avoid both parties waiting for responses that never come, I'd rather run the risk of being a bit repetitive.
Btw, I've been running a fullvis on the terrain map for about 78 hours now. It has reached 88%, claims that there are 13 hours to go and half an hour ago it even crashed my RVis ...
/me consults the good Dr Watson
78hrs VIS?! Um what are you mapping for?
Aguire:
#2348 posted by necros on 2004/08/14 13:36:44
the line in the batch file:
privis.bat:
priority below vis %1 %2 %3 %4 %5
command line:
privis -level 4 map
starts vising the map, but when i check in task manager, vis.exe is assigned the 'normal' priority.
that's what i meant by "does nothing"... any suggestions?
GTKRadiant 1.5 Docs
#2349 posted by R.P.G. on 2004/08/14 13:40:53
BTW, anyone using GTKRadiant 1.5 may want to check out SmallPileofGibs' docs on the subject:
http://zerowing.idsoftware.com/radiant-files/nightly/1.5.0/docs/
I've asked him to keep an eye on this thread, so hopefully he'll see when a new question is brought up, and he can let us know when the docs are updated.
Hm...
#2350 posted by necros on 2004/08/14 13:45:44
every point in the 'transition' section has convinced me not to switch to the newer version.
'select complete tall' was one of the best features of gtkr, because you could size the selector brush to exactly the right size before selecting the other brushes.
Necros
#2351 posted by R.P.G. on 2004/08/14 13:49:53
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.
Necros
#2352 posted by aguirRe on 2004/08/14 15:09:00
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 ...
Kell
#2353 posted by aguirRe on 2004/08/14 15:11:50
Just as a good example of Internet email reliability, I just received another copy of your Aug 4th email ...
Shadowdane
#2354 posted by aguirRe on 2004/08/14 15:20:24
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 ...
Vis
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. :)
Detail Brushes
#2356 posted by Kinn on 2004/08/14 16:16:30
didn't someone have some sort of experimental bsp compiler with detail brush type support for q1? Or am I imagining things...
Re: Process Priority
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.
Kinn
#2358 posted by aguirRe on 2004/08/14 17:03:38
Ray
#2359 posted by aguirRe on 2004/08/14 17:19:26
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.
Yeah
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?
NetVis
#2361 posted by aguirRe on 2004/08/14 18:54:24
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.
I Concur, AguiRe
#2362 posted by HeadThump on 2004/08/14 19:08:09
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.
|
|
You must be logged in to post in this thread.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|