I'm working on an experiment to create a highly detailed somewhat large room. Not really a conventional map (no monsters). Now it's time to vis the map. I could call it finished without running vis.exe, obviously it will not benefit from vis. Problem is if I want to create a proper Quake level adding more areas vis will take days/weeks.
My question is to anyone who knows in innards of vis.exe. Could a version of vis be created with a way to flag an area as ignore. A bounding box around a room that tells vis don't calculate whats inside but calculate the box to the rest of the map.
I know how to use func_ as details and all the tricks like that. Too much func_ makes for crap lighting.
func_viscluster?
https://developer.valvesoftware.com/wiki/Func_viscluster 

No. 

 

We tried for a func_detail entity, and it worked. But functionally its the same as a func_wall. To keep shadows you can place floating blocks (that don�t touch anything else) inside the func_.

The big issue to overcome however is flickering entity. The RMQ engine has this. Basically, if a func_whatever crosses more than x visleafs thenit�ll flicker / dissapear as the player moves through different leafs, thinking that the object can no longer be seen.

If you saw the floating galley I did in one of the RMQ demos - that entire thing was func_. Although lighting did suffer because I didn�t add any shadow clipping blocks.

Vis blocking can solve lots of stuff as well. Bit busy, but try searching �doughnut corridor�. Adding switchbacks and doglegs should always speed up vis against a map with open corridors.

If you�re doing a void style thing as opposed to room-corridor-room then you�ll have to use other tricks, like sealing off rooms with sky brushes. 

ijed Thanks for the info. I do know the vis tricks. Had a thought of making the whole thing into a bsp model and using skip and clip, connect to other rooms with vis blocked halls. maybe....

If only func_ could do lighting. 

Receives light, but doesn't cast shadows. Its still possible to get decent looking stuff with it, but more likely to produce artefacts as well. 

will not be solid, while the q3map2 compiler can simply compile it into the map, including clipping. 

I made a map in radiant then used worldcraft to compile it, when I did it saved over the map in some crazy valve format that radiant can't read, is there any way to bring it back? 

Use TxQBSP to make the .map into a .bsp

Use WVis to do the vis process

Use Light to do the light. 

but how do I get the sucker back into worldcraft? 

 

it says it's saving it as a game map, when I open it in notepad++ data is formatted differently and when I open it in radiant it says it was expecting a # instead of a [ 

AFAIK - although I heard mention of a script that strips out the extra texture information that WC adds.

Essentially it adds a few numbers to every brush to describe extra texture information - which is how WC3.3 manages to have so many more controls for alignment.

Not familiar with Radiant but if it refuses to read a WC3.3 level then maybe another editor will allow you to convert it back. Beware though, since you could well lose all texture alignment using either a script or editor to bring it back. 

WC saves in Half-Life / Valve 220 format. Someone posted a converter program at quakeone.com once, but I don't remember who or when. It might have been Scrama...

http://scrama.3dn.ru/tmp/MapConverter.zip

I haven't tested it.

http://quakeone.com/forums/quake-help/servers-coding/3997-half-life-bsp-q1-8.html 

it worked. 

Nice. (This means Worldcraft can theoretically be used for q3bsp/rbsp/fbsp mapping, too.) 

In a map editor, would it be useful to be able to create new textures out of multiple brushes without having to go into a 2D editor? 

A lot of the textures people make are combinations of existing textures done in order to reduce r_speeds. This would be great for trims etc.
It doesn't take that long to do in a 2d editor though, and obviously you can do more. 

Most of the textures I make are things I can't do with brushes.

What I do wish is that I could swap textures in a wad while Radiant is loaded and refresh the wad when desired. 

Not that making textures in editor would be a bad feature if it could be added. 

 

You mean arranging brushes so that the texture looks different? I do this already quite a lot.

Do you mean capturing such a configuration and saving it out to a 2D format? 

The latter.
I do the former all the time, but it tends to waste vertices and inflates clipnodes and visleafs. 

Combine textures to combine brushes. Would this also help the lightmap?

Highlight multiple faces create the texture then merge brushes apply new texture. Is that the idea? 

Pretty much. It's kind of like, you'll be mapping and making your trims as usual. You realize you'll probably have the same trim + texture layout everywhere so you just make a new texture right there on the spot, inject it into the wad and keep going.