Page MenuHome

New Voxel Mesher Modifier
Needs ReviewPublic

Authored by Martin Felke (scorpion81) on May 27 2019, 7:33 PM.
Tokens
"Love" token, awarded by slarti."Love" token, awarded by vklidu."Burninate" token, awarded by Pipeliner."Love" token, awarded by Torrent."Love" token, awarded by astroblitz."Love" token, awarded by Zen_YS."Love" token, awarded by harisreedhar."Like" token, awarded by Malkai."Love" token, awarded by joe_daniels."Love" token, awarded by 14AUDDIN."Love" token, awarded by Ztreem."Love" token, awarded by ZohaibAli."Love" token, awarded by weasel."Love" token, awarded by Debuk."Love" token, awarded by ReinhardK."Love" token, awarded by rbx775."Love" token, awarded by Zuorion."Burninate" token, awarded by pablovazquez."Love" token, awarded by Schamph."Love" token, awarded by jfmatheu."Love" token, awarded by dcvertice."Love" token, awarded by higgsas."Love" token, awarded by realeyez."Love" token, awarded by vitorbalbio."Love" token, awarded by tiagoffcruz."Love" token, awarded by Dragon.Studio."Love" token, awarded by Kubo_Wu."Love" token, awarded by HooglyBoogly."Mountain of Wealth" token, awarded by franMarz."Love" token, awarded by Muritaka."Love" token, awarded by nate066."Like" token, awarded by mankysee."Love" token, awarded by mistajuliax."Love" token, awarded by Peps."Love" token, awarded by blueprintrandom."Love" token, awarded by brilliant_ape."Love" token, awarded by MetinSeven."Love" token, awarded by amonpaike."Love" token, awarded by belich."Love" token, awarded by CodyWinch."Love" token, awarded by symstract."Love" token, awarded by juang3d."Love" token, awarded by Classycoder."Love" token, awarded by kioku."Love" token, awarded by ofuscado."Like" token, awarded by erickblender."Like" token, awarded by Dspazio.

Details

Summary

This patch adds an OpenVDB-based voxel remeshing mode and a metaball-based remeshing mode to the Remesh Modifier.
The Voxel remesh mode is taken from the sculpt-mode-features branch and the metaball remesher from the fracture modifier branch.
For now this is a combined patch since both modes affect the Remesh Modifier.
Putting this up in this form for reference only. I will probably split this into its two modes later.

Edit: i will let this in one mode, since particle and mesh voxelization is totally related, can share the CSG logic and creates less noise in the codebase, aka creating a new modifier is more disruptive.
The CSG logic is also helpful for particle meshing since you can for example cut away unwanted parts of e.g. a meshed sph simulation in order to have a fluid fit into a glass (without simulation overhead)

Diff Detail

Repository
rB Blender
Branch
arcpatch-D4960 (branched from master)
Build Status
Buildable 7423
Build 7423: arc lint + arc unit

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Fix build errors on Linux, quiet warnings.

Both functions are very useful. However particle meshing should indeed be a separate modifier and submitted as a separate patch. I guess ideally OpenVDB could be used for particle remeshing too, it's probably better than our metaball code in terms of performance and control.

The particle re-mesh is still part of this modifier, was there a reason not to move this into a separate patch?

@Brecht Van Lommel (brecht), you're working on a volumetric object type - which seems quite similar to this functionality. If this is going to be included soon - it would be good know which functionality from this patch will be duplicate.

It might make sense to to include as a "Volumetric Boolean" modifier only, leaving the meta-ball/particle logic for volumetric objects to handle.

Campbell Barton (campbellbarton) requested changes to this revision.Mar 13 2020, 5:49 AM

