Best practice for isolating user-coloured objects

Help Developers
21

"Very appreciate your feedback. I’ve made some attempts based on your suggestions, and I’ve encountered a few issues. Before I elaborate on these, let me first describe the effect I am trying to achieve: I have an array [a, b, c, d, e], each element corresponding to a different object. If I want to hide ‘a’, I can do so by calling hideObjects([a.objectid]). Then, for the reverse operation, which is to hide all objects except ‘a’, I use the code hideObjects([b.objectid, c.objectid, d.objectid, e.objectid]), showObject([a.objectid]). This is essentially the exact opposite of just hiding object ‘a’. However, in practice, when my model is too large, I need to pass in a very large number of ‘ids’, which is why I mentioned the issue of handling 16,000 ‘ids’ earlier. I also tried using just one root id, but then I found that I couldn’t display any components, so this method was not feasible for me.

Regarding the performance issue I mentioned earlier, I noticed that the demo you gave me was executed directly using JavaScript, but in my case, I am monitoring an array of ‘hideobjects’ through the ‘watch’ API in ‘FE2’, which is based on ‘Vue3’. I am not clear on the differences between these two methods, but they seem to affect the execution efficiency of ‘hideobjects’.

Moreover, when I set aside the performance issues, the result of my above-mentioned reverse operation also has a problem. Taking [a, b, c, d, e] as an example, in some cases when I call hideObjects([b.objectid, c.objectid, d.objectid, e.objectid]), showObject([a.objectid]), the ‘a’ component should be visible, but it isn’t. This issue occurs in the following model:
model0

I’ve observed that when I execute ‘hideobject’ on this model, using hideObjects('09ed976ef5fd5f33bdd2b64eae3fa3e7') results in a large number of components being hidden, which is not what I intended. The model link is as follows:model1

You can request access from me, and I will respond as soon as possible.

Additionally, I’ve always been wondering why the underlying mechanism of the ‘hideObjects’ function is to replace materials instead of using visible=false in Three.js or setting an invisible ‘layers’. Wouldn’t these alternatives be significantly more efficient in terms of performance than replacing materials?"

22

@alex To make it easier for you to understand the questions I’m asking more clearly, I’ve uploaded a video, here’s the link:hide

23

@zm1072223921

I’ll go over the topics you brought up one by one:

To make it easier for you to understand the questions I’m asking more clearly, I’ve uploaded a video, here’s the link:hide

The issue you’re seeing is caused by the fact that the Revit connector sends both architectural and structural elements. This means that you get both a RevitBeam and a Element1D each with the same mesh as their display value in the viewer. Due to how the viewer treats object duplication at the moment, this leads to incorrect behaviour for filtering. Whether the viewer will treat object duplication differently in the future, is still up for debate.

Regarding the performance issue I mentioned earlier, I noticed that the demo you gave me was executed directly using JavaScript, but in my case, I am monitoring an array of ‘hideobjects’ through the ‘watch’ API in ‘FE2’, which is based on ‘Vue3’. I am not clear on the differences between these two methods, but they seem to affect the execution efficiency of ‘hideobjects’.

The viewer is a JS library. It will always work like that regardless of how anybody uses it. FE2 is just another application using the viewer, it’s not the viewer itself (as I’ve explained several times before). It is possible that some filtering performance overhead is caused by FE2, and not the viewer as we’ve experienced that in the past. Unfortunately I’m not able to give you any guidance regarding Vue or FE2 in general since I’m not involved in it’s development

I’ve observed that when I execute ‘hideobject’ on this model, using hideObjects('09ed976ef5fd5f33bdd2b64eae3fa3e7') results in a large number of components being hidden, which is not what I intended. The model link is as follows:model1

I could not find any object with that id in neither of the streams you posted. Maybe you have a typo?

Additionally, I’ve always been wondering why the underlying mechanism of the ‘hideObjects’ function is to replace materials instead of using visible=false in Three.js or setting an invisible ‘layers’. Wouldn’t these alternatives be significantly more efficient in terms of performance than replacing materials?"

Typically, each three.js displayable object, like say a Mesh, will be drawn explicitly via a draw call to the GPU (unless it’s hardware instanced, but that’s besides the point). Now, if you imagine 160000 objects, as individual three.js objects, this means 16000 draw calls which is unfeasible to put it gently. The viewer batches objects automatically, so you always get a draw call count that can actually work. Additionally, even batched, you still have access and control over each object individually. You can change it’s material to whatever you want and you can transform it however you want.

To make it easier for you to understand the questions I’m asking more clearly, I’ve uploaded a video, here’s the link:hide

There is another important point I need to make here: What I see in your video, where all the beams are disappearing when you call hideObjects leads me to believe that you are using an old version of the viewer. I understand that you’ve forked the repo and your are changing FE2, but you can still choose what viewer version you’re using from FE2’s package.json. Set it to the latest one

After updating to the latest viewer version, and you are still having issues with filtering we can see then. But if you do follow up, I strongly suggest you make a code sandbox where the issue is presented

24

@alex
In response to your suggestion, I’ve created a sandbox to illustrate the issue I’m encountering demo. Additionally, I’ve uploaded an example operation to demonstrate how the problem presents itself video. This demonstration manually segregates the problematic objectids through a process of dichotomy, subsequently revealing the issue when the hideObjects function is invoked.
As previously mentioned, I’ve opted not to use ‘npm packages’, preferring instead the project’s source code prior to compilation. This approach facilitates my learning and the development of further extensions. However, I’ve noticed that while the ‘objectId’ remains constant within scenarios executed by my locally run code—allowing me to create functions based on this consistency and log them in the database—the objectid appears to change when executed in the sandbox using the ‘npm package’. Consequently, the hideObjects function, which I referenced in my last communication (‘09ed976ef5fd5f33bdd2b64eae3fa3e7’), generates an error, thus necessitating this dichotomous approach to isolate the problematic objectid.
Furthermore, I’ve encountered a performance issue as previously described; inputting 16,000 objectids into the hideObjects call results in approximately 30 seconds of lag on my page. This scenario operates on ‘fe2’, and I’ve observed that all encountered issues are resolved upon transitioning the 3D scene dependency to the ‘npm package’ relied upon by the sandbox. This resolution, however, poses a significant frustration for me as it hinders my intention to implement modifications and extensions within the viewer’s source code.
I eagerly await your advice on this matter.

25

Normally, you wouldn’t need the source code of the viewer in order to develop extensions for the viewer. If you want to change how the frontend works, then yes, since that it not a library like the viewer. If you want to work with the source code of the frontend you can still use the viewer npm package instead of the source by changing this line to any version you want. If you want the latest API 2.0, then you’ll need to get the latest from the viewer-next tag, like for example:

"@speckle/viewer": "2.17.0-alpha.12"

Don’t forget to run yarn to actually install the dependency.

If you still want work on the viewer source code you can very much do so, as long as you keep it updated. Here’s a guide on how to keep you fork synced with the upstream.

26

@alex After taking your advice, I utilized version ‘2.17.0-alpha.12’ of the npm package as a dependency and attempted to achieve my goal again. However, I discovered that the outcomes were similar to those obtained by using the source code directly. My goal is to effectively hide specific objects within a 3D model using the ‘hideObjects’ function in the ‘filtering’ module. I tried passing a large array of ‘ids’ to this function, but the objects were not hidden as expectedvideo. Additionally, I’ve observed that the function’s performance significantly degrades with models that have a high complexity or a large number of components.
How should I properly use ‘hideObjects’ to achieve the desired effect? Is there an alternative method I should consider?
I’ve also noticed changes in the 3D rendering section’s underlying logic, affecting the drag-and-drop functionality of objects in the ‘ExtendedSelection’ sandbox example. Upon inspecting ‘batchobject’ in the console, I discovered an ‘InstancedBatchObject’ class with an additional method. Whenever an object is of the ‘InstancedBatchObject’ type, the ‘transformTRS’ method for ‘batchObject’ becomes unavailable, leading the object to disappear instead of transforming. Is there an additional method or adjustment required in ‘ExtendedSelection’ to address this issue?

27

Hey @zm1072223921

Great to see you persevering and sharing your progress with us.

If you continue and look to base your code as much as possible on the various sandbox projects @alex has shared, I think you’ll get there.

We are constantly working to improve performance as much as possible. The render pipeline recently had a 20x speed boost. In due course, we will move our attention to interactivity performance, but it is a truism that bigger models require more process intensity.

1 Like