Hover effects for bitECS code path

[stalgiag]

There are currently no hover effects on objects added to a newLoader scene. I was recently working on pin interactions and missed having these visual indications of hover state.

I am going to begin the process of migrating these effects. After looking into it a little, it seems that this process will be useful as an intro to a few new systems that I haven't worked with before (most notably asynchronous work with generators to handle shader compiling). This issue is primarily intended to serve as an opening for suggestions if anyone has already done thinking towards this and as documentation of this work to avoid collisions.

[takahirox]

Hi @stalgiag, thanks for being interested in working on the hover effects with bitECS.

Please talk to the team before actually starting to work on it because we discussed that the current hover effects implementation approach (with A-Frame) may be a bit too complex.

Currently it overrides shader code on the fly but it may make resource management difficult. We might want simpler and more managable approach. It may be ok even if the new hover effects looks different than before.

[stalgiag]

Makes sense. Will do.

[stalgiag]

Some thoughts on this issue.

The current implementation potentially forces an expensive recompilation step (browser WebGL implementation dependent). A similar-enough effect could be achieved with other approaches. A few I have considered:

• Hover effect entity: Create a simple “hover overlay” mesh that can use GPU instancing (if multiple needed) or move to hover location. The material on this object would need a custom shader that creates a blended hover effect. This approach might end up just shifting the burden by tracking/updating transforms, handling any depth sorting updates, etc.
• Post-processing: I haven’t investigated our current use of Post Processing (and it seems like it's behind a flag) but if we were already re-rendering the scene for post-processing and the requirements of that secondary render were flexible, one could theoretically render a solid color for hover effects on this single pass. This approach only makes sense if we are already doing a post-processing pass (seems like no in most cases) and the pass is flexible to modification.
• Material Instance reuse: Currently a new material instance is created for every hover object. We can likely see substantial gains by creating a templateHoverMaterial and .cloneing this whenever we need a new material instance. The current implementation clones the standard material and then modifies the shader. Forcing a recompile (browser dependent).

My opinion is that the third option is the best. It could be effective if combined with some simplification to the hover shader chunks; a slightly less robust visual effect could drastically reduce expensive branching.

This list is not exhaustive and I welcome other ideas! I am also happy to pass this issue along to someone else or kick down the road if another suitable task takes precedence.

[keianhzo]

My preferred method would be to add some post processing effect to add a rim to the object but that might have some performance cost in some platforms (think VR) and would force us to enable the post-processing stack for all platforms so I'm not sure if that would be ideal. Otherwise I'd try to have something similar to what we have now. the Material instance reuse path sounds good to me. Honestly I never liked the current hover shader so if we can come up with something simple and elegant to get rid of that I'd be quite happy. Maybe design has something to say about that.