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.
This feature got lost with new auto-track API,
Added it back by extending frame accessor class. This isn't really
a frame thing, but we don't have other type of accessor here.
Surely, we can use old-style API here and pass mask via region
tracker options for this particular case, but then it becomes much
less obvious how real auto-tracker will access this mask with old
style API.
So seems we do need an accessor for such data, just matter of
finding better place than frame accessor.
It's a bit ugly but I couldn't find a better way to keep fast installs and
correct handling of switching between master and blender2.8 with different
lib directories.
This makes it possible to have an animated / procedurally generated mesh
that starts empty and obtains data in later frames.
Fixes the export of an empty mesh with an Ocean Modifier, as described in
issue T51351.
This allows you to put any kind of animation data on the mesh, and its
shape will be exported on each timekey. Note that this timekey is unrelated
to the animation data (so we don't export on each keyframe, for example).
A practical example is the addition of an animated custom property to
trigger the export of animated mesh data. The mesh data can then be created
from any source, like Python scripts.
Not only is this useful in itself, it also provides a workaround for one
of the two issues described in T51351.
This is written in a custom metadata key, so it isn't shown by utilities
like abcecho or abcls. However, it's still something that's useful to
have available.
Houdini writes vertex data in a different format than Blender does; Houdini
uses "face-varying scope", which means that the vertex colours are indexed
by an ever-increasing number over all vertices of all faces instead of the
vertex index.
I've also merged the read_custom_data_mcols() and read_mcols() functions,
because the latter was only called from the former, and the changes in this
commit would add yet more function parameters to pass.
A big chunk of code was copied between the if and else bodies. By using
a boolean to store whether the c3f_ptr or c4f_ptr should be used, the
in-loop condition is kept as simple as possible.
Note: the angle in bug isn't really reflex - using the vertex normal
for this test isn't always right, but usually is. At any rate,
shouldn't try to put vertex on edge between if a reflex angle.
This was two-fold.
1) The export used viewport settings to obtain the particle cache, rather
than render settings.
2) The child hair writer tried to obtain UV-coordinates from the parent
chair, without checking whether those were available in the first place.
Since we already have a rather advanced PovRay exporter, makes sense to
also nicely display generated 'code'.
Patch by Maurice Raybaud (@mauriceraybaud), thanks!
Cleanup (mostly styling) by @mont29.
Brightness/contrast node was changing color but did not modify alpha
or ensured colors are premultiplied on the output. This was giving
artifacts later on unless alpha was manually converted.
Compositor is supposed to work in premultiplied alpha (except of
some really corner cases) so it makes sense to ensure premultiplied
alpha after brightness/contrast node.
This is now done as an option enabled by default, so we:
(a) Keep compatibility with old files.
(b) Have correct behavior for newly created files.
Later on we can get rid of this option.
We were looping over all vgroups in destination mesh and making string
comparison, for every vgroup of every vertex of merged mesh! Crazy!
Now we simply create a temp mapping of vgroup indices, seriously
simplifies things (and gives significant speedup when merging huge meshes
with lots of vgroups, here with quick stupid test went from 120ms in
vgroup merging to less than 5ms, 25 times quicker!).
Root of the issue here was that two stupid modifiers could create named
vgroup CD layers (vgroup editing ones... shame on me :") ).
Fix that, and added some versionning code to also fix 'corrupted' blend
files created by those so far.
`screen_findedge()` is not expected to return NULL in that case, but
checking against that does not hurt (we do it in all its other call
cases anyway), better than crashing.
The issue is coming from some weird semi-finished canvas feature, which
was remapping coordinate without applying any differential on the sampling
ellipse (in fact, there is no ellipse, sampling think is always a single
pixel).
The whole thing is just weak in the compositor, for now just bring behavior
back to how it was prior to optimization (multithreading) commit.
