| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Tabs in middle of code (mostly for no reason / by accident).
|
|
D3081 by @rjg, with others.
|
|
Some of these API's can have 3D versions, explicitly name them 2D.
|
|
Was intersecting same triangle twice.
|
|
Use more watertight and robust intersection test.
It uses now ray to triangle intersection, but it's all fine because segment was
covering the whole bounding box anyway.
|
|
some hair is overlap.
Just using same code for distribution for face/volume as the one
changed/used for vertices since some months.
Note that this change is breacking compatibility, in that distribution
of particles over faces/volume may not be exactly the same as
previously.
|
|
Regression from rBfed853ea78221, calling this inside thread worker was
not really good idea anyway, and we already have all the code we need in
pre-threading init function, was just disabled for vertex particles
before.
To be backported to 2.79.
|
|
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
|
|
|
|
|
|
As pointed by Brecht, previous fix in rB61b49de44940 was actually incomplete,
we could still hit float rounding issue and hence same value in more than one consecutive
items of element_sum.
New solution is a bit different, we remove the 'minimal weight' check, and rather simply
ignores an item when the sum of its normalized weight to previous item's sum does not add
anything. Shall be safe and 100% effective this time!
|
|
rB046adde64f16 was actually pretty useless (and broken), since issue ends up not being
in binary search code, but in generation of the 'summed weights' array used to distribute
particles over mesh items - looks like very small weights could lead to null accumulated
weights, wich was breaking binary search.
Fixed simply by adding a minimal, non-zero weight for mesh items to be allowed to emit particles.
Hopefully we are done with this distribution mess!
|
|
Optimization in binary search could lead to equality instead of expected strictly greater than value.
Harmless but noisy, and better be strict here.
reported by sergey on irc (with koro cycles benchmark file), thanks.
|
|
Own stupid off-by-one regression in rB019ce363b01bba0afe1 and later...
|
|
Own regression from rB019ce363b01bba0af, not totally sure why removing the heading
zero value in element_sum broke binary search distribution in random branch, but...
New code makes thing sooo much simpler, by simply getting rid of all zero-weight
items in element_sum (at the cost of adding a temporary extra index mapping array),
that way neither random nor 'even ordered' distribution code has to wory anymore
about skipping zero-weighted items!
|
|
|
|
Also do proper intial/final checks to avoid adding particle on zero-weight extreme items,
instead of using cheap tricks like 'small offset'...
|
|
Previous fix made another issue even more visible, leading to +1 particle on first vert
and none on last one. This commit should fix both original and new issues.
|
|
When non-random, particle distribution used a small start offset (to avoid
zero-weight faces), which is fine with "continuous" entities like faces, but not
for discrete ones like vertices - in that case it was generating some undesired
"jump" over a few verts in case step was small enough
(i.e. total number of verts/particles was big enough).
|
|
rB201d3938622.
|
|
Now only fix correct handling of use_modifier_stack for grid distribution,
fixing it globally breaks all existing edited hair systems. :/
|
|
This reverts commit 2bd3acf7cd27c0c3ee77b10d56b91c3b03226d39.
Commit is valid in theory - but in practice, it means nearly all edited hair systems
would need to be re-created from scratch... Not nice, so better revert and note in code
that particle distribution is ugly and does not respect 'use modifier stack' option in most cases.
|
|
Disclaimer: this is tentative fix, seems to be working but you never know with particles.
If issue arise, we'll just revert this commit and hide 'use modifier stack' option
for grid distribution instead.
This commit also try to make choice of which dm to use during distribution more generic
(deduplication of code), again hopping not to break anything. :P
|
|
The issue was caused by fix for 31017 which resulted in some
missing intersecitons recorded which screwed inner/outer checks.
This is an old bug, so didn't bother with forcing re-distribution
to happen on file open to avoid possible other regressions.
|
|
location.
It also fixes another issue (crash) related to symmetric editing.
Quite involved, we (try to!) fix complete broken logic of parts of particle code, which would use poly index
as tessface one (or vice-versa). Issue most probably goes back to BMesh integration time...
This patch mostly fixes particle editing mode:
- Adding/removing particles when using generative modifiers (like subsurf) should now work.
- Adding/removing particles with a non-tessellated mesh (i.e. one having ngons) should also mostly work.
- X-axis-mirror-editing particles over ngons does not really work, not sure why currently.
- All this in both 'modes' (with or without using modifier stack for particles).
Tech side:
- Store a deformed-only DM in particle modifier data.
- Rename existing DM to make it clear it's a final one.
- Use deformed-only DM's tessface2poly mapping to 'solve' poly/tessface mismatches.
- Make (part of) mirror-editing code able to use a DM instead of raw mesh, so that we can mirror based on final DM
when editing particles using modifier stack (mandatory, since there is no way currently to find orig tessface
from an final DM tessface index).
Note that this patch is not really nice and clean (current particles are beyond hope on this side anyway),
it's more like some urgency bandage. Whole crap needs complete rewrite anyway,
BMesh's polygons make it really hard to work with current system (and looptri would not help much here).
Also, did not test everything possibly affected by those changes, so it needs some users' testing & validation too.
Reviewers: psy-fi
Subscribers: dfelinto, eyecandy
Maniphest Tasks: T47038
Differential Revision: https://developer.blender.org/D1685
|
|
Part of patch D1670 by @LazyDodo
|
|
Distinguish between line / line_segment
|
|
|
|
|
|
|
|
greater than 256.
|
|
Added some guards to prevent clumping to non existing particles. Also, adjusted threaded child path evaluation, so each child is evaluated once - previously virtual parents were done twice.
|
|
This was never working for threaded distribution.
|
|
|
|
to prevent double-freeing/invalid mem access.
This can happen with the "virtual parents" feature, which generates both
parent and child paths. Each task free function also freed the shared
context, leading to double freeing.
|
|
distribution code.
|
|
|
|
by type.
Instead of squashing totally unrelated code into the same monster
function.
|
|
easier.
This code is badly broken and needs to be replaced, but at least having
a workable code structure might help with quick hacks to fix the worst
cases.
|