Code Review

  • Many unused arguments, now marked - should be used or removed.
  • References to dm (old DerivedMesh) should be renamed to mesh_eval.
  • Commented code left in which should be removed, or comment for why it should be kept (if it's likely to be used in the future... for what.. etc).
  • Code that converts meta-balls looks to have copy-pasted code left in, needs cleaning up.

Note that I didn't review the C++ openvdb changes.

intern/cycles/blender/blender_mesh.cpp
1036

*picky* spaces around comments, use sentences.

intern/openvdb/intern/openvdb_filter.h
35–37

Double check on using system defines, also, not all are used.

intern/openvdb/intern/openvdb_level_set.cc
264–278

Looks like operator overloading could be used here, otherwise include comment why it's not.

intern/openvdb/intern/openvdb_mesher.h
119

This comment doesn't give any context if the reader doesn't know houdini function, should be expanded.

120

May as well link to the code directly if you're including a URL.

source/blender/blenkernel/BKE_remesh.h
2

Should use existing BKE_mesh_remesh.h (perhaps issue came from merge, this was renamed in master).

source/blender/blenkernel/intern/mball_tessellate.c
1494

Why not use the vertex normal to calculate the rotation?

source/blender/blenkernel/intern/remesh_voxel.c
2

Should be moved into mesh_remesh_voxel.c or at least use the mesh_remesh_ prefix if this is to be a separate file for other reasons.

source/blender/editors/object/object_ops.c
272–275

Use OBJECT_OT_modifier_remesh_csh_* for these operators.

source/blender/makesdna/DNA_modifier_types.h
1616–1640

Use e prefix for enums.

1627–1661

This is getting a bit un-managable, would prefer if each of these had their own sub-struct, for RNA as well.

1670

Avoid using back-pointers as they become invalid, just pass this as an argument.

source/blender/makesrna/intern/rna_modifier.c
5356

use use_ prefix for booleans, also for other booleans listed here.

source/blender/modifiers/intern/MOD_remesh.c
550–576 ↗(On Diff #22763)

We have similar functionality already, eg:

  • Object's join meshes (operator).
  • Boolean's join meshes (modifier).
  • Edit-Mode can load meshes into an edit-mesh which merges custom-data.

Is there a reason existing custom-data functions can't be used?

If this is needed, it could be moved to the CustomData API, with an explanation how it differs from similar existing functions.

578 ↗(On Diff #22763)

Could also be made into a generic function in BKE_mesh.h.

This revision now requires changes to proceed.Mar 13 2020, 5:49 AM

Regarding the volume object, I think that is separate functionality. In the future we will likely have a node for converting a mesh to a volume, a node for doing volume boolean ops and a node for converting a volume to a mesh. But we don't have that yet, and even if we did this is still functionality we want to provide with an easy interface.

I still think this is putting too much in one modifier, which may be conceptually similar as a programmer but from a user point of view it becomes unclear. It being less work to implement is not an argument. I think the existing remesh modifier could get an OpenVDB mode without any of the boolean or particle functionality, strictly for the same purpose as it exists now. Maybe the parameters for that can match the sculpt remesh operator.

Then this can be a new modifier to generate a new mesh from one or more geometric objects. Those could be particles and meshes to begin with. Surfaces and text are also easy to support since they just output meshes. In the future volume objects would also make sense, and maybe curves and hair though that is less obviously useful. I'm not sure what the right name for that modifier is.

Particle trails should not be part of this modifier, that's something that should be left to the particle nodes to generate. Particle velocity scale also seems like it should not be part of this. Isovalue, bias and sigma are not good names or descriptions for properties, they need more user friendly names.

Regarding the volume object, I think that is separate functionality. In the future we will likely have a node for converting a mesh to a volume, a node for doing volume boolean ops and a node for converting a volume to a mesh. But we don't have that yet, and even if we did this is still functionality we want to provide with an easy interface.

I dont get what is not easy with having multiple operands for CSG ? Also, this is intended to do CSG in volumes (avoiding many of the pitfalls of mesh booleans, like selfintersections) and get a mesh from this. The only thing i see is maybe when having too many operands, the panel might get crowded. And, you dont have nodes yet... somewhen in the future. But quite a few users would like to have this volume-based CSG. There are many positive comments and hearts for it in the tracker, and it was tested by several users and they all liked it. And really nobody complained about not having separate modifiers for it. Imho its important that the feature is working and is accessible. All slick inside one modifier, conceptually grouped, thematically totally related. From a users perspective, it doesnt matter if there is a different modifier or a different mode in the same modifier. If then somewhen you have nodes, you can easily throw away the modifiers voxel mode if you dont want it any more.

Adding new modifiers causes relatively much more hassle, coding wise. And removing them later even more, DNA Deprecations etc. This is also for modes, but i think its still less intrusive.

I still think this is putting too much in one modifier, which may be conceptually similar as a programmer but from a user point of view it becomes unclear. It being less work to implement is not an argument. I think the existing remesh modifier could get an OpenVDB mode without any of the boolean or particle functionality, strictly for the same purpose as it exists now. Maybe the parameters for that can match the sculpt remesh operator.

I dont see what is better to have actually MORE work for a quite similar feature set. It is also less work to review, if it was less work to implement before.
And the voxel modifier without CSG doesnt make much sense to me. Why crippling a working feature... The modifier as it is has been tested by many users
and we didnt receive a single request to change a single thing in the ui or a single question about CSG operands. Basically everyone understood how to use it.

For example: https://twitter.com/bluefox_3d/status/1218436520387891200?s=20

Then this can be a new modifier to generate a new mesh from one or more geometric objects. Those could be particles and meshes to begin with. Surfaces and text are also easy to support since they just output meshes. In the future volume objects would also make sense, and maybe curves and hair though that is less obviously useful. I'm not sure what the right name for that modifier is.

See, it doesnt make so much more sense to make a new modifier for this and a new for that, if those are related sub-features of meshing. And as I said before, this is supposed to do the CSG in volumes, with the help of openvdb functionality. And why wait for the future, if you can get similar functionality right now, or atleast a good part of it ?

Particle trails should not be part of this modifier, that's something that should be left to the particle nodes to generate. Particle velocity scale also seems like it should not be part of this. Isovalue, bias and sigma are not good names or descriptions for properties, they need more user friendly names.

But it doesnt hurt the user if it is included. A valid point against it would be if it crashes or aint usable for some reason, but this could be fixed. Otoh, if it cannot be fixed feasibly, it still can be tossed.
And things are named according to what they are. Those are terms the users can get along with. Nobody from the users also complained about the names yet.

Brecht Van Lommel (brecht) requested changes to this revision.Mar 13 2020, 1:11 PM

Sorry but no, it does matter for usability if it's one modifier or multiple. And the naming must be better. We are not creating software for engineers, we are creating it for artists.

I don't care that it is more work to implement it or that no one has complained so far. We start from the design and usability, not from trying to do the easiest possible implementation. It's really not that hard to add a new modifier.

I did not ask to remove CSG from the modifier, that can stay.

@Campbell Barton (campbellbarton) @Brecht Van Lommel (brecht)

Ok, what about:

  • Creating a new "Voxel Mesher" Modifier which contains all of the current Voxel Mode of the Remesh Modifier, including particle meshing and CSG
  • Creating a new "Metaball Mesher" Modifier which contains all of the current Metaball Mode of the Remesh Modifier, including particle meshing (as alternative to the voxel mesher, it yields differently looking results)

In both modifiers, you would be able to mesh existing vertices(metaball) or volumes(voxel) respectively, at the same time as you could mesh particles. Both options can be enabled simultaneously.

or

  • Creating a new "Mesher" modifier, which combines Voxel and Metaball meshing as 2 separate modes. This would still be separate from the existing Remesh modifier, so it is not overcrowded with functionality.

Can't we just have a single Voxel Mesher? There shouldn't have to be a metaball mode, any features that has could be implemented with OpenVDB too?

So what's the final word? A new voxel mesher modifier?

CSG is a top feature. 👍

Hi there. This Patch seems to be very controversial when it comes to how to add the functionallity to the UI correctly.
May I just ask if you could split this Differential up into multiple parts (Add Sculpt Voxel Remesh to Modifier, Add Mesher for particles, Add Particle Remesher, ... Metaball stuff)?
Because it seems clear that the new sculpt mode voxel remesher should just be another option in the current remesh modifier (from an artist perspective at least). What to do with all the other functionallity should not stop that part from getting implemented. I'm waiting for that for a long time now.

For the other functionallity, splitting particle remeshing and voxel remeshing doesn't mean redundancy in the code. The code could still use the same functions. I think splitting it into Remesher/Mesher is what is the most intuitive thing. What Brecht is saying I think is, that he doesn't want that the old metaball code to be used, because it is no longer maintained or will be replaced or something like that. Your code could use OpenVDB instead. Correct me if I'm wrong.

Please hear to what the blender foundation says, because the developers there are really experienced and know how to make very good code and software. Remember, they want your contribution. For the naming of parameters in the UI, leave the decision to them if they disagree for a reason. I also had to do that with my Solidify Extension. I still think Simple/Complex Mode is not very descriptive, for what it does, but it's fine with me, as long as I can use it and artists are not confused (but it seems like still nobody knows what complex mode does).

@Henrik Dick (weasel) what you ask for is a ton of work, the development of this feature has been a lot of work, and the already requested changes means also quite a lot of work.

What @Brecht Van Lommel (brecht) asks of having a Voxel Remesher modifier it's acceptable, there are weighted reasons about it and several benefits, present and possibly future, it has it's downsides because a lot of work from @Martin Felke (scorpion81) will be trashed, we used the metaball particle remesher for fluids, but it's understandable that maybe with OpenVDB may be enough, that removal takes also some work, not as easy as deleting the "metaball" part :)

But the separation you are asking for means a lot of unnecessary work, there is no actual reason other than make easier to understand and read the patch, and keep in mind that @Martin Felke (scorpion81) is not a paid developer, he does this as a free contribution to all of us, and he has been doing this for years. I don't think he deserves to do unnecessary things after all the work he is and has been putting on this awesome feature :)

@Henrik Dick (weasel) what you ask for is a ton of work, the development of this feature has been a lot of work, and the already requested changes means also quite a lot of work.

It's not a lot of work to add voxel remesh to the Remesh modifier. The operator is already there for sculpting, it's a matter of exposing the same properties. The way it was implemented, the code is already easy to reuse for a modifier.

Not saying that @Martin Felke (scorpion81) has to do it. Just that any developer that has worked on modifiers should be able to get that working quickly.

So, but the voxelremesh operator lacks CSG functionality, filters, as well as texture / material transfer, and the preserve Hard edges support. And not yet speaking of the ability to mesh particles. Should this be part of the operator then too ? So both the modifier and the operator can share a common codebase ? Either way, I disagree here that is just a little bit of work. I would estimate it is not rocket science, but not too trivial either.
Means I just need a bigger slot of time in order to do the required changes. Not sure whether other devs could do this faster, because they would need to read their way thru the code on their own or ask me for help in order to accelerate this a bit.

@Henrik Dick (weasel) what you ask for is a ton of work, the development of this feature has been a lot of work, and the already requested changes means also quite a lot of work.

It's not a lot of work to add voxel remesh to the Remesh modifier. The operator is already there for sculpting, it's a matter of exposing the same properties. The way it was implemented, the code is already easy to reuse for a modifier.

Not saying that @Martin Felke (scorpion81) has to do it. Just that any developer that has worked on modifiers should be able to get that working quickly.

This is the part I was referring to:

(Add Sculpt Voxel Remesh to Modifier, Add Mesher for particles, Add Particle Remesher, ... Metaball stuff)?

The Voxel Remesh from @Martin Felke (scorpion81) is not the same as the Operator one, but Martin has already explained this, it has way more work than just the remesh operator. :)

I created this patch which includes only the basic voxel remesh functionality in the remesh modifier. This way it should be easier to start adding these features to master D7292

What I am saying we should have is:

  • Voxel Mesher modifier for OpenVDB voxel meshing, including support for CSG and particles.
  • Remesh modifier with a new Voxel mode, that matches exactly the functionality already available in the voxel remesh operator, nothing more.

Both can be improved independently. If it helps they can share code under the hood, but that's not a requirement.

If the voxel remesh operator (and modifier) can get improved handling of hard edges and attribute transfer, maybe sharing some code with the voxel mesher, that would be welcome. But those kinds of things can be done incrementally.

@Pablo Dobarro (pablodp606) First, thanks for your help :)

But wasnt the new "goal" now to have the voxelremesh functionality in a new, separate voxel remesh modifier ? Putting it into the remesh modifier is what I already implemented.

@Martin Felke (scorpion81) Yes, but I only added the basic options that are already in the sculpt mode operator as a remesh mode as @Brecht Van Lommel (brecht) suggested. Now what is left is to move the rest of the features to a voxel mesher modifier.

But wasnt the new "goal" now to have the voxelremesh functionality in a new, separate voxel remesh modifier ? Putting it into the remesh modifier is what I already implemented.

The idea was to have one Remesh modifier that is for remeshing the object itself, to create a clean and even topology. Same purpose as the remesh operator and existing remesh modifier.

And then another Voxel Mesher modifier for the purpose of generating a new mesh from one or more geometric objects. Which to begin with would be meshes and particles, but could be extended to other types of geometry in the future (pointclouds, volumes, metaballs, ..).

Move to separate Voxel Mesher modifier, in case this would have taken a lot of time.

From quick testing I think these things should change:

  • CSG operands should use a standard list widget with +-<> on the side, and settings for the selected item below.
  • CSG operands could also just be renamed to Objects. Less technical name and really it's just a list of objects to use as input which may use CSG or not.
  • Don't change settings on objects used as CSG operands, editing a modifier on one object should not modify other objects.
  • Use checkbox icon rather than eye icon for enabling CSG operands.
  • Use text for percentage and Sync Voxel Size options, the icons make little sense.
  • Mesh and Particles don't have to be separate modes. Allow adding both meshes and particles in the objects list and make it a setting per CSG operand, since it's useful for e.g. combining a water surface and water droplets.

@Brecht Van Lommel (brecht) Should I commit the basic voxel remesh more in D7292 or are we going to continue the development using this patch?

@Brecht Van Lommel (brecht) Should I commit the basic voxel remesh more in D7292 or are we going to continue the development using this patch?

You can commit D7292. Development of the Voxel Mesher modifier can continue here. They're separate features.

Brecht Van Lommel (brecht) retitled this revision from New Remeshing Modes for Remesh Modifier to New Voxel Mesher Modifier.Mar 31 2020, 7:00 PM

Move to separate Voxel Mesher modifier, in case this would have taken a lot of time.

Hi :) Thanks for helping out with this. I have a few questions for some of the points you mentioned.

  • Don't change settings on objects used as CSG operands, editing a modifier on one object should not modify other objects.

