 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
...but it comes with zero assurances of it actually working or not corrupting data. :P
I took some of my lunch hour today to see if this could be done quickly. http://files.getdropbox.com/u/161473/Vis.zip That should be a multi-threaded version of BJP VIS. When you run it, you'll see some additional text appear like: "Using X threads." The X will be however many cores/processors you have in your machine. The percentage and progres stuff is all kinds of messed up and I don't have time to fix it today - lunch time is over! But I'll take a look at that in the future once the basics are nailed down. Anyway, try it, run some side by side timings and let me know if I'm crazy or if this actually works. The best way to see it work is to start up your Task Manager and look at the processor activity. All of your cores/processors should be pegged at 100% when this is running. Thanks! swapping to your vis for all my vising needs. i'm seeing 100% cpu usage, so it appears to be working fine. i'll let you know if anything weird happens.
you are currently on my list of people made of awesomeness for this, btw. ^_^ damn, i wish i had a quad core though. :( The part that scares me is if the map will load into Quake when it's done. That's something I can't test here. :) Let me know, plz!
I don't see why it shouldn't load into Quake. After all, all you changed was the resource management. The actual vis calculation and state file handling remains untouched.
I'm running a test at the moment. One hour of willemvis vs one hour of regular (single-threaded) vis. The time estimations would help here, but whatever. No idea if there's much of a gain. I don't have a real multicore machine, just one of those p4-hyperthreading dudes (I was always suspicious about this being a possible bottleneck). I also renamed the EXE for easier use.
http://files.getdropbox.com/u/161473/WVis.zip Give that a shot if you want the time estimates to be useful. So I guess now, whoever has the most cores/processors on their machine needs to become a VIS mule for the group. :P
Yes, there's definitely some improvement (with 2 threads) - I'd say it's at least 40% faster. I was so dumb as to accidentally close the window just now, so I can't tell the exact difference, unfortunately. But still, your version is useful for running at night when there're no other programs running beside vis. Thanks for offerning your lunch break.
well, i've been using it all day with fast vising. it is faster, but it's hard to tell just how much without doing a proper full vis.
i have a second map that's in the final stage so i'll do a couple of test runs of full -level 4 vising on it, one with and one without multithreading for a proper comparison, but assuming there isn't a fundamental difference in what vis is doing in -fast vs without -fast, i'd say it's creating how you managed to improve this blocking up tool, Willem!
If I count all vis time I made since I started mapping in '97 I could have learned C+ and have dived into it... too late I guess. Sorry, the file moved. I've made it permanent here:
http://www.quaketastic.com/upload/files/tools/windows/misc/WVis.zip It looks like the WVis times are rounded to the nearest minute?
This was on a Core2Duo E6850 (3 GHz). Original VIS run: ---- Vis 2.31 ---- Modified by Bengt Jardrup File: c:\quake\id1\maps\wish16.bsp 2929 portalleafs 8356 numportals State file out of date, will be overwritten testlevel = 4 ambient sky disabled average leafs visible: 192 max leafs visible: 646 near (-608 352 592) c_chains: 39836161 visdatasize: 219 kb compressed from 1049 kb Elapsed time : 6:52 WVis run: ---- WVis 2.31 ---- Modified by Bengt Jardrup Multithreading enabled by Willem File: c:\quake\id1\maps\wish16.bsp 2929 portalleafs 8356 numportals State file out of date, will be overwritten testlevel = 4 ambient sky disabled Using 2 threads. average leafs visible: 192 max leafs visible: 646 near (-608 352 592) c_chains: 39880904 visdatasize: 219 kb compressed from 1049 kb Elapsed time : 3:00 I just did this, so I haven't actually looked at the map in the game. If I see any problems I'll post them. The only difference in the log is the c_chains (no idea if that's important). I ran the full BSP, Light, Vis each time with no change to the actual I guess this is the recursive linkage made in between volumes. As in bsp process there's a volume expansion process that defines where are each faces / leafs, I think it is almost the same for vis process except the tools creates a chained list of volume in order to process them recursively (i.e from this volume, process the faces, and check what are the others visible volume not in the list, etc...) and determine which volumes (and then number of faces to render per volume) are visible from a given position.
This is how I understood the system in very "rough" way.. and maybe I'm wrong :P Progress in Quake map building, after all these years ! Nice work !
Quick question about something else: Does it really make a lot of difference if you make your curves just by cutting them with a circle, or if you use the vector manipulation to make them more or less the same size and triangles ? If anyone has some more info (on the web, maybe ?) about vector manipulation, please let me know. http://www.quaketerminus.com/hosted/happymaps/curv_tut.htm
Learn those ratios by heart, use them. The ratio used in the above tut is 0:2 2:4 4:2 2:0 if that makes any sense. There are other possible workable ratios but that one's always worked for me. As far as constructing said curves, the 2-point clipper will probably give you less headache (and fewer invalid brushes) than trying to vertex manip everything into place. I remember someone else having a problem awhile back with this
If they're passing over a sky brush then they'll always appear black unless the sky brush has a normal, solid brush inside it.
If they're appearing black when passing over normal lit floor then there's an issue with the origin of the monster. They take no reference from the walls. But what can I do as a mapper? Just rework the brushes in the area until the engine stops having an issue?
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |