Why do a vis, when it is enuff with a vis -fast? Or?

(Loffy) #1

Hi!
I have made an ET-map, and I want to compile it.
My main question is this. Why should I do a normal vis, when it seems to be enough to do a vis -fast?

This is what I do:
First I do the BSP:
=== running BSP command ===
“C:/Program/GtkRadiant-ET-1.3/q3map2” -v -connect 127.0.0.1:39000 -game et -fs_basepath “C:/Program/Wolfenstein - Enemy Territory//” -meta -mv 1024 -mi 6144 “C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2.map”
Connected.
1 threads
Q3Map - v1.0r © 1999 Id Software Inc.
Q3Map (ydnar) - v2.5.5-SD
GtkRadiant - v1.3.8-ET Jul 8 2003 13:02:47

Then I do the fast vis:
— Vis —
fastvis = true
Loading C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2.bsp
Loading C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2.prt
1754 portalclusters
6840 numportals
4941 numfaces
13680 active portals
1760 hint portals
visdatasize:392904

— BasePortalVis (13680) —
0…1…2…3…4…5…6…7…8…9… (41)
creating leaf vis…
Total visible clusters: 2492788
Average clusters visible: 1421
Writing C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2.bsp
44 seconds elapsed
Disconnecting
Connection closed.

Lastly, I do the light -fast:
— Light —
Fast mode enabled
Storing all lightmaps externally
Default lightmap size set to 256 x 256 pixels
(snip)

— StoreSurfaceLightmaps —
Subsampling…collapsing…sorting…allocating…storing…
writing C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2/lm_0000.tga
writing C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2/lm_0001.tga
writing C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2/lm_0002.tga
writing C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2/lm_0003.tga
projecting…done.
199095 luxels used
0 luxels stored (1.#J percent efficiency)
565 identical surface lightmaps, using 8079 luxels
0 vertex forced surfaces
0 vertex approximated surfaces
4 BSP lightmaps
4 total lightmaps
93 unique lightmap/shader combinations
Writing C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2.bsp
58 seconds elapsed
Disconnecting
Connection closed.

Then I zip it, and I have a pk3-file that works.
Back to my main question: Why should I do a normal vis (which takes a long time)?

Actually, I dont know how long the normal vis takes, for my map. I did start it, and it ran for along time.
Then i aborted it. (Yes, im a total noob. I need some feedback, and comments. am I doing the right thing? is this common? Are my bsp, vis and light-numbers “normal”?)

The normal vis (which I aborted) gave the following outputs:
— Vis —
saveprt = true
Loading C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2.bsp
Loading C:/Program/Wolfenstein - Enemy Territory/etmain/maps/berserk_beta2/maps/berserk_beta2.prt
1754 portalclusters
6840 numportals
4941 numfaces
13680 active portals
1760 hint portals
visdatasize:392904

— BasePortalVis (13680) —
0…1…2…3…4…5…6…7…8…9… (40)
12 average number of passages per leaf
139 MB required passage memory

— CreatePassages (13680) —
0…1…Connection closed.

139 Mb? Sounds like… I dont know. Is it common?

I stop spamming now. Hope to get some response. Thanks in advance!
(Not urgent.)
// Loffy

EDIT: I am using the latest Gtk radiant 1.3.11-beta.

(kat) #2

basically -vis -fast doesn’t calculate the full VIS(ibility) of a map so you can basically see the whole thing all the time regardless as to where you stand in it - it’s not ment to be used as a final compile but rather used as a rough and ready ‘compile the map to see what’s there’ kind of thing.

Doing a -fullvis calculates what can be seen at any given time and from where, so if you were standing behind a wall you wouldn’t ‘see’ what was behind it (or rather the engine wouldn’t be drawing what was behind it).

(JIM_BOB7813) #3

How does -fastvis work? Does it only calculate vis using a few of the largest brushes?

(kat) #4

I’m not technically sure what it does other than possibly calculating VIS relative to -light compile, it’s not calculating VIS(ability) but it is using the structure of what you see as a basis to work out lightmap data - I’d need to be corrected on this though as I’m not entirely sure

(Loffy) #5

Thanks Kat!
// Loffy