![]() So now, we have to remember to save the textures with the file, and on top of that, every time you transfer the file somewhere else and open it, it re-creates the “embedded files” folder there. That was not the case with V5, and is still not the case with V6, as saving of textures with the file is also not enabled by default. That is why I have argued in the past that the default would be that they are always saved with the file. Picture (frames) are often used as visual reference objects for construction and thus it is very important to keep them in the file (automatically) as long as they are needed. IMO, picture (frame) objects are not the same as textures applied for rendering - while technically they might be alike, they are generally used for different purposes. Well, for me this is a case of “If it ain’t broke, let’s fix it anyway”… I have hundreds of “old” Rhinno files, so moving to R6 has me feeling dis-empowered and vulnerable…Īnd if Rhino is set to save textures with the file, these will be saved - they are never embedded into the bitmap table as they are (optionally) in V5. ![]() What happened? This is just one of several puzzling surprises about R6 that I fear are only the tip of the iceberg. So I’ve spent time testing ‘PictureFrame’ and ‘Picture’ embedding and somehow I ended up with a folder called ‘/test_v6_embedded_files’ associated with a new file I created in R6 (test_v6.3dm)!? I can’t repeat the sequence of events that created it… Other experiments seem to embed the image within the. (my colleague never mentioned that he couldn’t see that hidden image/layer either) Much to my surprise, one of the more trivial issues I’ve discovered is that a ‘PictureFrame’ image (R5) wasn’t visible on my new laptop (R6) because the image was never embedded in the Rhino file and folder paths are different. I’ve been evaluating R6 for the last few days and find myself getting bogged down with worries about making any changes to my R5 files that will make them unreadable by a colleague who still uses R5. ![]() You can be sure to make many people happy with them. I really beg for the options that Helvetosaur and others asked for. It’s a pity and a fact as well, but external references of any kind are the most common reason for madness and confusion in our world. Neither comes it in handy, when you have set up a directory on a server, to which you upload your finished drawings, nor when you have to mail these data into other countries. And people on the other side don’t like externally referenced image-files. To be able to embed images is very important in these mannequins or the like or in the case, that you would like to get assembly instructions or this kind of more graphically oriented documentation out. This is very handy, when it comes to drawing i.e. quick export of DWG-files from rhino with embedded jpg-images. Through the last three years I worked out a workflow, that allows for the rel. Bolivia or you name it, don’t usually work with brand-new versions And even worse is the fact, that you have toĪlways stay compatible with very ancient versions of DWG, since internationally you have to assume, thatĬompanies you would work together with in i.e. Sadly I have to say the DWG-format it not going to fade in the near future.Īlmost every big company uses DWG as reference-files. Many folks out there have to derive and deliver DWG-files from their Rhino-Work-Files. ![]() It would be very crucial, that on DWG-export all images are properly (for the DWG-format) embedded into the drawing. Going into Doc Properties > Rendering and checking “Save support files in 3dm file” is not that obvious (to me at least) also the trick of re-doing the picture frame operation (with embed=yes), saving the file, then undoing the import is also not that obvious… How about EmbedPictureFrameImage…? It’s really easy to overlook this option due to the order of things - first, you choose the bitmap in the file dialog, then immediately you get the screen pick prompts to set the image - it’s easy to miss the command line options, and once you have terminated the setting the image, well, all the options are gone… You have no idea if the image is embedded or not.Īs a corollary - I would like a somewhat more obvious way of post-saving a non-embedded bitmap in a file. If the user is really worried about file size then they can go in and set it to No. There is no reason in this day and age not to store the image in the file. PLEASE make PictureFrame > EmbedBitmap=Yes the default ! I know it is supposed to be sticky once it’s set, but on every new install it is set to No. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |