Buildvisleafs
taleden
Join Date: 2003-04-06 Member: 15252Members, Constellation
Join Date: 2003-04-06 Member: 15252Members, Constellation
<div class="IPBDescription">...sssslllloooowwww....</div> I'm using the room-by-room approach to working on my map, and am currently finishing one of the hive rooms. However, when I compile with vis -full, the 'BuildVisLeafs' stage of rad takes a llllloooooonnnnnnggggg time.. so long I don't even know how long, I've never waited to see. When I compile without -full (all other settings identical), the map (which is just the hive room, nothing else) compiles in a minute or two; with -full, I've been sitting here for ten minutes already, and it's on 20/715.
Any ideas what causes rad to take such an absurdly long time? I have a lot of angled surfaces (pipes, interesting wall architecture, etc) - would that be doing it? Would hint brushes help? What exactly is the relationship between vis and rad that might cause different vis settings to so drastically change how rad runs?
-tal
Any ideas what causes rad to take such an absurdly long time? I have a lot of angled surfaces (pipes, interesting wall architecture, etc) - would that be doing it? Would hint brushes help? What exactly is the relationship between vis and rad that might cause different vis settings to so drastically change how rad runs?
-tal
Comments
Also, read the mapping guidelines and faq for more information, and also use the <b>Mapping Troubleshooting & Help Forum</b> as this seems to come under the <b>Help</b> category. Can't believe morons are still posting in the wrong place <!--emo&???--><img src='http://www.unknownworlds.com/forums/html//emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif' /><!--endemo-->
only reason i've ever had a problem with visleafs is because of sloppy brushwork.
ok, for example, when I compiled my readyroom which was this huge glass thing (can't describe it) but it was all curved and had lots of detail, it took about 10 minutes to compile and I have a p4-3 and 1gb ram... Compiling a map can take hours (for slower computers - days even!)
Just be patient...good things come to those who wait...
5 hours to compile..Just leave the compile alone the 5 hours and go to school like i do.
Start the compiler 8:00 at early morning and when you back from school between
14:00 -16:00...It finished for me..I use the time well! <!--emo&:D--><img src='http://www.unknownworlds.com/forums/html//emoticons/biggrin.gif' border='0' style='vertical-align:middle' alt='biggrin.gif' /><!--endemo-->
Hanz - if using carve is sloppy, and using vertex manipulation is frowned upon, how does one create architecture that doesn't look like Wolfenstein? I am fairly careful with my brushes, and honestly all these references to the nebulous sin of 'sloppy mapping' and people's varying distrust of both carve and vertex manip.. it all sounds a little voodoo-ish. Is there any slightly more scientific information available? What kind of brush work is considered 'sloppy' and why? Does anyone know what exactly the 'BuildVisLeafs' stage of rad does?
I have a 1.4ghz machine with 512mb DDR RAM, and I'm just compiling one room - without -extra, that takes about 60 seconds. Even an expected 9x increase in one stage doesn't explain a compile that, after 20 minutes, is still at 5% of a single stage.
And Thursday, thanks for the cheerful help. I am already using Nem's batch compiler, and Cagey's latest tools, and I sincerely apologize if I've been out of the mapping community for many months and haven't re-read every thread yet. But speaking of threads, didn't someone just bump the one about elitism?
Anyway, if a mod could phase this to the Help forum, it'd be appreciated.
Hanz didn't even mention vertex manipulation. That one is fine, but do not, ever, use Carve. It's really bad, and it's alot better to just Clip them instead (lower compile times, lower r_speeds).
But I'm still curious what, specifically, is meant by 'sloppy mapping'. Is this the 'Keiser Soze' of mappers, where elder mappers shake their fingers at younger mappers and berate them for 'sloppy mapping'? Or is there some specific kind of brushwork that qualifies as 'sloppy', for some specific reason?
Also, quaz- Tried sparse, didn't seem to help. Judging from the help text in BC, sounds like it's more of a memory-saver than a CPU-saver; since I'm just compiling one room (so presumably the memory requirements are small, compared to compiling an entire map), it probably hurts more than it helps, in terms of compile time. Thanks, though.
<b>Now back to the topic at hand:</b>
Sloppy mapping generally refers to the use of the arc tool and carving in hammer. The main problem with these tools is that they aren't creating very economical or optimised brushes. More often than not carving creates a group of brushes which have more faces than what is really required to make the shape or structure you are trying to make. Yes, doing it manually requires a little bit more time but the end result and minimised compile time is worth it. Not to mention, of course, r_speeds are usually lower...
Some people often comment that creating corners by slamming two brushes together is considered sloppy and that making them into proper "fitted corners" (see attached pic) is better "mapping style" and lowers r_speeds (which equates to shorter build times) - I can't remember if this was looked into in a thread here or on the old board but I'm sure it probably was. I myself don't bother with it because I'm not 100% sure of the credibility of the technique nor it's value in the long run.
Hope this helps somewhat. Haven't really given you anything that hasn't been said before.
Anyway, I do appreciate the help, sorry again if you felt attacked. I'm one of those programmer-type people.. I like specifics.
As for the fitted corners issue, I recall this debate and I recall someone doing some r_speeds and gl_wireframe research and determining that the angled-style 'fitted' method is not any better, and may actually be worse. I'm working on memory here, but as I recall, the reasoning was that coplanar, identically textured faces are merged at compile time anyway, so the two pieces of the north-facing outer side (in the right-hand image: marked B and C) will be merged and contribute only one wpoly anyway (assuming there isn't further poly splitting from texture tiling, but that's a whole nother issue). Also, the angled face inside the corner of the 'fitted' style (left-hand image) adds another 'plane' to the map, so in this case the left-hand style has 7 planes, while the right-hand style has 6. On the other hand, the BSP optimizer probably eliminates that extra plane anyway (once all its faces are removed, since they're inside a brush and thus invisible), so when it's all said and done, the two methods are probably completely equivalent, r_speeds-wise.
Back to the original topic, it now looks like both the BuildFacelights and BuildVisLeafs phases of rad are taking an extraordinarily long time. I'm comparing the compile time to previous versions of this room; as far as I can tell, the addition of the last 25% or so of the room (with comparable detail level to the rest of the room) caused a roughly 4000% jump in compile time, even for a beta compile (normal vis, not -fast or -full; normal rad, not -extra).
Anyway, it sounds like there isn't any known scenario that causes sudden enormous increases in rad time, so I'm content to live with it or try to figure it out on my own. Thanks for everyone's comments.
Attached: annotated illustration of corner techniques
Yup it has been commented by many but also proven to be wrong by some dude who was offended by being called a sloppy mapper <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
He tested both techniques and came to the conclusion that the half-life engine doesnt give a damn about either one of them. but the myth that miltering corners are better was wrong, it was worse in most cases...
<span style='color:gray'>I'll try and find the link to that page, very long time ago when I read it so I won't promise anything <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo--> your welcome to search for yourself on google if I can't find it
I searched on something like "sloppy mapping r_speeds"</span>
/me gots the link <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html//emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif' /><!--endemo-->
<a href='http://collective.valve-erc.com/index.php?doc=1047005525-19966900' target='_blank'>Clicketh the link</a>
I can think of only two things that cause huge jumps in vis and rad times...
<b>For VIS</b> - carving, hammer made arcs, and complex brushes intersecting with other brushes (ie a pipe touching the floor - go the mass break up of the floor)
<b>For RAD</b> - All the things in VIS + Texlights + A few light entities. The telling thing is usually the "swap" thing (can't remember the word)..Whenever it has taken a long time for one room for me and I wait for that number I know it will be in at least the 10,000+ bracket...lol... usually means if I go in game and put gl_wireframe 2 on I'll see that I had a 64 side cylinder hitting the floor which has made a beautiful origami pattern..