WISH: Command to package all linked files

[ryan.odom (Ryan M. Odom)]

Hi everyone,

It would be extremely helpful to have the ability to gather all linked files (materials, picture frames, blocks, GH, etc.) into one place so they can be neatly zipped and transferred to others. Currently, Rhino sometimes spits out the Embedded Files Folder with some embedded files but not all. I still don’t understand why Rhino does what it does when it makes this folder.

I often work on 3DM files that live on a shared server and are worked on my multiple people. We have a folder structure that words great, however, things inevitably get messy when myself or others put linked files in the wrong place.

I’ve posted about issues that I’ve had with Embedded File Folders in this thread. I think what I’m bringing up here deserves it’s own separate conversation.

What are your thoughts on this as a potential feature? Are there any hidden secrets that I’m not aware of?

[ivelin.peychev]

I made similar suggestion a while ago, but I guess it went unnoticed or intentionally ignored.

Suggestion: should be able to embed custom display mode settings in any given file

@pascal, How about a new type of rhino file. For example .3dmx like .docx, .xlsx, etc. being in fact a zip with manifest file and some xml configuration file also containing folder with graphics, file to store current viewport and a folder for the actual 3dm in there. A kind of a RhinoProject file. not just Rhino 3d model file. Just an idea.

Wish: Datadams to not pass on any data upon startup

I wish we get some OTTB GH components to organize Worksessions. That would be acceptable for the time being. Another option is to save .gh files along with .3dm files in a new project zipped xml extension say .3dmx Btw then you can reduce size of the 3dm and store all graphical properties and materials rendering scenes etc. separately. Just like .Epub .Xlsx .docx .pptx .3dxml Devs, don’t forget to mention me when you implement that

[ryan.odom (Ryan M. Odom)]

@ivelin.peychev

I made similar suggestion a while ago, but I guess it went unnoticed or intentionally ignored.

I wouldn’t assume this is being ignored. Hopefully, someone from McNeel is formulating a well thought out response.

[ivelin.peychev]

Well, I can’t find the actual post but I made one more suggestion somewhere and I was told that they will not change 3dm file for any reason whatsoever.

[ivelin.peychev]

There it is:

New python tools logical application architecture diagram

How about Worksession project. If you want to transfer the project you’ll have to add all files with their relative folder paths. Archiving / Extracting making sure everything is there with correct names of folders etc. If it was a single file (XML-based zipped) it’s manifest or some settings.xml could take care of all these links. The folder structure with all sub-worksession files with all graphics settings all usertext-attributes could be shared throughout the whole project this way. Yes, …

and the answer below

[ryan.odom (Ryan M. Odom)]

I can sympathize with the opinion that a second file format would be a whole can-o-worms. With that said, I think the issue that we’re bringing up, and surely recognized by others, can be resolved in a number of ways. Not everyone uses Rhino in a way that would benefit from this. A feature that would make our lives easier should also avoid making others lives more complicated. This is why I think the best solution would be a PackageProject command that would gather all linked files and other attributes if and when ya need it as not to intrude on others’ workflows.

[ivelin.peychev]

@ryan.odom

A feature that would make our lives easier should also avoid making others lives more complicated.

I can’t speak with certainty but the current 3dm file also contains other files, however not zipped but encrypted in some way, base64 or whatever. Hence, the ability to “Save small” simply cleaning the file from some of the data leaving only the geometry piece of the file. There are notes in the document. Dictionary objects to provide additional attributes for each file and each object, they may as well be serialized data objects embedded in there. This was similar before with DOC files. Now, DOCX files are zipped files containing the DOC file as separate files containing the data, text, styles, themes, images. Same could be implemented for 3dm but in such a way that it will not affect the end users, besides improving their (our) experience.

Of course there are other directions they could go like database-based application instead of file-based application but…

[ryan.odom (Ryan M. Odom)]

@pascal, @wim, @brian:

I’m curious what your thoughts are on this topic. Do you feel the Rhino community would benefit from such a feature? Are we asking the right questions?

[osuire]

Man ! Even the fellows that ask stuff politely get ignored nowadays !