Hello,
well… i got… something operational regarding different voxel sizes, but it doesnt look right and is very slow… Probably i messed up the transforms somewhere or so… but committing for reference.
7 Likes
Damn, years ago I worked on a VDB particle mesher which was rejected, but if I had thought of other uses of OpenVDB for mesh processing we could have those features back then. Oh well, better late than never, I guess 
.
If the reprojection happens directly after some mesh->volume->mesh pipeline, I think we could save some CPU ticks by reprojecting or interpolating the mask data on OpenVDB’s side. The level set already encodes the distance and direction to the nearest surface point, so creating a BVH tree afterwards is somewhat redundant. The loops could also be run in parallel.
I don’t understand the purpose of having different voxel sizes if the grids are going to be resampled to the voxel size of the main one. Am I missing something? Anyway, your code looks correct, although you should try to clean up the level set after the resampling (look for openvdb:: tools::signedFloodFill, and similar functions). Perhaps also use pruneLevelSet, instead of Tree::prune().
You should keep in mind that the level set grid is only the discretization of a function defining the distance to the surface, so we have to keep the function as true to the ground truth as possible. Maybe this is going to fix some artifacts.
Finally, transformation of grids is always slow in VDB. Perhaps doing the resampling via openvdb:: tools::doLevelSetRebuild is going to be faster?
4 Likes
Hi KWD,
nice to see you again here
Well the purpose was to allow finer detail in certain places of the grid like the text engraving, while the other parts of the grid shall be coarser. Hmmm, like “inverted” adaptivity, instead of removing detail where unnecessary, adding more.
Thanks for the helpful info OpenVDB is still quite new to me, i am mainly poking around in their cookbook or api docs and stackoverflow etc, lol to find out what is done how. Gonna take a look at your hints right now
So is this going to be merged into to the 2.80 trunk?
No. 2.80 is in feature freeze. Perhaps it will be merged for 2.81 though.
3 Likes
Nice to see you here KWD, you have a lot of experience with OpenVDB, i remember your application you showcased. Really hoped we’d see that tech in Blender. Hope you’ll help to shape this into a masterpiece.
Perhaps either main voxel size serves as a multiplier to all (inverse of what we have) or latest voxel size by order of execution (top to bottom) is preserved as final?
////
I’m gonna go out on a limb here and ask for the ultimate solution for Blender since subject of fluids was touched and more exotic use is found.
Ideal stack would allow mixing Filters with Operands as such:
For fluids OpenVDB solution often allows Dilation first, followed by Erosion and Smoothing:
It helps make things more natural as well as tweak appearance of surface tension or viscosity without resimulating.
Link to realflow: https://support.nextlimit.com/display/rf2016docs/HM+-+(Mesh)+Filters
Houdini Filter section: http://cgstrive.com/SS/2_4132019_c38c.png
** For modeling ** it might be more elegant solution than having per operand voxel size? It would allow Using lower res (faceted) geometry and smooth it for Big rounded Bevels without artefacts (that remeshing with different voxel scale causes). Smaller details(such as the Text example) would be added after Remesh filter. The advantage of it is that artist cannot start with voxel size 0.01, second op 0.02, third 0.01 etc creating very inefficient stack.
For example here I’m taking relatively faceted cylinder and smoothing it strongly. Combining it with box and smoothing result to get nice bevel. On top of it I’m Combining TEXT(font) with lower voxel scale (higher reso). Such a workflow would allow creating any object with any rounded corners:
6 Likes
The live remesh toggle is super convenient. Thanks! 
:
I look forward to future functionality. This modifier truly is amazing.
I realize its a work in progress but I did want to point out that the faster it peforms, the more flexible it becomes in the modifier stack. While the static, ‘one time’, remeshing is supercool this modifier really shines with animated components.
By this I don’t mean its slow currently, just that any effort put into optimization won’t go to waste and will be hugely appreciated. 
1 Like
Hey,
hmm maybe the different types of stack items in this modifier sub-stack of operands could be better solved with nodes ?
I am also wondering whether it might be useful to have a dedicated volume object which has an own modifier stack or nodeset operating on volumes.
Brecht created some skeleton code for a volume object here for example: https://developer.blender.org/rB74f7cdcf6bb8032b6bf8881007e0344366849859
But there needs to be a clever way to convert this dynamically from mesh and to mesh again. Without too many clicks and too much clutter… like if you really had volume objects, and you need mesh, you would need to convert the type.
Or have atleast special modifiers accepting other mesh objects to populate the volume, and finally a “to mesh” modifier on the volume object which just returns the modified mesh without type changing the volume object… Hmmm… this would be needed to thought through carefully.
I can hardly keep up implementing new suggestions or changing the implementation so it will be atleast partially compatible to before at this fast rate, lol 
Therefore, imho, its better to have the “complete” design on the table first 
Or atleast a complete set of requirements, to not forget anything important.
8 Likes
Understandable. Your remesher is already above all expectations. These subjects do need a lot of thought and planning, just throwing out ideas.
I’m personally a bit skeptical about Nodes. I do 95% of modeling in Blender for simple reason nodes are very clunky and slow to use as well as hard to understand for many. A layer like stack as in AE or systems in Modo, C4D are bit more elegant.
Regardless I agree that a dedicated volume object would be useful. Especially if it lets me load .vdb from other applications as Realflow or Houdini (clouds, fire, smoke, whitewater etc). Currently this is a massive headache! Perhaps KWD can chime in on this.
Once again job done already is above all expectations. Thank you!
3 Likes
Has Ton commented about this? Will it be merged for 2.81 as this really feature that can make Blender almost comparable to commercial sculpting apps. If anyone knows if Ton commented about this please post here, thanks.
Are there any plans to improve the baking system as well? I know it’s not part of the sculpting system, but it is used alongside it all the time. Right now baking in 2.8 is largely unusable due to lack of displacement baking and is the only thing I go back to 2.79 for. An updated baking system would be of immense benefit to everyone who sculpts in Blender.
Not that I know of. I’m not saying it will certainly be merged for 2.81. I’m just saying it certainly won’t be merged for 2.80.
1 Like
I have noticed that with Voxel Remesh, no matter how much you soften the faces with the brush, they look bad when the model is Normal Smoothed. It can be corrected with the Smooth deformer, but I think it should not be necessary.
That’s a failure of the smoothing brush algorithm, not the remesher. This is the reason that ZBrush has two smoothing modes, one activated with Shift+click, one activated with Shift+Click+Release Shift. One is meant for general smoothing, the other was added specifically for smoothing when using dynamesh.
4 Likes
Nice work man ! Are we seeing the original on left, remeshed on right ?
Thanks mate…
Nah, they are both the same remeshed model, with two different matcaps just for fun.
I sculpted this guy using only the voxel remesh workflow, to see how it compares with zbrush’s dynamesh, and so far, it works really well… 
6 Likes
I updated the build so the different voxel sizes on operands is working, but according to the commit it not optimized.
12 Likes
this is seems to going into the right direction,cant wait for the final polished version.thanks for the build uploads.
i have made a reference setup for a head sculpting (front and side backround reference with 30% visibility on top)
a fresnel shader like in zbrush would be nice,there you can set the visibility through the shader itself.
i have subd the cube with ctrl 5 and applyed.then i scaled the mesh to around 0.2 meter like a real scull has.if i now go to dynotop sculpting with constant detail,i have to set the detail to around 150 or more to get a rough start.
if i left the mesh at is,without scale, i need only a detail of 20 or so. i find it difficult to sculpt with this scale,but i think it should make no difference, if you want to start sculpting, with the same size the object (head) has in real.maybe i have overseen something? ofcourse i applied the scale (ctrl-a).
About volume objects, I think it is long overdue. I worked on one back in the days, Brecht also made some fundamental work in this area.
Although level sets could be sculpted directly (and Blender could have a volume sculpt mode if it had a volume object), generally speaking, volumes are inherently procedural and it is best to have a node system to build or process them. The modifier stack is far too limiting here, and currently it seems people are trying to cram as much OpenVDB/volume functionalities into a single modifier, which does not please me. Perhaps scattering the functionalities across modifiers could be better, more acceptable for a merge in master (like putting the boolean operations in the boolean modifier).
IMHO, nodes are the go to for such volumetric based workflow, but unfortunately the current “Everything Nodes” are not suited for the task as their abstraction will not allow for volume to mesh operations to occur right in the middle of the graph. It could allow to modify voxels or vertices in parallel, but not heavy topological changes to the object being treated (this was the same issue with Lukas Toenne’s system for those who remember it). So, let’s not put too many “random” functionalities in one modifier, since a more capable node system will not be here for a long time.
As for C4D, it seems to me that it is a node system in disguise : it is using a hierarchy of objects to express the final result, which is basically what nodes are (think of node connections as being parent/child relationships). It seems like a halfway point between a modifier stack and full blown nodes.
12 Likes