The overlord of the Dark Places can be summoned with r_showportals 1. I guess those are the VIS leafes. 

No. It's r_drawportals and those are something different. Still fancy. 

Would be to consider on the elevator cage, and add rails on sides of the elevator pipe... removing the huge "cable" on top of the elevator cage...

Anyway: I got this reply from aguirRe:

"These symptoms are both caused by the same thing, namely that a fastvised map is not as accurate (or efficient) as a fullvised map. A fastvised map will typically force the engine to render more of the map and this has several implications.

The main thing is obviously that the map renders more slowly (high r_speeds in-game), but this will also hide portal problems, e.g. HOMs or flickering bmodels. That's why an unvised map can't have any portal-related HOMs or flickering bmodels (the latter being caused by them spanning too many leafs).

With the fullvised map, rendering will usually be much more efficient, meaning that the engine can now skip rendering of objects that are behind other objects. However, skipping rendering basically means that there will now be a HOM in that spot, but theoretically (and hopefully) hidden by an object in the foreground.

If something went wrong in the vis calculations (due to portal problems), the HOM won't be hidden and therefore you notice it. The same goes for the flickering func_train; in the fastvised version the entire train is always rendered, which is slower, but less error-prone.

So the basic idea is that if all vis calculations are correct, the fullvised map will look the same as the fastvised version, but will be much more efficient for the engine.

If it wasn't obvious back then, I actually feared that your CDA map would exhibit HOMs after the 1200+ hour run and you'd might face another huge run after that (ugh ...). You were lucky then and it came out well, but this time you weren't so lucky.

This is the main reason why I recommend aborting long fullvis runs; if there are portal problems in the result, you'll be facing another long run after trying to fix the issues. Cutting down to a more reasonable duration of a few days or even better a few hours, will reduce the frustration enormously.

Having huge fullvis times is just very impractical, since the whole build process is imperfect, mainly due to the floating point inaccuracies that are accumulated during the literally billions of calculations. There are most likely also algorithmic errors in the qbsp/vis programs.

In some cases, you might even consider releasing a map entirely unvised, if the fullvised version has many errors and the fastvis data is huge and still doesn't make much difference in rendering efficiency. Of course, it still sounds unprofessional to release a large, unvised map ... Part of the map mastery is to keep the map efficient and still visually complex and impressive.

While playing through a lot of Q2 maps, I've noticed many similar issues, here often caused by misconfigured "area-portals", i.e. doors that actually block vis when they're closed. Some maps are also released fastvised, which will make even a fast P4 hot and bothered. A lot of mappers have had these issues during the years ...
"

So the explanations provided by jdhack are correct ;)

Well, I'll try (I cannot promise :P ) to not make another monster like this in the future: it is too much deceiving at the end :( 

I guess I try and keep things on a 32x32 grid really.

Sometimes a 16x32, and occasionally less.

When doing some rocky terrain or uneven brushwork using the fabled "triangle techique" I also try and keep that on points of a 32x32 grid.

And small details are generally func_illusionaries, and any little details in the actual brushwork will be on as much of a larger grid as possible, trying to keep individual points on an 8x8 grid here and there, perhaps contained within a rectangular section.

This is because it has been explained to me that the qbsp process has to break the map up into vis-leaves (or leafs maybe) and more importantly clipnodes which are chunks of the physical hull(s) of the maps - so either way if you dont want to incur bugs (of which there are an awful lot) then its best to try and keep these as simple and easy to digest as possible.

"r_showtris 1" on the console in Fitzquake will show you the marksurfaces which to a degree will match some of the outlines of these leafs and clipnodes described above of the actual model (the core "map" as it were)

the portals are the double faces of two adjacent leafs. the visleafs are the spaces between the portals (and at the outskirts of the leafs the marksurfaces i guess)

I guess thats what the vis process does - find out which leafs can be seen from each leaf so as to exclude the unnecessary ones.

Keeping it simple and "on grid" as possible is probably the best way of avoiding such issues. Sometimes bugs in the qbsp output relate to the float issue - the idea of having points of the map on a hypohetical grid size of fractions rather than integers - and a warning may be shown in the qbsp log during the process but it doesn't cause any actual crashes so everything seems fine, even when fas-vised or not vised. But you cant tell what the behaviour will be like after a level 4 vis, when everything has been as optimised as possible.