Do you mean the automatic change of the object viewport visibility here ? aka setting it to Bounds ?
This could go again, yes.

  • Mesh and Particles don't have to be separate modes. Allow adding both meshes and particles in the objects list and make it a setting per CSG operand, since it's useful for e.g. combining a water surface and water droplets.

You can already shift select both modes and combine them. (for the "main" object "carrying" this modifier).
Would it be ok to leave it as is for the main object ? Additionally I would add that as per Operand setting, too.
This way you could work with multiple particle systems, or combinations of meshes and particles.

Do you mean the automatic change of the object viewport visibility here ? aka setting it to Bounds ?

Yes, that's what I meant.

You can already shift select both modes and combine them. (for the "main" object "carrying" this modifier).
Would it be ok to leave it as is for the main object ? Additionally I would add that as per Operand setting, too.
This way you could work with multiple particle systems, or combinations of meshes and particles.

Shift-click is too hard to discover. Could we have the self object as the first item in the list always, with setting to disable but not remove?

Just in case anyone else was wondering what CSG is, here is a link:

https://en.wikipedia.org/wiki/Constructive_solid_geometry

  • attempt to perform all review related changes

hrm, i better should NOT have rebased my arcpatch branch to master before... lol... now there are unrelated changes in here as well (weld modifier stuff, curve stuff etc)
but the wiki docs regarding arcanist and arc diff (aka updating your diff) recommended that.

