Basically what Vondur said, although a longer fastvis usually indicates much longer fullvis. Conversely, if you've made a fullvis that took a long time, cutting down on the fastvis time will cut even more off the fullvis time (in percentage).

I also have a feeling that the higher the relationship between # portals/leafs is, the slower the fullvis will be. More than 3 often indicates a really slow session. 

AFAIK, I haven't touched the physics in either of my engines but I think I recall that there sometimes are small differences in what you can do.

Also, please remember that if you want the map to play well in normal engines, you must check them specifically. But using my engines during development can help with big maps, that's the basic idea. You can watch the console for warnings that indicate that you're exceeding some limit. 

Well, if I understood correctly, there is no way to anticipate what will be the running time of a fullvis with fastvis running time.. And the resulting ratio fullvis/fastvis is at least 3 times longer... hmmmm .. with my latest map I guess fullvis will take many hours... OK, thanks for these crucial information.. 

I was unclear. It's not the fullvis/fastvis ratio I meant; it's the ratio between portals/leafs which you see early in the vis printout. However, I can't substantiate this really, just a feeling.

AFAIK, there's no obvious way to precalculate the fullvis time beforehand without actually doing an extra run just for the estimation ... 

OK, I understand, I will see it "at time"... thanx 

I recall there were some attempts to implement Quake 2-like detail brushes into the Quake 1 compilers. Have there been any attempts at implementing Quake 3-like detail brushes (which are far more useful) into Quake 1? 

Those are already there. They're called func_wall. 

Don't be dense. 

1) func_wall's don't cast shadows

2) using an brush-entity in the same manner as detail brushes are used in Q3 will result in you exceeding entity-related limits imposed by the engine VERY fast. 

3) brush models are rendered very ineffeciently compared to world brushes, resulting in much higher wpolys, and other things like #clipnodes. 

Talk to a coder and he'll tell you the samething. You would need to rewrite the .bsp format to have Q3-style detail brushes work. 

what rpg said and func_illusionary works too.
as for the shadows, use antilight dammit ;) 

You would need to rewrite the .bsp format to have Q3-style detail brushes work.

I'm not arguing with that. But that's not what you said.

Funcs only work as a detail substitue in small, isolated places. And even then, they still add to the bmodel count and mess with the lighting if, for example, you want to make all your protruding light fixtures detail. It would likewise become impractical, or at least difficult and undesireable, to make all of the faceted psuedo curved architecture in a map funcs.
For e.g. a terrain map, Q3 detail makes the whole process easier to implement with vastly reduced compile times. Funcs are - take my word for it - not an option in this case.

Yes, detail isn't going to happen because of the bsp format, but that's no justification for declaring funcs a perfectly acceptable alternative anyway. Because in many cases, they're not. 

Yes, detail isn't going to happen because of the bsp format, but that's no justification for declaring funcs a perfectly acceptable alternative anyway. Because in many cases, they're not.

Of course they're not. But they're the closest you're going to get in all practical situations. I was assuming Jago was familiar with the limitations of using bmodel ents, and thus he could make an informed decision regarding when to use them and when not to. 

The fact that can sometimes manage to pull off some impressive geometry does not mean I am an engine expert :) As a matter of fact, I am pretty clueless when it comes to the inner workings of the Quake engine (or Unreal for that matter, even though I released 10 maps for that)... 

about bmodels and lighting. There is a place in my map where I have a brush model "fence" thing sticking up out of the terrain. Now, it had to be bmodel obviously, because you just don't want to go around arbitrarily jutting other brushes into triangulated terrain, but of course I don't get the shadows cast. Now I'm not too bothered about that, but I wondered if any light gurus (*hint* *hint* Aguirre ;) )had considered the possibility of making selected bmodels cast shadows. Considering how it would only seem to involve changes to the light.exe, and not to the .bsp format or engine, I was just wondering if it would be a theoretically possible thing to implement, or not. 

is that what you mean ...? 

I did find some Fullbrights that were not noticable in Fitzquake - that I can fix.

Ah, this must be the bug in fitzquake that doesn't show color 255 as fullbright, even though winquake treats it as fullbright. Fixed in the next version, BTW :) 

I didn't know about that. And that makes it easier for me now as Texmex did not correct one fullbright pixel in one of the problem textures even though it corrected the others.

Now, if I can just clear this packet_overflow problem a 'new' SP map is in the offing ... 

I am building my Q1SP in 2 parts for faster compile times and general convinience. Today I have realised that if I put both pieces together now and properly detail places which are missing detail, I will easily hit ~3500 brushes (without clip brushes and such). And this is Q1. AND both "pieces" are still missing many rooms. This puts my rough estimate of the final brushcount to 4000-4200 brushes. What kind of problems should I be expecting when I will eventually start merging both pieces together? 

Difficult to say with only those figures. # brushes is no problem for the compiler and brushes don't even exist in the engine (transformed into other objects).

Typical problems are clipnodes (especially if the map leaks) and marksurfaces, both related to complexity of architecture. Then comes entity overflows and vis problems if you're not careful with layout or brush amount/alignment.

Try to make complete builds as early as possible to get indication of problems. Then post here to get tips on how to proceed. 

My current Q1 map is around 7700 brushes and like aguirRe says, the brushcount doesn't really matter for the compiler - it's what the compiler turns those brushes into that can be a problem. Without clipbrushes, my #clipnodes is around 50,000. With loads of clipbrushes applied to out-of-reach areas I can bring the #clipnodes down to around 30,000.

#marksurfaces is another important figure. The limit here is again 32k, but you can exceed this limit in many engines and not have any problems. 

The map I showed pics of the other day is about 51oo brushes at the moment. It was started by joining 5-6 speedmaps I had lying around, a bit like you would like to do.

But as Kinn mentions it's the number of #clipnodes and #marksurfaces that matters.
Kinn mentions that #marksurfaces is limited to 32k, but some engines still can run it.
So far I have 41048 #marksurfaces and the map still loads in all the engines I tried it on, including the orig. GLQuake.exe.
Don't know about software Q since I cant run that! 

for the fence... i'm not sure what the technical problems might be, but you could try this:

rebuild the fence inside the func_wall, (make sure the texture alignment is identical to rule out z fighting) except cut off the bottom of the fence brushes just before they hit the terrain to stop them from splitting up the brushes.

i remember a while back, there was an article in pcgamer where some dude who mapped for half life gave "tips" to help map and he mentioned that in the desert maps, he had raised the catii 1 unit above the ground to not split up the terrain yet keep the shadows.

i remember suggesting that here before but it was not greeted warmly, so there may be technical aspects to this method that are negative... someone want to add to that? 

Single room map, player_start, single rectangular brush touching the floor but not the walls or ceiling = 210 clipnodes and 48 marksurfaces.

Add one default light = 125 clipnodes and 48 marksurfaces.

What principle is at work here and is it a useable feature when considering excessive clipnodes?