Arctic rendering and viewport mode in WIP

There’s a link to it here:

1 Like

Thanks!

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.

1 Like

Holo

Did you change your Arctic mode material to 240 grey?

Andy

At shallow angles it seems like the background gets very dark.

Hi @andy, All,

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.

Thanks for listening.

–jarek

3 Likes

Jarek

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.

  • Andy

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.

Jorgen

It isn’t that big a technical problem - it just needs to be fixed.

  • Andy
1 Like

OK, thanks!

I really like the concept of this feature. It would save lots of time. We generally render white / grey models but having multiple colours while modelling is really helpful.

An alternative model would be the override type system in Microstation. It essentially allows all layers to have 2 display modes. You can switch between mode A and mode B. This allows for much more flexibility because you might want the whole model to be white except for 1 object which you are trying to draw attention to.

Agreed. When ever I do ‘white’ renders I split the model up into 3 different shades to get definition between some surfaces/objects. I also need to add glass in there too.

Yes, I’d not thought of glass.

Maybe there could be a simple column in the layer properties which has a checkbox as to whether to be included in the Arctic Mode or not? That would do it for me because you could then have a glass layer which is unticked (or ticked?!) to not be included. Similarly, a layer with objects for emphasis, say an existing building on a site could also be marked in the same way and render as a colour.

To override a viewport display mode for specific objects I would suggest using the -SetObjectDisplayMode functionality that is already in place instead of introducing yet another column in the layer tab.

1 Like

That’s a pretty cool tool and one I didn’t know about, however it doesn’t really do what I was talking about I don’t think. It would work for the viewport but not for renders am I right?

Ha, yes. Most of this thread is about the display mode but you are absolutely right that it is also about the rendering. And no, that wouldn’t do anything for the rendering. We’ll have to hear what @andy thinks of mixed-mode renderings.

We’ve already made quite a few improvements to the quality since Tuesday, so if you are interested in testing this feature, and you “feel lucky” - download a new mid-stream WIP from here:

http://files.mcneel.com/dujour/exe/20161118/rhino_en-us_6.0.16323.05161.exe

We have no idea what is broken in this - generally mid-week builds have unchecked code in them. However, I’ve tested the rendering stuff and it all seems to be working.

  • Andy

How about I respect transparency?

4 Likes

Hi Andy,

Thanks for the explanation, all that makes sense knowing more about the goal that display/render mode is.
Good to hear that the tiling eventually will go away (along with making the Zbuffer mode more usable).

My only request I would still keep is exposing the control of the AO radius (checkbox for Manual under skylight, Unchecked as-is by default) for users that need more flexibility with the ‘amount’ of the effect you get. Would that be something you can consider?

I also like the idea of respecting transparency in this mode.

Many thanks,

–jarek

I gave it a test on the old laptop with the Geforce 330M card and the mode looks nice, great that you downsample when manipulating the view, but it is very slow on testmaxspeed as it doesn’t downsample.

Testmaxspeed took 137 seconds (esc support would be nice) and the entire system became very slow. It used 32% of the dual core, four threaded i5 and used all threads equally. So I guess it should avoid using thread one if possible.

Great work though, I’ll test it on the 1070 during the weekend if I have time.

Oh, and I had to reset the display mode for colors (light gray) to update and for the “iteration” to take place.