Any news on this?

Good question. I've noticed that currently in the 2.9 alpha the voxel setting is in the Remesh modifier, but unfortunately without all the useful settings that previous graphicall builds had for smoothing and filtering of the voxel data. I'm curious to hear what the plan is for this incredibly useful update to the Remesh modifier. Hoping to see it come to an official release soon :)

What about the CSG options? It's the best Boolean system we have in blender for many applications.

What about the CSG options?

AFAIK, they are part of this patch too. So if this thing moves forward, we'll have it. 🤔

I was hoping to see this in 2.83. 😒

I was hoping to see this in 2.83. 😒

This build has a working version of the CSG voxel mesher in 2.83, Im looking foward using it on 2.90 tho,
bw even if its not in its final form, the modifier on this build works fairly well.

https://blender.community/c/graphicall/kdbbbc/

What about the CSG options? It's the best Boolean system we have in blender for many applications.

By and large, when a Boolean was simply impossible by any other means, even by Zbrush which has a fairly robust Boolean system the CSG
operations of the Voxel Mesher always worked, Im really looking forward to being able to use it on 2.90 so I dont have to jump from the
build of 2.83 where it works at the moment to 2.90, as I sculpt in 2.90 but I do some Booleans on that custom build as well, however is nice to have all your
tools on the same build.