Page MenuHome

Fix/Simplify curve object to mesh conversion
ClosedPublic

Authored by Hans Goudey (HooglyBoogly) on Sep 17 2021, 2:02 AM.

Details

Summary

This patch simplifies the curve object to mesh conversion used by the
object convert operator and exporters.

The existing code had a convoluted model of ownership, and did quite a
bit of unnecessary work. It also assumed that curve objects always
evaluated to a mesh, which is not the case anymore.

Now the code checks if the object it receives is evaluated. If so, it can
simply return a copy of the evaluated mesh (or convert the evaluated
curve wire edges to a mesh if there was no evaluated mesh). If the
object isn't evaluated, it uses a temporary copy of the object with
modifiers removed to create the mesh in the same way.

This follows up on the recent changes to curve evaluation,
namely that the result is always either a mesh or a wire curve.

The new code works in my own testing, and the automated tests
pass as well.

Fixes T91445

Diff Detail

Repository
rB Blender

Event Timeline

Hans Goudey (HooglyBoogly) requested review of this revision.Sep 17 2021, 2:02 AM
Hans Goudey (HooglyBoogly) created this revision.
  • Fix the problem with wire mesh conversion
Hans Goudey (HooglyBoogly) retitled this revision from Cleanup: Simplify curve object to mesh conversion (WIP) to Cleanup: Simplify curve object to mesh conversion.Sep 21 2021, 1:11 AM
Hans Goudey (HooglyBoogly) edited the summary of this revision. (Show Details)
Hans Goudey (HooglyBoogly) retitled this revision from Cleanup: Simplify curve object to mesh conversion to Fix/Simplify curve object to mesh conversion.Sep 21 2021, 1:13 AM
Hans Goudey (HooglyBoogly) edited the summary of this revision. (Show Details)
source/blender/blenkernel/CMakeLists.txt
481 ↗(On Diff #42130)

This creates a dependency cycles between libraries. While this is something what historically is used in many areas, this is an indicative of weak architectural design of Blender modules and the way they interact.

Why is there an entire module for a couple of functions? Why cant those be in the blenkernel avoiding dependency cycle?

source/blender/blenkernel/CMakeLists.txt
481 ↗(On Diff #42130)

The module is meant to contain higher level geometry operations: T86869: Create new geometry-kernel module

I was going back and forth about doing that, so thanks for having a stronger opinion, I will move it to blenkernel instead.

  • Update for conversion in blenkernel instead
Jacques Lucke (JacquesLucke) requested changes to this revision.Sep 21 2021, 6:52 PM

Generally looks ok, better than before. Got a few inline comments.

source/blender/blenkernel/intern/mesh_convert.cc
879

Where is this checked for exactly? Why wasn't this necessary before?

944

double free

970–981

typo (evalauted_object)

This revision now requires changes to proceed.Sep 21 2021, 6:52 PM
  • Merge master after committing move of curve to mesh node
  • Slightly change comment
Hans Goudey (HooglyBoogly) marked 2 inline comments as done.
  • Fix double free
  • Add more detail to comment
source/blender/blenkernel/intern/mesh_convert.cc
879

I added more detail to the comment. The function I removed from displist.cc did not assign evaluated data.
But it's better to use the same function here, since we are creating a duplicate fake object for evaluation anyway.

944

Thanks, good catch.

source/blender/blenkernel/intern/mesh_convert.cc
879

The comment on LIB_ID_COPY_SET_COPIED_ON_WRITE says that LIB_TAG_COPIED_ON_WRITE has to be set as well. I wonder if there is a better way that avoids this flag hackery. Wouldn't be the first time though. And fortunately, this object is very short lived, so it might not be too bad.

source/blender/blenkernel/intern/mesh_convert.cc
879

I think "must" in the comment for this flag should actually be "will", that seems to describe the behavior.
When evaluating temporary objects like this there will probably always be some hackiness. Maybe this whole area could change more in the future.

Jacques Lucke (JacquesLucke) added inline comments.
source/blender/blenkernel/intern/mesh_convert.cc
879

An alternative would be to create a temporary depsgraph only for this object and its dependencies. That should be possible without too much hackery. Might be overkill for now, but something to keep in mind in the future. Maybe write that in a comment.

I've only done that once a while ago while testing something with particle nodes, but I did some cleanup on the related api back then (rB6a4f5e6a8c399). One probably needs DEG_graph_new, DEG_graph_build_from_ids, DEG_evaluate_on_refresh, DEG_get_evaluated_object and DEG_graph_free.

This revision is now accepted and ready to land.Sep 21 2021, 7:43 PM