This was slightly less obvious, especially particle billboard drawing.
That one now requires 1.5 times more space in VBOs and ParticleDrawData
buffers, since we have to draw two triangles per particle, instead of a
single quad... And diagonal of each quad is now drawn in wire mode, not
sure how much we consider this an issue (as in, will this particle draw
code change a lot in future?).
From quick check on the web seems there is no other way to do anyway. :/
Do not recompute both points's 2D coordinates for each segments, we can
copy over from previous one... Does not gives any measurable speedup off
hands, though.
Couple of things here:
- Boost is not necesserily compiled into your /opt/lib and system-wide
version might have been used. The recent change in Alembic did not
take this into account.
- Alembic needs some extra component of Boost.
This part might be missing now for other distros than DEB.
The issue was caused by recent change in inline policy.
There is some sort of memory corruption happening here, ASAN suggests
it's stack overflow issue. Not quite sure why it is happening tho and
was not able to solve anything here yet in the past hours.
Committing fix which works with a big TODO note.
The issue is visible on AVX2 machine when rendering cycles_reports_test.
Using Texture Arrays to store shadow maps so less texture slots are used when shading. This means a large amount of shadows can be supported.
Support Projection Shadow Map for sun like in old BI/BGE.
Support Cube Shadow Map for Point/Spot/Area lights. the benefit of using it for spot light is that the spot angle does not change shadow resolution (at the cost of more memory used). The implementation of the cubemap sampling is targeted for 3.3 core. We rely on 2D texture arrays to store cubemaps faces and sample the right one manualy. Significant performance improvement can be done using Cubemap Arrays on supported hardware.
Shadows are only hardware filtered. Prefiltered shadows and settings comming next.
This is an auto-generated list, crossing gl-deprecated.h, glew.h and the
Blender code. It allows Blender to build with core profile.
WITH_OPENGL_LEGACY=ON: nothing changes
WITH_OPENGL_LEGACY=OFF and WITH_GL_PROFILE_CORE=OFF:
It stubs deprecated legacy calls.
WITH_OPENGL_LEGACY=OFF and WITH_GL_PROFILE_CORE=ON:
It stubs deprecated legacy calls thus allowing Blender to build with
core profile only.
Technically you only want to use WITH_OPENGL_LEGACY=OFF when
WITH_GL_PROFILE_CORE=ON. But it doesn't hurt to have it working for both
scenarios.
Reviewed by: merwin
Differential Revision: https://developer.blender.org/D2610
Doing this in a fully 'clean' way is far from obvious, especially
unregister, you often end up leaving nasty 'orphanned' keymap items
referring to unregistered operators...
See gpu_shader.c for the main changes.
EXT_geometry_shader4 brought this feature to GL versions < 3.2, but now it's just cluttering up our code.
Soon all platforms will be on version 3.3 so we won't even have to check support at runtime!
Callers now have to use Gawain's PRIM enum to specify geometric primitives.
This makes the API more bullet-proof (at least less vulnerable) since GLenum covers waaay more than GL_POINTS, GL_LINES, etc.
Also prepares us for Vulkan.
