`formDepthTest` is being ignored by a couple of the bot forms and all of visualization tags.

[Blitzy]

formDepthTest is being ignored by a couple of the bot forms and all of visualization tags.

Ignore bot visualization tags:

• label
• label (floating)
• progressBar
• stroke

Ignored bot forms:

• keyboard
• iframe

I think getting the keyboard and iframe forms to respect the depth buffer tags should be fixed.

The question is should visualization tags respect the depth buffer tags or should they have their own alongside there respective appearance tags? ie labelDepthTest strokeDepthTest, progressBarDepthTest, etc?

test ab: https://ab1.bot/?ab=rc-formDepthTest

[KallynGowdy]

After thinking through this for a bit, I think we should try to come up with a paradigm that doesn't have all of these complications and also has a clear way to understand what is happening.

Some problems that I've been thinking about are:

• Labels are going to have issues because of render-order problems. What should a label that is on the back face of a bot do for example? A naïve implementation would simply set the label to a slightly higher render order than its bot, but then the label would show through its own bot!
• keyboard, mesh, iframe, progressBar, and stroke have the same issues. Because they are composed of multiple materials, disabling depth testing on all of them could lead to some very crazy visual bugs where they no longer self-occlude.
• Pointer events get occluded by all of this anyways, so the feature is only useful for visual elements. The developer does not have a clear way to choose to make such bots clickable based on their visual state.

If anything, I think we should keep it at one tag, since this is a massive amount of scope creep if we're going to try to maintain 4+ tags just to support depth testing (not to mention depth writing or other material tags). But, because of the problems mentioned above, I think we should investigate other mechanisms that can be used to achieve these types of use cases.

One idea is that we can support multiple render passes on the grid portal. Users could set the grid portal to an array of dimensions that they want rendered, and each dimension will be rendered in the order that it appears in the array. Pointer events work in the opposite direction.

[Blitzy]

I like the idea of supporting multiple render passes on the grid portal. This is typically how I would achieve this in a standard context -- having multiple scenes and rendering them each in the order you want them layered.

I do wonder how this might conflict with the already existing multi-dimensional grid portal concept of using portal bots.

We could maybe utilize the formRenderOrder (or other) tag of a portal bot to determine what order it should render its dimension's bots with base dimension of the grid portal.

[KallynGowdy]

portal bots would render in the same pass as the parent dimension, since they only exist because of that dimension.

[Blitzy]

Would we encode multi-dimensional grid portals in the URL parameter?

https://ab1.bot/?gridPortal=dimA&gridPortal=dimB

https://ab1.bot/?gridPortal=dimA,dimB

[KallynGowdy]

Yes. The first example already works actually, it just renders both dimensions in the same pass.

[Blitzy]

The more i think about it the more i like the idea of multi-pass grid portal dimensions.

I just ran into an issue with semi-transparent objects being rendered after the opaque objects i have tagged with formDepthTest: false and formDepthWrite:false because transparent objects are always rendered after opaque objects so they only get sorted with other transparent objects.