FEATURE: Casting new light on MapTool

Developer discussion regarding MapTool 1.4

Moderators: dorpond, trevor, Azhrei

Forum rules
Posting now open to all registered forum users.
User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

FEATURE: Casting new light on MapTool

Post by JamzTheMan »

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?
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

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: Casting new light on MapTool

Post by aliasmask »

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.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: Casting new light on MapTool

Post by JamzTheMan »

aliasmask wrote:Pretty cool. Lighting has always been kind of meh in MT, especially when you start overlapping different colors...
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:...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.
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. 8)

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

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: Casting new light on MapTool

Post by aliasmask »

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.

User avatar
RPTroll
TheBard
Posts: 3159
Joined: Tue Mar 21, 2006 7:26 pm
Location: Austin, Tx
Contact:

Re: Casting new light on MapTool

Post by RPTroll »

That looks pretty sweet! Thanks for all your work.
ImageImage ImageImageImageImage
Support RPTools by shopping
Image
Image

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: Casting new light on MapTool

Post by JamzTheMan »

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.
Ya, the freeze and all but at least the bulk of the work is done.

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

User avatar
aliasmask
RPTools Team
Posts: 9024
Joined: Tue Nov 10, 2009 6:11 pm
Location: Bay Area

Re: Casting new light on MapTool

Post by aliasmask »

I think a light creator dialog would be best, but it could just create a text based result.

Craig
Great Wyrm
Posts: 2107
Joined: Sun Jun 22, 2008 7:53 pm
Location: Melbourne, Australia

Re: Casting new light on MapTool

Post by Craig »

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)
  • 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
The Render Map step includes objects, tokens etc.

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...

User avatar
Jagged
Great Wyrm
Posts: 1306
Joined: Mon Sep 15, 2008 9:27 am
Location: Bristol, UK

Re: Casting new light on MapTool

Post by Jagged »

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!
That would be great. I always wanted it for statues and similar stuff.

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: Casting new light on MapTool

Post by JamzTheMan »

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.
-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


uthin
Kobold
Posts: 6
Joined: Fri Oct 16, 2015 1:45 pm

Re: FEATURE: Casting new light on MapTool

Post by uthin »

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... :wink:

User avatar
JamzTheMan
Great Wyrm
Posts: 1872
Joined: Mon May 10, 2010 12:59 pm
Location: Chicagoland
Contact:

Re: FEATURE: Casting new light on MapTool

Post by JamzTheMan »

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...
-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

uthin
Kobold
Posts: 6
Joined: Fri Oct 16, 2015 1:45 pm

Re: FEATURE: Casting new light on MapTool

Post by uthin »

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... :D

Thanks!

User avatar
Full Bleed
Demigod
Posts: 4736
Joined: Sun Feb 25, 2007 11:53 am
Location: FL

Re: FEATURE: Casting new light on MapTool

Post by Full Bleed »

uthin wrote:
Sun Oct 21, 2018 4:27 am
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... :D
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."

Post Reply

Return to “MapTool 1.4”