Adds a check when starting blender if your platform is supported. We use a blacklist
as drivers are updated more regular then blender (stable releases).
The mechanism detects if the support level changed or has been validated by the user previously.
Changes can happen due to users updating their drivers, but also when we change the support
level in our code base.
When the user has seen the limited support level message it is saved in the user config.
It would be better to have a system specific config section, but currently not clear
what could benefit from that.
When the platform is unsupported or has limited support a dialog box will appear including a link
to our user manual describing what to do.
**Windows**
Windows uses the MessageBox that is provided by the windows kernel.
**X11**
We use a very lowlevel messagebox for X11. It is very limited in use and can be fine tuned when needed.
**SDL/APPLE**
There is no implementation for SDL or APPLE at this moment as the platform support feature targets mostly Windows users.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D5955
Was caused by some drawcall not being done if the volumetric resolve pass
was drawn (using dual source blending seems to be the cause).
Not sure why this is needed since it is still reset before the next
drawcall.
The object color property is added as an additional output in
the Object Info node.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5554
This will have multiple benefit.
TODO detail benefits (culling, more explicit, handling of clipping planes)
For now the view usage is wrapped to make changes needed more progressive.
This is a big change that cleanup a lot of confusing code.
- The instancing/batching data buffer distribution in draw_instance_data.c.
- The selection & drawing code in draw_manager_exec.c
- Prety much every non-meshes object drawing (object_mode.c).
Most of the changes are just renaming but there still a chance a typo might
have sneek through.
The Batching/Instancing Shading groups are replace by DRWCallBuffers. This
is cleaner and conceptually more in line with what a DRWShadingGroup should
be.
There is still some little confusion in draw_common.c where some function
takes shgroup as input and some don't.
This is in order to have VAO handled by thoses batches instead of using a
common VAO. Even if the VAO has no importance in these case using a batch
will help when transitioning to Vulkan.
