Hi guys I have read sometimes ago that rhino “convert” internnaly to mesh while rendering any polysurface during /after compiling the geoemtry? is this the case? in that case would be faster for rendering to convert a model to mesh, instead of using polysurface ( assuming for example to have a very big model)?
I notice that for example when i use to render with other softwares, the loading process of the geometry, was faster. I wonder if working with polysurfaces some how is less conveniente than working with meshes, for rendering purposes.
Your statement is not precise. Everything needs to be converted to a mesh in order to render it - that is a list of triangles. There is no difference between polysurface and mesh from a rendering point of view - they are both a collection of triangles.
I’m not sure what you mean by “during /after compiling the geoemtry” There is a “geometry compilation” step that happens after the scene is exported for render, but that is an optimization step and has nothing to do with any conversion process.
If you’re experiencing slowdowns, that might be due to the meshing quality. Rhino does not really convert to mesh, during the export process the V-Ray plugin asks Rhino to generate a mesh representation (based on the current meshing settings) of a object (NURBS, polusurf, etc…). This representation might be cached by Rhino for future use. So in theory the first render might be slower than the following
In principle V-Ray can work directly with NURBS objects, but that makes a lot of issues.
Hi Nikolay, thanks for the reply! Yes, right it, my thought was a bit convoluted. I am currently working with a model with a lot of geometry, mainly quad meshes, for very simple shapes (mainly cubes). the problem I am experiencing is that rhino, to load the geometry before the actual render, takes a lot of time to start the render ( around 15 min). I am wondering now since you confirmed me that working with meshes or polysurfaces for the rendering phase, has no difference, if the problem could be that the meshes are mostly all exploded, so each cube for example is exploded in different faces.
there are surely way to semplify the model working with “just what is visible” for the rendering. But I was anyway wondering if there are some workaround to speed up a bit the process of loading the geometry, apart having less geoemtry to load.
I change the thread title, by the way, to make it a bit more clear.
Did you get the same long time per GPU and CPU mode? The general startup time of the GPU was/is slower. But I don’t checked it the last weeks.
General you could join separate meshes with the same material. So, less objects needs to be loaded. Be careful, your model is changed and best you keep the original one. I used this join method for an animation where hundred times the scene needs to be loaded.
An other way could be to work with blocks, if you have the same objects often at your scene.
Working with meshes and polysurfaces is exactly the same for the renderer, but not exactly the same for the exporter. The exporter is what you refer to as “loading the geometry”. It is actually a translation step from rhino native geometry to array of triangles. Here is a key difference. If the rhino mesh is a triangle mesh already then there is nothing to translate and the export is immediate. If it is quad mesh, there is an implicit conversion of each quad to a triangle. This is fast, but still takes time, and is slower. If the object is a surface, first rhino must turn it into quads and triangles depending on the edges, then the exporter turns the remaining quads into triangles, so this is even slower. Contemporary computers are fast. Really fast. 15 minutes export sounds terrible. I’d like to see this model, or a portion of it. It would be great if you can share small (but heavy) part of it without any materials for diagnostics
Interesting, in the past I used _QuadrangulateMesh to get the polygon count of my mesh objects a little bit down, but it looks like that was no good idea. Better seems to be to use _TriangulateMesh.
Hi Nikolay,
thanks for the reply, that actually clarifies a lot. Unfortunately being a model from my office I am not allowed to share it, at this stage.I will try to fix all the problems related to what mentioned, and let´s see. It is actually an exported model of a native revit model. It is very detailed, probably too much for our pourpose (more or less 1.5 gb), and all the blocks have objects which as I mentioned before are for some reasons exploded into separeted quad faces.I could Use Elefront to retain the blocks, for example and then convert it in a single geometry. I am pretty sure that cleaning a bit the model will make it much faster.
