Age | Commit message (Collapse) | Author |
|
2.8x branch added bContext arg in many places,
pass eval-context instead since its not simple to reason about what
what nested functions do when they can access and change almost anything.
Also use const to prevent unexpected modifications.
This fixes crash loading files with shadows,
since off-screen buffers use a NULL context for rendering.
|
|
Note that some little parts of code have been dissabled because eval_ctx
was not available there. This should be resolved once DerivedMesh is
replaced.
|
|
|
|
|
|
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.
|
|
|
|
|
|
Notes:
* Code in rendering and in game engine will still convert
tangents to a tessface representation. Added code that
takes care of tangent layer only, might be removed
when BGE and rendering goes full mlooptri mode.
* Baking should work discovered some dead code while
I was working on the patch, also tangents are broken
when baking from multires (also in master), but those
are separate issues that can be fixed later.
This should fix T45491 as well
|
|
modifier.
Since it was not ensuring dest has valid mdisp data matching new multires modifier subdiv level...
Also, fixed a bug in `multires_subdivide()`, which would crash when trying to
increase from level 0 (aka no subdiv) to > 1 (wrong check, trying to interpolate
when it should not). And added a few sanity checks.
|
|
This way it is possible to have viewport simplification bumped all the way up,
making viewport really responsive but still have final render to use highest
subdivision possible.
Reviewers: lukastoenne, campbellbarton, dingto
Reviewed By: campbellbarton, dingto
Subscribers: dingto, nutel, eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1273
|
|
|
|
Was trying to free a NULL pointer...
|
|
Mostly harmless things, though the 'multires' error was a real bug.
|
|
|
|
|
|
|
|
|
|
- BLI_BITMAP_SET -> BLI_BITMAP_ENABLE
- BLI_BITMAP_CLEAR -> BLI_BITMAP_DISABLE
- BLI_BITMAP_GET -> BLI_BITMAP_TEST
- BLI_BITMAP_MODIFY -> BLI_BITMAP_SET
|
|
|
|
Reshape and applying scale matrix on multires needs to create DM with simplify
setting disabled. Added a special flag to modifier apply for this now.
|
|
also replace AT with __func__ since AT expands the full pathname
|
|
|
|
|
|
|
|
|
|
|
|
edit mode.
|
|
This seems to be giving speedup up to 10% in own tests.
--
svn merge -r60104:60105 ^/branches/soc-2013-depsgraph_mt
|
|
calculations) into mesh_evaluate.c.
mesh.c was over 4k lines and complex functions mixed in with general library management.
|
|
|
|
hides that an arg passed is really an array which may be modified by other functions.
|
|
the mapping functionality.
replace ED_mesh_calc_normals with BKE_mesh_calc_normals().
|
|
Seems it was simply missing mesh normals update in multiresModifier_base_apply.
|
|
On file save the mesh gets loads from the editmesh but the derived mesh caches
wer not cleared. This usually happens through the depsgraph but it needs to be
done manually here. Most changes are some refactoring to deduplicate derived
mesh freeing code.
|
|
EditDerivedBMesh.tc -> em. ('tc' is odd name which isn't used elsewhere).
|
|
|
|
|
|
|
|
now blenlib/BLI doesn't depend on any blenkern/BKE functions,
there are still some bad level includes but these are only to access G.background and the blender version define.
|
|
|
|
|
|
|
|
|
|
|
|
is a multi-res modifier).
|
|
|
|
|
|
|
|
When OpenMP is enabled, memory allocation needs to be protected.
Fixes bug [#32111] Memory management regression from svn_46520
projects.blender.org/tracker/index.php?func=detail&aid=32111&group_id=9&atid=498
|
|
Problems were in the old multires loading system.
Actually, the sigsev itself was the easy part of the job (simply had to convert from tesselated data to polys/loops), but after that I was getting a horrible bunch of wild stray faces...
It finally turned out it was a mismatch in two different subsurf structs used while computing a mdisps layer from the multires DM, leading to getting complete random normals (null ones, NAN ones...), leading to complete dummy tangent space matrix, leading to absurds mdisps values...
Note: I also moved the copy of first layer's vertex and face data from old me->mr to mesh's v/fdata earlier in multire_load_old(), to be able to use general face_to_poly conversion function (later on we would have to do it by hand, the general function would erase our newly computed mdisps layer...).
Took me the whole week (something like 20h) to track this down: multires + subsurf = C nightmare!
|