Colors do not work at all with new material-changes.

[berberic2]

FreeCAD has experienced major changes in its material-system. Color (and material) does not work any more in the Render-WB.
I’m not sure when (and if) the new FreeCAD material-system will reach a workable state, but the Render-WB has to be updated in the near future…

[howetuft]

Hello,
You're right. I'll try to see what I can already adapt to the current state of the new system.

[howetuft]

To spare me some time: could you please attach a file illustrating the problems encountered? Thanks in advance!

[howetuft]

Er, actually, I think the problem might be more complex than just adapting Render:
https://forum.freecad.org/viewtopic.php?p=752086#p752086

To quote @wwmayer:

many, many colouring things are broken now.

Perhaps I'll wait a little while to find out what the new colour policy is in version 0.22, before embarking on a complete update of Render.

[berberic2]

Just a remark:
As the appearance (and material) implementation of freecad got less broken, we now have the problem, that the render-WB rendering does not look much better (if at all) than the freecad rendering. The conversion of appearance-parameters to the render-WB seems to be lossy, so especially shininess-settings seems to get lost.

(left freecad, right rendered with cycles)

[wwmayer]

Does it help to set the specular color in the preferences to black?

[howetuft]

The conversion of appearance-parameters to the render-WB seems to be lossy, so especially shininess-settings seems to get lost.

Sure. It's not lost, it's just unhandled - a logical consequence to the fact that, until 0.22, there has been no shinyness information in appearance parameters (to my knowledge). Therefore the default rendering material has been implemented as a Matte.

Does it help to set the specular color in the preferences to black?

Well, I'm not sure it would. I think the right solution would be to take the new appearance shinyness parameter(s) into account in default rendering material. I have to make my code evolve in that direction...

Please note however that the current behaviour (matte as the default) is not blocking, as there is always the possibility to override it by assigning an explicit rendering material to the object, for instance a glossy plastics.

[howetuft]

@berberic2
Please note also :
The shading model retained in ShapeAppearance (Diffuse/Ambient/Specular/Emissive/Shininess) is not physically-based.
This is in no way a judgment and I even think it's perfectly suited to rendering in the internal viewport, via OpenGL.
However, there can't be any exact equivalence with the shaders of the photorealistic engines (for example, see https://wiki.luxcorerender.org/LuxCoreRender_Materials - no direct mapping to the internal shading model).

As a conclusion, do not expect a perfect match between what you see in internal viewport and what is rendered by raytracing. At least, this is not my goal: I'll do my best to make default rendering not too far from internal view, but the workflow for a good rendering will always require the user to set materials (and lightings) for this purpose.

[berberic2]

I do not expect a perfect match. There would be no use having a render-WB if it looks the same.
But I would like it if the render-WB tries to realise my parameters in some way.

In my opinion the render-WB has a narrow scope of application.
A screenshot from FreeCAD with the shaded drawing style is sufficient for a quick display.
If it has to be really sophisticated, one has to export the objects to Blender.
So, the application is: get a decent rendering without to much work.
If you have to configure too much, invest to much time/work to make it look good, you might be better off exporting to Blender instead.

[howetuft]

you might be better off exporting to Blender instead.

Well, I don't agree with you. At least 2 not-so-obvious conditions for exporting to Blender:

1. Know how to use Blender (!)
2. Not to be in an iterative conception process (otherwise everything you do in Blender is to be done again next iteration)

Let alone the fact that you can do more than "decent" rendering via Render (some examples in the forum)...

But I agree with you about the need to reduce configuration in Render (I've got a plan to automate the installation of one or more renderers)

[howetuft]

Just rereading your post:

First, thank you for your frank opinion, it made me think about what I want to do for Render, and what I don't.

And from this thinking, I want to state here clearly my aim is not to confine Render to decent rendering.

I don't know if that's what most people expect. But I don't really care actually: I'm not developing Render to conquer a marketing target, even less to make money from it, but simply to enjoy myself - it's my hobby.

In contrast, what I do know is that:

• some people are able to use Render to create very elaborate renderings (https://forum.freecad.org/viewtopic.php?p=729315#p729315, https://forum.freecad.org/viewtopic.php?p=757672#p757672). I'm interested in what these people need.
• some people express me their gratitude for a workshop that allows them to design models and render them in iterative cycles (mostly PM, sorry, no quotation). I'm also interested in the needs of these people.
• Some people express their want to have everything they need in their workflow available in FreeCAD (https://forum.freecad.org/viewtopic.php?p=648497&hilit=sverchok#p648497). The needs of these people interest me too.
• On the other hand, some people would simply like a mere previewer before exporting to Blender (I'm not aiming this at you personally, I know it's a recurring request on the forum). Personally, I'm not interested in that and I'll do minimal job for it. On the other hand, Render is FOSS, so if anyone wants to extend its operation to this use case, contributions are welcome - or creating another workbench is always possible.

Lastly: in a certain way, I consider Blender as a concurrent tool for FreeCAD: many Blender plugins offer similar features as FreeCAD (BIM, parametric etc.) and I suspect they could replace it decently. So I don't think we should fall into the trap of delegating important parts of our workflow to Blender, or we'll wake up one day with all the community gone to Blender...