This is a pretty dumb question but could somebody explain to me exactly what glvis does?  From the description provided, it sounds like it does something similar to what Kyro-based cards do with hidden surface removal but I might be mistaken.  What sort of performance increases does it provide and if they are significant, why do more doom-engine enhancers not adopt the method?

Basicly it does the same thing that vis in Quake engine.<br>Vavoom uses vis data for rendering, faster sight checks and network updates. About other ports - well for rendering engines using old Doom renderer uses it's original algorythm, hardware accelerated engines may use some similar algorythm or, in worst case, render entire level.

Heh, I didn't know what Quake VIS was either but I looked it up and now I have a general understanding.<br><br>On one page that I read though it says that VIS only works well for relatively static worlds.  Is this wrong?  If not, what limitations does it imply and is there a way around such limitations?

Yes, vis works well for static worlds. And Doom uses 2D BSP trees, that makes world static in XY space, and Quake uses 3D BSP trees meaning that nothing in the world can move.<br><br>Limitations - for Doom engine it means that vertexes cannot be moved on flight. Hexen polyobjects are special cases and they also have their limitations.

Heh, I am dying to see just how the Doom III engine works.  If I remember correctly, one of the id programming guys said that he hated the static world assumed by vis.  I wonder how they will work around this...

Actualy it's BSP tree that makes world static.<br><br>Of course some other visibility test will be used. Most likely they will be portals.

I was very sceptical with using your glvis utility since using the "automatic" fast mode made playability VERY slow. I eventually used your standalone utility as you recommend and was very impressed with the speed increase. Have noticed on other forums that vavoom gets criticised for its slideshow slow fps. I think this is because they dont use your glvis utility. Please keep working on strife and maybe even fix that z-buffer "bug" with sprites in floor and the skybox - tks

When I run glVis on several of the larger<br>levels it hangs the system.<br><br>Can you add an ignore strict error or huristics <br>(rules of thumb) to allow glVis to process<br>every level that runs in doom.<br><br>(ie. like putting a limit on how far down the BSP tree glVis looks. Make it kind of like a real eye--even if we could see for many miles our eyes wouldn't because<br>after a certine distance everything would fade into a singlearity or point. Sounds the ear hears would work in a similar fasion--we can't hear people wispering in an other country no matter how queit it is.)<br><br>With such rules of thumb and rules of nature built into glVis it would be possible for glVis to process several levels that contain missing lines or unclosed sectors.<br><br>Set two variables for example:<br><br>#define MAX_VIS_DIST 1024 // After 1024 stop glVis<br>// it is invisable<br><br>#define MAX_SND_DIST 512 // After 512 sector is silent<br>// Nothing futher that 515 units can be heard.<br><br>Make these vars user defined.<br><br>What do y'all say about it!

Unclosed sectors is not a prob for glVIS. It cares only about segs, and for lines basicly it only needs to know wether it's one-sided or not. And if your level contains lines with wrong flags, it will make glVIS ignore them. As of BSP tree, glVIS doesn't use it. Limiting the sight distance isn't a good idea, since it's possible to see very far. And glVIS has nothing to do with sound.

What makes glVis freeze on some of my larger levels--I have a P-IV with 512 MB of RAM<br><br>Is there a limit on the size of a level that glVis can handle?<br><br>Is there a tool that can repair blockmaps--esp. broken blockmaps \& if not ??? what node builder should I be using ??? to handle large levels.

I don't know yet why it freezesa and wether it's really depends on size.<br><br>Theoreticly there's no size limits.<br><br>Blockmaps are created with node builders. On large levels it might be too big, so a node builder which can compress the blockmap is highly recomended. glBSP is such a node builder. See glBSP docs on how to make it build normal nodes.