None of this means you can't have scale though. You can make the brushes as big as you like :)

ramblings..... 

Bengt speaks wisely...

JPL, how about using a hub system, or chopping a big map into several smaller ones like you did with Five Rivers Land. So it feels like one big area, while in reality it's made from several pieces.

This would avoid the insanely long fullvis times (and each part wouldn't break any limits, either). There would be loading screens between parts though.

The problem with a hub approach is that you can't have one big coherent (outdoor) area like in CDA... 

go play it again! Steep cliffs. soe too. 

It has been proposed during beta testing, but unfortunately, the map interconnects are not really helpfull for a split tentative..

Five Rivers Land was more suitable, as more linear in its architecture... hence the easy split...

Well, I will try to not do monster map next time ;) 

clipnodes are affected by collisionable space - so if you have a load of stuff built on a small grid you'll have lots of clipnodes, even though nothing but a grenade or nail will be able to properly touch the detail.

If you want to keep the detail then the solution is metslime's skip tool - enclose all the stuff in a skip brush, meaning you can still see it fine but the processor doesn't waste time figuring out that a Shambler won't fit in there.

Whis is of course what you should do anyway with noclip brushes so that the player doesn't get stuck on geometry.

This is moving into guesswork but noclip affects hull's 1+2, so even just using that should reduce clipnodes.

Let's say you've got a complex corridor with lots of detail, but essentially it's a rectangle. Enclosing the walls ceiling and floor in four no clip brushes will reduce the clipnodes whilst leaving the thing exactly the same visually and without any irritating snags for monsters or player to get caught on.

Also Ricky, something I noticed in e4m1 - trigger brushes have their touch box set by their bounding box, not their brush. So if you have a diagonal trigger then its actually still just a rectangle. The same would apply to a circular trigger - it's still the square defined by the bounding box. 

Oh yeah, clip brushes can greatly cut down on your clip nodes. You need to experiment some but generally if you can wrap 3+ brushes in a clip brush, it's a net win in terms of clip nodes. 

It has been proposed during beta testing, but unfortunately, the map interconnects are not really helpfull for a split tentative..

Yeah, you would have to plan the map as a hub from the start. Just like Q2 maps. 

I'm pretty sure if you enclose surfaces in a skip brush, then the surfaces get clipped away by the compiler, because the BSP compiler itself doesn't know that skip is a special texture(the skip tool is run after BSP compilation). Although you can very carefully place skip brushes to simplify a surface's collision without actually colliding the faces behind, that's going to leave all the clipnodes and leafs in place. You may also have problems when you try to run vis on this.

Placing clip brushes does better, because they are disregarded by the compiler during the part of the build process concerned with visible faces. So that does get rid of clipnodes(usually). But because they are disregarded during the face generation process, they can't affect the number of leafs which are made by the visible faces.

The only way to reduce the number of leafs in the bsp, which are the convex spaces which are used for vis calculations, is to reduce the complexity of the geometry. This option does include offloading the complex geometry into a func_wall or func_illusionary and leaving simple geometry in the actual level to plug the hole. The advantages and disadvantages of this are well known. 

That's the main reason I'm trying out the BSP editor, especially when maps can get this big. It's amazing it all works out anyways. But like I mentioned (or if there are any floating point inaccuracies in the elevator brushes)check your elevator brushes. In the elevator's worldspawn position, if some of its brushes are out of the level, you got a leak and can expect the elevator to disappear. So just by stepping back those protruding bands in the elevator shaft (say by 4 units) you are assuring nothing is out of the level. If the elevator is okay though, eliminating the cable (or making it a separate entity) might do the trick.

This game can handle really big moving entities though. Even a 300 brush walk-in multi level section that is 1500L by 700W by 700H and is 1/5th of a level won't disappear.

Oh yea, don't cut this map up! It's best as it is. 

That should have been "In the elevator's qbsp's compiled position," not worldspawn position!!!
I goof... 

This dissapearing entity problem is happening in one of my maps, and I now realize the problem is thanks to what people are saying above. It's not a huge entity, but it seems (using r_showboxes) that func_rotate_trains, when far away from the map origin, end up with a HUGE bounding box, which means they pretty much overlap most of the visleafs in the level.

