Sorry to give examples of other programs but I think keyshot handles clay renders really well. As you can see by the short screencast, the background really needs a small gradient in order for it to work well, unless the model has an outline.
A very light grey would be better than white. most things I render are 240 240 240 for RGB white and you can barely tell the difference but it stops things being lost on screen.
This is keyshot 5 so no ambient occlusion in the video I posted.
Thatâs fine (giving examples from Keyshot) - changing the environment is another way of solving the contrast problem. Iâm not sure itâs as good as changing the material color though.
I have now changed the defaults for Arctic mode - but they wonât actually change in the WIP until next week. So in the meantime, please - before you comment any more on this thread, change the Arctic mode settings under Tools/Options/View/Display Modes/Arctic as shown below:
Well - this one doesnât have anything to do with Arctic mode, right? The shadows that weâre talking about are sun shadows. When I switch this model to Arctic, it looks OK to me - would you say the same?
As for fixing AA where there is a ârealâ shadow (as in a primitive light source shadow map) - is this a regression?
I think the lighting is too flat, so I prefer that it uses the default environment for lighting:
(Left is arctic, right is render mode with white object)
And I wonder if something between those two modes would be even better.
The material is white plastic with RGB: 250,250,250 (very light gray)
No reflection no gloss.
Always good to see some improvements in Rhino display. Great that the âambient occlusion /skylightâ is getting some attention and the quality of display improved. My worry though is that it may end up being another âteaseâ feature that shows some potential but is not very useful in production.
So far I can see this mode as a quick way to generate ambient occlusion pass, to be combined with the actual screenshot of different mode as an visual enhancement. Maybe I am wrong, but wasnât that already possible to get such effect by tweaking i.e. copy of rendered mode that uses Skylight and custom material/background? What is new here apart from slightly improved quality and âout of the boxâ access for less experienced users ?
More importantly, the way currently AO/Skylight is implemented is a step back as it produces âtilingâ effect on higher resolution screencaptures (see attached âbâ) - something that old Skylight did not have a problem with.
We see similar problem with ShowZBuffer command (tiling).
Which brings me to another thing I would find very important and useful - being able to have control over the quality and radius of the AO effect. Currently the same exact scene and geometry shades differently depending of how much âzoomedâ we are in the viewport. Is it possible to have it camera-distance independent, rather world units radius based? That way would make it more predictable and probably got rid of the tiling effect that makes is not very useful right now.
Hope we can make it more than an âeye-candyâ! If this gets implemented right along with making zbuffer/fog effect useful ( Better use of viewport ZBuffer functionality please ) discussed with @jeff a while ago, It would really bring Rhino to another level of viewport display and quality production output from the viewports.
Firstly, the idea is not to provide a way of doing post-processing with ambient occlusion. The idea is to provide a new mode that actually provides value to users out of the box - and weâve had requests for this kind of mode for years. Something that gets rid of all of the materials, background clutter and just focuses on the form of the model. A kind of âsimplifiedâ mode - or âsketchâ mode.
We may or may not be achieving that - but thatâs the idea.
Secondly, the world-space vrs camera dependent thing has nothing to do with the tiling. That has to do with the z-buffer being different for each tile. We expect to be able to fix that - itâs just a bug that needs attention. The new AO shader uses the z-buffer where the old one didnât.
Thirdly - about radius controls for the ambient occlusion. I donât want to do that. I want to have a solution which looks good no matter what. Interestingly enough, there is - for any given model or view - a âcorrectâ solution for the ambient occlusion. You can actually use Raytraced mode to see what this correct solution is - but getting to this solution takes more time than we have when weâre drawing the viewport in a working mode. Raytraced and Arctic (or Rendered mode with skylight on) provide two different methods of drawing fast enough. One progressively refines, one takes shortcuts, makes assumptions and leaves out information to get there at 50fps.
If we made it work in world-space only, it would mean that every single model would have to be adjusted by the user to make it look good. And that, in the real world, where 90% of users would never find the controls, would simply mean that Arctic mode would look rubbish 99% of the time. Thatâs not something I consider to be a good solution.
I imagine it would be possible to do a âpixle shiftâ instead of âtilingâ to get high resolution.
Some physical cameras achieve high res images from lower res sensors by moving the sensor a little bit and then weave that data together. https://www.dpreview.com/reviews/k1-pixel-shift-resolution-updated-field-test
It would probably require quite a bit of work though, and maybe a good old software interpolation is good enough as the AO is a bit blurry already.
