In order to satisfy his inhabitants’ culinary needs, our whale friend Fin has an internal sushi processing line. This manufacturing line relies heavily on the use of conveyor belts that transport the ingredients from one place to another, where they can be processed.
Our main demands for the conveyor belts were that they should be capable of transporting lots of individual objects without performance issues, and they should be easy to place and modify for our designers.
We designed three different conveyor belt systems until we found a solution that was fitting for our needs.
First Prototype
Our proof of concept just consisted of a series of boxes that offset everything on it in the direction of its forward vector. This was a very barebones approach, but it did the trick for starters. However this iteration had some major drawbacks. For one, because we used boxes for overlaps we were severely limited in the layout of our conveyor belts. Secondly, this system only consisted of the box colliders and did not incorporate a mesh for the belt. Therefore it was really cumbersome for our designers to make the belts look nice.
(In this iteration, the conveyor mesh needed to be added separately)
(Transporting objects worked fine, but the corners looked a bit wonky)
Roller Conveyor
In the second iteration, we attempted to make the movement on the belt physics-based. We decided that each segment should consist of multiple rolls that rotate on their own. The rotation of the individual rolls would move the objects from one roll to the next. This worked fine with short conveyors, but it did not scale well. Once a conveyor system consisted of a couple of hundred individual rolls, the performance cost of the system was too much. Since each roll needed to be updated and rotated each frame, the computational cost of the belt scaled with the amount of rolls on the belt instead of the amount of objects on it, meaning that this system would limit the amount of conveyor belts we could use in any level.
(This version only allowed 90° turns)
(Not pictured: bad performance on longer belt systems)
Spline Conveyor
Even though the physically accurate movement of objects in the second iteration was nice, we decided that it was not worth the performance hit and we didn’t want to inhibit our own creative freedom with limits like “there can only ever be 100 meters of conveyor belt in any level”.
So we went back to the approach in our proof of concept in order to solve its shortcomings - the rigid turns and cumbersome placement - while keeping its performance cost low. Our new and current iteration utilizes Splines and SplineMeshes, where the objects are offset by the conveyor each frame. The Spline defines the layout of the conveyor, each segment of the Spline is represented by a SplineMesh. This means that smooth curves are now easy for us to design with this conveyor belt.
This approach also brought some difficulties with it, like having to identify the curvature of a Spline segment and adjusting the objects’ speeds depending on their position on the conveyor (think inside or outside lane of the curve), but after fixing these issues, we decided to use this conveyor belt system in the final game.
(Designing the conveyor is now fast and easy)
Now that we can easily create conveyor belts with complex layouts, what’s left to do is finalizing their visuals. Once that is accomplished we can go on our merry way, transporting delicious sushi wherever we want.
(Objects can move in smooth curves)
We also condensed all information in a short video:
If you are interested in further insights to our conveyor systems or have any other remarks or ideas for improvement, feel free to ask at any time!
- Andi, Ralf