It’s a very interesting and complex problem.
While this technique of slicing will work in most cases, it will fail with some concave geometries.
Also VoroFrag fails fragmenting and keeping the normal of some not so complex geometries, as it seems to use this technique or a similar one.
As far as I could test, all problems are related to sliced geometries where the result has two or more loops of open edges one enclosing the other, building a closed concave volume.
VoroFrag doesn’t preserve specified normals. It’s easy to see by applying it for example to geosphere with all normals broken.
something like:
delete objects
with redraw off
(
global g = geosphere segments:3 isselected:on
norm = Edit_Normals()
max modify mode
addmodifier g norm
norm.Break selection:#{1..norm.GetNumNormals()}
converttopoly g
)
VoroFrag rebuilds normals and messes with them after that.
addmodifier g (VoroFrag())
Yes, I’ve found the same thing. Perhaps its a bug.
(
delete objects
node = converttopoly (tube smooth:on sides:10 capsegs:1 heightsegs:1)
polyop.setfacesmoothgroup node #{2, 6, 10, 14, 18, 22, 26, 30, 34, 38} 0
addmodifier node (vorofrag numchunks:10)
)
it’s not a bug. they just do everything without taking in consideration that normals might be specified. (Klvnk knows what i’m talking about that’s why he asked MCG followers to show any trick with specified normals handling (preserving))
Ok, give a try to RayFire Voronoi modifier and see if it also fails. The demo version has a fully working modifier.
BTW, I am sure Klunk knows what you are talking about. That’s why he would be in my Santa wish list if I had to recruit developers. And so are you, Rotem, Bobo, and the list keeps going on.
i think that rayfire and vorofrag have different and absolutely unrelated developers.
BTW, I am sure Klunk knows what you are talking about. That’s why he would be in my Santa wish list if I had to recruit developers. And so are you, Rotem, Bobo, and the list keeps going on.
it’a a very good team
My bad then. I thought they both whre developed by Martijn van Herk. Nevermind, forget what I said, but if you want you can give RayFire Voronoi modifier a try. It seems to do a very good job.
i would appreciate any evaluation of the rayfire. the tool and the pipeline look very solid and powerful. as i know it has pretty long development history, and everything looks fished out.
but i’m very interested to know what it doesn’t do well, what was missed, and all about what could be done better.
the task is kinda touched me… there are several algorithmic and topological puzzles which are challenging me.
the biggest one is to find where “cheese” and where “this cheese holes” (SOLVED)
the second one is to preserve normals (SOLVED)
and the third one is to make it works fast (IN PROGRESS)
A few things I can think of but I dont have much experience in this field and don’t know if they are possible with these plugins.
[ul]
[li]Relaxed tessellation[/li][li]Control over the relaxation[/li][li]Surface (only) Voronoi tessellation[/li][li]Multi-fragmenting with custom set of points[/li][li]A new Shape class for multiple connections (long awaited)[/li][/ul]
Unfortunately the Delaunay tessellation (Garment Maker) does only works with shapes.
[Pulldownit]( http://www.pulldownit.com/) seems to have a more comprehensive set of tools for fracturing.
(
delete objects
node = box()
addmodifier node (VoroFrag numChunks:50 selInFaces:on )
converttopoly node
polyop.deletefaces node node.selectedfaces
polyop.createShape node (polyop.getopenedges node) smooth:false name:"holo"
$holo.render_displayRenderMesh = true
$holo.thickness = 1.0
delete node
)
RayFire is much more powerful then pulldownit
i’ve watched all demonstration videos from http://rayfirestudios.com/ … it can a lot.
the only thing is probably not very well handling of normals.
rayfire is fast… it’s about 10 times faster than i have now. but my current solution is about 50-50 of built-in and custom code. probably rayfire makes 100% of slice, cut, and cap itself.
for example… there is built-in MeshCapper… but i found its slow. and wrote my own. my is about 10 times faster than built-in.
so there is now way to get the same performance as rayfire by using pure built-in max solutions.
it shows once again that the MCG is the poor man’s plays.
the performance doesn’t really bother me. there is no really difference between 2 secs and 10. both are not real-time.
i’m not sure that something cool can be made by easily playing with a modifier’s parameters.
so 2 and 10 secs don’t make difference in this case
I really don’t think this technique of slicing and capping is the best approach for real time solution.
RayFire Voronoi performs quite well up to 500-750 chunks on my end. Not real time, but pretty comfortable to work with.
If you gather the topological data from the Voronoi modifier, Rebuilding a mesh with 500 chunks including SG, MatID, etc. takes around 80ms in MXS so perhaps finding a fast algorithm to build the Voronoi cells data would make it much faster than slicing and capping.