FEATURE: Casting new light on MapTool
Moderators: dorpond, trevor, Azhrei
Forum rules
Posting now open to all registered forum users.
Posting now open to all registered forum users.
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
FEATURE: Casting new light on MapTool
OK, so had a few hours to kill yesterday and got a little A.D.D. on my MapTool coding. Guess i'm in a Proof Of Concept mode...
Any hoo, I was looking through alternatives for rendering FoW and found a few options. I shied away from LWJGL and Box2dLights for now, although they seem to offer OpenGL possibilities, it seems like something I couldn't really tackle in a weekend.
So I tried a few other options and ended up playing with tool called StraightEdge (library? mostly just a collection of a few java classes). It was pretty straight forward, and it looks like jfrazierjr found it a few years ago. Anyway, I plugged it in and tied it to the mouseMove for now to play with it and got it interacting with our VBL. That was the hardest part, because getting Polygons back out of an java.awt.geom.Area is just a PITA. Luckily I was able to leverage my VBL Macro code.
Here's a video of it running: https://www.youtube.com/watch?v=aBDtMa7uk90
When I get some more time, I'll see if I can hook up some more lights and or tie it to tokens so I can stress test it a little more. Thoughts?
Any hoo, I was looking through alternatives for rendering FoW and found a few options. I shied away from LWJGL and Box2dLights for now, although they seem to offer OpenGL possibilities, it seems like something I couldn't really tackle in a weekend.
So I tried a few other options and ended up playing with tool called StraightEdge (library? mostly just a collection of a few java classes). It was pretty straight forward, and it looks like jfrazierjr found it a few years ago. Anyway, I plugged it in and tied it to the mouseMove for now to play with it and got it interacting with our VBL. That was the hardest part, because getting Polygons back out of an java.awt.geom.Area is just a PITA. Luckily I was able to leverage my VBL Macro code.
Here's a video of it running: https://www.youtube.com/watch?v=aBDtMa7uk90
When I get some more time, I'll see if I can hook up some more lights and or tie it to tokens so I can stress test it a little more. Thoughts?
Last edited by JamzTheMan on Sun Mar 15, 2015 6:27 am, edited 1 time in total.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: Casting new light on MapTool
Pretty cool. Lighting has always been kind of meh in MT, especially when you start overlapping different colors. What I would really love to see is an effect like a light source, but for darkness where is lowers existing light. I guess the light source would need priorities. Also, using set radiance levels like in PF of dark, dim, normal,bright and a mechanic to merge them would be nice. But I'm just dreaming. I think that would take a major effort to accomplish.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: Casting new light on MapTool
Ya. I did try a couple of light sources with this ( a blue and yellow one) and they blended pretty cool like. I think this would give some nice effects. I also toyed with the idea of allowing a "flicker" factor, something that would give it a more "torch" like look and have the light wax and wane in brightness and distance. Although I'd have to break that out into another thread and threading isn't a strong suit of mine, but an idea...aliasmask wrote:Pretty cool. Lighting has always been kind of meh in MT, especially when you start overlapping different colors...
Not sure if you missed this post? http://forums.rptools.net/viewtopic.php?f=26&t=23976 and also my list of enhancements in my Jar, but I've had that and been using it in Pathfinder games for over a year now.aliasmask wrote:...What I would really love to see is an effect like a light source, but for darkness where is lowers existing light. I guess the light source would need priorities. Also, using set radiance levels like in PF of dark, dim, normal,bright and a mechanic to merge them would be nice. But I'm just dreaming. I think that would take a major effort to accomplish.
I added a "Lumens" setting in the Light Source definition. If you set it to a negative number, it acts like darkness. A positive number isn't needed but the absolute values are used for ranking. In other words, -20 Darkness blacks out the screen for normal lights (with no lumens) but Darkvision (personal lights set to 100) overcomes Darkness, but Deeper darkness set at -140 overcomes darkvision and Daylight set with lumens 160 overcomes that, etc.
Now, there's no "special effects" and MapTool doesn't have a concept of "Ambient Light" or "Dim Light", and I can't "add or subtract" lights for now. That would be a bonus and would then allow for full Pathfinder rules of Darkness -> Dim Light -> Bright Light. Not sure how to represent that graphically though.
Oh, and I found a neat little lib for my next POC. It turns images into java "shapes". I'd like to add a special layer (or mark the stamp/token?) where that token would cast a shadow but still be seen (ie the token would be above the FoW layer), so you basically get something like players can see a roof or car but not behind it. Oh, I have plans and Ideas!
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: Casting new light on MapTool
Cool. Too bad it's not in b91.
I can imagine parameters like this:
fire light: circle 5 #yellow circle 5-15 dim #orange
where dim is just lumens -100 or whatever. I'm not sure how bright light would be represented, lumens=+20? Also, having different color lights that don't need to overlap seems key to have. Perhaps a transition option between light colors and lumens to make the change gradual.
Also, the option for the use of html colors instead of rgb values would be an added benefit.
I can imagine parameters like this:
fire light: circle 5 #yellow circle 5-15 dim #orange
where dim is just lumens -100 or whatever. I'm not sure how bright light would be represented, lumens=+20? Also, having different color lights that don't need to overlap seems key to have. Perhaps a transition option between light colors and lumens to make the change gradual.
Also, the option for the use of html colors instead of rgb values would be an added benefit.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: Casting new light on MapTool
That looks pretty sweet! Thanks for all your work.
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: Casting new light on MapTool
Ya, the freeze and all but at least the bulk of the work is done.aliasmask wrote:Cool. Too bad it's not in b91.
I can imagine parameters like this:
fire light: circle 5 #yellow circle 5-15 dim #orange
where dim is just lumens -100 or whatever. I'm not sure how bright light would be represented, lumens=+20? Also, having different color lights that don't need to overlap seems key to have. Perhaps a transition option between light colors and lumens to make the change gradual.
Also, the option for the use of html colors instead of rgb values would be an added benefit.
If we go with this new light, we'll have to reimagine the light source config. Right now lumens is all or nothing but it should drop off like you said. And we could use hex or rgb or color names. Suggestions on how to set up the config? text base or go more dialog like states? I think a dialog with a preview/color picker would be nice....hmmmm
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: Casting new light on MapTool
I think a light creator dialog would be best, but it could just create a text based result.
Downloads:
- Notepad++ MapTool addon
- RPEdit details (v1.3)
- Coding Tips: Modularity and Design
- Videos: Macro Writing Tools
Re: Casting new light on MapTool
I wanted to add some thing like this and started writing my own (I don't know what to call it because its not really either ray casting or shadow casting)
library similar to straight edge a while ago. But now straight edge has a lot more than it used to so it looks like it should work well -- and my code still
has several bugs and less features than straight edge now, so on to the other problems that need to be solved. Namely fog of war and exposed areas.
This method generates lots of little triangles that will be painful for fog of war to continually merge.
So I was thinking it might be better to carry around exposed areas as a bitmap, for maps that are always a specific size this is easy (bit map is same size
as map), it does mean that FOW is not as smooth when you zoom in as it will become pixellated, but I really don't see this as an issue since the background
image is going to be pixellated anyway. For unbound maps its a slightly harder problem as you cant create infinitely sized bitmaps. So I was thinking that it
would be best to create "tiles" of bitmaps on demand, when area is exposed if the bitmap doesn't exist create one, of course you would need to map tiles to
map co-ordinates but thats not too difficult.
Changing FOW to work this way should result in significant speed up, and with straight edge and some optimisation allow for a ridiculous amount of lights.
I see the render loop looking something like the following (some time in the longer term future)
Anyway this is off the top of my head from things I was thinking about long ago, I am sure it can probably be optimised to remove some of the overdraw.
Other randomish thoughts
Since Lights are rendered to a buffer this makes it possible for have lights drawn as a bitmap on your map if you want oddly shaped lights or something.
VBL can be cached for the viewer/light to speed up the get VBL + Preprocess VBL step.
Eventually it would be good to move to simple polygons for VBL (lines would be very thin polygons), that way with a bit of vertex sorting you could to a
simple intersection test to check which "side" of the line you see (inside/outside) and you can then eliminate VBL based on this in the preprocess VBL
step if you like giving you a way to do one way VBL, like wise you could also have VBL tagged with "interacts with XYZ vision/light" and in the preprocess
step remove any VBL that this type of light/vision passes through from the working set.
Also Jamz if you want to try light drop off I would try linear drop off, I know this is not how light works in the real world but it tends to look better in overhead
graphics then distance squared.
Anyways if you want more info or have any questions I have thought about this quite a bit in the past so ask away...
library similar to straight edge a while ago. But now straight edge has a lot more than it used to so it looks like it should work well -- and my code still
has several bugs and less features than straight edge now, so on to the other problems that need to be solved. Namely fog of war and exposed areas.
This method generates lots of little triangles that will be painful for fog of war to continually merge.
So I was thinking it might be better to carry around exposed areas as a bitmap, for maps that are always a specific size this is easy (bit map is same size
as map), it does mean that FOW is not as smooth when you zoom in as it will become pixellated, but I really don't see this as an issue since the background
image is going to be pixellated anyway. For unbound maps its a slightly harder problem as you cant create infinitely sized bitmaps. So I was thinking that it
would be best to create "tiles" of bitmaps on demand, when area is exposed if the bitmap doesn't exist create one, of course you would need to map tiles to
map co-ordinates but thats not too difficult.
Changing FOW to work this way should result in significant speed up, and with straight edge and some optimisation allow for a ridiculous amount of lights.
I see the render loop looking something like the following (some time in the longer term future)
- For each light
- Get VBL in "bounding" area
- Preprocess VBL
- Pass VBL to straight edge
- Get Polygons and Render Light to a a light buffer
- For each Viewer
- Get VBL in "bounding" area
- Preprocess VBL
- Pass VBL to straight edge
- Get Polygons and Render "view" to a a vision buffer for viewer
- Combine vision and light buffer (combine the images so where there is vision you use the value of the light buffer or 0 else where) into "visible buffer".
- Render this to FOW exposed area mask
- Combine "visible" buffer with FOW
- Render Map
- Render combined "visible" and FOW buffer over map
Anyway this is off the top of my head from things I was thinking about long ago, I am sure it can probably be optimised to remove some of the overdraw.
Other randomish thoughts
Since Lights are rendered to a buffer this makes it possible for have lights drawn as a bitmap on your map if you want oddly shaped lights or something.
VBL can be cached for the viewer/light to speed up the get VBL + Preprocess VBL step.
Eventually it would be good to move to simple polygons for VBL (lines would be very thin polygons), that way with a bit of vertex sorting you could to a
simple intersection test to check which "side" of the line you see (inside/outside) and you can then eliminate VBL based on this in the preprocess VBL
step if you like giving you a way to do one way VBL, like wise you could also have VBL tagged with "interacts with XYZ vision/light" and in the preprocess
step remove any VBL that this type of light/vision passes through from the working set.
Also Jamz if you want to try light drop off I would try linear drop off, I know this is not how light works in the real world but it tends to look better in overhead
graphics then distance squared.
Anyways if you want more info or have any questions I have thought about this quite a bit in the past so ask away...
Re: Casting new light on MapTool
That would be great. I always wanted it for statues and similar stuff.JamzTheMan wrote: Oh, and I found a neat little lib for my next POC. It turns images into java "shapes". I'd like to add a special layer (or mark the stamp/token?) where that token would cast a shadow but still be seen (ie the token would be above the FoW layer), so you basically get something like players can see a roof or car but not behind it. Oh, I have plans and Ideas!
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: Casting new light on MapTool
Wow, ya, it is a little daunting when you list it all out...
We may want to store the VBL as Polygons as well vs Area's. It's easy enough to convert them to an area if needed but vice versa not so much. Maybe a KMultiPolygon from StraightEdge? Oh and Lines are already polygon triangles in our VBL, that is how the get stored in Areas at least. You can see this if you zoom in really far or look at the PathIterator.
And what I did for the POC, I gpt the latest VBL on change only, ie zoom change, scroll, etc, and they are stored as occluders by StraightEdge which caches intersecting points IIRC. So on move, the render is pretty faat. In the video, the Last VBL update is the time it took to get the VBL area, comvert to polygons, store the occluders and refresh the vision, generally in the 10ms or less range.
Once the light or vision is calculated, it returns KPolygon so that can be cached. At least for light sources, the only need to be recalculated if they move or VBL is changed.
Currently I couldnt get the KPolygons from straightEdge to properly translate on scale when the zoom scale changed so I had to get the area, scale it, then recreate the occluders/light, so lots of work to properly nail it down, for a POC it's ok.
Re: Soft FoW, i remember that conversation and agree, a bit map may be the way to go. We could probably soft blur the edges if needed? In fact, a overall blur effect could look cool, after all, it's representing a memory of what you once saw.Would be cool to see it blur more the longer it cached. Whether that translates into less resolution/memory savings or not... We should probably code an option to skip soft FoW as well, we dont even use it in out game, and prefer you only see what you currently see, period. Would eliminate the macro options we currently employ.
We may want to store the VBL as Polygons as well vs Area's. It's easy enough to convert them to an area if needed but vice versa not so much. Maybe a KMultiPolygon from StraightEdge? Oh and Lines are already polygon triangles in our VBL, that is how the get stored in Areas at least. You can see this if you zoom in really far or look at the PathIterator.
And what I did for the POC, I gpt the latest VBL on change only, ie zoom change, scroll, etc, and they are stored as occluders by StraightEdge which caches intersecting points IIRC. So on move, the render is pretty faat. In the video, the Last VBL update is the time it took to get the VBL area, comvert to polygons, store the occluders and refresh the vision, generally in the 10ms or less range.
Once the light or vision is calculated, it returns KPolygon so that can be cached. At least for light sources, the only need to be recalculated if they move or VBL is changed.
Currently I couldnt get the KPolygons from straightEdge to properly translate on scale when the zoom scale changed so I had to get the area, scale it, then recreate the occluders/light, so lots of work to properly nail it down, for a POC it's ok.
Re: Soft FoW, i remember that conversation and agree, a bit map may be the way to go. We could probably soft blur the edges if needed? In fact, a overall blur effect could look cool, after all, it's representing a memory of what you once saw.Would be cool to see it blur more the longer it cached. Whether that translates into less resolution/memory savings or not... We should probably code an option to skip soft FoW as well, we dont even use it in out game, and prefer you only see what you currently see, period. Would eliminate the macro options we currently employ.
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: FEATURE: Casting new light on MapTool
took the liberty to edit the subject so it fits with the rest.
GETTING STARTED WITH MAPTOOLS - TUTORIALS, DOCS, VIDEOS, TOOLS, ETC
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
DISCORD (the new MT forum!)
My stuff
Excel Tools: Table and Light editors
MT Tools: Bag of Tricks: Tools for Maptool, Dungeon Builder I, Dungeon Builder II,onMouseOverEvent.
Frameworks: Dark Heresy, Rogue Trader, Deathwatch, Black Crusade, Only War, SET Card Game, RoboRally
Wiki: Debugging Tutorial, Speed Up Your Macros, Working With Two CODE Levels, Shortcut Keys, Avoiding Stack Overflow, READ THIS
Re: FEATURE: Casting new light on MapTool
Hi,
Sorry to revive such an old thread, but I am curious to know if this is still something that is sort of being worked upon? It would add so much atmosphere to my games...
Sorry to revive such an old thread, but I am curious to know if this is still something that is sort of being worked upon? It would add so much atmosphere to my games...
- JamzTheMan
- Great Wyrm
- Posts: 1872
- Joined: Mon May 10, 2010 12:59 pm
- Location: Chicagoland
- Contact:
Re: FEATURE: Casting new light on MapTool
NP. Life happens so things get...delayed?
Anyhoo,ya. I had put this on the back burner for what I'm calling MapTool 2.0 which is a pretty big rewrite converting over from a swing awt application to using JavaFX. I actually just started on it this month and...well, it's going to take months and months unfortunately.
But ya, along with that I'm rewriting the render engine so it'll be more fancy and with more options...
Anyhoo,ya. I had put this on the back burner for what I'm calling MapTool 2.0 which is a pretty big rewrite converting over from a swing awt application to using JavaFX. I actually just started on it this month and...well, it's going to take months and months unfortunately.
But ya, along with that I'm rewriting the render engine so it'll be more fancy and with more options...
-Jamz
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
____________________
Custom MapTool 1.4.x.x Fork: maptool.nerps.net
Custom TokenTool 2.0 Fork: tokentool.nerps.net
More information here: MapTool Nerps! Fork
Re: FEATURE: Casting new light on MapTool
I also hate it when life gets between me and important stuff. And as for "months and months"... At least it you didn't say years and years...
Thanks!
Thanks!
- Full Bleed
- Demigod
- Posts: 4736
- Joined: Sun Feb 25, 2007 11:53 am
- Location: FL
Re: FEATURE: Casting new light on MapTool
Isn't "Months and Months" a coder euphemism for "Years and Years"?
Maptool is the Millennium Falcon of VTT's -- "She may not look like much, but she's got it where it counts."