It's also worth pointing out that the oddly-shaped completely transparent chunk in the first screenshot is intentional in the map, not a rendering bug; I put it there for testing adjacent portals with different overlay properties.

1) What's their ExtraData implementation?
2) It has been mentioned in IRC that transparent holes won't be masked as such (yet)
3) Do they work both for basic and linked portals?
4) Any chance that when transparent holes are possible, there'll be linked portals that let traces (e.g. hitscans) and projectiles pass through and other objects not?
5) Can you trigger-model the overlays so as to create breakable glass?

kristus said:
What about textures with "holes" in them? Like the Mid* textures.

Not yet. We have to establish some way of specifying masking on linear textures first. ZDoom steals a palette index to do this. I don't know what we should do, frankly.

printz said:1) What's their ExtraData implementation?
2) It has been mentioned in IRC that transparent holes won't be masked as such (yet)
3) Do they work both for basic and linked portals?
4) Any chance that when transparent holes are possible, there'll be linked portals that let traces (e.g. hitscans) and projectiles pass through and other objects not?
5) Can you trigger-model the overlays so as to create breakable glass?

Overlays can be placed on any portal surface AFAIK, though they only really make sense on linked and anchored portals. The flag properties that control portal behavior are runtime modifiable, so it may end up being possible to toggle them via switches once Aeon is available.

Xtroose said:This is great news. I have a couple of questions.
Is it possible to use this effect with custom TRANMAPs?

No. I imagine a rendering path to do this could be potentially implemented, but I don't think it's in the plans. Some possibilities for handling masked textures (like MIDSPACE) on portal surfaces are being considered, though.