1.4 feature implementation idea - Layers, VBL and MBL.

[kristof65]

Ok, so the post here got me thinking about usability and the underlying architecture of MT in 1.4.

Craig says:

Vision and Lighting
Along with moving to OSGi architecture this is the biggest change. The plan is to completely rewrite this part using a much more efficient way of representing and rendering VBL. This will allow for things that are not possible to do with the current way vision is handled as well as faster rendering. We are looking to add GM definable light and vision types, and the ability to define if VBL blocks one type of light/vision and not another (so you could have x ray vision for example). Objects/Tokens will be able to have different types of images depending on what vision type they are "seen with"

Multiple Layers
The map will have multiple layers, these will act a lot like layers in drawing programs allowing the GM to set who sees what layer etc.

Movement Blocking
There will be movement blocking/penalty functionality where the GM can "draw" areas on the map that the player cant move or will require extra cost to move.

All of which sounds great, and some ideas have probably already been flung about how all that should work. And the planned implementation may be exactly what I'm about to propose. But while I was working on doing the VBL on a map for my next session, I started thinking about how nice it would be if it worked a certain way.

The map I'm working on was created in ProFantasy's CC3, exported to png, and imported into MT where I've been putting in the VBL. While doing the VBL, I kept thinking about how it would be nice if I could just import another monochrome (or even greyscale) image to overlay and use as my VBL layer - because frankly, it wouldn't take me more than 3 minutes in CC3 to create such an image that exactly matched my current map.

Craig's mentioning that the maps will have multiple layers led me to wonder "will the VBL and MBL be special functions, or just special type of layers?" Which got me to thinking about how VBL and MBL should just be another layer, albeit ones with special functions. Because if VBL and MBL were just other map layers, then importing images and placing objects would make them much easier to manipulate. Furthermore, it got me to thinking that a user should be able to define more than one VBL (or MBL) layer.

Not only would the ability to have more than one VBL layer make it easier to implement certain things (like different VBL for different vision types), but could allow for easier implementation of vision (or movement) related features that haven't been thought of yet via macros.

Anyway, just some thoughts I wanted to throw out there for digestion...

[Craig]

The map I'm working on was created in ProFantasy's CC3, exported to png, and imported into MT where I've been putting in the VBL. While doing the VBL, I kept thinking about how it would be nice if I could just import another monochrome (or even greyscale) image to overlay and use as my VBL layer - because frankly, it wouldn't take me more than 3 minutes in CC3 to create such an image that exactly matched my current map.

This has been discussed many times, unfortunately the answer to this is not going to happen. To use bitmaps as VBL would require resorting to a MUCH slower algorithm for light and vision rendering as it would then require testing every pixel vs testing line intersections.

Craig's mentioning that the maps will have multiple layers led me to wonder "will the VBL and MBL be special functions, or just special type of layers?"

Layers will be similar to how they are in popular paint programs. You can "draw" objects on them, VBL on them, put tokens on them, re-order them, hide them etc. Not sure yet if layers will be single purpose, such as you cant put objects on a "VBL" layer, or if they will be able to hold mixed contents. There will probably be some special layers for things like drawing tools. Layers will have some ability to interact with vision, but they wont be the only way you can specify what is able to be seen by what vision type.

Not only would the ability to have more than one VBL layer make it easier to implement certain things (like different VBL for different vision types),

Using different layers for different VBL types could make rendering take more time if you have VBL that can block multiple types of vision, it depends on the set up. I am not sure that it will make it easier to make VBL as you would have to do that same VBL multiple times.

[jfrazierjr]

The map I'm working on was created in ProFantasy's CC3, exported to png, and imported into MT where I've been putting in the VBL. While doing the VBL, I kept thinking about how it would be nice if I could just import another monochrome (or even greyscale) image to overlay and use as my VBL layer - because frankly, it wouldn't take me more than 3 minutes in CC3 to create such an image that exactly matched my current map.

This has been discussed many times, unfortunately the answer to this is not going to happen. To use bitmaps as VBL would require resorting to a MUCH slower algorithm for light and vision rendering as it would then require testing every pixel vs testing line intersections.

It has also been discussed about the possibility of importing an SVG file. Is that something that might work in your new vbl model?

[jmurrayufo]

Why not pre-process a VBL layer in bitmap form into a form that the map-tools engine can deal with? This would work great as it would allow the user to select a 'level of detail' during the import to detail the objects in. Lower settings would result in VBL layers that are horrible approximations of the imported VBL image, but are easy for the program to run quickly in game. Higher settings would get closer to the level of detail of the image, sacrificing CPU time during a game.

[Scubba]

Lower settings would result in VBL layers that are horrible approximations of the imported VBL image, but are easy for the program to run quickly in game. Higher settings would get closer to the level of detail of the image, sacrificing CPU time during a game.

A la Flash's "Trace Bitmap" feature. I like it! One nice thing, this could be easily separated into it's own feature/task without disturbing the underlying VBL tech.

