...I started one ages ago, but each time I got close to putting it out someone released a new engine that changed the previous limits :) Some engines have remained stable with respect to some limits I suppose... 

gb: You can save some brush models by e.g. turning all individual func_walls of room into one large entity (if visibility permits it) and trigger_counters as well as trigger_teleports in monster cabinets into point entities.

JPL, distrans: The standard engine limits are listed in the glquake-bjp readme. 

Thanks a lot for the information: I'll check it right now ! 

Thanks, AguirRe. That makes sense.

It appears my rotating lift alone contains 133 "bmodels", 132 of which are func_movewalls.

Another problem with rotating stuff... all those movewalls will rapidly increase the brush model count. And it looks like they need to be brush models and not point entities.

Think about this: A normal rotating door might have 8 or 12 movewalls, plus the door bmodel(s). Four of those could already add 50 bmodels... then I tried to make all crates in the map breakable, which apparently is not a good idea at all... 20 more bmodels... that's 70... and then I have this sucker of a rotating lift cabin. ^^ All this is not counting the monsters.

So it's rather easy to have over 200 bmodels like that. You live, you learn.

Neg!ke, thanks for the tip with the point entities. I use the Quoth spawning already though, so I don't even have monster trigger_teleports. I'm not even using func_walls yet, but that sure sounds useful.

This map has only 5 rooms and some corridors yet, btw. and only 6 or 8 monsters already placed. And wham, it breaks the model limit. ^^

Good opportunity to learn how to creatively save entities without being too obvious, I guess...

this game gets more and more interesting... 

Is there a way in standard quake to make a teleport that teleports only monsters but not the player? 

...oh good, there is a list of the standard limits. Might be useful at some stage...ta mate! 

I have recently completed a Q1SP map, which has roughly 20,000 portals. It is hence taking a very long time to VIS -level four it. Is 20,000 portals much larger than a normal map, and if so, what can I do to remedy it?

Thanks. 

Make some complex things func_wall entities?

Make sure complex geometry doesn't see other complex geometry (curved or dogleg corridors..)

Send a fast-vised or non-vised version to some mapper for testing. 

Basically, either reduce visibility via level design (90 degree corners, etc), or reduce the polygon count (make trim flush with walls rather than sticking out, func_walls, etc).

There's really no magic to VIS, just lots of tedious work. :) 

How goes the vis project with the map I sent you Willem? 

Yes, 20k portals is very big, with older vis tools you wouldn't even be able to vis it at all, make sure to use an enhanced vis that can handle it (mine does and I think Tyrann's works, too).

Also, make sure to use a modern qbsp that doesn't create bogus prt files with a huge amount of portals, all wrong. Again, mine and Tyrann's should do.

For more info about improving vis times, see my ToolTips doc. 

"How goes the vis project with the map I sent you Willem?"

My interest sort of petered out there, sorry. I got caught up in other stuff but thanks for sending it along anyway! 

Yup, mine has 20000 portals, too. Fastvis is bearable, fullvis is ... not nice.

Both Tyrann's and Lord Havoc's tools can handle it. So should AguirRe's.

I'll not do that again, though :-)

Question: Do any Q1 tools support Hint brushes?

Question 2: Do sky brushes block vis the same way that normal brushes do? 

Answer ( short ): No.

Answer ( long ): Support would be required not only in the compilers, but in the .bsp format and the engines. This issue appears on Func perennially.

Answer 2: Yes. 

If there are two rooms next to eachother with say a 32 unit wide wall between which is just one brush; is this less effective at blocking than 2 separate walls with a void in between? 

Alexander Malmberg's qutils have hint, detail and skip brush support, and while I've never tested it, I'm pretty sure they don't require any special engine. 

Unless I misunderstand hint brushes, it would only be the BSP compiler changing. The hint brushes simply suggest cuts, don't they? 

because it has no vis 

...take a trip in noclip. If the brush you are talking about is solid than you should see a void in between anyway :)

Quake does not draw brushes, it draws faces on some of the internal surfaces of volumes. 

Unless I misunderstand hint brushes, it would only be the BSP compiler changing. The hint brushes simply suggest cuts, don't they?


Ack, you guys are right. I was getting confused with detail brushes. My bad. 

No need for hint brushes anymore, it turns out that hvis isn't terribly effective and thus half of the map was drawn at once. This doesn't happen with tyrutils or aguirRe's utils. 

I've managed to reduce the vis level four time by about a factor of four. 

Nice! Definitely pays off to invest a little effort in your VIS times. Pays off in spades at the end when you want to iterate on the map and tweak things. 

...trying to get sickbase to vis in a reasonable time frame. Unfortunately I started my first final level 4 vis and then after about three days it because apparent that it was going to take a hell of a long time, so I went back and re-worked my arrangement, turned as many things into func_walls as possible, then set it off again. And then I had to do it AGAIN after another couple of days, because although it was going faster than before, it was still gonna take a hell of a long time.

Wasting a couple of days then stopping it, re-working and starting again will save a lot of time in the long run. Half an hour of map adjustments can equate to weeks less vis times, when doing horrible open planned maps!!

Getting it as efficient as possible first time is even better!! :P