I ran into the issue where an image captured @ let’s say 1600x1200 px is different than the same one captured @ 2x the size (3200 x 2400). I expected the 2nd one, after scaling 50% would match the 1st one, but no, somehow the lens is different and they are way off…
I don’t understand the logic why Rhino would do that - I thought as long s the aspect ratio is the same, the view crop/lens would be exactly the same. @SamPage - is there some lensing obscure magic I am missing on this one?
I did some more testing and looks like this is buggy - the Rendering keeps the exact same view when rendering the same aspect ratio but different sizes of the current view; as soon as the ViewCaptureToFile size is larger than the screen/view, the lens/image crop is off and differs from the smaller sizes/same aspect ration or the same exact render sizes.
open any file or make a few boxes
Render @ 1600 x 1200, save
Render @ 4800 x 3600, save
ViewCapture @ 1600 x 1200, save
ViewCapture @ 4800 x 3600, save
The last ViewCapture should be different than the 2 renders and smaller ViewCapture (use wider lens camera)
thanks - and to clarify why this is important (apart from pure logic) - for some parts or “elements” of the capture, it is important to do it in 2x size so the lines can stay thinner, or for ZDepth to actually have it AntiAliased (original size is not -AA-ed, but if you do 2 x size and then scale the capture by 50% it works nicely).
But in general, we would like to have the output predictable, just like the Rendering is.
I have noticed fix for this bug has been slated for v7. In our workflows this discrepancy is a big deal…was hoping for a fix within v6 SRs cycle. Any hope for earlier fix? I guess we didn’t whine loud and long enough
Thanks Steve, I may try that but the main issue is this happens inside many of the scripted automated tools that rely on this command producing consistent output based on image proportions. Using this workaround would not help there. It used to work fine before, but I can’t pinpoint at what version this problem started happening…
I’m just trying to find a solution that works for you now. I don’t know when or even if we will be able to fix this ViewCaptureToFile issue during V6 service releases, so it seems worthwhile to explore alternative options. If the print command version works, we may be able to figure out a way to have this be a replacement function for scripted automated tools that you are using.
I just tested this via Print dialog and can confirm than when the output is set to ImageFile, there is no issue that ViewCaptureToFile has (the same proportion views of different sizes cameras match perfectly).
I ran into problems when trying to see if that can be automated - the “command line” version of the print dialog is lacking many functions that dialog has, so I am not able to define the pixel sizes etc. and replace the scripted version of viewcapture with the print dialog…
Another issue I ran into “by the way” while testing (with Print Dialog) is if I set line width to 1 mm and Scale to 10, the output thick lines are weirdly jagged.
I was looking into it to see if that could be an alternative to non-working line scaling in ViewCapture commands, and even the non-working workaround of using the OpenGLWireThickness to simulate it (it works nice for Edges but ignores Curves for screenshots). So - many options to try but neither of them works as a solution to the problem so far.
Unless somehow you can implement the Print viewcapturing method of scaling the view into ViewCapture command and fix the scaling problem ?
This issue is not going to be fixed in V6 as it has the potential to break other parts of ViewCapture. I do think we can solve this by getting a custom script that works for you as an alternative. Does the following python script provide the output that you are looking for?
Thanks for the note and the sample script! It does the job for now (I tested many sizes outputs and they match perfectly). Since the tool that this bug is affecting is written in RhinoScript, I needed to run this Python code from inside RhinoScript, which actually worked quite well and I can even embed the python script as RhinoScript function, no need for a separate .py file.
I need to be able to capture the view as-is, with mixed display modes and various curve/edge/mesh edge widths. Setting up print widths would not cut it. The scenes can have 1000s of objects with mixed display modes. Trying to solve it with print widths is a coding nightmarish solution. Does this python method ignore any display thicknesses by default? Unfortunately if the thicknesses are ignored this workaround is not helping much, sorry.
Hi Steve - thanks! To clarify, the issue now is not even wire thickness scaling as much as recognizing the wire thickness. In case of captures of mixed curve/edge thickness viewports, they all come out as 1 pixel, no matter what the thickness on display is. So for example if I have curves @ 2 pix, edges @ 1 pix and some per-object display modes with curve thickness @ 3 pix, they would all capture @ 1 pix.
Obviously scaling these proportionally would be a plus, if achievable, but I remember a while ago you said it is not easily achievable and was slated for future releases.