I’m working on an animation in which a ripple travels through a hemisphere of hexagons in which a crack progressively grows from a focal point over the course of several ripples, and then a section of the dome explodes in, then gets sucked out.
It’s not working like I think it should. I have the hexagons living under a standard Fracture object, and that’s influenced by Spherical and Delay effectors to create a ripple. I then have that Fractured group living under an R19 Voronoi Fracture that has two distribution sources, one to break the overall field of hexagons and another that concentrates smaller fractures along a strip within that group. Because I want the strip to live within the overall group I am NOT creating points per object.
I have Autoupdate Animation activated. The manual says:
If the Voronoi Fracture object has a clone-generating object as a Child object, which in turn is animated using Effectors, this option defines if the animation should be taken into consideration by the Voronoi Fracture object (option enabled) or not (option disabled). The former is very render-intensive, i.e., slow, and can therefore be disabled. Note that clicking on the Update button will not update the animation.
This makes it sound like if I have Autoupdate Animation activated I should be able to move my hexagons with the effector and the Voronoi fractures will be “remembered” as the hexagons within it are moved. That’s not happening. As the hexagons start being effected I can see the fracture facets jumping from frame to frame, as if the hexagons are moving THROUGH the Voronoi Fracture. When I attempt to use a Rigid Body simulation with this setup it doesn’t work right.
The only way I’m able to get this to behave the way I expect is to use Create Points Per Object. Set up that way my hexagons will ripple and the simulation will work properly because the Voronoi Fracture isn’t jumping from frame to frame while its Fracture object is being effected by the ripple. This works regardless of whether Autoupdate Animation is enabled. The disadvantage is I have less control where my points are concentrated in my overall field of hexagons. To get many small fractures I have to break EVERYTHING up, and that really slows things down. I suppose I could use multiple Voronoi Fracture setups, one for my strip of many small pieces and another for the bigger ones.
Is there anything I’m missing?
Thanks.
Shawn Marshall
Marshall Arts Motion Graphics
I can’t seem to attach the scene file, so here’s a link:
Without a scene file, it is kind of difficult to say. I was stopped the first time trying to understand your set-up when I read “Spherical Effector”. What is that? I assume a spherical falloff?
Do the points of the Voronoi ripple as well, otherwise that would make sense if not (that things become awkward), that the fracturing seems to be un-impressed by the previous fracture.
The next stop is with the Rigid Body. Dynamics comes AFTER MoGraph. Sorry, you can certainly see how it was set up, and each detail is on your screen. I don’t have that. So, I would have to guess and the guesswork with each possible iteration of possibilities becomes larger.
I’m not even certain, are the “hexa” shapes shaping the crack, or is it a mixture? Too many questions. As in: The whole object has to be broken, how about Geometry Glue?
Let me know if you share a reduced file, which reproduce all the problems. (Reduced as in, no lights, no third party stuff, etc)
I have a link to my scene file at the bottom of the post.
In my earlier tests I found that if I apply an effector directly to a Voronoi Fracture hierarchy all of the individual fractured parts ripple independently. They should retain their hex shapes while the simulation knocks out chunks of them. Adding a connector object at default strength doesn’t keep the pieces together as they’re effected.
Thanks for the file, that allows for so much more clarity.
I see some conflicts here, and I need a little bit more time, but just to address some points. In hope they will help me to understand more your targets.
• All the Source elements are independent from the scene, they stay static. Hence the huge change while they are moving
• The MoGraph Selection will change with the fragmentation to a certain degree.
• Dynamic Trigger “On Collision”, might happen already with the wave
• Geometry Glue might help to reduce the complexity.
• Effectors might be better added later, not in the Fracture.
I have to check if a split of the set up might help, or if a different approach might be more helpful, as in a weight map based on the Sphere object (Collision Object).
I’m not sure what I’m looking at in your scene file.
Let’s ignore for now the Dynamics Simulation and the Mograph selection and all of that. To me the main issue is forcing the Voronoi Fracture to “stick” to its underlying hexagons while they ripple. The only way I’ve been able to make it do that is to apply the fracture points on a per-object basis. Applying the fracture points across the group results in the fractures jumping around once the effector starts moving them.
Thanks for generating these sample scenes; I appreciate your help. Sorry for the delayed reply.
I think iteration 32 is the closest to what I’d need. In my current mockup I’m putting the cloned hexagons under several Voronoi objects. I have a strip of hexagons in a Fracture object being broken into smaller pieces in one Voronoi with the surrounding field being broken into fewer, larger pieces by a different Voronoi. The resulting scene is very slow.
I’ll play around with putting the Voronoi fractured elements under a Fracture object like you’ve shown. It might turn out that once I get the number of fractures/pieces I want that the scene’s going to slow to a crawl regardless of how it’s organized.
When it comes to baking this would you suggest cacheing the dynamic simulation or generating a Mograph cache?
You’re very welcome, Shawn, thanks for the feedback.
The set up with the single Voronoi per object is something that works, but that leaves much to desire. Hence my search for other options, as in creating the hexa-globe (…_42.c4d) in a procedural way. Not ideal and not simple, either, so the search hasn’t stopped. One thing that I haven’t shared was the idea to create the “point source” in the same way as the hexa-child objects, so they stick. But I have no options that each child -combination is not interfering with the neighbor child, as in splitting it.
Caching or not. Typically caching is better, more stable and more often than not faster. I do my tests via the Attribute Manager> Mode>View Settings> HUD: Frames per second. Which isn’t a 100% indicator about the later renderings of course, but it allows for some kind of evaluation.
Yes, you are spot on, to find the exact “hexa-child-objects” that need to be crumbled, to be more efficient. If the “crash” into the hexa-globe is fast, perhaps there is a way, to switch from pure hexa-child, to a mixed set up (hexa and some voronoi fractured hexa). Sounds perhaps cryptic, and yes, I have to explore it. The core idea being, in the moment the Cloner switches, the object is created and the dynamic starts.
Yes, that “locked into” excludes an area of exploration.
FPS, yes, nice.
The Dynamic Cache includes only dynamically information. The MoGraph Cache adds all attributes of a clone, e.g., color. The dynamic cache will not trigger the MoGraph Cache to be written.
I tried to find a simpler and faster set up, but the set up below seems to fulfill all the requirements and is (kind of) reasonable in terms of time investment.
To get all the Voronoi Object in the correct position, I “inherited” all the information first, which I have documented in the screen capture clip. For this clip (reduced to one minute) I needed all in all not even four minutes.
The scene file contains a set up for Dynamics as well, to see if the work pays off at all
… and another one, Shawn, this time a completely different approach. As usual ( at least I try), I like to provide different approaches, so everyone following along has more options or can at least chose. This one took only a few minutes to create.
First I create that hexa (and “quint”) kinda “planet” with a script (recorded with the Script Log., so I have it in a second)
Secondly, the soft shape of the elements will be created, to come as close as possible to your example.
Then the Formula Effector is used for a quick “motion” check.
What follows then is the use of the “Explosion FX”, fast and simple.
In the scene file (not in the clip), I have added a sphere as effect, but it has no function other than to be visual.
Thanks for these new iterations, sorry again for the delayed reply. As often happens I’m under a deadline crunch and can’t respond immediately. It’s a cool project that will run at an installation at Coachella, but the clients are throwing a lot of tricky scenes at me that aren’t exactly in my wheelhouse. I’m a bit freaked out.
I ended up doing the ripple through a MG Fracture that lives under a Voronoi Fracture which is what gets blown up. The source in the latter is set to Create Points per Object so the Voronoi pieces don’t change as the ripple moves through it. The setup is slow, but not intolerable.
Thanks a lot for the feedback, very nice of you.
Please don’t you worry about the delay.
Sounds like a great place to have your work shown, Coachella! Great!
I haven’t given up, and I don’t know why this didn’t worked before, I tried it and had no luck.
(Edit, it turns out that a hard drive had a problem -the power adapter- and switched off temporarily. Moving to a different disk solved all problems. /edit)
So, I do not got the dynamics working as single “chunk-dynamic”, but there is a way. What works directy, is this set up: Parent Voronoi, then Child Fracture, then single elements, while the Fracture is moving. As requested.
The Dynamics in file …MGpp_11.c4d is XPresso driven, with a selection. So, my suggestion would be to have several MG-Selections with more and more selected and in that sequence they get animated in the Dynamics Tag. See file …MGpp_12.c4d which is cached already
The file …MGpp_01.c4d is without dynamics, but just to get the set up demo’d, Create Points Per Object. Again, no idea what happened early. The …MGpp_11.c4d is really slow for me here.
I hope that will safe some time
Let me know if there is a question, I happy to look into it.
All the best
P.S.: (yeah! 12:16am) … here is the XPresso set-up to get the dynamics working. It checks now each and every single “Voronoi” chunk and if the distance is right, it triggers for this chunk the dynamics. I hope that gives you now everything you need to get the initial set up working in the way you like.
Note: With a MG Selection, based on the Fracture Object, the Voronoi Fracture could be limited to the needed parts only.
