Perhaps you need to specify a root domain name there :) 

Orl

I won't be able to grab it until tonight, so please leave it there until later on.

Thanks! 

Hey, Orl, all 3 of your emails did come through. I'm not sure why you were getting failures on your end.

Yours too, headthump!

At any rate, thanks! 

that's weird. Well, at least you get em. 

with lun3dm4 textures :

http://www.quake3world.com/forum/viewtopic.php?f=10&t=35324&sid=1691228c051d7706c5fab620b2bf5838 

Very nice ! 

You can get a wad from the BSP, but its mostly IDbase tex and fury.wad.

AguirRe, do you still have the version of the map source from Sickbase after you altered the solid ents? I think I might have it at home, but I dont have it here at work... I do have the one before you altered the solid ents, i.e. the exact file I sent to you.

Willem - this took 6.5 days to vis!! On an Athlon XP 1700 that is. All that is wrong with the version I have is there are a few flickering ents, cause my solid ents fall into to many places around the map. AguirRe broke them up a bit by hacking the map file. (What a hero!!) 

bsp: 7,28
light: 10,15
basevis: 1.10
full: 39,28 minutes 

Better machine than mine then, but that's not saying much.

By basevis you mean full?

I used a few lighting options like -extra4 and stuff, but also the -gate option that would counter balance any slowdown. 

I thought I had time for VIS research but in reality, I probably don't. :P I have a few maps that people sent me if I DO get time though, but thanks! 

---- Vis 2.31 ---- Modified by Bengt Jardrup



File: warpc.bsp

7341 portalleafs

20038 numportals

testlevel = 4



average leafs visible: 174

max leafs visible: 594 near (-2560 3968 512)

c_chains: 147877441

visdatasize: 477 kb compressed from 6581 kb



Elapsed time : 39:28

State time : 0:07 

The Hand had something like 3000 max leafs visible.

My new map isnt far off the same!

This is a reflection of speeds, isnt it?

So Warpc is a pretty fast running map, innit.

Its over the lightmaps limit tho, so Ijed makes biiiiiig maps with simple enough brushwork that they run at a good speed. 

Is the max leafs visible thing eqivalent to r_speeds? 

...I think they're fairly relative.

TBH I dont really know what a leaf is. I sort of assume that it's an "area of the map". The more complex the geometry of the map, the more leafs there will be, right? (somebody help me out here...)

It all equates to more triangles on the screen at any one time which is basically kinda what r_speeds is a measure of?

(its very shady around here...) 

you're not too far off.

qbsp divides the worldspace into many small, convex volumes, some solid (inside a brush) and some non-solid (air, water, etc.) A leaf is a non-solid volume of space in your bsp. As you walk around the level, your viewpoint is always inside a leaf. And vis.exe figures out what other leafs you can see from the leaf you're in, and the game will only draw polygons that are touching one of those other leafs. (each leaf has a list of polygons it touches.)

r_speeds actually counts those polygons as they are being drawn.

If you want to visualize a leaf, imagine the simple case of a cube-shaped leaf. It has 6 sides, and some of those sides will be touching other leafs -- these are portals. Other sides of the cube will be touching solid space -- these are polygons (since there's a visible surface anywhere air meets solid.) For example, a leaf in the corner of a room might touch a floor and two walls, and the other 3 sides are portals. 

The number of triangles shown (=r_speeds) is a lot higher than the number of leafs? 

Not necessarily -- some leafs have no polygons (if they are floating in the middle of the room, for example) so they would increase the leaf count but not the r_speeds.

Also, r_speeds counts polygons, not triangles. Each polygon is made up of 1 or more triangles. (square = 2 triangles, hexagon = 4 triangles, etc.) 

I knew the outlines of that, but is it also right that polygons are split by textures - so a 256 square wall with a 128 texture becomes 8 triangles instead of 2?

Also affected by scaled up / down textures? 

it's true that there is a max size to polygons, based on the amount of texture/lightmap space taken up by it. At texture scale 1.0, the max size is 240 in world units, and anything larger gets split.

But all that splitting happens in qbsp, so when the engine is rendering, each polygon is already verified to be 240x240 or less. 

You can visualize that pretty easily, FYI. Just build a large hollow box, compile it, and load it in Quake.

"r_drawflat 1" will show you the BSP splits and where QBSP cut everything up. 

Probably the most concise yet useful explanation of the process I've ever come across. 

I now know what a portal is! As well as a few other interesting facts...

...next time I compile I will read the log from a slightly different viewpoint.

So "r_showtris 1" in Fitzquake is showing the triangles which comprise the polygons.
I will try "r_drawflat 1" later and see what that looks like. Are there any other things you can do? Like to see the leafs for example?

I am learning the need to know about these things from a mappers point of view. I want my level to be as big as possible but not limited to certain engines. So I'm always looking at the info in the Qbsp log to see how many marksurfaces etc I have got. Also AguirRe's Bspinfo.exe is usefull to me for the same reason. The only way I can find out how many lightmaps I have is by loading in AguirRe's engine, and typing lightmaps on the console. 

Well, "r_draworder 1" is a fun one because it draws the world backwards so you can see exactly what is being drawn from your current location.

I think that about covers it... 

r_draworder is only supported in software engines (winquake, etc.) i believe.

also, you can see lightmap count in fitzquake using "imagelist" command -- they are numbered starting with lightmap00. 

Sorry, I'm a software guy so that's how I roll. :)