Rendering Workflow / Quality

Principally the former (viewport response to changes), though the latter is certainly relevant too.

A designer is constantly rotating, looking, evaluating; and while sometimes such is best done in one mode or the other, the bar has been raised in terms of doing so photorealistically, in a manner and speed that is fluent and non-disruptive.

Ok, good. We’ve tried improving response during the last few BETA releases. I guess we’ll see where things stand when I get Raytraced to work on the Mac (:

Anyway, in this particular case it is not so much about what the others do - I have a fairly good idea of that. It is more about finding the right solutions of getting that performance to react to changes as instantly as possible with as good quality as we can get - besting the technological obstacles. The hurdles we’ve created for ourselves make it a challenge, that’s the PITA bit I meant. And that will stay on as eternal todo to improve.

And believe me, having to use this daily, especially in Debug builds, the incentive to get it render faster than the speed of thought is there.

1 Like

Hi All,

If there is a 3dm file and we’re looking at what material and lighting changes could be made to increase realism, please post the 3dm file as well as some example images, either photos or renderings, of other objects that show the type of realism you’re after and I can try to help.

1 Like

I think it’s depressing to see the lack of common sense, observation skills and visual ability to even understand that the results critiqued here are just pathetic.

Guys, this as a default result is NOT OK. BY ANY MEASURE:

image

This thread continues to show a talent problem, a skillset problem and a cultural problem. Not a software and settings problem.

You also need to STOP asking users to do your work. This is exhausting guys. Hire extremely good visual artists (they are a lot more affordable that developers and 100x easier to find) and make them part of your team. Make them the “golden eyes” decision-makers of what meets threshold to ship a product. What anyone else in the McNeel team thinks it’s good enough does not matter, you all have proven you are completely unqualified to make any decisions on rendering quality.

You guys are the inmates running the asylum. This non-sense needs to stop. And this playing dumb and confused, and setting low expectations as a reason of why the work is sub-par is not cool guys.

…in the meantime (because I don’t see a solution in sight for this decade) I’ll focus on reporting and documenting how you guys can make our work easier with 3rd party renderers. Right now that workflow is extremely broken too, especially with Octane. But I’ll make a new thread for that in the next few days.

I love you guys and don’t take this personally, but you just don’t seem to get it. And if you never ‘get rendering’ it’s ok. But stop gaslighting users like we are the crazy ones complaining that our renderings look bad. It’s disrespectful of our trade, our work and our time. You need to be better at this.

Best Regards,

Gustavo

4 Likes

A lot of tough love here now, but I guess it is now or never.
Here is a simple “plug” with a default metal material with 60% polish. The biggest issue here is that there is NO shadows on the metal part. It is just reflective and frankly looks like OpenGL. And if I hit render and wait for Rhino Render to “do it’s magic” then it is even worse:

My biggest issue with Metal as a material is that I have no control over both reflection amount and shine, nor the color of the reflection. It is just too simple.

But Rhino render has at least some shadows.

So here took the shadows from a white object and multiplied onto the default material (default to the left, sandwich to the right) and it looks better right away:

Same exersize done to a ring and it improves right away:

Hmm… internal shadows looks to be overwhelmed by the hdri file…

Jorgen

I understand this might look better, but it’s not physically how metal reacts to light. If we go down this path of adding in shadows that aren’t really there to make things look better in certain circumstances, we will end up with materials that don’t react the way you think they should when you change certain parameters.

Of course, if you know how to multiply in shadows from a diffuse shader to get that effect, then great. Otherwise, you might try setting the color of your metal to something less than “white” - this will cause it to lose energy in the areas where there’s a lot of internal reflection (ie - corners) and look shadowy.

As for your other comments:

My biggest issue with Metal as a material is that I have no control over both reflection amount and shine, nor the color of the reflection. It is just too simple.

The metal material has three parameters - “color” - which is the color of the reflection, “Polish” - which is essentially “shine”, and also an additional bump type.

In my opinion, this is the exact right result. What you are seeing inside those pipes is the perfect specular reflection of the back of the inner wall of the pipe - which is exposed to bright light from the hole at the back.

The white pipe will not get any darker over it’s length (unlike the gold one) because white reflection doesn’t lose any energy with each bounce. This makes me think that an action item here would be to make the default metal something other than “white”

OK - here’s some evidence for what I’m talking about:

In this photograph of actual reality below, there is a metallic cylinder (cookie cutter) and a diffuse cylinder (toilet roll). Notice how the shadow from the light source is clearly visible on the diffuse cylinder, but there is no corresponding line on the metal one. Metal objects - at least reasonably polished ones - do not show a “diffuse shadow”. You can also see that the shadow that should be present from my finger is not there (that little black smudge isnt a shadow - it’s a reflection of something outside).

There is nothing you can do to the camera position or light position that will cause the cookie cutter to show a shadow.

And here is the multi-bounce reflection effect that you can see on the gold tube in @Toshiaki_Takano’s post. You can see three separate bounce regions that progressively get lighter toward the back of the tube. The darkest one is right on the very edge of the tube nearest the light. This is exactly the opposite of what you would expect from a shadow.

Let’s leave RhinoRender out of this for now - it’s old, and incorrect.

Hi @andy
Thank you for the explanation.
I think I’d get some real material and try to find an environment in the real world which I like and try to reproduce that in cycles.
Seems like faster to understanding and getting a good setup.

One different default HDRI is preferred though, one that is like a studio but with more diamatic reflections but not as much as the gem studio seems a good.
Less linear reflection than the current default.

Gustavo

“you all have proven you are completely unqualified to make any decisions on rendering quality.”

Thanks. From @theoutside, @BrianJ, @nathanletwory and @me.

All I can really say is that you haven’t figured out how this works.

If you want a company that tells you what you want before you know you want it, we’re not that company. Instead, we try to get our actual users to explain to us what they need, and we try to provide the tools to do that.

Ideally, it will turn out that if we solve a problem one of our users has, we will have solved it for a couple of dozen more. Sometimes it works out well. Sometimes we have to iterate a few times before we get it right. If everyone seems cool with what we’ve got, we stop iterating.

Sometimes we properly screw it up.

We also don’t look at other software as an example of what we should be doing. If you want what the other software does, well…there’s the other software. It already does it. Sometimes that other software is a 3rd party plug-in for Rhino - that’s even better, because we get some of their success rubbed off on us.

And we don’t try to enforce solutions on users that are basically our own idea of how stuff should work. Heck - you’re the designer. I’m just a recovering architect who hasn’t lifted a Rotring pen in anger for 20 years. And if we hire designers…well…we just made them not designers anymore. So they’re now basically useless.

In other words, you need to tell us what you want. Not the other way around.

You guys are the inmates running the asylum. This non-sense needs to stop. And this playing dumb and confused, and setting low expectations as a reason of why the work is sub-par is not cool guys.

Exactly. That’s exactly what we are doing.

Deliberately.

But we’re not playing dumb and confused. We really are confused. We have only a hazy idea of what’s going on in your head. And it would really help if, instead of insulting pretty much everyone here, you would try to explain it. Probably around seven or eight times - until it finally gets through the rubbery outer layer of our cluelessness.

I know it’s frustrating. I’m sorry we’re so thick. But we really aren’t gas-lighting you.

And we’re not attempting to set expectations any way at all. We’re just trying to solve our users’ problems the best way we possibly can. And when we think our users think there’s enough solved problems, we ship something.

So - stepping back a little here:

We have the tube thing that looks a bit like a spark plug. And apparently it looks like crap.

Let’s have some discussion about why that is. And whether the changes we could potentially make to Rhino before we ship the next version - which isn’t all that far off people - would actually make for a good general solution.

Ideally, in a respectful and calm way.

Because otherwise I’m going to stop listening.

Andy

4 Likes

@Toshiaki_Takano

I certainly agree that more “studio types” would be great. In this version of Rhino, we were concentrating on having something which we called the “white studio” as the baseline. I understand fully that this studio - just like in the real world - isn’t going to cut it for every job.

I also understand that’s its not absolutely trivial to figure out how to replace the studio with another one of the many supplied HDRs. That’s something I hope to address in the future. It is certainly already possible now though.

In fact, “Snapshots” is the genesis of the “studio switching” feature for Rhino 7. We very much hope that we can actually provide ready made snapshots of studios to add to your designs. But we just didn’t get there for V6.

1 Like

One more thing I would like to say in this thread about the suitability of the default environment in V6 - remember, this is what you get in V5 if you make two metal cylinders and a diffuse one using the rendering defaults.

image

And this is what you get in V6 (OpenGL):

or with Cycles

Sounds good. Can’t wait to use V7 WIP.
I miss the render window in V6 WIP, the
focal blur and lighting controls were pretty good.

As for cycles, during V5 I was checking out
Blender so I may be a probably biased. It’s great that it’s getting into Rhino.

One thing is, I don’t know kow machine power is allocated, but during ray traced viewport sampling, normal UI lags a bit and hope it can be optimized or have way to slow down the sampling to prioritize UI.
Lighting controls seemed to be especially slow.
Using GTX1050, i7 and 24GB shouldn’t be that bad of a spec so, any others below that would have quite hard time… maybe? or could be my pc dependent.
Also macbook pro users will definitely see the lag.

I can’t spend too much on render software so improvements in cycles is really welcomed.

Keyshot is fast microwave drag and drop and really great… but it’s just so expensive… I need to get a 3D printer before that…

Sounds good. Can’t wait to use V7 WIP.
I miss the render window in V6 WIP, the
focal blur and lighting controls were pretty good.

I know you’re talking about missing the Cycles renderer that renders to the render window, but I still can’t figure out what you mean here.

See what I mean about cluelessness?

Could you show me?

One thing is, I don’t know kow machine power is allocated, but during ray traced viewport sampling, normal UI lags a bit and hope it can be optimized

Yes - we know about this. And quite honestly, we still haven’t figured out exactly what’s going on. We’ve thought we’ve solved it a number of times already, but it keeps creeping back.

It’s a priority to resolve this.

1 Like

Thanks!