[Wish-suggestion] Bake+Reference geometry option.

Replies to This Discussion

Permalink Reply by David Rutten on June 12, 2011 at 2:55pm

Ángel,

 

how about an option to mark certain components as "Volatile" or "Transitional" or something, meaning that they only retain their data while they operate? This would mean no data tooltip information and no previews, but it might reduce memory overhead quite significantly in certain cases.

 

There's quite a lot of typing that has to be done to make this work well (I need to completely rewrite the logic that determines the order in which components are solved), which is why I haven't started on it yet.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Andrew Heumann on June 12, 2011 at 3:49pm

The merits of the volatile data approach for process power aside, I think there's another reason to consider Ángel's suggestion: it would streamline the process of allowing a user to make manual edits in rhino to GH generated geometry, a manual step in the middle of the parametric modeling process.

Permalink Reply by Ángel Linares on June 13, 2011 at 4:52am

Hi David, 

 

That option you speak about is a good improvement to grasshopper performance, but like you said, it needs a lot of new code and work at Mcneel. 

 

Bake+Reference could be fast to implement and a esay way to lighten memory and processor in big definitions while Mcneel works about "Volatile" mode.

 

Andrew is right pointing this posibility of break the parametric process like an opportunity in design. Some times is necesary to "touch" geometry in the middle of the creative process.

 

Thank you for your fast reply.

 

Best Regards.

Permalink Reply by David Rutten on June 13, 2011 at 6:53am

I fail to see how it would lighten memory. Baked geometry will require more memory than geometry in Grasshopper. Even if that geometry does not end up in the Rhino undo/redo buffers.

 

It would indeed be possible to bake geometry with additional data and then reload geometry with that data. This at least gives you the possibility to intervene manually in the process. I'll try and put something in the next release that does this.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Ángel Linares on June 13, 2011 at 7:11am

I think that my very bad english don't let me explain what I want to write here. I'm really sorry for it.

 

If I have geometry generated in a big process and I could bake the result, delete that process, and reference the geometry/data, all the process behind that step could be deleted or disabled. This will be translated into more memory and processor time for the next step in definition...(I supose based in my experience).

 

Example: I create an array of spheres in a surface using a really heavy algorithm,etc. If I could bake the spheres and reference in a new component, all the process behind could be disabled/deleted "without consecuences" (ok, I lose the "parametric chain" but is no problem because that are the right spheres). The new reference spheres are lighter than all the process that generate them.

 

Please let me know if I'm wrong about that. And thank you for consider this wish to next release.

Permalink Reply by David Rutten on June 13, 2011 at 8:56am

Ok, I think I understand. You have one ghx file generate a bunch of -say- surfaces, then you bake those surfaces, close the ghx (thus releasing all the memory it was consuming), open another ghx and import the geometry again.

 

Right?

 

 

How about this? I add an extra object called something like "Geometry Cache". You have to give it a unique name. If you plug geometry data into the left side of this component, it will bake all that geometry and attach UserStrings to all those objects like "<name>: {0;0;3}(8)" where <name> would be your name and the rest is the exact location of that piece of geometry in a DataTree. It should probably also delete any objects already in the 3dm file that have that custom name/data assigned to them.

 

If you don't plug any wires into the left side, it will instead search the 3dm file for all geometry with the appropriate user data, load them into a correct DataTree and supply that data to whoever plugs into the right side.

 

If you plug wires in both ends, it will just function as a generic Geometry Parameter.

 

It might be tricky to write a good event handler for this thing, maybe I'll just restrict myself to an UPDATE NOW! button on the object itself, so you can trigger an update manually.

 

ps. benefit of this approach is that everyone can create and harvest geometry with such user text, whether they use Grasshopper or not.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Ángel Linares on June 13, 2011 at 9:17am

That could be great! Nice approach to have a more generic and powerfull tool :) Updating manually is not a big problem, I think. 

 

And now I must ask you something: closing the ghx file is the only way to free memory and processor? If you disable components inside a opened ghx is not quite similar (not looking at GUI resources consumption)?

 

I don't know if could be usefull mention this (only putting my thinkings out) but, if we mix the concept of "Geometry Cache" and "Volatile" component and some kind of files, all these doesn't bring us to something similar to "Vray Proxies"? That could be a strong tool in future.

 

