Faster VIS!?

Moi · Post by **Moi** » Wed Sep 14, 2005 1:02 am

just use the 'normal'-settings, this will speed up the process a lot.

DARKHALO2K · Post by **DARKHALO2K** » Wed Sep 14, 2005 3:02 am

Moi · Post by **Moi** » Wed Sep 14, 2005 5:02 am

I'm using WorldCraft 1.6 Shareware.

You should be able to get all parameters by typing:
vis -?

in the console

Post by **Tyne** » Wed Sep 14, 2005 7:42 am

Use tyrvis, tyrbsp and tyrlight. Best programs for compiling quake maps that I've seen according to most quake 1 mappers.

DARKHALO2K · Post by **DARKHALO2K** » Wed Sep 14, 2005 1:00 pm

Moi · Post by **Moi** » Fri Sep 16, 2005 1:52 am

Tyne wrote:Use tyrvis, tyrbsp and tyrlight. Best programs for compiling quake maps that I've seen according to most quake 1 mappers.

Any idea where I can download this ones? I've tried google without any big success

DARKHALO2K · Post by **DARKHALO2K** » Fri Sep 16, 2005 2:01 am

Moi · Post by **Moi** » Tue Sep 20, 2005 2:10 am

Thanks DARKHALO2K, im going to test this and report how good it works...

BlackAura · Post by **BlackAura** » Tue Sep 20, 2005 4:59 am

Assuming you don't have an ancient machine (like, something released within a few years of Quake), there's no way maps should be taking hours to vis.

If you are using hardware that old, then there's nothing you can do to speed the vis process up. It's just slow, so you may as well ignore the rest of this post.

The original Quake levels take only a couple of minutes each to re-vis on my system, even at the highest levels. If your levels are taking hours on modern hardware, they're going to have to be several orders of magnitude more complex than id's levels, which means that you're going well beyond what the engine was designed for.

If you have a look around id's levels, you'll notice that geometric detail is used sparingly, and they tend to use texture detail instead. That's largely because the BSP process does not work well when you have lots of fine detail. Everything in the level proper needs to be part of the main BSP tree, which works by splitting the level in two along faces. Adding additional geometric detail can add far more complexity to the level than you may realise, which in turn makes the vis process take longer.

I would guess that the primary culprits are going to be things like tables, chairs, vending machines, light holders, and any other objects you might have placed in as part of the level. Bad idea. Those objects will be incorporated into the level itself, and considering how detailed small objects are compared to rooms, that's going to add a hell of a lot of complexity.

There are two things I can think of that might help. First, you can try attaching objects to an entity. Even if it's just a func_wall, it'll still be removed from the main level, and treated separately. You won't be able to tell the difference once it's in the game, because it'll look exactly the same.

Second, use MDLs of objects instead of building them in the map editor. They won't be lightmapped, but for small items that doesn't really matter. They would also look significantly worse than level objects in software Quake, but look just fine in hardware.

Neither of those types of objects are even considered by the vis process, so if they were causing problems you should notice a decrease in vis times after you replace them.

Moi · Post by **Moi** » Wed Sep 21, 2005 1:37 am

well while tyrbsp and tyrlight seem to run faster,
tyrvis takes too much time to compile, so no improvements speedwise out there...
you should use the standard vis.exe i guess.

Mr.INSANE · Post by **Mr.INSANE** » Wed Sep 21, 2005 8:16 am

Normal Vis absoultely sucks

With my experince its probally the worst porgram to vis maps since it hates any detail

Go with tryvis its better in some ways and theres a few others that vis well
Including Lordhavocs
hmap2
http://icculus.org/twilight/darkplaces/ ... 050621.zip

theres problly some others out there aswell