FP Improved Plastics and Drop Targets For Future Pinball

[SpacePirateScott]

Here is a sneak peak of the new plastics and drop targets that I'm adding to the Roller Disco table. The screen shots and video are from the proof of concept that I worked on this weekend.

I haven't been happy with how the plastics generally look in FP, so I have been poking around with a couple techniques. I am also unhappy with how the drop targets look when lit in low light conditions.

Here is what the plastics and drop targets look like with on a dimly lit table with shadow maps enabled.



The biggest problem with the shadow maps is that they are not dynamic. When you drop a target light is still blocked even though the target wouldn't be blocking the light in real life.



I know that am showing off the worst case here. Normally a table creator would make sure that there is a hardware light illuminating the plastic and drop targets or using the advanced technique of brightening the texture, but what I wanted to accomplish something like this photo of the real table. In the photos of this table it is only lit with the lights on the table and glow from the translight. (note the lightbulb is actually a pink LED, so the colors are a little weird.



If we examine the photo there are a couple things that tell your brain that this is a clear piece of plastic with a graphic on the back and lit from below. First the graphic is brighter than it would be if it was just lit with the normal lighting. We already have a pretty good way of doing this, although I haven't seen it many tables yet.

Secondly, we can see the playfield in the space between the graphic and the edge of the plastic. And finally, the biggest thing is the light that is reflecting from INSIDE the plastic onto the far edges of the plastic. So if we are able to replicate this then we should be able to make more realistic plastics.

Also note how the plastic drop targets are translucent and are transmitting some the light from the bulb.

I am pretty happy with what I came up with: The plastics look nice, the drop targets are nicely back lit and the shadow maps are updated as the targets are dropped and reset.




It also looks pretty good in bright light as well, but this demo is just hacked together so I can't toggle the light on an off in real time yet. I will post a video of that when I get it working.

And here is video of the work in progress in action:

So, hopefully, you are thinking, "That's looks not too bad, but how hard is this to set up?"

Well the good news is that you don't need to use blender. (That's always good news)

For the plastics:
- This is all done in the FP editor. It was taking me about three times longer to create one of these plastics than a normal one. You can use generic textures for the reflections and edges, or tweak them in photoshop for a slightly better look. If you want a "lit from below" look, then there will be a couple lines of code to adjust the brightness.

For the back lit drop targets:
- This is just a texture swap and a couple lines of code to brighten the textures. I did make custom textures for this table, but I have made a set of generic ones that will work pretty well. If you want to toggle the light behind the drop targets and have the drop targets look correct, then you will also need to some code to swap the textures.

For the dynamic shadow maps:
- Unfortunately you will need a bunch of patience and some basic photoshopping skills: Open two files, copy the first into a new layer in the second file, and adjust the layer blending modes. The rest is done in the editor and game engine. If you have already created shadow maps and have the above photoshop skills or equivalent then you can do the asset create side.

There is also coding involved. The WIP needs about 30 lines of code, but more will be needed to handle the turning on and off of the light. I am thinking of creating a class to simplify it, so I don't think you will need a lot of programming skills. Just copy/paste from the example and change the names of the textures and models to match your table.

If there is any interest, I will post a full tutorial after I finish the table.

That's it for this week.
Cheers!

 

[TerryRed]

Very nice!

Yes, even though I now can render tables in Blender and do some pre-baking... for some things it's simpler and easier to do it in a paint / image editor. So for my plastics, I still do the "illuminated" portion in GIMP to line up with the bulbs underneath, and use FP-BAM to create a shadows layers from the items on top of the plastics and composite those, etc. It can be done in Blender, but sometimes its a matter of control and the look you want.

Same for targets / drop targets. Yes they could be back-lit in Blender (which is how VP BTK tables do it), but sometimes some good manual compositing can get the exact look you want.

For shadows and drop targets.... yah the trick there is you want different shadows for every combination of drop target that is dropped as the shadows change based on that. The shadows can be done manually like you did and then controlled, etc.



I have a couple of other methods I have used on other tables.


Shadowmaps method: (alternate method tricky)

- you can have multiple bulbs (in the same spot) with no visible model
- one bulb for each target dropped combination
- have each drop target combination manually popped up on table startup (or use a surface / wall the same size for each target)
- then have BAM create separate shadow maps for each bulb / combo. Then save those generated files (from the BAM\cache file) and set them aside for later
- when you have your entire table done, then you can let BAM create a new cache file for shadowmaps (in BAM \ cache)
- add your previously made drop target / bulb shadow images to the cache zip
- close FP and reload the table

As long as there are no differences from the cache file to whatever you have in the table script for shadowmaps... then you can have BAM save all shadowmaps to a single TGA file (uses the same name as the table file and is located where the table file is). Import that shadowmaps TGA to Texture Manager. (can be named what you want as long as it ends with "-shadows". I name it "Shadowmaps-shadows"). This will have BAM use this single TGA file (which has all the same images from the previous cache file) for all shadowmaps (matched up with your settings in table script) instead of generating shadowmaps on table startup (which makes the cache file).

Then of course have code to change what drop taget bulb is turned on / off based on what targets are dropped, etc.

It's a bit tricky to understand but once you get it, it allows for shadowmaps to be used for drop target combos, which gives the benefits of shadowmaps / ray cast shadows, and also changing the colour of the bulb which changes the shadowmap's light map as well.... and FP-BAM automatically controls it like any other light.

This is the method I have to use for Silent Hill to allow multiple playfields to swap in and out while still have proper shadowmaps and ray cast ball shadows and light maps.


Overlay method

