mapping basics

[ungoliant]

probably will need 2, fllood.

 

heres an image i made a few minutes ago to illustrate 2 corner vp: once again to reiterate: no matter how trivial it might look at first glance, this whole concept is a reaaaally big separation of visportalling concerns, "set it and forget it" type stuff.

If this L-hallway separates one whole side of the map from the other whole side of the map, then that means until the player crosses over one of those 2 portals, the other side of the map will not render. period. its a great technique.

Edited June 27, 2011 by ungoliant

[fllood]

Fyi, here's a relevant article to the mitering question:

 

http://forums.tf2map...ead.php?t=10372

hhmmm everyone say different in that one, hrhrr ...

 

The rooms drawn there aren't the one I meant and did for mitering though. Look at the VP example from Springs or me. The edges I did miter in my map so far are corners like where the blue diagonal VP hits the edge (or the two purple VP's meet). For all other room brushes I use Fig 1 and 3 so far. If it's worth doing ... well, as you say, most probably as esoteric as with caulk and yeah maybe not worth it below huge maps

Edited June 27, 2011 by fllood

[brethren]

(re: Ungoliant's diagram above)

 

Doesn't seem like a big deal to me. If those VPs are perpendicular instead of diagonal, as long as they're positioned at least some distance away from the L-bend, it's the same effect.

 

Btw, this is all great stuff guys, keep it coming.

[Springheel]

It's kind of like caulk, some say it makes a big difference, others say the gain in fps isn't worth the time it takes to do it.

 

The caulk issue was put to the test and found not to have a measurable effect. http://wiki.thedarkmod.com/index.php?title=Caulk#The_Effect_of_Caulking_on_Performance

 

At some distance he will see area three round the corner when viewing (see green diagonal line). That shouldn't happen with using a diagonal VP.

 

If it's all one vp, then won't the whole thing be open as soon as he can any of it? That means as soon as the player can see down the hall, the entire thing is open. With two, the other half will often be blocked and therefore not rendered. They don't need to be quite as close to the corner as I made them in that little diagram.

[fllood]

Found Serpentine did recommend the diagonal VP method in the newbie questions thread and did a small test map to prove.

 

I'll take a look at it the upcoming days.

 

Mr. Mike said one interesting thing to be also considered: Sound propagation.

To him sound seam not working well in Serpentine's testmap using the diagonal VP's.

Edited June 27, 2011 by fllood

[ungoliant]

If those VPs are perpendicular instead of diagonal, as long as they're positioned at least some distance away from the L-bend, it's the same effect.

 

not true. Don't forget: Brushes, and even the void, do not block line-of-sight to VP's. Here is another example picture to illustrate perpendicular vs parallel(and on the same line) VP's:

 

The L shaped hallway deal isn't even that important. It could be any shaped passage. As long as 2 parallel in-line VP's cut the original visleaf into 3 leafs, the only way that the 2 outside leafs can be visible at the same time is to be standing inside the middle leaf.

Edited June 27, 2011 by ungoliant

[fllood]

Brushes, and even the void, do not block line-of-sight to VP's.

that's an interesting info ungoliant!

thinking about it confuses me.

What does block Line of Sight to VPs if not Worldspawn and Void?

And what is the black block in the middle to block the Line of Sight in the parallel picture in the middle but not in the perpendicular example?

Edited June 27, 2011 by fllood

[brethren]

Yeah, I thought I was starting to understand how VPs work, but now I'm more confused than ever.

[ungoliant]

What does block Line of Sight to VPs if not Worldspawn and Void?

And what is the black block in the middle to block the Line of Sight in the parallel picture in the middle but not in the perpendicular example?

 

sorry I should of elaborated. The black block in the middle does represent the void, and is indeed invisible when calculating line of sight to VP's. However, the VP's in all examples illustrated in that picture separate the north and south end into their own visleafs. Visleafs are bounded by visportals and the void. Everything in between portals and the void is solidified into its own leaf. These leafs block line of sight towards other visportals. When a leaf is rendered, it no longer blocks line of sight to VP's. But the void itself that serves as a bounding box is always invisible when calculating line of sight.

 

To summarize: A player stands inside a leaf. All other leafs in the map are cut off from rendering unless he can see a portal leading to an adjacent leaf. The only thing that blocks the players line of sight to another visportal is a visleaf. If an VP in the players current leaf is visible, the leaf on the other side is rendered. Now, that leaf no longer blocks the players line of sight towards other visportals. To see further, more portals inside the new leaf can be checked from the players line of sight. If they are visible, the portal opens and even more leafs will render. etc etc.

 

Another exception. Note the bottom left diagram in the illustration that says: "wrong side of VP". that vp is inside the players current leaf. But even if that VP is visible to the player, the side of the leaf that the player can see is facing a closed leaf, and so it remains closed. In order for a VP to open, the face that the player can see must be facing a rendered leaf, not a closed one.

[fllood]

I gave up on Mitering after a month experimenting. As Brethren predicted - it becomes to much pain if you often need to resizing brushes for probably little to none tris gain.

 

Edit: found that for a few occations it still make sense though to ease texture usage.

Edited July 29, 2011 by fllood

[fllood]

deleted

Edited August 31, 2012 by fllood

[ungoliant]

just thought i'd post a blurb about something cool I found. In dark textured areas, bright textures can create a serious eyesore, and kill suspension of disbelief, limiting textures that can be used effectively in the area. This can be mitigated perfectly by adding "rgb <float value 0 to 1>" to the diffusemap stage in a material shader.

 

If you use the startmap pack, you'll have a materials folder with custom.mtr in it. Copy/paste the original shader by right-clicking "view shader definition" in the media bar in DR for the texture you want, and paste it into the custom.mtr file. If applicable change "diffusemap darkmod/xxxx/xxxx/texture" to:

{
blend diffusemap
map darkmod/xxxx/xxxx/texture
rgb 0.x
}

the rgb value is a multiplier you can use to darken the red, green, blue channels simultaneously... cannot be brightened by using values above 1.

Also, make sure you rename the virtual file pathname listed at the very top of the shader definition to something custom so it doesn't overwrite the original shader at load time accidently. I use the virtual folder darkmod/custom for all custom work. Loading the custom shader for use inside DR will require you to load your working map directory into mod (fs_game) setting in the DR game preferences, then restart DR.

Edited August 23, 2011 by ungoliant

[fllood]

just thought i'd post a blurb about something cool I found.

The rgb value is a multiplier you can use to darken the red, green, blue channels simultaneously... cannot be brightened by using values above 1.

Useful Info ungoliant! Thanks for sharing.

 

Loading the custom shader for use inside DR will require you to load your working map directory into mod (fs_game) setting in the DR game preferences, then restart DR.

That had been also the answer for my question above. Didn't worked though with the models I wantd to use. I found the custom model didn't show in DR for a static path had been set to the .aso file by the modeller making it unusable unless fixed. The path for any model textures must be relative to fs_game.

[fllood]

A question about performance in hindsight of lights touching and visportal scissoring:

 

I do have some huge brush as floor and patches which do span multiple rooms. Is it advisable/necessary for performance reasons to cut them the size of each room? Or not worth the extra efforts given specially that patches cannot easily be cut?

Do changing the decal patches to func_statics 1:1 would do any good or just the same for performance?!

 

background:

 

Many big floor patches I use are transparent decals which I found do much trouble to AI and and bugtracking work if not very much care is given in aligning multiple small patches. For that reason I like to avoid splitting the few big room spanning patches I currently use. But performance might get an issue in my map. I remember someone mentioning the formula for performance impact: lights multiply worldspawn or func_static. So I like to know how much impact it might have using big brushes or patches - if any at all.

Edited August 23, 2011 by fllood

[ungoliant]

I do have some huge brush as floor and patches which do span multiple rooms. Is it advisable/necessary for performance reasons to cut them the size of each room?

Do changing the decal patches to func_statics 1:1 would do any good or just the same for performance?!

 

background:

So I like to know how much impact it might have using big brushes or patches - if any at all.

 

it is extremely advisable borderline on completely necesssary to cut up those brushes/patches between rooms. Although if the floor is worldspawn, the rendering will get cut off in closed visportal areas, the main issue is multiple lights touching a single surface. Having like 10 lights touching surfaces is just a recipe for disaster, always try to limit how many lights affect a surface. I start getting paranoid if 3+ lights touch a brush. Theres a cvar that will color-code rendered surfaces based on how many lights are touching it, but i forget what it is.

 

Changing decals to FS has no peformance impact as far as i can tell. decals do not splinter other worldspawn into smaller tris as far as I know, which is the primary function of converting to FS. The only effect this would have is to cause the whole FS to render if any part of it is touching an open leaf, just like any other FS. So it's probably bad to do this.

 

Dont forget, if your using patches for the floor, they do not create pathfinding at all, its part of the collision model. the brushwork underneath is what makes the pathfinding. Monsterclip is good for making pathfinding areas that are invisible and intangible to the player. As long as the monsterclip touches or is very close (0-40 units or so?) to the patch, the AI will figure out how to traverse the patch. This applies to models and other FS surfaces as well as patches.

Edited August 23, 2011 by ungoliant