beautiful models 
also nice texture at least the 2nd picture with the white paint, nice simple but well done lighting/reflection setup. the rest of the colors look nice but look a bit like xmas deco. did you upscale with nearest neighbour, or why is there such a strong aliasing?
Thanks, yes I agree, the white one is prettier, the others are “tech-demos” to see how cycles handles metals.
And yes, that is a bug in the “beloved” viewcapturetofile that messes up on the laptop where it uses the 2x scale of the viewport (for speed) also in output. I like the feature, but it shouldn’t use that for export. Thanks for bringing that up!
Edit: Good point about nearest-neighbour by the way, the viewport could probably use a fast realtime opengl based upsampler to smooth out the jaggies.
?
What does that mean? If you specify scale of 2 you get double resolution. What am I missing here?
Or are you referring to the DpiScale setting?
My laptop has a retina display and Rhino 6 has defaulted raytraced to use the viewport in half resolution and then upscale the image with nearest neighbour, and that is fine as speed is more important than resolution on these small screens. BUT viewcapturetoclipboard should not use the upscaled result and should rather use the view as is at half resolution. (At least don’t recalculate with out asking!)
PS! I am not using 2 as scale, but 1.
Here are my similar settings in viewcapturetoclipboard (viewport is here smaller than what I usually use though):
And I set number of passes to 1 regardless of what I use in the viewport so it doesn’t suddenly start to calculate a new image.
(yeah, you know that I think that raytraced and rendering images should be two separate things… so I won’t focus on that here 
)
As you can see Rhino thinks that the viewport is 459x489 px and that this is the correct raytraced result as well.
Right, you probably are starting the ViewCapture command after passes count for the command has already passed. I didn’t take the DpiScale setting into account for determining when to start a modal render. I suppose I should (will log a YT item for that tomorrow). A modal render (when the progress bar pops up) always renders with pixel size of 1, i.e. native requested resolution.
Until that case is fixed you could do a macro where you
-_RotateView _Left
-_RotateView _Right
-_ViewCaptureToWhichever _Enter
That should start a modal render with the correct pixel size. Stop-gap, but should keep you sustained until fix is in.
/Nathan
p.s. untested macro, no idea if I wrote it correctly. Consider it a pseudocode
Note that the DpiScale setting I am talking about is an advanced Cycles setting, unrelated to the Scale in the view capture dialogs. And the macro won’t work when you keep passes set to 1 obviously.
Anyway, keep pleading with @andy, build up the pressure!
Here is an example of the viewcapturetoclipboard with scale sat to 2x:
But this isn’t how I want to use viewcapturetoclipboard! I don’t want to wait for it to calculate! That is what I want a render button with a propper render view for. Because waiting with out being able to evaluate is just a silly step backwards to the 90’s!
Point is that I want the image captured as it is, that is the BEAUTY of viewcapture and why we have loved neon for 5 years… it is a perfect sketch tool that saves tons of time and when/if we want to run a high res render then we set the settings as we want them and use the render button and wait for the statusbar to do it’s thing WHILE we see the result and can ZOOM in on the details. I really hope you see that you are cutting away important tools for efficient designevaluation by forcing users to use viewcapture like this.
Peace and (rough)Love! 
2 Likes
I fully understand the Need For Speed. I was merely making a point for how to render at native resolution (: But noted and will further YT when no longer in bed pretending to sleep ^.^
2 Likes
Hmm, now I am not sure whether I should YT this issue or not (re-render when DpiScale != 1.0, i.e. when on high DPI screens).
Looks much better! can mcneel use yours as default?
@andy would like to get the model from @Holo to lift the color information, so he can update the color picker with the better colors.
2 Likes
Hi Jørgen! Could you render the same scene with Maxwell and Maxwell materials (you have Maxwell, right)?
It would be nice to be able to compare…
Philip
Here are the other materials adjusted as well. The nuances are much more subtle and here shown in aluminum.
Getting the reflection blur amount right is important for the right material feel though.
Again only used a single rectangular light + the default setup.
Here the custom Titanium color is used:
Now it’s of to the family and some weekend adventures!
3 Likes
Hi guys, before you start printing labels on the V6 CD’s you should revisit the Rhino render becuase it doesn’t handle the environments correctly:
I don’t know what’s causing it but Cycles seems to do just fine, so I guess it doesn’t look for textures in the same areas. And it also has some bad gradients going on
Great, look forward to test it!
Oh… and I hope that comment was taken with humor as I see it referenced all over that page 
It is just a joke we have over here that when bad colors are used in consept design we ironically ask in an sincere tone if they (the colors) were picked by an (product)engineer.
Peace and love!
I found another oddity that I recreated on the rim:
To simulate anisotopic noise I added some noise to the bump and used sphere as uv mapping and this odd pattern appeared in “cycles” raytraced. So I did a Rhino render to see if it behaved the same, in case it was the uvmapper, but Rhino render seems to rather ignore the bump.
SingleRim.3dm (3.0 MB)
Oh, and OpenGL handles this correctly:
