| Age | Commit message (Collapse) | Author |
|---|
|
The formula used to compute the bend did subtraction of two big numbers
to get the position. Changed to find the delta and add that,
by rearranging the formula into a more numerically stable form.
Reviewed By: mano-wii, campbellbarton
Ref D11074
|
|
This fixes T87666 and T83252.
The boolean modifier and geometry nodes can depend on the geometry
of an entire collection. Before, the modifiers had to manually create relations
to all the objects in the collection. This worked for the most part, but was
cumbersome and did not solve all issues. For example, the modifiers were not
properly updated when objects were added/removed from the referenced collection.
This commit introduces the concept of "collection geometry" in the depsgraph.
The geometry of a collection depends on the transforms and geometry of all
the objects in it. The boolean modifier and geometry nodes can now just depend
on the collection geometry instead of creating all the dependencies themselves.
Differential Revision: https://developer.blender.org/D11053
|
|
Under some circumstances, modifiers are evaluated more than once.
One time to compute the actual output geometry and another time
with `MOD_APPLY_ORCO`. This design probably has to be revisited
at some point in the context of geometry nodes. However, that would
be much more involved than a bug fix.
The issue was that during the second evaluation, the node tree is
evaluated based on a slightly different input geometry. The data
generated during the second evaluation overwrote the cached
data from the first evaluation, resulting in incorrect data that is
shown in the spreadsheet.
The fix for now is to simply not log any data in the second evaluation.
|
|
The `bisect_distance` in the mirror modifier was hard-coded to `0.001`.
This would result in some unexpected behavior like vertices close
to the mirror plane being deleted or merged.
The fix now adds a parameter to the mirror modifier to expose the
bisect distance to the user. The default is set to the previous
hard-coded value to not "change" previous files.
Ref D10201
|
|
Some curve modifiers (namely Hook, SoftBody and MeshDeform) can only work
on pre-tesselated spline points.
Before the modifier UI refactor in rB9b099c86123f, users would get the
'Apply on Spline' option, but disabled and with a tip explaining why
this cant be changed. After rB9b099c86123f though, this button was
always enabled [but disfunctional] leaving the user without an
explanation why this has no effect.
Now restore this functionality since it is quite important information.
Additionally, this button now appears to be ON in these cases which
makes more sense from the user perspective (so it does not represent the
actual setting on the modifier -- this would internally be switched ON in
the modifier calculation anyways though, see
'curve_get_tessellate_point')
Differential Revision: https://developer.blender.org/D11029
|
|
|
|
|
|
This has technically been fixed by rB3e87d8a4315d794efff659e40f0bb9e34e2aec8a,
but the fix there is questionable, because it disables an optimization for vertex groups
entirely. This fix is a little bit more precise in that it only disables the optimization when
the object is used by some geometry nodes modifier.
|
|
This refactor simplifies having standalone function pointer that
does a single conversion. It also speeds up implicit type conversion
of attributes.
|
|
|
|
This introduces a context path to the spreadsheet editor, which contains
information about what data is shown in the spreadsheet. The context
path (breadcrumbs) can reference a specific node in a node group
hierarchy. During object evaluation, the geometry nodes modifier checks
what data is currently requested by visible spreadsheets and stores
the corresponding geometry sets separately for later access.
The context path can be updated by the user explicitely, by clicking
on the new icon in the header of nodes. Under some circumstances,
the context path is updated automatically based on Blender's context.
This patch also consolidates the "Node" and "Final" object evaluation
mode to just "Evaluated". Based on the current context path, either
the final geometry set of an object will be displayed, or the data at
a specific node.
The new preview icon in geometry nodes now behaves more like
a toggle. It can be clicked again to clear the context path in an
open spreadsheet editor.
Previously, only an object could be pinned in the spreadsheet editor.
Now it is possible to pin the entire context path. That allows two
different spreadsheets to display geometry data from two different
nodes.
The breadcrumbs in the spreadsheet header can be collapsed by
clicking on the arrow icons. It's not ideal but works well for now.
This might be changed again, if we get a data set region on the left.
Differential Revision: https://developer.blender.org/D10931
|
|
The fact that geometry from instnances isn't realized when applying
a nodes modifier can be very confusing, especially for new users.
Nodes themselves realize geometry instances implicitly whenever they
need to. We also currently make instances real and convert points to
mesh when a modifier is added after the nodes modifier. With this
commit, we simply do the same thing when applying the modifier.
There are a few downsides though:
- This can be an extremely heavy operations in some cases where
geometry nodes is used to instance heavy geometry.
- We will still have the issues with materials, since instances use
materials from their original objects, but real geometry uses
materials from the modifier object.
It was decided to live with the potential performance downsides
for now, the idea is the upsides of the change are more important,
and people making complicated setups will be more likely to know not
to apply the modifier. In the future there could be a warning if it's
necessary though.
Ref T87083
|
|
With this patch, users can define custom tooltips for the exposed
properties of their Geometry Nodes Groups.
Currently this custom tooltips are only used in the modifier panel,
but its a long term goal to use it in the node editor.
Reviewer: Hans Goudey
Differential Revision: https://developer.blender.org/D10884
|
|
|
|
Some object types don't have a geometry component in the depsgraph.
Before, there always was a warning printed when such an object was
used in the object info node (e.g. to get its location).
|
|
This is a minor change to add some plumbing code
to support custom geo nodes. This is working the
same way as the custom cycles and compositor nodes.
An example add-in is attached to D10784
Reviewed By: JacquesLucke
Differential Revision: http://developer.blender.org/D10784
|
|
Previously only attributes of "real" geometry were displayed in
attribute search. This commit adds code to look through attributes
on instances and add those to the search drop-down too.
This required implementing the same sort of recursive traversal as
the realize instances code. The situation is a bit different though,
this can return early and doesn't need to keep track of transforms.
I added a limit so that it doesn't look through the attributes of
too many instanced geometry sets. I think this is important, since
this isn't a trivial operation and it could potentially happen for
every node in a large node tree. Currently the limit is set at 8
geometry sets, which I expect will be enough, since the set of
attributes is mostly not very unique anyway.
Fixes T86282
Diffrential Revision: https://developer.blender.org/D10919
|
|
The problem was that you could getting write access to a grid from a
`const Volume *` without breaking const correctness. I encountered this
when working on support for volumes in the bounding box node. For
geometry nodes there is an important distinction between getting data
"for read" and "for write", with the former returning a `const` version
of the data.
Also, for volumes it was necessary to cast away const, since all of
the relevant functions in `volume.cc` didn't have const versions. This
patch adds `const` in these places, distinguising between "for read"
and "for write" versions of functions where necessary.
The downside is that loading and unloading in the global volume cache
needs const write-access to some member variables. I see that as an
inherent problem that comes up with caching that never has a beautiful
solution anyway.
Some of the const-ness could probably be propogated futher in EEVEE
code, but I'll leave that out, since there is another level of caching.
Differential Revision: https://developer.blender.org/D10916
|
|
Previously, the spreadsheet editor could only show data of the original
and of the final evaluated object. Now it is possible to show the data
at some intermediate stages too.
For that the mode has to be set to "Node" in the spreadsheet editor.
Furthermore, the preview of a specific node has to be activated by
clicking the new icon in the header of geometry nodes.
The exact ui of this feature might be refined in upcoming commits.
It is already very useful for debugging node groups in it's current
state though.
Differential Revision: https://developer.blender.org/D10875
|
|
The issue was that where_on_path uses a resampled curve to get the data
from the curve. This leads to disconnects between the curve the user
sees and the evaluated location data.
To fix this we simply use the actual curve data the user can see.
The older code needed a cleanup either way as there were hacks in other
parts of the code trying to work around some brokenness. This is now
fixed and we no longer need to clamp the evaluation range to 0-1 or make
helper functions to make it do what we actually want.
Reviewed By: Campbell, Sybren
Differential Revision: http://developer.blender.org/D10898
|
|
|
|
The main goal here is to remove the need for a C API to the code in
`mesh_boolean_convert.cc`. This is achieved by moving `MOD_boolean.c`
to C++ and making the necessary changes for it to compile. On top of
that there are some other slight simplifications possible to the
direct mesh boolean code: it doesn't need to copy the material
remaps, and the modifier code can use some other C++ types directly.
|
|
The old path that didn't skip the conversion to and from BMesh for
the exact solver was not yet removed from this file. At this point no
problems have came up in the new implementation, so it's safe
to remove it.
|
|
This commit improves the performance of the node by up to 40% in some
cases when there are only two input meshes, mainly by skipping the
conversion to and from BMesh.
When there are more than two input meshes (note the distinction from
"Geometries", a geometry set can have many mesh instances), the
performance is actually worse, since boolean currently always does
self intersection in that case. Theoretically this could be improved
in the boolean code, or another option is automatically realizing
instances for each input geometry set.
Another improvement is using multi-input sockets for the inputs, which
removes the need to have a separate boolean node for every operation,
which can hopefully simplify some node trees.
The changes necessary for transforms in `mesh_boolean_convert.cc` are
somewhat subtle; they come from the fact that the collecting the
geometry set instances already gives transforms in the local space
of the modifier object. There is also a very small amount of cleanup
to those lines, using `float4x4::identity()`.
This commit also fixes T87078, where overlapping difference meshes
makes the operation not work, though I haven't investigated why.
Differential Revision: https://developer.blender.org/D10599
|
|
Differential Revision: https://developer.blender.org/D10857
|
|
The node tree evaluator now calls a callback for every used socket with
its corresponding value(s). Right now the callback does nothing.
However, we can use it to collect attribute name hints, socket values
for debugging or data that will be displayed in the spreadsheet.
The main difficulty here was to also call the callback for sockets in
nodes that are not directly executed (such as group nodes, muted
nodes and reroutes).
No functional changes are expected.
|
|
needed
The geometry nodes modifier did not specify that it needs all custom data layers.
Therefore the modifier evaluation code tagged some layers so that they will not be
copied later on by calling `mesh_set_only_copy` in `mesh_calc_modifiers`.
|
|
When boolean's Object also has a modifier that depends back on
the target Object, a crash occurred.
In a case like this, BKE_modifier_get_evaluated_mesh_from_evaluated_object
returns NULL, so just have to protect against that case.
|
|
Previously this was only supported within nested node groups.
Now it is also supported for the root node group that is referenced
by the modifier.
|
|
Fixes an unreported issue that vertex data on large ngons (>255)
is messed up due to type conversion to char and back to int.
Ref D10734
|
|
Python
Previously, the code expected the id property to have the `IDP_FLOAT` type.
However, when assigning a Python float (which is a double internally)
to an id property, it would change the type to `IDP_DOUBLE`.
The fix is to allow both types in the geometry nodes modifier.
|
|
UI hints should only be modified when the depsgraph is active.
Otherwise two threads evaluating the same object in different depsgraphs
can conflict with each other.
|
|
This was included for `FILE *` which isn't used in the header.
Ref D10799
|
|
|
|
For example, it would crash when connecting a float to a geometry socket,
under some circumstances.
|
|
|
|
|
|
The information is not exposed in the attribute search yet.
|
|
This patch adds multi-input support to the Attribute Remove node.
Reviewed By: Hans Goudey
Differential Revision: https://developer.blender.org/D10698
|
|
I had done some experiments to see what Fast boolean did for material
mapping and thought it just used the same slot in the target as the
slot in the source. The truth is more complicated: if the target material
exists in any slot of the destination, we need to remap to whatever
slot has the matching material. I fixed Exact Boolean to do this.
Since the materials may be in the object, this means that BKE_mesh_boolean
had to get another argument, the remapping arrays.
I will note that the current behavior of Fast, and now Exact, is not ideal.
Ideally, if the source material does not exist in the target, a new material
slot should be created in the target and the source material copied there
(and incrementing the material's reference count). Maybe a future project,
but for now, I want the behavior of Exact to match that of Fast.
|
|
|
|
|
|
Note, this does not allow users to connect the same socket more than once to
a multi-input-socket in the UI. However, the situation could still happen when
using node muting.
|
|
|
|
The crash would only happen when the output of the Join Geometry node is used.
|
|
A few changes to make this consistent with other modifier panels:
- Title case for UI labels
- Use property split (and therefore decorators)
- Declare sublayout variables after getting modifier info
|
|
projectors
Make this clear in property UI descriptions and deactivate aspect &
scale fields if no camera projectors are present.
ref T86268
Maniphest Tasks: T86268
Differential Revision: https://developer.blender.org/D10634
|
|
|
|
The commit rB6f63417b500d that made exact boolean work on meshes
with holes (like Suzanne) unfortunately dramatically slowed things
down on other non-manifold meshes that don't have holes and didn't
need the per-triangle insideness test.
This adds a hole_tolerant parameter, false by default, that the user
can enable to get good results on non-manifold meshes with holes.
Using false for this parameter speeds up the time from 90 seconds
to 10 seconds on an example with 1.2M triangles.
|
|
|
