Vis compile ?

(lennyballa) #21

So higher is better? Isn’t there just a “butt”?

(SCDS_reyalP) #22

As I said before, if your blocksize is large, whether it is bad for your map depends on the actual construction. It defaults to what it does for a reason… the main one being to help keep the bsp tree balanced.

(Thej) #23

this is the official read for the _blocksize
_blocksize : q3map always splits the BSP tree along the planes X=_blocksizen and Y=_blocksizen. Default _blocksize value is 1024. Increase the blocksize using larger powers of 2 to reduce compile times on very large maps with a low structural brush density.*/

(SCDS_reyalP) #24

Thej,
FWIW, blocksize can have 3 dimensions when using q3map2.

(SoulRebel) #25

If arrange to have some of your sturcture on block bounderies, you can make your map slightly more efficient.

yes. my blocksize is 1024 (i think i know what these blocks are… i think i can see grafic-differences on running maps every “block”?)

and one part of my terrain is 2048 x 4096 and the grid-size is 8 x 32

(Thej) #26

well when i set _blocksize 1028 1028 2000 for instance the horizontal doesnt show upo when i do show blocks, but could be ofcourse that it does work with q3map

(Shallow) #27

Of course, what you meant to say was that you set it to 1024 1024 2048, right? :wink:

Values that are not a power of two are baaaaad :moo:

(Thej) #28

hehehehe, was just setting an example :smiley:

(SCDS_reyalP) #29

You should not be able to see the ‘blocks’ in game. If you can, there is something very wrong with the map.

The reason that putting your structure on block bounderies can help is because it reduces the number of splits in the BSP. The compiler ALWAYS splits on the blocks first. If you want the gory details, they are here http://www.planetquake.com/spog/stuff/technical.html

(Loffy) #30

Aha! So, what you are saying is that I can a) have a look and see where the machine splits my map, and b) make sure that I arrange objects inside my map so that they are “in line” with these split-lines. For example, if I see that the compiler splits right through a building, and rooms inside that building, I can try to move the building left/right or up/down. (So the rooms arent splitted into more areas - bsp areas.)
(The more bsp areas there are, the longer it takes for my pc to calculate all the visability stuff when compiling the map.)
I’ll try it. Thanks! // Loffy

(SCDS_reyalP) #31

Yeah thats it. For example, there is always a split at 0,0 Now suppose you made a 1024x1024 room centered around the 0,0 (extending 512 in each direction). The room would get split into four parts, and store the vis data to say that each of those four parts of the room could see each other. Now suppose instead of centering the room, you put it so that one corner was at 0,0. Then you wouldn’t get any extra splits, because each wall would be on a block. That may sound trivial, but depending on the exact layout of your level, it can have a noticable impact.

Obviously, there are other, more important considerations for the layout of your level, but when you have a choice you may as well take advantage of it.

The portal viewer plugin is an excellent way to see how q3map is spliting up your map. You need to do a full vis with -saveprt in the command line to use it. Then do ‘load .prt file’ and set it to display in the 3d and/or 2d views.

blocksize is also important if you are using fog culling. If your blocksize is much bigger than your fog distance, and you have open terrain, you will end up drawing a lot of stuff you don’t have to. (it may still get culled at runtime, but doing it at compile time is much more efficient.)

(SoulRebel) #32

ok… i understand now how -vis works but the next question:

i have a terraion which is 2048 x 4096 (divided to 1024 blocks)… all of the terrain are structural brushes because they are close to the void… so, when i load the prt file in the plugin-command i see a lot of yellow lines (yes, they are everywhere!) … i do not know how to optimize that… how can i handle this? i cannot place hint-brushes because they can be seen from everywhere of this terrain (i have small hills but they are no “real break”)

so, how did the splash-damage crew the fueldump map?

(SCDS_reyalP) #33

You don’t want the terrain to be structural. It is far too complex. If you have hills/mountains that you want to block vis with, they should have simple caulk walls embedded in the terrain. If the hills aren’t large, there is no point in even trying to do that.

Below your terrain, you should have a big flat caulk floor.

If you do use hills with caulk walls in them, you will also need to ensure that there are some splits at or below the wall height, otherwise the compiler will think you can see over them. Again, the portal viewer should make this clear, and you can use hint brushes to add splits where you need them. Use ‘skip’ on the faces of the hint brush that you don’t need splits on.

When you look in the portal viewer, remember that the compiler tests each of the volumes defined by the portals. So if you don’t want the geometry in volume A from being drawn when the player is in volume B, you must have structure which prevents you from seeing any part of volume A from any part of volume B.

There is another plugin, bobtoolz vis viewer, which you may also find useful.

(SoulRebel) #34

thx… so far

one basic question: i never used terrain in maps till et… normally, brushes should not cross each other… but with terrain it is nearly impossible to curve all brushed (houses, bunkers on terrain, in mountain…) in right position or when i use the csg-substract method there will be ONE terrain brush be devided into “hundreds” of brushes… not a good solution… is “brush-crossing” the best way in such cases?

(ziege) #35

Just delete the brushes in the terrain to make room for your houses and bunkers. Use the clip tool to make more perfect cuts. CSG subtract just completely screws your map sometimes, I pressed it once and was finding wierd giant traingles in wierd places for days after, so just avoid it trust me!

You can overlap the brushes too, as long as it doesn’t cause z-fighting (correct term?) where it trys to display two surfaces on one plane. So if you have water for example, it’s OK to have a large water brush overlapping the terrain. Cutting it out perfectly manually would take forever.

(DeAtHmAsTeR) #36

yes it is the correct term

(SCDS_reyalP) #37

Avoiding subtract is good.

Overlapping brushes, by itself is NOT a problem (yes, I know the manual says never to do it. The manual is wrong, or at least making a gross generalization).

What is a problem is overlapping textures. That will cause z-fighting (which you can see on many of the splashdamage maps, especially in 16 bit mode). Sometimes z-fighting is unavoidable, since it can happen at long distances even when the textures don’t actually overlap.

With current version of q3map2, your terrain does not have to made of same sized brushes. So you can edge or vertex edit terrain brushes, or hand create the brushes next to your buildings etc and then merge them into the terrain func_group. That is the best way to shape the terrain around other stuff.

If you want to move the corner of a terrain brush in XY, I suggest using edge edit first. Then use vertex edit to make sure the vertex is exactly on the grid in Z.

(SoulRebel) #38

ok… as i thought… thx a lot

(SoulRebel) #39

next one: i am frustrated, trying all the time to optimize the -vis

one example:

|ssssssssssssssssssssssssssssssss
|…|
|…m…other…|

…P…m…sector…

i have this poblem: player § is standing on a terrain… the map divides into 2 sections… the one the player stands in the left, the mountain (m) (naturally split) and the right sector should not be seen!

now when i load my prf file i can see the things behind (but above) the mountain… how can i block the line of sight that only section left is visible!

i have tried caulks, hints… but no effekt

(Thej) #40

try a big brush covered with the texture common/areaportal and put that above the mountain or if the mountain is detail, make a brsuh from bottom to top, maybe that works