The platform's floating View/Inspect button panel will not work for my non-frag visuals

[JackConradGray]

In some of my app's workflows, I am manipulating abstract 3JS graphics in the 3D view.

Of course, the platform's floating View/Inspect button panel will not work for my non-frag visuals.

I would like to hide the View/Inspect panel while I am working with the non-frag graphics. Is that possible?

One value of being able to use non-frag geometry is to be able to create interactive UIs that let the user work on abstract business objects rather than concrete IFC representations.

If there were a way to create such abstract IFC objects, it is not clear if that would be better or not, but it might be worth considering. haveing lightweight mostly 3JS frag objects would let them participate in the undo redo mechanism, and other frag related mechanisms, no? This request duplicates one made in issue #35.

This would be better than hiding various UI components and/or duplicating them for light weight 3JS elements as long as the lightweight IFC wrappers around the 3JS objects did not slow things down noticeably, and they would participate in the existing frag tool behavior.

[HoyosJuan]

Hey @JackConradGray, thanks for flagging this!

Before jumping into a solution, we'd love to understand your use case a bit better. Worth noting that frag elements are themselves Three.js objects under the hood, so it's not really a "frag vs Three.js" divide, it's more about whether your abstract business objects map naturally to an IFC-like wrapper or not.

Could you share a bit more about what's driving you toward plain Three.js here? Is it about needing a shape or behavior that doesn't fit the IFC data model, avoiding the overhead of the frag machinery for something transient, or something else entirely? Not pushing back on the approach at all, just want to make sure we're not missing a gap we should close, or a lightweight wrapper pattern we could point you to instead.

[JackConradGray]

Thanks for reaching out Juan.My project is not for a specific client—its goal is more to build something I want to automate since it will help me do it more efficiently.  Also it will hopefully attract clients 😎which will fund more interesting explorations. My 3JS UI elements represent abstractions that ultimately will resolve to building elements.My project is a space planning app that needs to quickly manipulate RGBA colored lines, circles, poly lines, and interactive 3D objects with custom controls and custom renderers.  I am getting good UI interaction performance with 3JS, so if I could get similar performance with standard fragment wrapped 3JS that would be a win/win.  I can arrange a demo if that would help.  Jack ***@***.*** Aug 9, 2026, at 11:32 PM, Juan Hoyos ***@***.***> wrote:HoyosJuan left a comment (ThatOpen/platform_services#35) Hey @JackConradGray, thanks for flagging this! Before jumping into a solution, we'd love to understand your use case a bit better. Worth noting that frag elements are themselves Three.js objects under the hood, so it's not really a "frag vs Three.js" divide, it's more about whether your abstract business objects map naturally to an IFC-like wrapper or not. Could you share a bit more about what's driving you toward plain Three.js here? Is it about needing a shape or behavior that doesn't fit the IFC data model, avoiding the overhead of the frag machinery for something transient, or something else entirely? Not pushing back on the approach at all, just want to make sure we're not missing a gap we should close, or a lightweight wrapper pattern we could point you to instead. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>