[kristof65]

It has also been discussed about the possibility of importing an SVG file. Is that something that might work in your new vbl model?

I can understand if a VBL layer can't/won't be a bitmap file. But the ability to import any type of file for VBL - say an SVG file - would be a huge step. Even if I can't export a file type natively from CC3 to use as VBL, being able to export from CC3 to something I can convert to a file type I can import to MT would save a lot of time. It took me nearly 2 hours to set up my VBL for my castle maps - 2 hours I much rather would have spent on other things related to the game. Exporting to dxf, converting to SVG and importing into MT would still be quicker than the status quo.

Using different layers for different VBL types could make rendering take more time if you have VBL that can block multiple types of vision, it depends on the set up. I am not sure that it will make it easier to make VBL as you would have to do that same VBL multiple times.

If you implement some sort of way to import files like SVG to use as VBL, and/or export or copy VBL layers, then sure it would be easier. To go back to my castle map as an example - three of my four castle levels were over 50% identical to each other, each level was imported into MT as it's own map. If I could have imported an SVG file, it could have been done in CC3 using their tools. MT having export/copy tools for VBL would have allowed me to export/copy the VBL I did for the first floor, meaning I would have had half my work done for me on the second and third floors.

I didn't specifically mention it, but now that it's been brought up, there definitely need to be more tools for working with all the layers. The ability to import and export layers, as well as copy/paste between them (be they VBL/MBL/Regular) should be implemented. Or at least between layers of the same type. MT doesn't need to become a full featured paint/drawing program if it becomes friendlier to importing and exporting.

So as long as you implement more tools for doing things like importing, exporting and copying VBL, having multiple VBL layers won't really be that much more work for the user. Sure, it might be more work for the machine doing the rendering - but there are factors to consider there, as well.

First and foremost, consider that by the time 1.4 is a fully functional release, consumer level computers will be more powerful than they are now. So it's probably better to design a little over what today's PCs can handle. Secondly, you could always design in customization settings to restrict VBL options for slower machines, similar to how the min/max memory and stack sizes are set now. Not an ideal solution, but doable.

[Phergus]

As Craig has already said this has all been discussed before and there is nothing new being presented here.

The developers are completely aware of how time consuming it is to draw in VBL. The use of SVG as a possible way to bring in VBL from external tools has been under discussion here on this forum since 2006 that I know of. The same with auto-converting a bitmap.

Lack of ideas isn't the problem.

[Azhrei]

The ability to import and export layers, as well as copy/paste between them (be they VBL/MBL/Regular) should be implemented.

You can already do this.

Export your map (with VBL drawn on it), then import it back in under a different name. Now replace the underlying graphics with different graphics. Done.

Importing and exporting maps are "beta" features and need to be enabled on the Preferences dialog.

As Craig has already said this has all been discussed before and there is nothing new being presented here.

Yep. People probably feel better if they see it discussed periodically though. Now that that's happened we can move on to other things.

[Full Bleed]

The developers are completely aware of how time consuming it is to draw in VBL.

Speaking for myself, I don't find drawing VBL all that time consuming... just "quirky" and sometimes difficult to put together something that's going to produce the fastest performance. For example, it would be nice if we could draw one continuous line, changing directions (kind of like VBL waypoints), and know that the VBL intersections would be "perfect" (as opposed to overlapping lines that are clean on one side but not on the other.) Perhaps something like a "snap-to intersection" would be nice so that separate vector lines would snap to another to form one perfect line for a less complex shape.

The "draw VBL block and cut out" method just doesn't work for many maps.


And I've long been a proponent of the so called "two-way" VBL (VBL blocks you can see into but not out of) for trees, columns, doors, etc.

[aliasmask]

I think having VBL/MBL objects will be cool. This can even be it's own special layer. You'll be able to see the object, but not passed it and moving the object will also move the VBL/MBL (like opening a door). I'm assuming this is on the wish list somewhere.

Speaking of 1.4 layers. Seems pretty tricky, but I think if there is a mechanic where you can specify which layer can be seen by which other layers it will be possible to have rooms on top of other rooms with different objects and VBL. It will be token specific of who sees what and the GM will be able (like a player view) change current layer perspective. Players should be able to change perspective layer as well according to where their owned tokens are located.

I mentioned this before, but I would like a fuzzy vbl where you can draw a vbl line (thick) or area and tokens will be able to see in to vbl area, but not out the other side. If they enter the vbl area, then they'll be able to see both sides (like standing at a cliff edge).

[Craig]

Maybe we can add an export/import VBL feature. Then someone is free to add a conversion from bitmap or SVG to this format (which should be a lot easier to understand than current file formats in 1.3).

Converting from a bit map to a vector for complex bit maps efficiently -- and I am talking about efficient vector count not time taken to do it -- is no trivial task, consider most of the tools that do this end up with a series of vectors that are good enough to scale and draw but not necessarily great for our purposes. Also any good method of doing this has a string of patents a mile long attached to it.

