full vis / extra rad problem.

Well, I realised I wasn't running vis -full and rad -extra, so for the last compile, I did. I was supprised but not too bothered that vis took half as long, and rad took three times as long, bringing the compile time to 3 hours 15 on a P4 3.1? The process was working 100% in RAM, and my memory bandwidth is 5.5gigs/second. I did have one instance of leaf portal saw into leaf, but as I understand it, all this does is give a HOM somewhere?

Anyway that isn't the main issue; My main question is why did my map then have loads of lighting errors, and r_speeds on average 100 more than for a normal compile!? I can tell that this wasn't due to things I had added to the map, because gl_wireframe 2 showed huge amounts of overdraw in the worst areas - things were being rendered that would then not be rendered having moved closer to them! Things being rendered on a different floor of the castle? Quite a few of these were opaque func_walls, but not all, and I had plenty of these on the previous compile.

[edit] 'qrad' was a mistake, using merls [/edit]

What compile tools are you using ?

I'd say, if you didn't have problems without a full rad/vis, run a normal then, the map looked good. Try doing a full rad, but a normal vis.

scary_jeff said:
Well, I realised I wasn't running vis -full and qrad -extra

OK, first thing you do is get ZHLT (or MHLT or XP_Cagey) tools...

Hehe, I saw it, and Force didnt! :razz:

rats

The qrad was a mistake, meant to just type rad, I'm using Zoners, Merl's customs build 1.7. I'll give full rad/normal vis a try for the next compile.

first off, i don't use or recommend the 17 build or the Xcagey tools till you are sure the 2.5.3 tools won't give you the best results... i have seen instances where they do in fact preform better, and produce better results.

secondly, gl_wireframe 2, is highly reliable, if it is showing you the floor beneath, you can count on it drawing it, thus more r_speeds.

3rdly... and this is the kicker.. "full" vis is not always better than "normal" vis.. i have seen way to many cases where normal produced the optimum results.. in fact, i have used full only once..either in N_P or D_T.. all the rest were normal vis compiles.

lastly.. your compiles are long, because of the visible distances calculated in rad.. your map is much smaller, and less complicated than the pitcrew1 map, and yours takes longer to compile due to its viewable distances.. you may just have to deal with this cause sometimes, you cannot sacrifice that level of quality to lower the r's by 50 points..

I did what Forceflow said, as well as making a lot of my opaque func_wall brushes just 'normal' (not opaque), and the map compiled in under an hour (the map has more detail than before on top of this). Also 'normal' vis has left me with better r_speeds than full vis. There is still overdraw, but as I said before, experimentation with hint brushes should be able to reduce this.

Thanks :smile:

Yeah, remember that full VIS isn't the end-all solution. Since it's refining it's visibility calculations, it could easily end up drawing more (as opposed to "mistakes" it had made before). :smile:

insert razz here

forces reply was essentially what i said.. condensed :razz:

Opaques are a killer. And they look like garbage anyway in all the cases I've tried to use them. Makes a pitch black shadow on the player, has harsh stair-case edges etc.

Orpheus said:
forces reply was essentially what i said.. condensed :razz:

hehe :smile: