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.
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)
glFramebufferTexture() is only available from OGL 3.2, it is also not part of the ARB_framebuffer_object extension.
I don't know if there is a better way to check for mesa drivers or if using the 2D version will have issues with f2f16a256, but so far I had no problems
- test for 2D textures first since it's the most common case
- declare variables close to where they're used
- fix compiler warning for proxy (uninitialized use)
- safe return if n != 1, 2, 3 (should never happen)
- white space
The fragment shader expects a normal, but the vertex shader was not providing one.
Fix: added a new vertex shader that has normals + smooth color interpolation.
I also split gpu_shader_3D_vert in two:
- one with just position
- one with position + normal
For each of the builtin shaders, we should be able to look at the GLSL and tell exactly what it's doing. Using #defines and #ifdefs for rendering options makes the shaders hard to read and easy to break.
The specialized color functions are better in every way:
- faster lookup (don't have to match "color" string)
- flexible inputs (RGB with separate alpha)
- automatic alpha = 1.0 if not specified
Sort of related to T49043
This eliminates tons of glGetAttribLocation calls from the drawing loop. Vast majority of code can keep making the same function calls. They're just faster now!
- remove 2D-specific variants of BuiltinUniform enum
- rename remaining builtins to exclude "_3D" since they can be used by 2D or 3D shaders
Follow up to D2626
See GPU_matrix.h & gpu_matrix.c for the important changes. Other files are mostly just updated to use the latest API.
- remove unused functions, defines, enums, comments
- remove "3D" from function names
- init to Identity transform (otherwise empty stack)
- gpuMatrixReset lets outside code return to initial state
Part of T49450
Follow up to D2626 and 49fc9cff3b
* Brings us closer to core profile, all matrices are working, and apart
from a problem with text drawing, Blender is working fine.
* Reduce the coding overhead of having to setup/teardown when
alternating between 2D and 3D drawing sessions.
* Gives us fewer modes and states we need to keep track of.
Unfortunatelly this also "rejects a fundamental change" the original
design was trying to make - that 2D is different from 3D and
deserves its own best implementation.
That said, it is still aligned with the function API design as
originally implemented (i.e., it still uses gpuTranslate2D, ...).
Finally, if you build with core profile and this patch you get:
https://developer.blender.org/F545352
[The text glitch is an unrelated issue].
Reviewers: merwin, sergey, brecht
Differential Revision: https://developer.blender.org/D2626
On Apple we use OpenGL 2.1 + an ARB extension for framebuffers.
The glFramebufferTexture function is part of OpenGL 3.0 but not part of the ARB extension. This commit fills that gap.
All other platforms are using GL 3.0+ already so it's not an issue there. All platforms (Mac too) will use GL 3.3+ soon so this workaround will be removed.
The U-resolution of the imported curves was kept at the default value
of 12, which is way too high for imported hair. We export hair at a
fairly high resolution already, so it's not needed to subdivide even
further when importing.
Of course this may have an impact on other curves that do require this
U-resolution to be higher. In that case the resolution can be
increased after importing.
I removed the default nu->orderu = num_verts, as that allowed every
point to influence the entire spline, which was more expensive for the
CPU, and unlikely to be needed. The orderu computations had off-by-one
errors in the curve importer, which are now also fixed. The correct
values are:
- Linear: orderu = 2
- Quadratic: orderu = 3
- Cubic: orderu = 4
These values are also what is stored in the Alembic file for curves of
type kVariableOrder, according to the reference Maya exporter
maya/AbcExport/MayaNurbsCurveWriter.cpp, function
MayaNurbsCurveWriter::write(), in the Alembic source code.
The result is a frame rate increase of roughly 100x (tested with one
100-hair test on one machine, so take with grain of salt).
These were the last few glGetUniformLocation calls in source/blender.
The new system gets uniform information once when a shader is created, then uses this cached info every time after that.
This supports our common character animation workflow, where a character,
its rig, and the custom bone shapes are all part of a group. This group
is then linked into the scene, the rig is proxified and animated. Such
a group can now be exported. Use "Renderable objects only" to prevent
writing the custom bone shapes to the Alembic file.
