| Age | Commit message (Collapse) | Author |
|---|
|
|
|
unstable to some extend and crashes a bit in some case. Still works fine in normal mode
|
|
before implementation
|
|
Fix some cases that still assumed there to be a global DPI, instead of a per
window DPI that needs to be set before reading U.dpi.
|
|
The issue was caused by combination of following factors:
- Blender Internal viewport render can not distinguish between which parts of
main database changed, so it does full database re-sync when anything is
tagged for an update.
This way, if any NodeTree (including compositor) is changed, Blender Internal
viewport is tagged for full render database update.
- With old dependency graph, scene-level drivers are evaluated on every
iteration of scene_update_tagged, even if nothing is tagged for an update.
This causes compositor drivers be evaluated quite often.
- Driver evaluation checks whether value was changed, and if so it tags
corresponding ID type as updated (this is what was telling viewport to do
render database update).
This check was quite stupid: current property value was checked against the
one coming from driver expression. This means, if driver value is outside
of the hard limit range of the property, the property will always be
considered updated.
The fix is to compare current property value against clamped value from the
driver.
|
|
Using an arbitrary face as the source of the UV data is mostly fine, as
vertices on seams will generally map to different parts of the texture
that have the same color.
This is regarding fed853ea782211298c902759ec8cd8e455d8b41d
|
|
|
|
When doing any transformation on a rigid body object that has delta
transforms, the object would be offset by the amount of the delta
transform.
|
|
Last fix only accounted for direct changes to the RB settings, but
failed for, say, object transformations. This fix accounts for any
change that might invalidate the RB cache.
|
|
Fix 9cd6b03187b91bb2c267a45eac3cee7738e0e220 introduced a bug that
prevented simulation after a cache invalidation (for instance when
changing a setting after simulating). This fixes that.
|
|
Particles were ignoring the lattice modifier visibility, and
"influence" property.
|
|
|
|
Patch by Alexander, with some refactoring by Brecht.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D2709
|
|
|
|
This makes the last time (`ltime`) stored in the rigid body world (`rbw`)
only be updated once a simulation step actually occurs, this prevents
another simulation step from being solved unless the current time is
exactly one frame after the last cached frame. Thus this prevents the
formation of gaps in the cache, such as seen in T50230.
Reviewers: mont29, sergey, angavrilov
Tags: #physics
Maniphest Tasks: T50230
Differential Revision: https://developer.blender.org/D2458
|
|
dupliface in final render
DupliVert/Face were not using render DM at render time.
|
|
Now that some node types may have custom context, we need to handle that
in the (convoluted :| ) UI code of nodes as well.
Reported in T43295 by Gabriel Gazzán (@gab3d), thanks.
|
|
Fix is a bit ugly, but cannot think of another solution for now, at
least this **should** not break anything else.
And now I go find myself a very remote, high and lonely mountain, climb
to its top, roar "I hate proxies!" a few times, and relax hearing the echos...
|
|
|
|
named datablock.
This is annoying especially for exporters who do use mesh name, since it
broke any relation with actual Mesh naming in original Blend file.
Unfortunately, we cannot avoid the extra .xxx digits. ;)
|
|
Also remove duplicate & mismatching comments from grease-pencil header.
Keep comments close to implementation to avoid getting out of sync.
|
|
or dp.
Children where always getting at least one segment of fixed length...
Now fully hidden ones (zero length) get no segment at all.
Note that even very short ones keep getting one 'unit' length segment - would
rather avoid changing that at this point, given how complex children
particles 'length' can get with all kind of modifiers... Think we can
live with that for now anyway.
|
|
|
|
|
|
'Convert To...' Object operation has very weird effect of actually
working at obdata level, not object level, which means *all* objects
(even unselected/hidden/in other scenes/...) using same obdata will be
converted to new selected type.
IMHO this is very bad behavior, but... not a bug really, so do not
change this for now.
But at least, do not do that when working on some linked data, else it
leaves Blend file in invalid (incoherent) state until next reload.
So workaround for now is to enforce the 'Keep Original' option when some
linked object/obdata is affected by the operation.
Also fixed somewhat broken usercount handling in Curve->Mesh part.
|
|
Eeeeeek!^2 Calling unconditionnaly ID freeing `BKE_libblock_free()` on a
datablock (ob->data, i.e. Curve) that may be used elsewhere...
Veryveryvery bad!
|
|
|
|
|
|
Noisy change, but safe, and better do it sooner than later if we are to
rework copying code. Also, previous commit shows this *is* useful to
catch some mistakes.
|
|
They were modifying some source ID prop, instead of copied version of
it... Found while making all source of ID copying const. ;)
|
|
|
|
This function is similar to BKE_libblock_free but does no DEG
tagging or any extra things, just operates on memory.
|
|
Optionally it'll also give name used for memory allocation.
|
|
|
|
That's the kind of commit that are nice to do - getting rid of
half-working custom pieces of code, now that we have generic tools
to do same thing. ;)
|
|
Was internally a no-op operation, which only caused extra work
to be done during depsgrpah traversal and evaluation, without
making any measurable improvement.
|
|
|
|
|
|
|
|
Was just keeping the default '1' user from `BKE_libblock_alloc()`,
instead of using correct way to handle extra virtual user needed when we
want to keep unused datablocks around...
|
|
|
|
This way we reduce amount of time wasted in spin-lock later on when all threads
are starting to sample texture.
|
|
Reduces amount of system-wide allocation calls. Will be
mainly visible when using lots of images in texture nodes
or regular BI rendering.
|
|
This was causing proxies updates on every frame, even if they
do not really change. Additionally, it was causing second round
of armature update when used from inside dupligroup (viewport
ensures all objects from dupligroup are up to date before draw).
|
|
at random.
DM evaluation code was simply never clearing the `deformedOnly` flag
when evaluating a generative modifier...
Quite astonishing this never got catched before, a lot of particle code
relies on valid value of this flag!!!
|
|
Take Two, did not detect that dynapaint was also creating named vgroup cdlayer!
|
|
The Issue
=======
For a long time now MinGW has been unsupported and unmaintained and at this point,
it looks like something that we should just leave behind and move on.
Why Remove
==========
One of the big motivations for MinGW back in the day is that it was free compared to MSVC which was licensed based.
However, now that this is no longer true we have basically stopped updating the need CMake files.
Along with the CMake files, there are several patches to the extern libs needed to make this work. For example, see:
https://developer.blender.org/diffusion/B/browse/master/extern/carve/patches/mingw_w64.patch
If we wanted to keep MinGW then we would need to make more custom patches to the external libs and
this is not something our platform maintainers are willing to do.
For example, here is the patches needed to build python: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3
Fixes T51301
Differential Revision: https://developer.blender.org/D2648
|
|
|
|
Assert the index is in-range for the layer type.
|
|
We had handling of fully duplicated polygons already, but... absolutely
nothing to sanitize partially merged polygons! This were giving us
totally invalid geometry, with duplicated vertices in single poly,
invalid edges, etc.
Now we do check for invalid loops inside polys, and generate new edges
as needed to get only valid polys.
For some reason this was a nightmare to get running fully OK, playing
with old and new indices is really, really mind breaking.
|
