The jewelry production business is rather time-consuming and requires designers to make a lot of repeating tasks on a daily basis. Today there is a strong demand to enhance and simplify this process and our team took up a new challenge to create the service which would automate some designer's tasks and would allow users to reduce the number of repeating actions. Our main task was to allow an end user to create different designs using various groups of materials.

Here we are not going to cover all tech details, but we would like to share with you some issues we faced and successfully solved working on this project. So, let's get started.

Here are the main goals of our custom software development project based on the Rhino software, the render farm manager for rendering parametrized designs:

- create a web service with simple GUI which the user could connect to;

- give the ability to specify the file which the user wants to visualize;

- implement a possibility to configure advanced settings like this: specifying materials for layers, choosing a camera view;

- link the web service with the Rhino desktop application for processing the user’s model and rendering images on a server machine.

While discussing the development details we decided not to make a complex service and instead to develop a simple version – an MVP that met all basic requirements. This gave us an opportunity to check our solutions and easily debug them.

A tech stack we used for this project is:

- Python/Django;

- Rhino API;

- HTML and JS;

- Ajax;

- MySQL.

The first version of the application started and sent requests for the server. Receiving the task from the server it started Rhino, with a certain script which executed rendering of pictures. But starting the Rhino program took far too much time. It was necessary to integrate a request on the master and data handling directly into Rhino script. It was rather simple to manage, but in practice, there were some problems.

Rhino rather often failed for various reasons. Some of them we managed to catch (thanks to logging, and some remained). Taking care of Rhino's work was rather problematic, so we decided to write a small program to immediately restart Rhino after it failed or closed, which we called as “Follower”.

Generally, there were cases when Rhino continued to work but at the same time, the script in it stopped. We solved this problem to make communication of the script of the Rhino with the Follower. For this purpose, we have allocated “shared memory”. That allows the script periodically to write down in it, the Follower checks value in memory and zero out it. If after zeroing there was no answer in a row quantity of times, then the Follower stopped the process and restarted it. That way we have managed to stabilize work of the whole system.

Taking into account that our service allows specifying any materials, this raised another issue how we can change the present materials in the file of the model. We have analyzed the structure of the model and have established that objects can physically exist and we can easily receive their characteristics, but there are also other types of objects — by instance, and because of it in the file on layers there was not a mesh, but the instance of mesh which is stored in a layer. Because of it using a material didn't apply the material to an object.

The first decision which we decided to try was to use the material to each object of a layer (that occurs more slowly, but it worked). Also, there was a problem that use of the same material to several objects was impossible and it was necessary to load a great number of identical materials and to apply each material to each object. This process strongly slowed down work of the system and took away a lot of memory of the computer…

We conducted research and found that it is possible to disconnect mesh from their instance which is on Gem layer. Thus we realized untying of instances in our script. This solution has helped us to solve both these problems.

There was also a problem where some materials weren't being rendered to user's satisfaction. It became clear that materials which contained textures were being incorrectly drawn. We have found out that the links to the resources didn't indicate their real location. And the solution was found quickly. We have written a script which automatically processes the file, replacing links in the file with real links to these resources.

As a result, all materials have been listed, the application has downloaded them, then the user takes them from our data, takes a template and it shows how the product will look, the script specifies where to take these materials, indicating references from our sources. We are able to use user-specified materials. As a result, the user has an opportunity to use such functionality.

Here is a demo video of renders we can do using render farm we built. 

We told you about some issues our team faced and successfully solved. If you liked our approach to search solutions and you need for a custom software development please contact us: http://jazzros.com/contacts#we-are-listening