Some questions for ya :)

1.) Fastvis -- if I use this in a map that doesn't have cavernous areas, but maybe a moderate corridor or 2, might any software Quake users have grey-out issues? Also, I read somewhere through here I believe you recommended somebody use the parameters -fast -level 4 -- is that right? Or is -level 4 actually -full?

2.) Faces... heres what my process window reads:

9801 faces
1607 brushes
219 entities

I am apparently near my limit of entities (255 or 256). Um but generally, I have little details in the map - like floor trim, and inset lights and such, which will contribute to any VIS concern, regarding too many faces (as I read brush count isn't really the issue). Basically I am wondering, when might I want to start worrying about too many faces?

3.) Light -gate 1 -- I've read changing the gate can help issues with too many dynamic lights in one area or proximity. I have several warnings of "Too many light styles on a face" which I could fix manually if it gets excessive... will this just print to the player's console, and not crash the engine (software)?

Overall I am trying to be a little considerate of software users, as few as their may be. When I release all this I'm recommending Fitzquake though.

Thanks! 

2) how do you get rid of the fullbright spots on some textures?
thanks alot.

Select a texture, right click and choose "Brightness", then click "Remove Brites". 

1. Software greyflash appears because there are too many things in view for the engine's default values of the cvars r_maxedges and r_maxsurfs. Doing only a fastvis just increases this risk. Level 4 vis is what's usually considered a fullvis and you either use -fast or -level 4, not both.

2. I don't know why you think you're close to the edge with any of those values, but I can't see any obvious problems. Faces are a concern for vis, but it's better to look at the vis leafs/portals values for hints. Entity limits are usually much higher than your values if not each entity is unique, i.e. has its own model.

For comparison, Lun's recent huge lunsp1 has 2275 entities and 20900 faces. I don't think you'll have to worry too much about entity/face limits yet and when you do, you'll probably hit the edict/portal/packet limits instead.

3. The Fade Gate in Light is mainly for cutting processing time significantly with basically no losses. It has cut times by up to 93%, but typically around 50-75%.

The problem you mention is a basic limit of the Q1 switchable light styles; you can't have more than four on each face, including ambient light. You'll have to reduce the overlapping of switchables.

This can be done by e.g. brushes, linear attenuation or spotlight cone. Disregarding this issue will in the engine just cause bad lighting (depends on switchables setup) in that area, nothing else.

To help software (i.e. WinQuake) players, just follow the classic rules for good Q1 maps. Many limits are basically the same in most engines, soft or GL. Greyflash can be fixed by just increasing the cvars r_maxedges/r_maxsurfs to 99999 e.g. in the autoexec.cfg.

In my WinQuake (and other engines), most limits are raised so it's more of a performance issue, e.g. having 2000 shamblers attacking you in one big room will probably be a slide show ...

Maybe the easiest rule is to make full builds of your map now and then, check the logs for errors/warnings and make sure it's loadable/playable in the target engine(s). This way you'll catch problems early on. 

don't release a map that's only fastvis:ed or the mapping gods will eat you alive 

And cyBeAr -- well, I certainly hope I don't come across a VIS that takes days or weeks, mostly because theres only one computer and I'm not the only one that uses it - and also, no feckin' way am I waiting that long. 

come to think of it, how hard / unorthodox would you consider making a detail brush type that casts shadows? So a lot more stuff could be func_wall:ed and thus vis quality would improve and time lessen a _huge_ amount.

(always fullvis a release. And run around with software to see grey-outs. Even czg's terra6 has one greyout place in sw... :( ) 

> don't release a map that's only fastvis:ed or the mapping gods will eat you alive

No, that would just be Archos, the god of ancient hadware, outdated software, and pottery. 

Listen to the words that have been spoken to you.

If you really can't do a long vis in one session on your computer, then:

1. Use aguiRe's tools, I believe they allow you to pause the VIS job and resume it later,

or,

2. Ask some nice person to run the VIS job on their own computer. 

If you come across a full vis that takes days/weeks on a modern computer, you've probably done something totally, utterly, horribly wrong. Design the map properly. 

I've read aguirRe's reply, thank you.

I use his tools (what else is there to use?) and am aware of VIS save states. It's just I've read of people having huge, detailed maps that will take days no matter what. 

I don't know, but there are other aspects than reducing fullvis processing time, e.g. higher r_speeds and tjunction sparkles in-game (see also my ToolTips). Not to mention saturating the unique model limit (usually <200) pretty quickly.

And vis "quality" wouldn't improve at all, you'd just shortening processing time (which of course still is important). 

There are many excellent Q1SP maps that take days or weeks to process. Kinn's Marcher took about 140h to finish and several of necros' and Tyrann's maps required many days.

As more mappers want open and epic style, this trend is probably here to stay. If only I could find a cure for vis like the Fade Gate for Light ... 

I did say 'probably'. :D

I'm assuming Phait is not doing anything that is even close to the scale/complexity of Marcher. That's a pretty extreme example.

And with all due respect to Kinnecros, if you're doing something that is that far beyond the limits of the original game engine and tools, you have to expect that kind of grief. Personally I don't believe in 5000 poly Q1 maps.

That doesn't mean I won't play and enjoy maps like Marcher, but I do feel that stuff like that is excessively indulgent. 

I've read aguirRe's reply, thank you.

Good for you. I didn't. It didn't concern me. I was just trying to be helpful. Sorry.

It's just I've read of people having huge, detailed maps that will take days no matter what.

Well, that's not necessarily true. There are a few things to note:

Q1 compilers are fairly fickle and unpredictable. Your map may take much more or less time to process than you can reasonably expect, depending on the exact geometry/layout of the level. However, having said that...

Good vis blocking will probably cut down the VIS time of your level tremendously. You can have a complex, high poly level and still have a short vis time, if you are sensible (and a little lucky).

If you have a level which is essentially one or two massively open areas, with a lot of complex geometry partially occluding other areas of the map (or not!?), your map will take a long time to vis, and (probably) run like ass.

However, if you section off each major area very well (eg long/bendy corridors, water with no -watervis, etc) and guarantee that no large, complex areas see directly into other large, complex areas, you will keep your vis time under control.

You WILL drastically increase your vis time if you don't do this. Basically, if you have a complex room/area which has direct visibility to another complex area, your vis time will go up exponentially. So if you have a complex area which can see into another complex area which can see into another complex area... well, you get the idea.

Of course, this is just my layman's understanding of it, based on experience and only a little real knowledge. I'm sure if I've said something incorrect, aguiRe will call me on it though : ) 

No it's basically correct. The thing that maybe is the most difficult to intuitively understand is that visibility for vis/engine does not mean point-to-point, it's leaf-wise. If you can see another leaf from anywhere within the current leaf, it's considered visible.

Leafs are the many small or big blocks of empty air inside a map that's generated by qbsp, all separated by the portals.

Also, there's no obvious relationship between the vis processing time and the "quality" (i.e. low r_speeds in-game). One might even say that the longer vis runs, the more it fails to optimize the map (i.e. higher r_speeds).

Maybe the best way to understand how vis works, is to load a map that's fast- or fullvised in WinQuake, enable cvar r_draworder 1 and have a look around. This is how the engine sees the map. 

Insightful posts. I did know of the hinderances of long distances from area A to B and/or C, and so on. I don't have any areas that are reaaaaaallly long and open, so maybe I have disregarded a couple spots I could implement some VIS blocking, that didn't seem as problematic.

The thing about big, detailed maps is - it's like the new standard these years now. Kinn's work actually inspired me to start the addon I'm working on - and while no map is *yet* ;) as big in scope, detail still abounds and I might get a little more ambitious. 

you said that making stuff func_walls doesn't improve vising.
But when I've checked stuff in quake with r_drawflat (that shows how qbsp breaks the brush faces into polygons), for example czg's terra6, it really makes a difference.

Look:
http://skynet.campus.luth.se/~chosen/bam/fitz0040.png
http://skynet.campus.luth.se/~chosen/bam/fitz0041.png

In terra6, there are thin window bars (2 horizontal and 2 vertical brushes) on every window opening, and they are world/bsp because of lighting questions I guess. But if you change them to func_wall, r_speeds drop a lot. Notice the vastly different amount of faces.
(I was trying to make terra6 a dm level at winter but sw fuhquake kept graying out at places (many people use that), and I haven't finished yet. The map is at the same dir if you wanna check it out.)

My layman's understanding is that qbsp has to do this because of the fundamental bsp tree splitting algorithm, and it can't be routed around by anything except by excluding the brushes from the whole bsp - i.e. making them entities.
That should also reduce vis times since there are less faces. Maybe i'm wrong. Also entity-making directly should reduce leaf count! 

so I don't know, maybe the final visibility calculation product will be approximately the same but the number of faces drops by about a factor of 3 in my example case area so both the vis and the game should run faster.

Make possibility to make shadow-casting func_walls please! A bit flag in func_wall? (or a completely new entity type? That is changed to func_wall during compiling after lighting or something... that would be a hack though, preventing multiple compiles on a bsp) Light entities are already modified anyway so it's not a big step - and it would anyway only affect compile time if done right and the maps would work perfectly in old engines too.

thank you. 

I really don't know how much you know about mapping, so forgive me if I sound condescending. However, you (along with some other folks) might want to read this article at Rust on poly count reduction:

http://www.gamedesign.net/node/53

It's written for Quake 2, but a lot of the information still applies to Quake. 

some people complain that entities greyflash out. I've found this to be a problem with the map in general having too many faces or something in sw quake - which the changing of detailwork to func_walls would precisely cure!
If you bring details to world to avoid them flashing out, that'll just flash out something else, like health paks and only worsens the problem by increasing the face amount a lot!

I don't know what the func_walls do to network traffic. I imagine, since they can never move, their position would never need to be transmitted anyway and they would cause no traffic at all. 

I'm editing the interface GFX, all is going well so far:
http://www.phait-accompli.com/q/s4/pre/gfx_1.jpg

But - I cannot find the number .lmp(s)! Where be they? 

The numbers are all hidden in gfx.wad, along with most(all?) of the HUD elements. You might need a program like adquedit to get at them.

WARNING
Adquedit requires you to add directories to it's list of mod folders before you can open them. Deleting them in adquedit with the delete key does not remove them from the list, but rather deletes the folder itself. I almost deleted my entire drive like this, fortunately the adquedit folder comes high up alphabetically, and it crashes when it attempted to delete itself. 

Thanks. Yeah I'm using Adquedit and exporting to PCX, and I found a PCX to LMP conversion app. Thanks for the warning also, but I recall deleting a folder, and haven't noted anything missing on my hard-drive. 

... I've even got triangles on me triangles. For Bob's sake, give me a circle!

http://img344.imageshack.us/img344/9509/fitz00014cw.jpg 

Aguirre: in addition to r_draworder in winquake, you can use r_showtris in fitzquake to get similar information.

Bambuz: that's weired how your gun and monster models don't have solid-colored triangles, but instead are smooth shaded. What video card are you using?

Preach: I did delete my entire C:\games folder doing that. It was terrible.