Hi @pascal ,
Are there any updates that fix this bug?
Our company is currently all on SR12 but updating soon. (waiting on IT roll out)
This issue is when someone saves a named view and then the file is opened on another computer with different screen res or toolbar setup and even with “restore aspect ratio” selected they don’t match up perfectly.
Thank you!
Sebastian Misiurek
Hi Sebastian - not really, I’m afraid - the bug is currently on the pile for V7 as far as I can see.
-Pascal
Hi Sebastian - you didn’t specifically mention layouts and/or floating viewports here so I thought I’d mention that a regular viewport gets restored with the correct aspect ratio when the named view is saved from such viewport.
-wim
Hi @wim + @pascal ,
My issue is slightly different than the one above since I am trying this out in regular Rhino viewports and not floating or layout. I make sure to select “restore aspect ratio” then double-click on the named view and it loads a regular viewport in a slightly different aspect ratio to try and match the original. The really unfortunate part is that it almost works, the images rendered out are only slightly off from each other.
Is there a known consistency for this bug? or is it random? I can’t seem to find a pattern between different saved images aside that they differ slightly. If there is some consistency, then maybe we can compensate for it in photoshop.
We’re a large architecture firm and have lots of teams collaborating on producing renderings and images and it’s a critical part of the workflow that the saved image can be reproduced perfectly so we can keep updating renderings while others are post-processing.
We upgraded our whole office to Rhino 6 10 months ago, telling everyone we have to wait for Rhino 7 for them to be able used named view correctly isn’t a reasonable solution.
Is there any other work around or suggestion? Is there any chance this can be addressed in a SR update in V6?
Thank you,
Sebastian
Hi Sebastian - I understand it’s extra work but you can set the pixel size directly- e.g.
-_ViewportProperties _Size 800 600 EnterEnd
Is your workflow consistent enough that you could just add buttons that set one of some small range of stock sizes?
-Pascal
OP here.
It’s important to be clear what the problem is.
It’s not with the pixel dimensions.
It’s that the station point and target of a restored view doesn’t match exactly that of the saved view. Or maybe it’s the “lens length”. Or maybe both. Either way the upshot is that for many purposes the image needs to be precisely the same as the one saved for repeated iterations of the same view of a model, and the way it works currently this isn’t possible.
Hi Pascal,
Thank you for the quick response!
That works perfectly. I entered in the original widthXheight of the named view and everything matches up.
The process was: save a named view, move viewport size around, and then go back to the named view and enter the original named viewport size, then it matches up. The breakdown occurs when you try to restore a view to it’s aspect ratio vs its pixel size. Keeping the same aspect ratio and scaling it up or down won’t always give you the same pixel size.
I think the easiest solution to this would be to add a “Restore Size” check box under the named view tab.
This isn’t always ideal, but when you want to perfectly match a named view this would be an excellent solution. For us, setting a set of preset viewport sizes that are consistent with output size could be possible but it’s more likely that people already have saved views. So we’ll write a button that pulls the original named view viewport size and sets the current viewport to that size so we get consistency.
Maybe this can be implemented in a future SR or in V7. We can share what we come up with if successful.
Thank you both,
Sebastian
cc: @mswaidan
@sebastian.misiurek, @djhg - my guess is if the view is set to pixels that are in fact the correct aspect ratio, even if not the original size, before restoring the named view, it ought to work. But I’ll test here and we’ll see if we can find a way to tune this up.
There is necessarily rounding that takes place when the multiplication occurs but it should not be off by more than a pixel.
thanks,
-Pascal
I’m not clear how to implement the workaround in my gif example…
Right, it is different when the view is saved from a detail - that seems more clearly buggy to me.
-Pascal
This had never been fixed, had it?