Part of the workflow which I commonly use is to print a shaded version of the project along with Make2D linework. However, on so many occasions when ‘printing’ a rendered raster, there is a brightness distortion in the middle of the image.
Here is a screen capture from the rendered viewport:
And here is the image after export
Note the dark patch in the middle. There have been many occasions where this occurs with plaster or other materials applied.
Does anyone have a similar problem?
Hi Jeremy - are you exporting via ViewCaptureToFile? Are you saving at a resolution different from the screen? If so, does this problem appear if you save it 1:1?
The image was Printed in Rendered mode at 600DPI to A3 PNG or JPG. The native screen resolution is Quad HD, and if you mean save it at 1:1 in terms of scale, it’s a perspective, so that’s not possible.
Hi Jeremy -
That means that the exported file has 8 times the amount of pixels that you see on screen (8:1).
As a test, what happens when you use
ViewCaptureToFile and use the screen resolution - i.e. 1:1?
Coming back to this topic as the issue is occuring in another project in 7 Beta.
I did 1:1 capture with viewcapture to file and there’s no line.
But when I print this at the required higher resolution (600DPI) jpg/PNG and specified scale, this is what happens.
note the massive line which bisects the image. I’m not sure what to do with this.
Printing a rendered view to scale and DPI is integral to my workflow, and am wondering how to avoid this problem
Hi Jeremy - is this in Arctic mode? (looks like…)
If so, please try ViewCaptureToFile at a similar pixel dimension and see if that looks any better. There was a bug in ViewCaptureToFile in Arctic, fixed recently, and it may be in Print as well.
That looks like Arctic and the tiling problem that was recently fixed when ViewCaptureToFile was used with a custom resolution larger than the viewport.
This has been fixed in V6 and V7.
it’s the same in arctic and rendered mode.
You are right that the test ones above were made in arctic mode, but the original ones for my project (very similar) were made through render.
I just did this one with render, and you can see the same line bisecting
What build of Rhino V6 are you running?
This is Rhino 7 Beta
Then this message thread is in the wrong category.
The fix had been added to V7 but only tested earlier this week,
The fix is not is the public build yet, but it’s in the pipeline.
HI John, sorry for adding this to the wrong category.
However, this was an extension of what was happening six months prior in Rhino 6.
For this reason, I assumed it was a good idea to continue the issue on this thread.
Generally that’s a bad idea for this reason.
If a message has sat idle for a month or more, it’s best to start a new message.
In one month, we will be on a new service release and in this case, a different version of Rhino.
No one with V7 Beta will find this information here because now it’s in the wrong category.
That said, this “hijacking” happens all the time.
Duly noted, I had no intention of ‘hijacking’ the thread, and will post new topics as recommended in your comment.