Hello everyone,
I am now back to the drawing board.
Following @MattE suggestion, I made a serie of test with PictureFrame on Rhino5 for mac and Rhino6 for windows.
Result is, any PictureFrame which has been mirrored, scaled, rotated or copied will not appear when the file is exported to a .dwg format (the plane will not be exported at all). Using a line + “trim” is not a problem. Is this a known issue?
@pascal, I am sending the 3dm file I used on Rhino5 mac. dwg export scheme is 2004 Solids. On Windows Rhino6 it is 2007 Solids. Let me know if you need anything else.
Thanks!
PFrame V2.zip (390.9 KB)
yes that is a know issue, at least to me i am sure there are some babbles about it but they are quite a while back, yes trimming/rebuilding a picture frame makes a nurbs surface out of if and thus will not render in exports anymore.
@encephalon, thank you for your answer.
In other words, does it means that it is the way it is so the best thing to do is to adapt to the issue? There is no plan to fix this in the future?
hi, it seems i mixed things up a bit, testing on my mac version trimming still keeps the picture frame and can be imported as dwg, also copying mirroring and scaling works as long as it keeps the status “plane”. moving one corner or rebuilding the picture frame converts it into a nurbs surface, it then will not export anymore. workaround may be to mesh it and export it as dae file or fbx, probably also obj, but i cant test if that works on autocad since i dont have that installed currently. i am not sure if nurbs can be exported with textures at all, i think thats just a general limitation.
Hi All,
Old post, but here in 2022 nothing much has changed, it still does it. Tried everything, and it is definitely NOT an export setting issue, also not an picture material or texture settings.
I’m using rhino 7 latest update.
My only work around is to actually insert picture frame, scale it once on import, never scale it again , as soon as you scale or deform in any way it disappears. however the trim , does work. that you can do.
SO: in short. If you insert a photo(picture frame). Move it about scale it to get it right… draw a line around it , delete it. import again and drag it to your frame. then trim , then export happily to DWG. any distortion you have to do in the photo edit itself. not through rhino.
THIS only of course applies to needing it to export to dwg.
Thanks, might be useful to some. I spend hours trying to figure this out…
Hi all,
from today I’m experiencing the same behaviour on export to dwg.
I have to say that it worked for years like a charm and hence I guess it might have something to do with the very last update for Rhino V7 a few days ago ?
Amazingly the PDF-export works like expected. No problems there.
I also get this warning-dialogue, that tells me, that some object had been skipped on export.
When looking into the details with F2, it’s only the picture frames.
Does anyone have new insights ?
Thanks in advance.
Hi Claude - I see it is not working in 7 (Exporting scaled in 2d pictures to dwg) and appears to be working in V8/WIP. Judging from the bug report, it was a bug before the previous 7 release but I will check - if it is a regression in 7, then we’ll want to look at making the fix there as well.
This bug appears to be in earlier V7s as well.
-Pascal
Hi Pascal,
thanks for looking into it. Quite some of my customers insist on having their drawings in PDF and DWG and
probably won’t stop until I’m going leave this world one day.
Now - PDF always worked like it should, but DWG-Export (we all like it - don’t we) always needs special care.
often times the leaders won’t export correctly, sometimes it is the angular dimensions, sometimes
dimensions shift quite reasonably, though the font seems ok. It’s a ‘hassle’ the ELON would say 
And two of these customers also want imagery (greyscale) included into the drawings with an overlay of the outline vectors.
So the way I did this with Rhino-5, when we started in 2014 was to save the shaded models in a 2K-resolution,
then cropped them in a vector graphic package and dragg&dropped the resulting orthogonal view-imagery back
into Rhino’s modelling workspace step by step in order to make them match the projected vector-outlines of
the views. I used ‘O-Snap’/project(ed), to make sure the necessary scaling would not lead to a warping of the
images ‘surfaces’. I then dragged all the surfaces downward in ‘-Z’ about 5 mm, since they would otherwise occlude the outline vectors.
That usually works for the DWG-export THE FIRST TIME one exports.
But once you have zoomed in/out or had some other action going on, the next export would have the images/surfaces
somehow be ‘pushed’ over the vector outlines, though on close inspection the imagery were still sited 5 mm below the rest (vectors) of the drawing.
To overcome this, I would have to again (for another then correct export with the imagery below the vectors) drag all the imagery
further down, or as I found out later, ‘up’ for 1mm (it seems it is only important to a) move them up or down but b) keep them
under in the negative ‘Z’).
What do I want to say ;)?
As a member of the group of users, that try to use Rhino for ‘product documentation’
and ‘assembly instructions’ I would like to kindly ask you to also test the said behaviour of pictures/images against vectors,
where the imagery has the tendency to jump on top of the vector elements even if you had placed them way beneath those elements.
BTW - the ‘drawing order’-command does’nt seem to help here.
As I said, I work out all my drawings in Rhinos Model space by simply placing a number of drawing frames with
all needed text elements in the xy-plane and then starting to position my projection results into them and detailing them.
It turned out to be more pragmatic (for my kind of work) than using the layout-space and working with details etc…
In a last step I then use the Layout-space to set up pages for a PDF and/or DWG export, but the only
element in the Layout-space will be the rectangular frame of the detail 
I’m sorry for the amount of text you have to digest (if you will ;), but this issue of ‘jumping’ imagery on DWG-Export
is a favorite of mine, as it cost me (but not only me) too many hours and annoys me since too many years.
I would of course wish, that someone other then AutoDESK could come up with a more modern format
for a successor, that would finally make DXF/DWG obsolete.
Best, Claude
1 Like
Hi Claude- draw order commands (BringToFront etc) should help this case - have you tried that?
-Pascal
Hi Pascal,
Claude wrote: “BTW - the ‘drawing order’-command does’nt seem to help here.” <
Nope … it does’nt help.
I gave the WIP/V8 a try though and indeed it exported, but all ‘leader’-elements would hover far above the actual drawing plane, when I re-imported the file into Rhino V7 or V8, though in V7 from where I exported everything looked clean at the time of export.
I also found, that the PDF and the DWG too were very large files.
I then used purge to clear the files and exported again. Voila, the files shrunk from 28 MB to 9.5 MB for the DWG and form 7.5 to 2.9 MB for the PDF.
This was not the case some Month ago. It has been ‘introduced’ recently only.
When I exported the DWG from V8, it too displayed the warning, like V7.
There was however a difference in the listing.
In 7 it says 0 of 11 were exported, in V8 it says 1 of 12 was exported.
When opened in the DWGsee-viewer it nevertheless shows all pictures and when I open the DWG-file with Rhino 8 or Rhino 7 they do all display too.
WEIRD …
If you wish, I can upload the file for your inspection.
Yeah, I need to see what you are dealing with - please send to tech@mcneel.com or upload via
Rhino - Upload to Support - to my attention and please include a link back here, as well as precise as possible steps to reproduce the problem you see.
thanks,
-Pascal
@Claude - That is almost exactly the same workflow as I developed, for clients asking for very similar outputs.
The draw order commands are unreliable (in V5, anyway). I’ve commented as much in the past. Even if you get a collection of items set up to display correctly using draw order without resorting to messing around with Z heights, if you then group them and copy that group, the clone won’t neccesarily retain the draw order. That’s especially true if solid fill hatches are involved. The only way to fix it is to ungroup, clear draw order and start again.
Claude’s comments about leaders in V8 are also concerning. I’ve got stacks of files that were created in V5 and I can’t risk bringing them into V7/V8, saving, then finding that I can’t output what the client wants without loads of rework. V5 is in no way perfect, but it’s the Devil I Know and I also know the workarounds to fix these problems. Leaders, text, dimensions are always the things that seem to screw up when exporting to DXF / DWG, if something is going to go wrong. The line work very rarely gives problems.
Obviously I need to understand what you all are doing better than I do - Claude has uploaded a file, I’ll try to make sense of it all. That said I would not expect draw order commands to be useful other than in Rhino - that is, they would not affect any export to other formats that I know of - I am not sure if that is part of what you all are asking for.
-Pascal
Hi Pascal,
over the years I have noticed, that quite a number of users (mostly freelancers) are using Rhino to create technical documentations via PDF-output.
If one eventually has elaborated a workflow, Rhino IS DEFINITELY
THE ‘Swiss-knife’ everyone dreamed of.
After all, technical documentations are still a major use case.
You have to have ‘the papers’ ready at every harbour or frontier. And let’s not forget
the ‘assembly instructions’. A whole industry is taking care of it of course, but frankly,
which freelancer would invest into a multi-thousand dollar/Euro highly complex software-solution like the one e.g. Lattice3d.com is offering. That’s for the big players only.
There is however great demand for this kind of work, that small to middle sized companies would deligate to us freelancers, where Rhino’s abilities and flexibility are almost the best one could get.
So everything, that could help in this respect is sought for e.g. on Food4Rhino and the likes and every advertising of new capabilities of Rhino to acchieve these graphically oriented outputs would result in a whole lot of new positive ‘votes’ for it.
Rhino’s general abilities together with Grasshoppers are the one side which all of us realy appreciate to have access to, but there is still this other kind of work. Less inspiring, hard concentration work like technical drawings, documentations, assembly instructions, patent-documents …
VR and Hololense will take their time. We are talking at least a decade where
technical documentation of any kind will be around in the common form of paperwork - PDF, XML and the likes are digital, so they will even persist on every form of display.
I guess optimizing this field in Rhino (even in the form of a plugin) would be very much appreciated and could easily help to further solidify Rhino’s place and reputation in the world of CAD.
You would probably be surprised, how many people would immediately support
a further development in that field.
E.g. ‘Snapshots’ and what will hopefully become out of it is a fine example of an initative in the right direction, when it comes to presentation and documentation.
A further pragmatic integration into Rhino could (dreaming :)) lead to a new level of
awareness for Rhino’s capabilities.
NPR-rendering styles are another very much appreciated feature.
If Rhino would have a SVG-based vector-shading style, that would be another
very usefull one too, in order to substitue pixel-based imagery completely.
It could be ‘toonlike’. When ‘Penguin’ was released, I was mesmerized.
Sadly it did not evolve as I would have wished for.
Freelancers love Rhino for it’s price-performance ratio. Rhino is the ONLY serious package in the market with this ratio. Advertising people would coin: ‘Democratizing CAD’ … and it’s true.
Freelancers are a mighty group and some of them might have been better off writing CAD novels - don’t you agree?
If I can help with the ‘interpretation’ of the file I uploaded, please don’t hesitate to ask.
It’s about the production and sale of mannequins. Mannequins are notoriously difficult when it comes
to technical drawings
(I vow to get back to less long texts soon.)
Hi Claude - thanks, I have your file - I think there are two things here - correct me if I am wrong
-
Picture objects, if scaled non-uniformly (e.g. Scale2d) do not export to dwg.
-
DWG export somehow gets draw order wrong.
Is that correct? Is there more to it? How would I test point 2?
Draw order commands in Rhino will have no effect as far as I know on anything in dwg export. What could, possibly, is the order of objects in the data-base. This might explain why setting draw order seems to help for one export - the object affected by a command in Rhino moves up to the top of the object table and may then be exported in that order.
-Pascal
Hi Pascal,
1.) I imported the images with ‘the add picture plane’-command in the first place and did only scale them uniformly in the xy-plane.
When I found out, that it would not export the images when exporting DWG, I started fiddling around.
I went into the properties and tried to switch of the ‘alpha’ and ‘self iluminted’ property. (What’s that even good for … could the apha-channel have something to do with it? )
No effect. I then checked if the layer had been accidentally shut off - it had’nt.
I then tried to find out, where the images actually resided in order to make sure there was a proper path. With no result. I then deleted the images and tried to import them directly with copy and paste. No effect either. My next attempt was to again import the images via ‘add picture plane’ and
to make sure, that I would have the O-snap-‘project’ enabled before I started scaling (which I usually have). That made a difference. So it might indeed have to do with a scaling, that includes the ‘Z’-direction, even if it was so miniscule, that it was not obvious. (PDF seems to handle this completely differently, as it seems to be tolerant against this.)
- Set up drawing or use mine. Erase all images and import them again. Either with ‘add picture plane’ or in other ways like via clipboard, then (if you use my drawing or subdrawing) scale the images to fit the respective outlines (of the respective Mannequin-views)
When exporting DWG with images and vectors sited in the same plane it sometimes works but mostly does’nt. So to make sure there’s a defined distance move the imagery down on another level below the vector plane. E.g. 5mm or even more.
Then after a ‘zoom-all’ and in plain top view export to DWG via ‘save as’-DWG.
As said, it may or may not work for the first attempt.
Try it and when you find out that the vectors will get occluded by the imagery (although that should
not be possible, because it had been aranged below the vectors), go back into perspective view and
push the imagery a little further down. Say 7mm. Then export again. It will mostly work.
If however you will come back and amend something, even if it is only an updated dimension or text-element and you will try again, the imagery will most allways be back on top of the vectors.
I think the misplaced leaders, rotated and mirrored angle dimensions and Font-issues are IMHO a different story. As far as I could learn from rumors in many blogs and groups this may have to to with ancient code in the DXF & DWG-format itself and can’t be refurbished, because of AutoDESKs policies (?)
But that is ‘hear-say’ Amber’s lawyer says.
Sorry about this amount of text again. In ‘short terms’ ← I have no skills … so to speak
(Was out of office for a few days, hence only today found the time to answer)
Hi Claude - thanks - we meed to be even more specific:
Using what command? (e.g.Scale2d or gumball scaling in the plane will be non-uniform scaling, even if the effect is not different from Scale)
What does ‘works’ mean vs doesn’t work? Assuming the export of all the objects happens at all (?) how are you determining what works and does not work? How can I test this?
-Pascal
Hi Pascal,
I’m sorry for my somewhat diffuse informations.
Before I started investigating the issue, I usually used ‘scale3d’ with the ‘‘Osnap’-project’ active,
to make sure the scaling would only affect the xy-plane.
Since I allready anticipated and also read in the rhino forum, that one should better only use ‘scale2d’, when working with images/bitmaps,
I in the meantime only used ‘scale2d’. (so reason 1. for images to not export was a wrong scaling method)
As a result, the images would ‘more often’ get exported correctly . So I viewed the path’s of the images under the material properties and sometimes
they displayed a …/temp/… - subdirectory, which of course made me reason.
So when I searched the forum again about ‘dwg-export’ and images I found a user (did not take the name down) who claimed,
that the images would only appear correctly on export, when all used images could be found in the same directory, in which the DWG-file resided.
I checked that and that helped a lot. I found however, that it was also sufficient, if the images where copied into a subdirectory
of the dir, where the DWG-file resided. (so reason 2. was the fact, that the images had reside in the same or a subdir of the DWG-file)
So I am able now to place (jpg < is the format I used) images in my rhino-drawing and scale2d them to the demanded size,
to meet the vector outlines of the Mannequins views (Top, Front, Right …etc.).
On export I get no issue report. Everything exports just fine.
BUT - the drawing order is usually only correct at the first time of export.
If one is forced to go back and do amendments of whatever kind, the images will (sometimes all of them, at other times only some of them)
pop over the vector-outlines and everything else like dimensions etc…
The effect looks, like the image/images have been forced to a topmost plane above everything else.
I could not as yet find out, what the reason for this could be.
As a matter of fact, I can avoid the effect, when I select all surfaces, hence images,
before export and move them downwards a little bit (e.g. 5mm).
When I then export right after that action, the chance to get a correct result is very high.
One would still have to control it, as it still produces errors in some cases.
I know this sounds a bit like Mambo-Jambo, but that’s what I can see and state.
Someone in the forum even had an explanation for the effects. May be it was you?
It was about the way, DWG-export would collect and stack the data.
Sadly can’t find it at the moment.
At least, I am now prepared for the ‘wrong’ scaling and the storage
of the images in the same directory as the DWG file.
Only the ‘drawing order’ issue and the odd behavior of ‘dimension leaders’,
angled dimensions and rotated or mirrored texts remains.
Hope that helps and again big THX for looking into this.
A solution for this issue would help me and many others to get more sleep
and save a lot of nerves
Hi Claude - but where is this effect seen? Presumably in some other application, not Rhino, correct? - which one?
Try:
test 1: Before you export, cut and paste the picture.
test 2: before you export, cut and paste the curves.
Is there any difference?
-Pascal