I am now facing a performance problem in my project when there is many objects.
I know there is a performance optimization section in the document, but I’ve tried all of them and nothing works. Some of them even break my scene.
And I also know that for large amount of meshes, I should use instances. However, my situation is a little different. Normally, if you have a large amount of meshes, they are usually the same or at lease pretty similar. In my case, I have to draw the meshes by myself. So, every single meshes is different, they have different width, height and length. Most of them are simple, just a normal cube, few of them are arcs which are made from a extrusion of a curve line.
There’s still a way where you could use instances in this scenario, and that would be by having short “base” meshes and combining their instances. For example, you draw a straight section, a curved section, a diagonal section, then instance and combine them using transformations. If you have played something like Roller Coaster Tycoon before, it’s the same idea as their roller coaster building, where you have base sections that are repeated and combined:
If you can detail exactly what you’re trying to achieve then we can give better advice for the approach.
For example it looks like you’re creating a moving mechanical conveyor system. If the pieces are purely visual then we can consider splines with an extruded face (Drawing Curves). The UVs would be aligned and then it could just be a case of animating the UV coordinate if you need it to animate. Each spline would be a mesh node.
Also remember generally having a large number of nodes will take-up memory and can hinder performance, it’s always best to try reduce nodes and in almost all cases you should be able to.
Scale, rotation, and translation For example, you wouldn’t need to create a different section for each possible angle of the straight section, you can just rotate the base piece. You can see another example here, where I use just one straight piece and rotate them to place them in the horizontal direction:
For arcs indeed you’ll need more base pieces, but there are still places where it can be reused, for example, this section:
it seems the two curves here have the same radius, they’re just mirrored from one another, so you could reuse the same base piece for both.
Is the large number of meshes the conveyor, or the items that travel on the conveyor? For the conveyor, I wonder if you could use Node Geometry (Node Geometry | Babylon.js Documentation) to generate all your meshes and merge them into a single mesh that would only be one draw call. For the boxes, maybe use Solid Particle System (Solid Particle System | Babylon.js Documentation)
I am sorry for the late reply (since I’m using my office laptop, and I should not work when it not working time) and did not gave you more detail about it.
Tough your solution looks amazing; the moving UV may not work since this project is more like a digital twin that emulates the real-world situation. Which means that each moving part on the conveyor should be model as a separate mesh because the width, length, height and gap can be different when loading different modal.
Nevertheless, I appreciate the work you have done. Thank you so much!
I also have the idea that I should merge the static meshes into one giant mesh. However, I found that could be difficult for my use case since even for the static conveyors, they should have the ability to change their color (e.g. green for running, blue for reverse running and red for error).
Yes, both of them are the requirements.
The PG is making, but it might take a lot of time since it is very complex. (Personal speaking, getting the correct coordinates is the most time-consuming part)
I understand you have specific requirements but you must be very detailed on what you’re trying to achieve because the best optimisation is based on the constraints you can impose and also smoke and mirrors that can be created .
Do you need physics for each conveyor piece?
Does each conveyor piece align to an Asset (as it’s a Digital Twin)?
If so, how will the user interact with the model, conveyor and pieces?
Is Picking required for features such as, metadata display? It looks like you just need individual pieces to be coloured based on their health/age.
How many conveyors belts and pieces will there be in total?
Is the conveyor static or dynamic? If static then this opens up many options. I do not mean animation. Dynamic requirement means you want to be able to configure the geometry of the conveyor on the fly or you may have model revision imports etc.
The UV animation option above I could design to work with dynamic conveyors without having many nodes and it work with collisions. Basically I would shoot rays on the mesh which will calculate position on Path3D/able to work out which piece to be coloured etc. Possibly an over-engineered option but certainly the most efficient for rendering, which is where I usually start. Also picking would be more intuitive than many collision nodes.
It would be good to detail your full Digital Twin project requirements because these models are usually huge/unoptimised.
Thank you for your detailed questions!
First, let me introduce the idea of this project.
This project is aiming to provide a holistic view of a very large conveyor system, since it is very large, the original software treated as many different smaller parts. The following is an example of how we sperate the whole system.
Edited(Due to regulation, I have to remove the picture)
You can see that each smaller system is inside a sperate VM, as a human, it is very difficult to get an overview of the entire system in our mind. Thus, we develop a new system to help us solve this problem. The following is the picture of the new system, it combines all the three sub areas above.
Edited(Due to regulation, I have to remove the picture)
Then, I would like to answer your question:
No, the collision has already been calculated by the original software, all the things that BJS needs to do is to display the meshes at the correct coordinate and the correct state (color).
No, there is no need to have Assets, since this project is facing to engineers, they do not care about visual effects. Besides, the whole idea of this project is to display the view of the whole system, we do not want interaction at this point, which means picking is also NOT a requirement.
In theory, there is no limit. However, in practice, the largest modal I faced has more than 6000 conveyors and this can be even more since the system can continuously generating parcels (you can treat it as a box mesh), which do not have constraints on amount anyway.
If you mean geometry, it is static, once a conveyor is created, we do not modify its geometry. But the position and rotation could change.
If all the devices on the belt are identical (the gray + blue things in your screenshot), then thin instances would probably be the fastest solution to render these devices.
For example, you wouldn’t need to create a different section for each possible angle of the straight section, you can just rotate the base piece. You can see another example here, where I use just one straight piece and rotate them to place them in the horizontal direction:
