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.
There is only two places which are using texture matrix mode:
- Tiled tface support.
- Texture shading mode for texture mapping.
Both cases are subject for reconsideration: it is likely that we'll be getting
rid of tface, which means game properties like tiles needs to be revisited
anyway. As for texture shading it is using basic shader which is also not
supported by core profile anyway.
The ABC_export and ABC_import functions both take a as_background_job
parameter, and return a boolean.
When as_background_job=true, returns false immediately after scheduling
a background job. This was the old behaviour of this function, which makes
it very hard for scripts to do something with the data after the import
or export completes.
When as_background_job=false, performs the export synchronously, and
returns true when the export was ok, and false if there were any errors.
This allows further processing.
The Scene.alembic_export() function is deprecated, and will be removed from
Blender 2.8 in favour of calling the bpy.ops.wm.alembic_export() operator.
As such, it has been hard-coded to the old background job behaviour.
It is required for our new matrix stack to only have projection and model view
matrix modes. This commit ports paint cursor overlay to model view matrix.
The export is still slower than needed, as the particle systems themselves
aren't disabled during the export. It's only the writing to the Alembic
file that's skipped.
This combines the Mesa fix (16e929e6ff by @brita_) with the Mac fix (89e23c743e by @merwin).
And uses the same fix for another call to glFramebufferTexture introduced in f1fb605ec9.
The issue was going to the fact that GL_ALPHA was deprecated in core profile
and common solution online is to use GL_RED instead. That is what is done in
this commit.
Curve resolution isn't natively supported by Alembic, hence it is stored
in a user property "blender:resolution". I've looked at a Maya curves
example file, but that also didn't contain any information about curve
resolution.
Differential Revision: https://developer.blender.org/D2634
Reviewers: kevindietrich
Object Info node can be useful to give some variation to a single material assigned to multiple instances. This patch adds support for Viewport and BI.
{F499530}
Example: {F499528}
Reviewers: merwin, brecht, dfelinto
Reviewed By: brecht
Subscribers: duarteframos, fclem, homyachetser, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D2425
This replaces access to the first scene layer (which was wrong) with a linear
lookup of scene layer by it's active index.
This seems to be a better temporary solution to have things working for until
we've got proper workspace, depsgraph and it's per-layer storage in place.
The order number written to Alembic is the same as we use in memory, so
the +1 wasn't needed, at least according to the reference Maya exporter
maya/AbcExport/MayaNurbsCurveWriter.cpp, function
MayaNurbsCurveWriter::write(), in the Alembic source code.
Furthermore, when writing an array of nurb orders, the curve type should
be set to kVariableOrder, otherwise the importer will ignore it.
For now only compute GGX convolution. The GGX LUT used for the split sum approximation (UE4) is merged with the LTX mag LUT that uses the same parameters (theta and roughness)
