[Renderer Workbench] Lighting
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
[Renderer Workbench] Lighting
Hi everybody!
Playing around with the new Renderer Workbench, I had a feeling we could improve the new Renderer Workbench by adding some lighting functionalities. Here is my proposition:
Problematic:
At the moment, to set lighting in rendering, we rely on renders templates, with 2 flavors for each back-end renderer: standard, sunlight.
The main advantage with templates is that they require no tuning from the user. But there is a major drawback: it is not possible to adapt the lights parameters to the object you want to render, as all lights parameters are set once and for all in the template.
That being said, template is a good approach for sunlight lighting, because sunlight lighting is mostly independent from the object you want to render. And sunlight is naturally suitable for building rendering (arch).
However, there are other rendering situations for which sunlight lighting is not really suitable: part rendering, indoor scene rendering... For those situations, we need to light the scene with lights objects and we need to be able to adapt the lighting parameters to the rendered object. Those parameters encompass:
- number and types of lights
- positions of lights
- powers of lights
- colors of lights
- etc.
So we need mechanisms to do that in the workbench...
For all situations also (part, outdoor arch, indoor arch), we might also want to use image-based lighting (https://en.wikipedia.org/wiki/Image-based_lighting), which can offer some interesting lighting possibilities as well, especially with HDRI images.
Proposition:
My idea would be to add the following capabilities in Render WB:
1. An image-based lighting functionality.
It would allow to add an HDR image to the model, to be exported to the renderer.
2. A few lights objects, accessible via the WB toolbar, that could be added in the render view
In order to preserve the multi-renderer orientation of the workbench, it would consists in a small common subset of lights objects that could be handled by all back-ends renderers, ie:
- Points lights
- Areas lights (as rectangles)
Those objects would be exported to the renderers in the same way as geometry.
Those objects would bear an 'active' property (inactivated lights wouldn't be exported).
Those objects could be grouped in Lights groups, with an 'active' property also.
3. A three-points lighting functionality
As the above #2 functionality may introduce some complexity to non-advanced users, I propose to add a one-click action which would add a standard configuration of lights achieving a classic lighting scheme, the "three-points lighting": see http://www.3drender.com/light/3point.html, https://en.wikipedia.org/wiki/Three-point_lighting, or this blender plugin https://blender-addons.org/tri-lighting-addon.
For all those functionalities, I would replace the present "standard" template with a "dark" (or "flat") template, with no light.
Roadmap:
Collect the feedback from this thread and adapt my proposition.
Make a first implementation of the above ideas with Luxrender renderer.
Generalize to the other renderers once we agree on the result.
--> What would you think about that?
Playing around with the new Renderer Workbench, I had a feeling we could improve the new Renderer Workbench by adding some lighting functionalities. Here is my proposition:
Problematic:
At the moment, to set lighting in rendering, we rely on renders templates, with 2 flavors for each back-end renderer: standard, sunlight.
The main advantage with templates is that they require no tuning from the user. But there is a major drawback: it is not possible to adapt the lights parameters to the object you want to render, as all lights parameters are set once and for all in the template.
That being said, template is a good approach for sunlight lighting, because sunlight lighting is mostly independent from the object you want to render. And sunlight is naturally suitable for building rendering (arch).
However, there are other rendering situations for which sunlight lighting is not really suitable: part rendering, indoor scene rendering... For those situations, we need to light the scene with lights objects and we need to be able to adapt the lighting parameters to the rendered object. Those parameters encompass:
- number and types of lights
- positions of lights
- powers of lights
- colors of lights
- etc.
So we need mechanisms to do that in the workbench...
For all situations also (part, outdoor arch, indoor arch), we might also want to use image-based lighting (https://en.wikipedia.org/wiki/Image-based_lighting), which can offer some interesting lighting possibilities as well, especially with HDRI images.
Proposition:
My idea would be to add the following capabilities in Render WB:
1. An image-based lighting functionality.
It would allow to add an HDR image to the model, to be exported to the renderer.
2. A few lights objects, accessible via the WB toolbar, that could be added in the render view
In order to preserve the multi-renderer orientation of the workbench, it would consists in a small common subset of lights objects that could be handled by all back-ends renderers, ie:
- Points lights
- Areas lights (as rectangles)
Those objects would be exported to the renderers in the same way as geometry.
Those objects would bear an 'active' property (inactivated lights wouldn't be exported).
Those objects could be grouped in Lights groups, with an 'active' property also.
3. A three-points lighting functionality
As the above #2 functionality may introduce some complexity to non-advanced users, I propose to add a one-click action which would add a standard configuration of lights achieving a classic lighting scheme, the "three-points lighting": see http://www.3drender.com/light/3point.html, https://en.wikipedia.org/wiki/Three-point_lighting, or this blender plugin https://blender-addons.org/tri-lighting-addon.
For all those functionalities, I would replace the present "standard" template with a "dark" (or "flat") template, with no light.
Roadmap:
Collect the feedback from this thread and adapt my proposition.
Make a first implementation of the above ideas with Luxrender renderer.
Generalize to the other renderers once we agree on the result.
--> What would you think about that?
Re: [Renderer Workbench] Lighting
There is already an on going effort related to this.
I'll try to find a link.
I'll try to find a link.
Re: [Renderer Workbench] Lighting
I can't find, but IIRC this was @furti that did that...
furti wrote: Ping
Re: [Renderer Workbench] Lighting
Until now there is no lightning Support available i think.
I added customizable lights to the archtexture workbench a while ago http://forum.freecadweb.org/viewtopic.php?t=39031
My goal was to use this information and add this lights to the render workbench.
But cuttently I'm pretty busy planning our house. Maybe you can build on top of this lights and add them to the render workbench.
There is some ongoing effort in enhancing the workbench. https://github.com/FreeCAD/FreeCAD-render/pulls
I added customizable lights to the archtexture workbench a while ago http://forum.freecadweb.org/viewtopic.php?t=39031
My goal was to use this information and add this lights to the render workbench.
But cuttently I'm pretty busy planning our house. Maybe you can build on top of this lights and add them to the render workbench.
There is some ongoing effort in enhancing the workbench. https://github.com/FreeCAD/FreeCAD-render/pulls
Re: [Renderer Workbench] Lighting
OK, I'm going to see first how I can use Archtexture features for my purposes!
Re: [Renderer Workbench] Lighting
Hello all,
As a follow-up to my previous post, I looked at existing code, and below are my conclusions at this stage (all of these are my personal opinions so feel free to comment):
1. Point Lights (PL)
What is reusable from ArchTextures WB:
- PL Creation/Deletion
- PL Placement
- PL Color
- PL Visibility (on/off)
What needs some adaptations:
- PL Power setting: every renderer has its own logic for PL Power configuration, which makes the point tricky:
Therefore I would propose to add a RenderPower attribute to Point Lights (in ArchTextures WB), with the following characteristics:
- In watts (because it is the more precise unit, from a physical point of view)
- With no upper bound (as nothing justify to limit light power)
Then each renderer exporter script would be in charge to convert this value to its renderer's logic.
The renderer exporter would also provide default values for its other parameters (efficiency, size, intensity_multiplier etc.), possibly accessible as object attributes in the Render Project object.
For the internal rendering (in ArchTextures WB), we have to decide whether we keep the current Intensity parameter as a free value or we link it to the new RenderPower parameter (and, in that case, we should decide how we link it).
2. Area Lights (AL)
There is no such functionality in the ArchTextures WB at the moment, but we can add one. My idea would be to use rectangular areas (defined by a center point, 2 sizes parameters (X & Y), a normal vector, and angle of rotation around normal), with color (emissive) and visibility.
However, please note that there is the same Power issue as above, so we must address it for PL before starting anything before starting anything with AL.
3. Image-Based Lighting (IBL)
No such functionality in OpenInventor (and then in ArchTextures WB). Moreover, OpenInventor doesn't know anything about HDR image format, which is required for IBL. Therefore, in my opinion, it can only be implemented in the Render WB, as an attribute to the render project to be exported by the renderer script.
Please feel to comment!
If OK, my plan is to focus first on Point Lights, creating the RenderPower parameter, and adapting the LuxCore exporter...
As a follow-up to my previous post, I looked at existing code, and below are my conclusions at this stage (all of these are my personal opinions so feel free to comment):
1. Point Lights (PL)
What is reusable from ArchTextures WB:
- PL Creation/Deletion
- PL Placement
- PL Color
- PL Visibility (on/off)
What needs some adaptations:
- PL Power setting: every renderer has its own logic for PL Power configuration, which makes the point tricky:
- In Open Inventor (internal renderer), power is controlled by one attribute (Intensity), which is unitless and upper bounded (it must be in [0.0,1.0]). See here: https://developer.openinventor.com/User ... ights.html
- In LuxCore, power is controlled by 2 parameters (Power, Efficiency), which are in IS units (watts, lumens/watt), with no upper bound. See here: https://wiki.luxcorerender.org/LuxCore_ ... ype:_point
- In Cycles, power is controlled by 1 parameter (Power), which is in IS units (watts), with no upper bound. There is also a secondary parameter (Size), to control the sharpness of shadows cast by the light. See here: https://docs.blender.org/manual/en/late ... oint-light
- In Appleseed, power is controlled by one mandatory parameter (Intensity) and a bunch of other optional data (intensity_multiplier, exposure, cast_indirect_light, importance_multiplier). Intensity is unitless and with no upper bound. See here: https://github.com/appleseedhq/applesee ... ight-model
- In POV-Ray, power is directly controlled by RGB light color (meaning that RGB(1,1,1) is twice more powerful than RGB(0.5,0.5,0.5)). So, it is unitless and upperbounded. See here: https://www.povray.org/documentation/view/3.6.1/308/
Therefore I would propose to add a RenderPower attribute to Point Lights (in ArchTextures WB), with the following characteristics:
- In watts (because it is the more precise unit, from a physical point of view)
- With no upper bound (as nothing justify to limit light power)
Then each renderer exporter script would be in charge to convert this value to its renderer's logic.
The renderer exporter would also provide default values for its other parameters (efficiency, size, intensity_multiplier etc.), possibly accessible as object attributes in the Render Project object.
For the internal rendering (in ArchTextures WB), we have to decide whether we keep the current Intensity parameter as a free value or we link it to the new RenderPower parameter (and, in that case, we should decide how we link it).
2. Area Lights (AL)
There is no such functionality in the ArchTextures WB at the moment, but we can add one. My idea would be to use rectangular areas (defined by a center point, 2 sizes parameters (X & Y), a normal vector, and angle of rotation around normal), with color (emissive) and visibility.
However, please note that there is the same Power issue as above, so we must address it for PL before starting anything before starting anything with AL.
3. Image-Based Lighting (IBL)
No such functionality in OpenInventor (and then in ArchTextures WB). Moreover, OpenInventor doesn't know anything about HDR image format, which is required for IBL. Therefore, in my opinion, it can only be implemented in the Render WB, as an attribute to the render project to be exported by the renderer script.
Please feel to comment!
If OK, my plan is to focus first on Point Lights, creating the RenderPower parameter, and adapting the LuxCore exporter...
Re: [Renderer Workbench] Lighting
Really thorough summary and proposal. Thanks for the effort here, @howetuft
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: [Renderer Workbench] Lighting
Thank you! I've started to write some lines of code for Point Lights rendering, hope to be able to present something before X-Mas...
Re: [Renderer Workbench] Lighting
This is mainly for the architecture users, but maybe also put on the list support to export the hosek-wilkie skylight. The major renderers (appleseed, luxcore, blender) already support this.
The user doesn't even need to guess the direction of the sun. Look at https://forum.freecadweb.org/viewtopic.php?t=18587. PySolar can take as input longitude, latitude and time, and it will spit out the correct direction of the sun.
If you want to be extremely precise, I can take a look whether the output of PySolar and hosek-wilkie are compatible with eachother. This is in respect to the apparant (after atmospheric refraction) or real position of the sun. I thought they were but I'm not sure.
The user doesn't even need to guess the direction of the sun. Look at https://forum.freecadweb.org/viewtopic.php?t=18587. PySolar can take as input longitude, latitude and time, and it will spit out the correct direction of the sun.
If you want to be extremely precise, I can take a look whether the output of PySolar and hosek-wilkie are compatible with eachother. This is in respect to the apparant (after atmospheric refraction) or real position of the sun. I thought they were but I'm not sure.