Even though this will have to change once we get workspaces, we will
still have a depsgraph for the Scene.
This is required for the upcoming depsgraph.objects RNA iterator.
Example, imagine an object Cube in collections 1 and 2 where both
collections are nested to A. Now we set a "color" property as follow:
```
Scene -> GREEN
--
A -> RED
↳ 1 -> BLUE
↳ 2 -> -
```
In this case the object will be RED, because of A↳ 2.
Now if we have:
```
Scene -> GREEN
--
A -> RED
↳ 1 -> -
↳ 2 -> PINK
1 -> -
--
The object will be PINK because of A↳ 2.
Note that the (top level) collection 1 doesn't influence the object color
because there are no overrides on it. The scene render settings (GREEN
in this case) are only used as fallback if an override is not set at
all.
That's a quick hack to address that specific case, new pointer IDProp
actually enlights a generic problem - datablocks using themselves - which
is not really handled by current code, would consider this not-so-urgent
TODO though.
Immediate mode built-in shader is used for this drawing already.
So there is no reason to try building basic shader which is not
supported in the core profile.
This replaces all direct usage of:
- FIRSTBASE
- LASTBASE
- BASACT
- OBACT
Some usages still remain in legacy utility functions which are called
all over the place.
With the explicit calls we don't need to worry about current state
outside of the GPU module now. In fact. we don't need to worry about
current matrix mode in core profile at all.
Legacy OpenGL now has some code which ensures current matrix mode
when using explicit calls to push/pop matrix.
There is no need to break assumptions of what's being modified
by this call and what's restored. The changes in this function
simply spread crappyness outside of the UI block.
There are two major things in this commit.
First one is to have proper stack for projection matrices. This is
something what OpenGL specification grants to have at least 2 elements
for and what is required to have for proper editor drawing without
refactoring the way how we restore projection matrix.
Supporting this stack have following advantages:
- Our GPU stack is closer to OpenGL specs, making it easier to follow
by other developers who are always familiar with OpenGL.
- Makes it easier to port all editors to a new API.
- Should help us getting rid of extra matrix push/pop added in
various commits to 2.8 branch.
The new API follows the following convention:
- gpuPushMatrix/gpuPopMatrix ALWAYS deals with model view matrix
and nothing more.
While this name does not fully indicate that it's only model view
matrix operator, it matches behavior of other matrix operations
such as transform which also doesn't indicate what matrix type
they are operating on.
- Projection matrix has dedicated calls for push/pop which are
gpuPushProjectionMatrix/gpuPopProjectionMatrix.