P.S. I doubt that the max number of visleafs an entity can touch is only 1, but it makes sense that it might be a low number. I will have to look into it. (For static entities, the fix is to increase MAX_VISEDICTS but, dynamic entities work differently. Also, you'd think it was related to MAX_EFRAGS but increasing that alone doesn't seem to solve it.)

If you want to keep the detail then the solution is metslime's skip tool - enclose all the stuff in a skip brush, meaning you can still see it fine but the processor doesn't waste time figuring out that a Shambler won't fit in there.

This is correct except you mean clip brush, not skip brush. Skip brush will have the wrong effect, as Preach said. 

I realised afterwards that anything inside a skip would just be removed anyway. 

Switching editor won't save you from the floating point inaccuracies that aguire talk about. 

Well, for map brushes there are no float coordinates in a BSP .map file anyways. That has to be a reason I do not get HOM's. I'm not familiar with Quark, but I've opened some Quark generated .map files people submitted from the net, and seen brushes with coodinates like 31.999998 or something. Did someone acually align a brush to that point (there's no reason)? More likely I would have placed it at 32! 

you just need to disable the floating point variable in quark to get rid of that. 

For I have answered your prayers! Well, maybe not, but I did find the source of the disappearing-model problem.

The short version: it's an engine issue, and the fix is dead simple and doesn't seem to affect performance in any significant way. In progs.h, find the following line, and change 16 to a larger number (64 seems good to me):

#define MAX_ENT_LEAFS 16


See next post for full explanation. 

It's not so simple, and raises at least as many questions as it answers. But here it goes:

When an entity is spawned, and whenever its location or size changes, Quake builds a list of all the leafs it touches. Then, each frame, it checks if any of these leafs are visible from the player's current position (using the data from the vis util). The problem is that the size of each entity's touched-leaf list is limited to MAX_ENT_LEAFS (16). So even if it touches more than 16 leafs, it uses only the first 16 it finds.

JPL's elevator model, in its "down" position, touches 38 leafs. Now, first of all, this sounds ridiculously high. Secondly, this number is the same in both the fullvis version and the fastvis. So why does it do the disappearing trick in the fullvis, but not in the fastvis? Is it just the luck of which 16 leafs make it into the entity's touched list? (I don't know the answer)

The other surprising discovery was that in this map, there are a fair number of other entities that touch more than 16 leafs. (A shambler with 21, a gug with 28, a ladder with 42, etc.) In fact, I found that even in the original id maps, there is the occasional entity that hits this limit. Yet they all draw fine. WTF?

Anyway, increasing this limit from 16 to 64 eliminates the problem from fort_driant-fullvis. As well, it also fixes the disappearing/flickering model problem in other maps (including the original release of Ricky's sickbase). 

...


... Quake. 

jdhack is the greatest Quake engine coder ever. 

regardless if there are any floating point coordinates in the .map file or not it doesn't stop the compiler from using floating point in it's calculations.

mainly due to the floating point inaccuracies that are accumulated during the literally billions of calculations.

It should be possible to change the tools to be less numerically error-prone but that would also most likely make them take even longer time. 

Great work, JPL! This was quite a monster to play!

I played on normal difficulty, finished with all kills but one, and only 2/14 secrets! Must have taken 45 minutes or so. The fastvis version with fitz085 ran fine for me (7600gt, at 1920x1200).

Just the grand scale of this map made it awesome, but there were lots of details I liked. The use of flamethrower guys (especially the ones at the fort entrance that attack you through the windows) - that was the most enjoyment I've had encountering that enemy so far in Quoth. I enjoyed the theme and textures too - sort of a HL/D3 fusion feel.

A few suggestions - the button texture wasn't obviously a button to me, at first. The passageways in the fort were a bit narrow and difficult to navigate, and the high number of buttons made it hard to know what they were doing, sometimes. I was also hoping for (maybe this is hard to believe) more climactic fighting once I got to the top of the reactor and started heading back to the start. Maybe I needed to play on hard ;) Having the quad + RL made quick work of the last fight :) 

That sounds like good debugging info. Do you type r_showtris 1 and count something (?) in the triangles, or the number of triangles?