Really all you need is the ability to put a plane on another plane. Then you could render all the pass-through cutouts but then also render opaque stuff as black blobs overlayed in layering order. Then just add the final result to the lighting plane.

Gonna refer something that was said to Lummox in Discord:

TerXIII06/22/2018
Odd question for you.
Is there a way to treat an object in vis_contents identically to an underlay?
I've got an animation I'm trying to move over to vis_contents ATM.

Essentially, that hammer animation is being handled by manually adding and removing an overlay and an underlay object.
Updating it frame by frame.
But I'm running into a number of issues.
1) vis_contents don't act like overlays and /images, in that they don't sync icon_states or directions with their parents (which is nice)
2) All the mob's overlays and underlays are rendered with FLOAT_LAYER to keep them from popping out of proper perspective. It's the only way I can get this playing nice is using an object in underlays with all the frames behind the player in one icon, and alll the frames in front of the player on the other icon, which is an object added to overlays.

TerXIII06/22/2018
I could probably fix the FLOAT_LAYER problem using KEEP_TOGETHER on the player ot make sure that the player is always rendered with all overlays on a single layer, and I could actually use vis_contents, animate(), and a single icon to flip the frames.
Except that changing the direction of the object mid-frame will cancel the animate() call.
And also that every time the player changes directions, the vis_contents component would have to be synced to the player's direction.
Which is a non-issue, as I've already got the tool use action tied to the player's Move()/Relocate() calls, so in theory any time dir changes, I can hook it, provided I always change dir by using a naive Relocate proc.
You've talked in the past for some kind of flagging system for appearances that affect how they are rendered when used as overlays or attached to a root object.
I believe Tom also mentioned it long, long ago.
I believe a number of these problems could be addressed via a set of flags:

apperance/var/vis_flags = 0

VIS_LAYER_SELF 0
VIS_LAYER_OVER 1
VIS_LAYER_UNDER 2
VIS_LAYER_SEPARATE 3

VIS_RESET_DIR 8
VIS_RESET_ICON 16
VIS_RESET_ICON_STATE 32
VIS_RESET_MOUSE_OPACITY 64


Bits 0 & 1 are layering rules.

VIS_LAYER_SELF means that the object uses its own layer to render according to the default rules for the container.
VIS_LAYER_OVER means that the object is treated as an overlay regardless of layer, plane, or rules for the container.
VIS_LAYER_UNDER means that the object is treated as an underlay regardless of the layer, plane, or rules for the container.
VIS_LAYER_SEPARATE means that while the object is ostensibly attached to the root object, it layers as though it is not part of the root container at all.

VIS_RESET_DIR means that the overlay, vis_obj, or image uses its own direction to determine direction.
VIS_RESET_ICON means that overlay never attempts to use the parent's icon to determine its own, even if null.
VIS_RESET_ICON_STATE means that the overlay never attempts to use the parent's icon_state to determine its own, even if null.
VIS_RESET_MOUSE_OPACITY means that overlay has its own unique influence on mouse_opacity.
(edited)
Of course, this would break any current use of vis_contents, and /image, as the behavior is inconsistent across the board.
So it's not an ideal solution...
I dunno.
Maybe a better solution is for bit 0 to mean ALL_DEFAULT, which doesn't really make sense at all, because it cancels out every other bit in the flag sequence.
But it would allow the inconsistent behavior to persist without breaking.
Actually, flag 0 should be VIS_OVERRIDE, which must be on for any flags to change, which would allow any value where bit 0 is off to mean do the default thing.
Which is kinda clunky, but better than the alternative of break fucking everything.

Lummox JR06/22/2018
A big question for me is whether the parent and child should both support flags or if only one side should; because it makes sense that the way visual contents are treated should depend on the purposes of the container, but I also see a point in exceptions. Also, I wonder if some kind of option for a layer or plane delta would be appropriate.
One thing I'd like to get into 513 is some concept of plane organization, so that planes can be grouped in a more logical way. It might make a lot of sense in certain games for multiple planes to be summarily affected by the same transform, filter, etc. which would be like plane masters having children.
TerXIII06/22/2018
Those are all solid questions.
In the weird wild world of BYOND's server-side rendering cues, this stuff gets complicated fast.



Sorry about the formatting, but the gist of the above is that I feel like generalizing the behavior in overlays/underlays where overlays and underlays can take icon, icon_state, etc. cues from their parent, could actually address this issue. One of the major problems with doing this manually is all the work that you've got to do in terms of updating and animating stuff. If there were a way to specify that a graphic should update like an overlay when in vis_contents, a good chunk of this issue could be easily solved without a lot of work for the developer.