We concluded this is going to be the display mode users will need to work
with the most, so makes sense to make it the default one.
Also, if the opened file only has one collection in the active render
layer, we expand it (almost empty list would be misleading).
What I had to do to make the expanding work is a bit ugly, but didn't
find a better way. During do_version we don't have access to the
TreeElement instances, and including ED_outliner.h to share code here
should be avoided too.
Internal change needed for template support.
Loading the user preferences first so it's possible
for preferences to control startup behavior.
In general it's useful to load preferences before data-files,
so we know security settings for eg.
GL_SELECT is really slow in this branch and will be removed.
For now we simply change AUTO behavior to avoid possible conflicts with merges
and upcoming color-id-based selection.
Talked with Pablo Vazquez (venomgfx) and Julian Eisel (Severin), and we came up with this solution instead.
Basically, if the file has only one layer, it is converted to a collection named "Default Collection". Otherwise we name the collections: "Collection 1 [converted from 2.75]"
Just do early output and don't bother with any GLSL program bind when
there is not enough points of lasso to draw.
This could have happened at the very beginning of the stroke.
The thing i'm really starting to hate is the requirement to specify both
operation code and node type. Seems to be duplicated enums without real
need for that.
This addresses an issue raised by D2453 -
that there was no way to check if operators are run
multiple times in a row.
Actions are still ignored that don't cause an UNDO event.
Was using some threaded queue on top of task pool, tssk...
Now using properly task pool directly to crunch chunks of smooth fans.
No noticable changes in speed.
Tried to completely get rid of the 'no threading with few loops' code,
but even just creating/freeing the task pool, without actually pushing
any task, is enough to make code 50% slower in worst case scenario (i.e.
few thousands of simple cube objects).
The root of the issue was in custom normal code, so far it assumed that
we could only have one cyclic smooth fan around each vertex, which is...
blatantly wrong (again, the two cones sharing same vertex tip e.g.).
This required a rather deep change in how smooth fans/clnor spaces are processed,
took me some time to find a 'good' solution.
Note that new code is slightly slower than previous one (maybe about 5%),
not much to be done here, am afraid.
Tested against all older report files I could find, seems OK.
So we can store (for example) vertex positions in one buffer and normals + colors in another buffer. Not super exciting right now, but very useful once we start changing some attribute values.
Supports future work by Clément et al. Only tested with one VBO per Batch since that's all our current code uses.
glMaterial
glColorMaterial
glPixelTransfer
and glEnable/Disable for
GL_FOG, GL_LIGHTING, GL_COLOR_MATERIAL
All of these were just setting default values, so I don't expect any visible change.
Part of T49165 (general OpenGL upgrade)
GPU_viewport_bind & unbind should be called as pairs. A recent commit -- 3b91989a09 -- called unbind only for some code paths, overflowing OpenGL's matrix & attrib stacks.
