Seems like the new ViewCaptureToFile dialog box is a “Bit Wonky”.
If I put a name in the Save file as, nothing happens in first option. When I hit browse, the save file box comes up.
Withe the file name and extension. I had already saved some as png, so that was default file type. So the original name I placed in SaveFille as, has no effect (which is OK, if we are not given the option in the first place, and it uses original filename as default).
If a name is added to first save file as dialog, then it shows up here in Settings ??? And Rhino is trying to use these “settings” …
Other than that it works fine, I think, for my needs.
Wait, the old one wasn’t wonky? First, to be clear: you’re using the -ViewCaptureToFile. That first dialog box needs a full path to where you want to save it (e.g.: /Users/rhinorudi/Desktop/foo.png) in order to work. Second, the non-dashed command actually asks you where you want to save the file before showing the command options - leading many to believe (understandably) that you can’t specify resolution, etc. Third, we’re inheriting this wonky behavior from Rhino for Windows, fwiw. Other than that, the command works fine
@dan it seems I may have been doing this is last released build. The script i run is on my work computer. I try to keep my scripts also in a Dropbox folder, but not there now. If I run the command from the menu it runs fine, ‘non-dashed’ command.
I will check my script tomorrow and reply back.
Dan, I have used the non dashed variant and the dashed one, but none seem to offer any way of setting resolution or anything else. The result is invariably a relatively small picture with jagged lines representing surface edges (anti-aliasing?) I can see a greyed-out “options” button, but none of the file types seem to make this operative.
You are correct, I was using an underscore instead of a dash by mistake. But the observation is similar to that which I posted in my “Viewport printing issues”-thread, namely that you are not getting an image of your viewport, but rather a picture with the same camera settings as your viewport, the extend of which is determined by the Width and Height (and scale) settings. However, the comment I had on the surface edges is absent with this command, so we have progress!
Jeff, the picture I showed above as the result of the “wrong” viewport capture is in my view (pun!) correct as it shows the contents of the viewport as I can see them in Rhino, with the same aspect ratio and contents. The following picture is the result of the dashed viewport capture command, with a rather extreme width to height ratio, and shows more content, i.e. the picture is not restricted in width to the boundaries of the viewport window:
It is just an observation, my preference would have been the result of the non-dash version, but with a possibility to set the resolution of the output.
(p.s. I have never understood the fine difference between image and picture, maybe language is a factor here )
that’s just because you’re changing the aspect ratio though… keep it the same and the same view/contents will show at the new size…
• viewport is 1000px * 800px…
• export at 3000px * 2400px (same aspect ratio)
• the view will be what you see in the viewport only larger
just use the scale option instead… in the above example, it would be the same export when simply entering 3 as the scale.
the dialog is far from perfect (there isn’t even an aspect ratio lock for instance) and it’s a bit non-conventional in how you have to do the export but i’m pretty sure the functionality you’re after is already in there.
Jeff, that is exactly what I realized a bit later (when lying awake in bed…), it was just my mindset. But part of that is because I am also looking at printing, see my “Viewport printing issues”-thread. There the aspect ratio is set by the paper size/orientation, i.e. the viewport content is increased in width or height automatically to fill the paper. Thanks for your patience in explaining it.