Curve piping rhino what is the logic behind light geometry?


#1

Hi,

I would like to ask what is the logic behind some of render commands related to geometyr such as curve piping?

These tools are created for rendering purposes.

Are they activated when rendering is running?
How is the goemetry stored as Instance objects or something else that it does not eat the memory?


(David Rutten) #2

Yes, rendering and visualisation in general.

They should be visible in any (most?) viewport modes that would support them. Shaded, Rendered, anything that can handle meshes.

Either the meshes are calculated during viewport redraws (not an option for most of those since it would slow down the refresh rate significantly) or they are calculated once and cached as meshes. They are not stored as separate objects with layers and names and stuff, just as pure geometry.

The purpose of these tools is not so much conservation of memory, as it is conservation of intent. The underlying geometry does not need to be changed in order to make it ‘look’ like you want it to look. Curves and surfaces can retain their core shape, while appearing to be more complicated.


#3

Is there a specific type in rhinocommon for this? I am searching for method/types that are very light in terms of display . For instance if instead of curve piping I would like to have hundreds of sardines?


(David Rutten) #4

You can draw your own geometry using a DisplayPipeline, this is what Grasshopper does and you can make that as sleek as you like. You don’t even need blocks, if you’re good at three-card-monty type programming you can shuffle display transforms and draw the same shape over and over again in different places.

Things like CurvePiping are done using Custom Render Meshes and they are available in RhinoCommon. Have a look at the CustomRenderMeshProvider2 (CustomRenderMeshProviderClassic has been obsoleted by this new and improved type).


(David Rutten) #5

Incidentally CustomRenderMeshes come in two flavours; there’s meshes associated with specific objects, and meshes associated with the document. This is an important distinction to understand when deriving from CustomRenderMeshProvider2 or you’ll be adding the same mesh fifty thousand times to the same viewport before you know it.


#6

Is this something something I can start looking into:

When using curve piping geometry is not baked? It is just display thing?

If yes then at what part it is connected to render. (not display but Rhino render, vray etc)


(David Rutten) #7

Yes. Just display.

Those render engines know where to look to get all the relevant meshes. The Rhino SDK acts as an intermediary between plug-ins providing custom meshes and render engines that wish to consume them.


#8

But I see that rhino render and v-ray render the same curve piping geometry.

So the last question I have how the geometry is stored or passed to those engines from curve piping?
(What time the geometry is baked rather when displayed? when render command is pressed?)


(David Rutten) #9

The implementation details really do not matter. The rendering plug-in asks Rhino; “can you give me all the meshes+materials I need to render the current scene” and then Rhino just supplies a collection of meshes+materials. Some of those meshes come from objects inside the RhinoDoc, other meshes come from plugins that are providing custom meshes. The renderer cannot tell the difference.

The meshes are never ‘baked’ into the RhinoDoc, because that’s not where the render plug-in looks for them.


(Nathan 'jesterKing' Letwory) #10

http://developer.rhino3d.com/api/RhinoCommonWin/html/M_Rhino_DocObjects_RhinoObject_CreateMeshes.htm

http://developer.rhino3d.com/api/RhinoCommonWin/html/M_Rhino_DocObjects_RhinoObject_GetMeshes.htm

These two functions should help you access the render meshes.