Question about how VBL works.

[Oryan77]

I'm trying to make sure that I create VBL in the most efficient way to reduce lag on my large campaign files. I use lots of token, large high res maps, animated doors, and lots of light sources all within the same map. So performance can be an issue (I use MT offline to play).

I've heard in the past that it is good practice to just create one solid rectangular VBL over an entire map, and then cut out the areas within it. So that is what I normally do and it seems to work well.

I was wondering about other routines I might do when creating VBL and whether or not it could reduce CPU performance.

1. If I create an area of VBL and then use the VBL tool again to overlay new VBL on top of existing VBL, does MT recognize it as two separate layers of VBL or do both areas merge to form a single VBL object?

2. Similar question to #1, what if I draw a rectangular VBL and then use the VBL line tool on top of that area that would extend outside the rectangular area? Does it merge to become a single VBL object or is it two objects (the rectangle shape and the line shape)?

3. Does performance change any when using the rectangle VBL tool to draw "lines" down the center of all of a buildings walls vs creating a solid VBL and cutting out the sections of the rooms? If so, would it improve performance if I "filled in" the outisde areas of the rooms so that the outer edges of the VBL end up having only 4 corners (as if I created one solid VBL rectangle and cut out the rooms)? Or will it recognize all of the fill-in areas as separate VBL objects (which relates to my question #1).

[aliasmask]

Here's a post about how I do VBL.

http://forums.rptools.net/viewtopic.php ... 29#p225029

[username]

Oddly enough, aliasmask, you state your method sacrificies performance in the other post.

Some general remarks on performance. VBL in MT is based on java areas, basically constructive solid geometry, CSG for short.

1. All objects are kept, they are not coerced (I am not even sure, whether objects fully covered by others are dropped) so create your VBL with as few objects (construction steps) as possible.
2. The larger (in the number of corners!) the objects are, the longer it takes to analyze them, prefer rectangles over free-hand.
3. Avoid the holes in solids in holes in solids... pattern. MT internally stores orientation to areas (forgot what they are called internally) and keeps lists of "islands". These can have "islands" themselves and so forth. Algorithmically that is more involved then flat CSG. (I don't recall, why that is needed, because CSG already covers that.)
4. The last point may seem to conflict with the suggestion "Hide everything with a big rectangle and cut away the visible". But this is not really true. One "violation" doesn't hurt much. You are usually cleaner, because you don't leave cracks. And on average I suppose, you save a few objects and complexity by creating the rooms instead of the walls.

The algorithms involved are linear in complexity (1) and (2) above, they are quite efficient. I don't recall for (3). To your questions: (*) VBL is only one layer (but technically a lot of different objects belong to it). (*) Objects are (almost?) never coerced. (*) What is the most efficient cannot be said in general statements like that (see above). The only general advice, I'd give, is: don't use the concentric areas approach, where you hide everything, unhide a big rectangle, hide a medium circle, unhide a smaller circle, hide an even smaller rectangle, .... Better cut the "frames" out of the biggest shape.

[aliasmask]

Yep, my method has more vbl lines but looks better than pure strait lines hugging a wall. From my experience, the difference in performance isn't that much. What really drags down performance are the number of objects (object layer) on the map, or so I've noticed. I also changed my default vision range to 120 in dungeons and 240 in outdoor daylight conditions to cut down on the calculations. The Bag of Tricks has an option to clear FOW after each move which helps if you're having lots of lag.

[Oryan77]

Thanks. I think I understand that.

So having more objects on the object layer will cause performance issues in relation to having lights and VBL on?

If so, does copying/pasting the same object multiple times still reduce performance? I thought it was better to build maps within MT rather than built them in Photoshop and importing a large file?

[aliasmask]

Lights are another issue. That does add to performance. I usually only add extra lighting when needed or change from night to day if there are plenty of lights. I basically don't recommend using lighting for special effects. If the PCs have their own light sources, then it's usually not an issue and extra lights aren't needed.

As far as how much is too much, that's hard to say. I did discover this performance drag when I made a Stonehenge type map and added a bunch of individual rocks. Movement was noticeably slowed, but it was still playable. Only through experimentation will you know how much is too much.

Almost all my maps are photoshop maps with individual set pieces added like doors or things that can be removed which I put on the background or object layer. The large map really only affects the initial map load and I recommend using a campaign repository. I think my largest single image for a map was about 6500 x 4500. One trick is to maybe make your map at 1/2 or 1/4 scale and then stretch it in MapTool if it's particularly big. Another method if you have large empty area is just create the map in sections or with large tiled stamps. I once created a very large sewer system and garden maze using tiles and a city that was about a mile across by strething and using a 10px grid. If I wanted more detail, it could put an overlay map on top of the city map or just use another MT map.

Using the drawing tools does allow you use big areas, like drawing a Forrest with a pattern but I rarely end up doing that because the MapTool paint tools are less suited for layered drawing techniques and more suited for special effects and group drawing board.

[JamzTheMan]

The VBl isn't as much a factor as vision and lights from my experience. Unless you draw very very bad vbl, like individual bars on a jail cell (did that once, for effect, tall about lag lol) you should be good. Zooming in and making sure you have nice corners vs 4 pixel pigtails or openings will help. Snapping your VBL to grid when you can helps in that regard.

But don't put torches every 20 feet and add lights to them. As Alias said, just turn vision to day if its well lit. Otherwise turn off light sources in other parts of the map and try to keep it less than 10ish (YMMV).

Another thing I noticed was MT will calculate vision for every NPC on the map (and light sources will compound this) on every token move. So I created two macros to turn vision on/off for tokens, and if I have lag I will first turn vision off on all NPC tokens. I had Keep on the Borderlands all on one map once with over 200 npc tokens IIRC and it was bad lag because of that.

Generally I usually use a lot of objects for decoration and do not find they add any lag. Increase memory, yes, but never affects my performance.

This is with over 200 Pathfinder sessions ran, so been around the block a few times.

[Oryan77]

Oh thanks guys. I think that actually clears up a lot of issues up for me.

So my performance issues probably aren't so much the VBL I use since I think I've got a good system going for creating VBL (cover everything and just cut out the individual rooms).

The issue is with lights, since as soon as I change vision to "night", all hell breaks loose. I do like you did with Keep on the Borderlands, and I have lots of tokens on a big high-res map. I tend to put lights in any room that is supposed to have them. Switching from night and day would most likely confuse me. I do however like the idea of turning NPC vision on/off.

I also don't know why I never thought of just turning the lights on in a room as PC's enter the room. I've created some nice tokens and macros for my lights that would make doing that easy. I can select a "sconce" that has a graphic of a sconce without flames, I can hit my "sconce" macro and the graphic switches to the show handout image within the token to change the image to a sconce with flame. The macro also turns the light source on for that token.

Could one of you give me the code to use for a macro so that I can turn vision on/off only for NPC tokens that I select?

[JamzTheMan]

The most basic macro is: [h: setHasSight(0)] and check "Apply to selected tokens".

I like your idea for the torches, feel free to share that macro.

You could even get fancy with it (as I don't know about you, but I usually keep those sort of items on the Object layer and switching layers to select torches, etc can be a PITA) you could set a macro to select all the torches within x cells/feet of a PC and turn them on (ie any torch within 200 feet).

I have a similar macro for detect magic that could be modified:

Expose Auras

Code: Select all

[h: cond = '{ range: {upto:12, distancePerCell:0, metric:"ONE_TWO_ONE"}, setStates:["isMagical"], layer:["HIDDEN"] }']
[h: tokenList = getTokenNames("json", cond)]
[h, FOREACH (token, tokenList): setLayer("TOKEN", token)]
[h: count = json.length(tokenList)]

[h, FOREACH(token, tokenList, "<BR>"), CODE:{
	[cantSee = json.isEmpty(canSeeToken(token))]
	[layer = if(cantSee == 1, "HIDDEN", "OBJECT")]
	[setLayer(layer, token)]
	[count = if(cantSee == 1, count - 1, count)]
}]

Exposed {count} magical auras.

Would have to see if the canSeeToken includes "vision" ie "light" or does it just use vbl and max distance to calculate. Would still need some manual intervention, for say, a torch in a room 250ft down a hallway would still show light to a PC and should be on and wouldn't be caught by this macro.


Usually, most underground dungeons I have are usually populated with creatures that all have darkvision so wouldn't really need torch lights anywhere. And if it is something like, say a human cult dwelling, they probably would have enough torches to consider it all lit, so turning daylight on is easier. But occasionally, there is that map with fire places, or forges, etc that you need some torchlight for ambiance and to create those nice dark corners.

I would say, Lighting/Vision is really or number 1 bonus to going digital. Sure, mapping is nice and so is VBL, but I could emulate that well enough with markers, a mat, and mini's. But I would NEVER have, on a round by round basis, considered torch lighting, vision distance, and vbl as well as MT could. It's really made playing races with Darkvision more enjoyable and we never have a caster without light spells.

[Oryan77]

It's really made playing races with Darkvision more enjoyable and we never have a caster without light spells.

I completely agree. That is kind of why I prefer to keep my light sources turned on rather than flipping back and forth from daylight to night. It adds to the coolness factor of MT and players love the realism of being able to interact with light sources. So when they are in a dark dungeon, and using torches, then they can see way off down a hallway of the map that some light is protruding from an open doorway, they want to go investigate the source like moths to a flame.

I'm actually working on a D&D documentary at the moment for my film class (I'm an adult student). It focuses on me introducing D&D to a group of 4 people that know nothing about D&D. They played their first session last Friday and they absolutely loved what Maptool does for the game. The players running the dwarf and half-orc thought it was so cool that they could see their darkvision being used within the program and they felt "special" for not needing torch light like the 2 elves needed.

I'll see if I can get time to create a post to explain my light tokens/macros. It's something I really like a lot and I don't know why I've never shown it here. I guess it is something that I just assumed everyone was already doing since it seems a little obvious to me.

Speaking of which, so are you saying that it may be possible to make tokens on the object layer turn their light source on/off depending on how close PC tokens are to them? If so, that would be an amazing feature and would really help on my lag issues by only using lights as they are needed rather than having every light turned on within a map.

[JamzTheMan]

We pretty much make fun of anyone that now plays a rogue/ninja/sneaky type as a human or non-darkvision-race.
"So..your plan is to sneak up on the base with your torch in hand? brilliant."

Regarding your last question, yes, see mt Expose Auros macro. Basically:

[h: cond = '{ range: {upto:12, distancePerCell:0, metric:"ONE_TWO_ONE"}, setStates:["isMagical"], layer:["HIDDEN"] }']
[h: tokenList = getTokenNames("json", cond)]

Sets a condition to get all tokens, up to 12 cells away with a state of "IsMagical" on the "Hidden" layer.

So adjust accordingly, ie 36 cells, state of "IsTorch", layer "Object". Now, that will get all tokens regardless of VBL. But you can further process it via the canSee macro...but like I said, if that torch is around a corner, you would miss it via macro.

What I would probably do is have a hidden token on the map that I could move around/down hallways, etc, that would have the macro to expose/hide torches. Mmm, you could even process the macro "onTokenMove" so as moved it around it would turn on torches...maybe a second to turn off torches...

[Oryan77]

I haven't had a chance to try that yet, but just thinking about it, how would the macro know "which" light type to turn on for each individual light source? Meaning, some lights will cast 20-ft of light, others cast 60-ft, some may even cast different colored lights.

Can details like that be distinguished for each object?

[JamzTheMan]

I would use states/properties. I'd set one state "isTorch" (or isLight, whatever) so you can do one pass to get all the torch tokens.

The light source could be just a property, read the prop and set the appropriate light source. Could store the prop to match the light source name like "lumens=Torch - 20" so you could loop through it easy enough.

I would then just save the different "torch objects" in another folder as rptokens so you can reuse them later more easily.

[Oryan77]

Hmm, I'm pretty confused about all of that. I'm a graphics guy and terrible with the coding side of things. I would love to get a system like that working with my light tokens.

Which BTW, I created a post to explain how I do my lights.

http://forums.rptools.net/viewtopic.php ... 51#p256451

Luckily I already have my lights saved as token files. So if I can ever get what you are talking about to work, I think I just have to change the token properties and save them out again.