map compile problems with qoole

omega · Post by **omega** » Sat Oct 29, 2005 10:15 am

me and my brother have made several maps. but we have not been able
to release a single one because we have got some problems
with compilng the map with lights.

we are working with qoole v2.50 for editing because it is much easier to
handle the cubes with it than qoole v99. i have never tried qradiant or
other programs because i am to lazy to learn the commands of it

. so
after we have finished editing the map we set the lights in qoole v99
because q99 has got a much better compiler than the previous versions.
so: qbsp works, qvis and qrad do not work. we tried to compile the map
over 3 days but it has not finished (it does not work with both versions).

i dont know if it is the complex structure of the map, because we have tried
to make less edges and to build in new effects (some really interresting
ones, but, as i have already mentioned before, we have never finished a
map:P)

so can anybody help us without saying "u should work with another
program!"?;)

tia
omega.at

NRGizeR · Post by **NRGizeR** » Sat Oct 29, 2005 10:20 am

"u should work with another program!" (yes, you really should)

but more to the point, the vis AND rad will take a long time if you have a slow computer, big map, and/or high brush complexity

help us out with some numbers here, how many brushes have you used? what kind of computer are you compiling on? when the VIS stage has been run, how many numportals are reported? is the map leaking?

NRGizeR · Post by **NRGizeR** » Sat Oct 29, 2005 10:24 am

oh, and also, the compilers have nothing to do with the editor used, if qoole isn't even worse than I thought and they've written their own compile tools as well (which I highly doubt)... the compilers used were written by idsoftware, and there are also improved versions out there (arghrad for example) that I would really recommend using...

V34 · Post by **V34** » Sat Oct 29, 2005 11:05 am

Remember to give you brushes textures.

omega · Post by **omega** » Sat Oct 29, 2005 11:54 am

of course i give my cubes and brushes textures:P

ok

my computer:
AMD Athlon XP 1700+
640 MB Ram
Radeon 9800 Pro
Seagate Baracuda 200 GB
Windows XP v2002 SP 2

maps are not leaking
i made bigger and smaller maps:P
and i used 1000-3000 brushes, i think
(i have always used a high amount of brushes)
dunno exactly the count of numportals

i have deleted most of my maps because i made better ones all the time
until i gave up. but now i thought: well, lets ask what's the problem with
this motherfuckin shit;)

and which program i shall use in your opinion?
pls with tutorials and websites

tia
omega.at

NRGizeR · Post by **NRGizeR** » Sat Oct 29, 2005 12:40 pm

The only one that I'm really familiar with is radiant, so if you want to try that out, you can find it at http://www.qeradiant.com (qeradiant 147 works nicely for q2 and windows, if you want to try the gtk version that also has q3 support but decent q2 support still, use gtkradiant 1.4.0, and if you want doom3 support, but kind of a buggy version with not that good q2 support, use gtkradiant 1.5.0, and if you download the gtk versions, be sure to download the "classic package" or you won't have q2 support at all...) and you can find tutorials here:
http://www.abo.fi/~cbjorkel/aq2/ricebug_tuts.zip

Now to your problem:

I don't really see how that would take that long, if it's not leaking, you should be able to RAD that in a couple of hours on that machine... is it only the RAD that is taking long, or is it the VIS as well? have you compiled ANY map at all? or are you just building it and only when it's done try to compile it? Do you get any weird output from the compilers?

Oh and if it's the VIS that takes long, I would really like to see the number of numportals that you have... I have a sneaky suspicion that you don't use detail brushes?

-NRG

V34 · Post by **V34** » Sat Oct 29, 2005 7:02 pm

sic wrote:of course i give my cubes and brushes textures:P

Took me a week to understand.

Post by **Beavisss** » Sat Oct 29, 2005 7:11 pm

"u should work with another
program!" ...
qoole is like shit

V34 · Post by **V34** » Sat Oct 29, 2005 11:29 pm

Beavisss wrote:"u should work with another
program!" ...
qoole is like shit

What do you use Beavisss?

NRGizeR · Post by **NRGizeR** » Sun Oct 30, 2005 12:40 am

V34 wrote:What do you use Beavisss?

He uses radiant as well... I tricked him into it!

The other editor that I would recommend is Quark, since that's also still being developed. I would still say that if you want the most features, go with radiant, but at least on paper, radiant only wins by a hair...

Flunx · Post by **Flunx** » Sun Oct 30, 2005 5:40 am

Listen to NRGizeR! He's a smart man :-)

omega · Post by **omega** » Sun Oct 30, 2005 6:58 am

hehe;)
ok lets try radiant when i have enough time again...

"I have a sneaky suspicion that you don't use detail brushes?"

what are detail brushes for?

NRGizeR · Post by **NRGizeR** » Sun Oct 30, 2005 8:26 am

sic wrote:"I have a sneaky suspicion that you don't use detail brushes?"

what are detail brushes for?

Well I bet that that's your problem... detail brushes in q2 is mainly used to tell the compilers that the brush is a small detail that can be overlooked by the VIS process, and thus reduce the time that the VIS stage will take dramatically

What are Detail brushes and when should I use them?
Detail brushes are used to help speed up the compile time by "hiding" those brushes from the compilers. Since the QBSP compiler breaks up a brush if another brush intersects it, this means that a lot of brushes may be created. Detail brushes can be used for any brushes that do not block the player's line of site.

This is taken from a text file included with the gamex86.dll source code. The author is John Carmack.

The basic idea is that you should make all of the brushes that aren't major occluders into detail brushes. This lets the vis program ignore all of the little protrusions that never really block sight. Because of the factorial order of the vis algorithm, it is pretty easy to get a 10x speedup in vis time by making the non-essential brushes detail. This also gives a method to fight some of the errors that still occur in bsps. If polygons are dissapearing in the game, but they come back with "r_novis 1" set, then there is a vis error. This can usually be fixed by making more of the brushes between the problem viewpoint and the problem polygon into detail brushes.

That was from www.gamedesign.net, I really recommend for all new q2 mappers to read through the general q2 editing tutorials found there (http://www.gamedesign.net/node/42)

And oh, a word of cauting, when you start making brushes detail, it is very common that you make too many into detail brushes, so make sure to ONLY make those brushes detail that doesn't actually block visibility... Also note that if you make a brush into detail, it will also "leak" so don't make any of the brushes that outiline the map into detail.

NRGizeR · Post by **NRGizeR** » Sun Oct 30, 2005 8:31 am

Oh, and while I'm fairly certain that this is your problem, I'd still really like to see those numportal numbers, (shown when the VIS stage starts) to be 100% sure what the cause of it is.

omega · Post by **omega** » Sun Oct 30, 2005 4:19 pm

thnx for your help NRGizeR!
maybe there will be a map of me soon;)

but the count of numportal do not show up when qvis starts....