As for SVG, this has the advantage that it can be vectors already, it could also contain bitmaps, and even if it didn't contain bitmaps its almost a certainty that MapTool will not support all of the primitives that SVG does. So now the code would be needed to turn the other primitives into the ones that MapTool will support.

I think its better that MapTool has its own format that it can import/export VBL, then if anyone wants to create tools that convert from SVG -- or bitmaps if they feel that they have to perform some type of penance -- to this format and back. As I don't really want to add a whole lot of extra code and libraries to MapTool that are just going to attract bug reports for any old wacky SVG file that some random program spits out, I think having a fixed format that MapTool can import and others can write converters or plugins for other programs to target is the best way. Time is limited and there are many other things I think its better that I spend my time on, the VBL editing tools in MapTool for one, as even if you import VBL from SVG you would possibly need to edit it in MapTool anyway as SVG is not going to contain all the information needed for things like 1 way VBL, types of sight/light it blocks etc.

[kristof65]

As Craig has already said this has all been discussed before and there is nothing new being presented here.

Yep. People probably feel better if they see it discussed periodically though. Now that that's happened we can move on to other things.

It's not so much that, as it is that there is no one place all the 1.4 stuff is being discussed. I tried to find an appropriate thread to post my comments to, but found none.

I know the developers are quite aware that there are some things that need to be discussed prior to writing a single piece of code - because I've seen and participated in those conversations. But they are all over the place here, in no semblance of order, rhyme or reason. It makes it hard for people to know what has been discussed, what hasn't, etc.

So I'm sorry if all this has been discussed before - it isn't obvous to the casual user of the forums.

@Azhrei: I haven't yet tested the import/export map features of b75. I knew it existed, and wondered if it would help, however, I had a limited time to get my campaign prepped for game night, and stuck with a tried and true method to do my VBL. But it took how many versions to actually get an import/export feature into MT 1.3? Better off discussing those now, before 1.4 coding begins, so we don't have to wait another 75 versions.

@Craig: I'm fine with MT having it's own format for importing/exporting VBL/MBL. Hopefully someone will then step up and write conversion tools. In a perfect world, I'd love to see MT import CC3 files natively, but that's way too much to ask for - I'll settle for any sort of import/export.

@Full Bleed: Actually drawing in VBL is more quirky than time consuming for most things, but you must admit there are several ways that one could cut down the time needed - things like copy/cut/paste, import/export, VBL "stamps", etc - that would really help when trying to do maps with lots of similar features (like trees or columns) or for multiple maps that have partial matches. And I like the idea of "two way" VBL myself.

[kristof65]

Speaking of 1.4 layers. Seems pretty tricky, but I think if there is a mechanic where you can specify which layer can be seen by which other layers it will be possible to have rooms on top of other rooms with different objects and VBL. It will be token specific of who sees what and the GM will be able (like a player view) change current layer perspective. Players should be able to change perspective layer as well according to where their owned tokens are located.

Stuff like this can lead to some great in game fun. The session I just ran in this castle, I did something similar - only using the new feature that allows only owners to see tokens.

One of the PCs was being visited by a spirit the other PCs couldn't see. Using the feature that only let's owners see a token, I set the spirit token to allow that player as owner so he could see it as well, but nobody else. The group was fairly confused as to what was going on for awhile because the one player kept referring to the old man that no one else saw.

[jfrazierjr]

One of the PCs was being visited by a spirit the other PCs couldn't see. Using the feature that only let's owners see a token, I set the spirit token to allow that player as owner so he could see it as well, but nobody else. The group was fairly confused as to what was going on for awhile because the one player kept referring to the old man that no one else saw.

ROFL. I am glad my patch helped your game. In 1.4, I hope to have it so that each token can have DM defined groups and those tokens are visible to that group. It was just to much change for 1.3 to do that. I was thinking about this such as secret doors, invisible creatures, etc. For games such as D&D or the similar, a perception check could add a token to the group(s) that the door, creature, etc can be seen by, BUT would not have any ability to modify said thing(as they could with owner only)

[JonathanTheBlack]

One of the PCs was being visited by a spirit the other PCs couldn't see. Using the feature that only let's owners see a token, I set the spirit token to allow that player as owner so he could see it as well, but nobody else. The group was fairly confused as to what was going on for awhile because the one player kept referring to the old man that no one else saw.

ROFL. I am glad my patch helped your game. In 1.4, I hope to have it so that each token can have DM defined groups and those tokens are visible to that group. It was just to much change for 1.3 to do that. I was thinking about this such as secret doors, invisible creatures, etc. For games such as D&D or the similar, a perception check could add a token to the group(s) that the door, creature, etc can be seen by, BUT would not have any ability to modify said thing(as they could with owner only)

The secret door check can be done now, with setOwner, if that function is available and works.