Keep index using the outer scope for GHASH iter macros,
while its often nice, in some cases to declare in the for loop,
it means you cant use as a counter after the loop exits, and in some cases signed/unsigned may matter.
API changes should really be split off in their own commits too.
GPU_buffer no longer has a fallback to client vertex arrays, so remove
comments about it.
Changed a few internal structs/function interfaces to use bool where
appropriate.
Use for-loop scope and flexible declaration placement. PBVH does the
same thing but needs ~150 fewer lines to do it!
The change to BLI_ghashIterator_init is admittedly hackish but makes
GHASH_ITER_INDEX nicer to use.
This makes it possible to use scenes as a kind of
multi-user meta-strip (with their own time).
Currently this supports rendering & drawing nested strips,
but no convenient way to tab-enter into a scene strip.
yet another bug introduced by recent shadowing changes -- q and r CCG arrays
were overwritten by the temporary evaluation because the code was changed to
use global pointers instead of the local ones.
Naming of the variables could be changed to be a bit more accurate.
The main new feature is mixed variable declarations and code, which can help
reduce uninitialized variables or accidental variable reuse.
Due to incomplete C99 support in VS 2013, variable length arrays are not
supported, BLI_array_alloca must still be used. The header <tgmath.h> is also
not supported.
Differential Revision: https://developer.blender.org/D1631
GPUBuffer rendering is now done using vertex buffers.
Vertex arrays are completely removed from GL 3.2 core profile, so we'll
have to do this change at some point anyway.
This commit, though big, is not modifying blender in any way. Use should
be exactly as if the vetex buffer option is constantly on.
Aside from some minor cleanup, this commit:
* Fixes checking twice for multiple usage of same vert by a same poly.
* Fixes handling of ME_VERT_TMP_TAG vert flag by that check (there was no guaranty
that flag was cleared for a poly's vertices before we start checking).
This fixes two issues:
* Normals were not being recalculated correctly when not using optimized
drawing for CDDerivedMesh (Multires actually handles that correctly).
* Loop normals (autosmooth option) were also not being calculated. Doing
this calculation is not desirable, since it can't be done correctly
without a severe performance hit. This is easy to test by doing a
dependency flush on the mesh after each scuplt stroke step. Instead they
are now disabled during sculpting.
We have currently a gooseberry file (scenes/01_island/01_meet_franck/01_01_01_A/01_01_01_A.anim.blend)
that links against two -pre repo libs, which are hence not available for common mortals,
and generate warnings and placeholders during load step.
Issue is, among those missing (directly) linked datablocks, we have two shapekeys!
This should never happen nor be possible at all. I tried understanding how this could happen,
with no luck at all, best bet would be some wild/bad call to `id_us_plus()` over those skeys
at some point...
Anyway, this commit:
- Handles a bit better those 'cases that should never happen' at load time.
- Adds several checks in ID handling code (and save/load code) to try to detect where/when
a non-linkable datablock becomes LIB_EXTERN (i.e. directly linked).
We have callbacks for that, they also do some checks and help ensure things are done
correctly. Only place where this is assumed not true is blenloader (since here we
may affect refcount of library IDs as well...).
As we can see in (original) read code, ob pointer in groupobject is actually a 'USER_ONE' case.
This was not done in 'add object to group' code, probably because we can assume objects always
have at least one user in that case? Made it explicit now. Also fixed foreach_ID_link looper.
In general we have waaayyyyyy too much 'own handling' of ID->us count in code currently,
will clean up that...