Best Regards.

Permalink Reply by David Rutten on June 13, 2011 at 10:01am

"closing the ghx file is the only way to free memory"

 

You could also disable components, but that might destroy more data than you care.

 

"and processor?"

 

you can't really save processor cycles. If a ghx file is loaded but not visible, it won't take processor resources. Or rather, so few you could not possibly measure it.

 

I don't know what VRay proxies are.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Ángel Linares on June 13, 2011 at 10:08am

I see. Thanks for the answer.

 

Vray Proxy (First link I've found using Google): http://vray.us/vray_documentation/vray_proxy.shtml

 

Vray Proxy store mesh in a file with read only porpuses. Then load it in render time.

 

Best.

Permalink Reply by dominic on June 14, 2011 at 1:16am

 

Interesting range of options:

 

1. Volatile: some info not available for tool tips and previews. Would be interesting if the amount or type or info could be defined by the user.

 

2. Geometry Cache: with a DataTree to index things. I guess, DataTree could also provide addresses to other user defined data.

 

3. Proxies: the baked geometry is actually stored externally, and instanced/referenced into the file on demand. Vray proxies are really a LOD tool that allows the renderer to work with light weight 'proxies', and only load the 'full' data when rendering. For GH, I guess that there should be some thought about what or how the proxies are generated? Vray, I think, can use point clouds, polygons and other light weight geometry. A quick fix for GH, might be a truncated version of the script?

 

4. Disabled: Suppressed. Could be part of the above range. When a user disables a cluster, say, maybe there should be an option to replace it with a Proxy or Geometry Cache, with its tagged info? Would make Disabled option richer.

 

Permalink Reply by David Rutten on June 14, 2011 at 3:50am

So a Vray proxy stores data in a file instead of in memory, and the big benefit here (I assume) is that it either reads the bits on the disk instead of bits in the RAM (which would make it much slower), or it only briefly loads an entire mesh object when it has to, then frees the memory again. Thus when you have 1000 proxy mesh objects it only ever requires the memory to load one of them at a time. This would also severely impact performance, though less so than interacting with the data directly on the disk.

 

Or is the VRay proxy system meant to give you meshes with triangle counts that 3DMax cannot handle?

 

If it loads all proxies during render time, then the benefits in terms of memory consumption only manifest themselves when you're not rendering. And it doesn't really matter how much memory you use, just as long as you don't go over the 2GB (or 3GB) limit on 32-bit systems.

 

So reducing memory consumption is only a worthwhile investment if you're liable to exceed the preset limit otherwise.

 

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Ángel Linares on June 14, 2011 at 4:49am

I think that it is a mix between the concepts that David has putted on the table. When you create a proxy I think that Vray pre-process the information of the mesh, materials, etc., then save it to a file. This file contents a really light preview mesh, and all the data necesary to load in render process without needs more "pre-process".

 

Another point: I have read that if you are going to create a big forest with the same tree, is better that you create only one proxy and instance it over the scene.

 

I don't konw where is the trick about proxy but it works quite well and I thought that could be a good idea to have in mind. First time I only talked about bake+reference, if you (David) think that this is a empty dialogue, don't worry to say.

 

I don't know if GH development could be beneficiate with this ideas but the way someone has solved his proplems of memory and processor could be a nice inspiration.

 

Copy/Paste:

(-http://www.spot3d.com/vray/help/150SP1/vrayproxy_params.htm-)

 

"The .vrmesh file format:

Meshes are exported to a special .vrmesh file format. It contains all geometric information for a mesh - vertices and face topology as well as texture channels, face material IDs, smoothing groups, normals - in short, everything that is needed to render the mesh. In addition, the mesh is preprocessed and subdivided into chunks for easier access. The file also contains a simplified version of the mesh used for preview purposes in the viewports.

It is important to realize that the mesh is in a "ready to render" format. No further modifications to the mesh are expected. You can't apply modifiers to the mesh, or animate it in any way except if you animate the position/orientation of the proxy object. If you need to make changes to the mesh, you can import it back as an Editable mesh (see the Import section below) and re-export it back to a .vrmesh file."

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page