- have BAM create shadowmaps similar to above but instead save each light and drop target combo to a separate Transparent TGA image. Then you can edit these images how you please and use them in an Image List on an overlay, and simple swap the images for each bulb / drop target combo as needed. This however won't give you a shadowmap or ray cast shadow or a light map.

This is the method I used for Star Wars DSA GE for the lightsabers, shadowmaps, etc.


Yah, drop targets are tricky for this stuff.

 

[SpacePirateScott]

For shadows and drop targets.... yah the trick there is you want different shadows for every combination of drop target that is dropped as the shadows change based on that. The shadows can be done manually like you did and then controlled, etc.

You would need 32 shadow maps for all the permeations for 5 drop targets, but there is a trick so you only need one shadow map for each target, plus one for all targets up. So 6 shadow maps for a 5 target bank.

You render 1 shadow map for the all up, and then for each target you render 1 map with only that target down. You can "subtract" all up shadow map from the individual target like this:




Then to get the correct effect you just turn on the shadowmap for any targets that are dropped.

It works perfectly you but you still have the issue with having to provide premade shadow maps and the annoyance of managing the logic. I am looking at trying to automate some of the process and will post a tutorial and an example table.

 

[SpacePirateScott]

I'm going to try to use this technique for making disco ball lighting effect for the SuperNova version of the Roller Disco table

We will see how feasible this is.

 

[madmrmax]

If there is any interest, I will post a full tutorial after I finish the table.

Umm yes please!

Wow very cool to see your technique here for the plastics. Trying to get the right colorization of plastic lighting really makes the table shine!
-mark

 

[GeorgeH]

Shadowmaps method: (alternate method tricky)

- you can have multiple bulbs (in the same spot) with no visible model
- one bulb for each target dropped combination
- have each drop target combination manually popped up on table startup (or use a surface / wall the same size for each target)
- then have BAM create separate shadow maps for each bulb / combo. Then save those generated files (from the BAM\cache file) and set them aside for later
- when you have your entire table done, then you can let BAM create a new cache file for shadowmaps (in BAM \ cache)
- add your previously made drop target / bulb shadow images to the cache zip
- close FP and reload the table

It seems like you could leave all the bulbs you added in place on the final table. Set it up in the script so the correct light is turned on when a target is hit and turn the other lights off. Then let BAM generate the normal shadow maps. The only problem I can think of is you might see a short flash when one light turns on and and other light turns off in the same location. It might not be noticeable if one bulb is set so it is always on be quite bright with no shadow maps. The brightness of the lights that turn on and off can be quite dim and still trigger the shadow map. The brightness of the bulb has no effect on how bright a shadow map is. The shadow map just knows when the light is on or off.

Just an idea. I don't know whether it would work or not.

 

[SpacePirateScott]

The only problem I can think of is you might see a short flash when one light turns on and and other light turns off in the same location.

With the way that BAM currently works, you do need a bulb for each shadowmap and you turn them on and off to toggle the shadowmaps. If the shadowmaps overlap, then you do see the brightness change, but if you use the "subtracted" shadowmap as I showed above, it works seamlessly as you can see in the video.

The brightness of the bulb has no effect on how bright a shadow map is. The shadow map just knows when the light is on or off.

You can adjust the "brightness" of the shadowmap, by adjusting the bulb color with the bulbExt.SetLetColor function. If you have a white bulb RGB(255,255,255). it will make a fully lit shadowmap. If you change the bulb to grey RGB(128,128,128), it will also half the brightness of the shadowmap.

If you look at the 20 second mark of the ColorSequencer demo video, you can see this in action. The color sequencer is changing the color of light to adjust the brightness.

 

[TerryRed]

Shadowmaps, raycast shadows, and their lightmap (the coloured area of a shadowmap) are directly affected by the brightness setting of their light source.

If you change the brightness of your light using the BAM Ext.brightness command it will affect all of the above. No matter the colour of the light.

 

[SpacePirateScott]

Yep, the lighting formula is complicated. You have RGB color of playfield texture is modified by all the hardware lighting. then each shadowmap's map is added to brightness based on how bright each pixel in the shadowmap is except that is modified by the distance from that shadowmaps bulb's ext.brightness color but reduced by the RBG value of bulb's color. The final value is then multiplied by texture's xbam.brightness.

If this is confusing, welcome to the joy of 3d graphics :)

The simple way to look at it is this. The hardware lights brighten things up as you would expect. Closer things are brighter and surfaces that are facing the light are brighter. Increasing the brightness of light brightens this effect. Changing the light's color is like putting a colored gel in front of the light. Assigned the bulb a darker color, is like adding a darker filter to the light. If you set the bulb color to RGB(0,0,0) its like putting a solid black shade over the light,

The bulbs controlling the shadow maps do the same thing, except the bulbs only effect playfield and not any of the other game field objects.

Brightening the texture increases the effect of all above.

By mixing and matching these settings you can get some pretty cool looking lighting effects.

 

[GeorgeH]

Shadowmaps, raycast shadows, and their lightmap (the coloured area of a shadowmap) are directly affected by the brightness setting of their light source.

If you change the brightness of your light using the BAM Ext.brightness command it will affect all of the above. No matter the colour of the light.

Ok, I sometimes make the mistake of equating glow radius with brightness. The .brightness code in the script does affect the shadow maps. You can, however, set the glow radius to 0 in the script and the shadow maps are basically unaffected. It is possible to set the glow radius so high that it washes out the shadow maps but that isn't what I was talking about. That is my experience anyway. I normally leave all the other parameters for the bulbs under the plastics set to the default but have a setting on the lighting tweaker where you can adjust the glow radius for them.