Hello all,

I know this topic was covered before at one point,
but I thought I'd try again.

I think animating geometry and recursively running it through the “Cookie” sop is about as cool as it gets.

There are a few lingering problems though that I can't seem to get around.
I thought I'd pick the accumulative brain of the forum, offer up my ideas, and see if there isn't a way to make this coolest tool work properly (when animated) for production purposes.


The scenario so far:
3 spheres same amount of points (frequency 6), animated translation, different scale. Three cookies total.

“Sphere 1” stationary, while “sphere 2” bashes into it with animation and a cookie is pulled as a “A minus B”, so “Sphere 1” gets a hole cut in it.
“Do Jitter” is set on the “Cookie”.

From here a “Clean” sop is used to help the normals and polys be legit.
Down the chain, “Sphere 3” is introduced and animated-bashes into the first cookie.

The 2nd cookie is also set to “A minus B”, with “do jitter”.
A “Clean” is used afterwards as well.

ok here are the problems.

1) I would have thought that the “Clean” sop would have taken care of any occurrences of reversed normals on the cookies, but it doesn't. There are frames here and there where the intersecting surfaces created still have inverted normals.

2) Even with “Jitter” on or off, there are moments where the surface does not calculate properly. In fact there are frames where the geometry disappears altogether.

ok here are some solutions I've come up with.

1) Render out the first “Cookie” as .bgeo, bring that in as a “File” sop. Then pull the next cookie.
This tends to make things more stable, but still not ideal surface wise.
That and the “Preceduralism” and creative interaction is destroyed.

2) Get everything working and then on a frame by frame basis animate the “Jitter amount” starting from the top of the chain. Huge pain in the butt.

Any ideas?
Is this just a matter of the limitation of the tool?
Basically… am I just asking too much from this tool?

Even worse problems when doing it on Nurbs with the “Surfsect” sop.

thanks

All my best

Jim

For whatever it's worth, when I tried this, I found that you need to be careful to also ensure that:
- Consolidate Edges is enabled so that points are fused
- You can only cookie between two disconnected pieces of geometry

For what I did to make sure these conditions are satisfied, you can look at my file from odforce: http://odforce.net/forum/index.php?showtopic=3472&view=findpost&p=23173 [odforce.net]

What it does is recursively make cuts using a noisy grid via the SOP Solver DOP. It does this by maintaining a stack of the disconnected pieces of geometry. At each frame, it pops off exactly one piece from the stack, performs a single cookie, and then pushes all the newly disconnected pieces (2 or more) of geometry onto the stack. I think there are sometimes still unexplained cookie failures so I think it's inevitable that you will need to keyframe some of the jitter values.

Hey Edward

thanks for the link to the Hip file.
I'm eager to check it out at length,
and will comment on it.
It'll take a bit of time to deconstruct this,
but I will.

As far as the “consolidate edges” is concerned:
I find that it really tends to messy up the edge of the connecting surfaces.

To fix this I tried these options:

1)In OBJ in “Render” tab
Geometryolygons as subdivision surfaces
This helped some, but still pretty rough.

2) Also tried subdividing in sops,
same result just one happens at render and one happens in sops.

If I dig around perhaps I can come up with a solution for this problem (hopefully in sops)

thanks again

Jim

here's a hip file where I was screwing around with this.
I actually got it working exceptionally well!
There is a bit of a trick.

You'll need to render out your own “.bgeo” files (in the “rop_geometry”/rop output driver), and then place the proper path in the “file” sops in order to get this to work.

I've attached a .hip file, but let me break down what I found out.

Cookie 1: Large sphere as input 1. Multiple spheres that animate (but must never intersect each other), ran into a merge. Cookie is pulled as “A minus B”. “Jitter” is set once, with no keyframing! The normals even seem to be happy.

Cookie 2: Here I want to geometry to intersect with the holes in Cookie 1.
If I just do it off the last cookie (cookie 1) it seems to be unstable. If I render out the .Bgeo files for cookie1, and then read them back in as a “File” sop to input one of “Cookie 2” then things are quite stable.

This technique is repeated with a “torus” for cookie 3.

It takes rendering out .bgeo files (oh well),
but this is no longer such a big deal because a “merge” sop can be used as the second input of a cookie,
as long as the geometry going into the 2nd input never intesects with each other. Intersection might not be such a problem if the cookie was not animated

Jim

I can't think of offhand why saving to disk and then reading it back in will make it more stable. Since you're writing out .bgeo's, I would expect no precision lost even. Which frames are “unstable” when you wire them directly? I only have access to Apprentice at the moment so no ROP outputs.

a “merge” sop can be used as the second input of a cookie,
as long as the geometry going into the 2nd input never intesects with each other.

This seems to be a less restrictive constraint than the condition I impose which is to only ever intersect two pieces at a time (ie. one piece per input). However, I still strongly suspect that part of the problems that you would have encountered will be because without Consolidate Edges enabled, you can easily have different pieces that touch (ie. intersect) each other.

I'm not sure why you tried doing things with subdivision surfaces as that doesn't really have a bearing on the problem. One potential problem with it is with normals as explained in another recent thread [sidefx.com]. Since you used point colours, there are also only single points now that can only take on one colour value each.

One can easily fix this problem for Cookies though as jlait recently taught me. What you do is create a primitive attribute such that their values are different along the edges that are “cookied” or “cut”. Don't worry about the normals being messed up until the final output. Then you can recover the proper normals by using a PrimitiveSplit SOP to cusp those edges using this attribute.

I've attached an example of this using your file. I've removed the Point SOPs that assigned colour, choosing to procedurally choose primitive colours instead (ensuring that all the spheres using a different colour). This primitive attribute Cd is then used by the PrimitiveSplit SOP at the end to recover the hard edges. Sorry about the .hipnc file format though. To help you out, I've coloured all the new SOPs I added in yellow.

Nice!

Your use of the “connectivity” sop and “primitive split” sop was nicely done.
The “connectivity” (created “class” attribute) will certainly make grouping a lot easier as well.

I just had the point colors just thrown in there for display purposes.

As far as rendering out the .bgeo files…
you're right, it doesn't make any difference.
Perhaps it was my constant tweaking evoking imaginative distortion. ops:

My attempts with subdivision was just a quick dirty means at trying to smooth out the geometry from the “consolidate edges” in the cookie.
Your solution of the “Primitive split” seems also to take care of the rough edges created by the “consolidate edges” of the “cookie”.

I've added a new version of the file.
All new sops have been colored light purple.
There is a “switch” near the bottom of the chain to move between the stable version (Switch setting 0) of the scene,
and another version (Switch setting 1) with a new problems.

Switch 0:
I added another stationary sphere (non-intersecting for a total of 2 spheres) into a “merge”.
The merge is then wired into the first input of cookie1.
The second input of cookie1 is the same as before, 5 animated non-intersecting spheres.
So now both inputs have multiple non-intersecting objects in them.

I thought I had the makings of a “rule” here with working with animated cookies.

You can have as many sources placed into a “merge” for either input,
as long as sources inside a merge do not intersect.
Even with consolidated edges,
you still need to avoid having the source geometry of the merge “intersect” in any way.


Then I complicated things, and this rule started to break down.

Switch 1:
This takes the output of cookie2, creates two copies of it.
One copy is rotated, scaled and translated, so it sits slightly above and in front of the original copy.
A new cookies is pulled (cookie3) as an “A minus B”.
It immediately appears that no amount of “jitter” (on cookie3) can save certain frames here…
while others appear to be salvageable with multiple adjustments to cookie3 jitter.
However adjusting a frame that looks fine in “cookie 2”,
but not in cookie3,
can sometimes be fixed by adjusting cookie2 jitter.
So maybe it looks fine in cookie2, but really there are visually undetectable problems…
or maybe just closer inspection to see the problem is needed.
Either way, this jitter issue is has become more difficult,
because now in order to fix cookie3, you have to start playing around with other cookie sops jitter.
This is sad because there were some very promising results prior to cookie3…
even though it's only on spheres in this example.
Perhaps we're back to your original condition:
“ only ever intersect two pieces at a time (ie. one piece per input) ”
Which would be unfortunate.
I'll give it some more time, after I get some sleep.

With these experiments
I now feel like we're getting really close to nailing this one.
I know from past post that others were very horny for this as well,
but it was never resolved.
I think we're getting close here.

thanks
and again… nicely done.

Jim

Which frames are you talking about that have the problems in Switch 1? With all these random cookies, you could easily be running into creating degenerate geometry. You could try putting in Clean SOPs after each Cookie to help with that. Off the top of my head, that's the only reason I see right now as to why a jitter value in one cookie can affect how a downstream cookie works.

Personally, I think you're trying to push it too much with all these multiple pieces of geometry. What is the end result that you're trying to achieve?

Yeah I am probably trying to “push it too much”.

The “clean” sop doesn't really seem to help very much on each step of the cookie.
I'll have to give it closer inspection.

“As far as ”Jitter“ not helping,”
what I meant was that in certain cases you actually have to upstream and change jitter in previous cookies to make later cookies work.

“what is the end result I'm trying to achieve?”
Well, as far what has been happen happening here with this last example,
simply a test to try to stabilizing animated cookies and find out any limitations/rules,
so that the boundaries of the process are somewhat defined.

What I'm trying to achieve overall is:
1) Stable intuitive animateable sculpting tools that can be additive or subtractive,
that can use a wide variety of shapes.
Meta is nice as well, as well as the “brush/sculpt” tools but cookies have the potential to get the job done better.
Sort of like having a block of marble that you chip away at to create a piece of sculpture.
Now if each one of those “chips” can be animated and controlled procedurally,
then creative possibilities come rushing in.
Add to that the fact that animated “unions” can be done as well…

2) Recursion (aside from being a time saver) is great because with slight variation of a simple set of rules (placement, offset through time, etc.) you can get some very wild effects. Some natural looking, some other worldly. All done with objects that the user has visual feedback with throughout each step of the creation.

Hey Jim one other thing you might try is if you have two pieces or more geometry on the righthand input that may interesect you could try doing cookie union to remove the intersecting regions and then fuse points on those parts first before trying to intersect them with anything else.

Thanks for the tip Simon!

I'm going to chase this a bit more soon.
I'll post any of my findings here for anyone who might be interested.
Maybe even add some “user comments” in the help.

I also welcome/encourage anyone else playing around in this area,
to write their findings here.

I know this is an old thread, but I thought I might throw in some advice that seemed to work well when I animated a cookie through some fairly complex geometry.

If you have some complex geo (say, a car) and you want to “eat away” at it using a cookie, you'd need a few things first.

1. The model should be watertight (closed, welded verts, etc) and poly normals should all be facing the correct directon. Higher res models, though slower, tend to work better. Also, use the “Facet SOP” to convex geometry and triangulate it. I find this is better than the “pre-convex” option in the cookie. You can also use “Bricker” here to add res.
2. Using the connectivity->partition, create a group for each connected piece using something like “piece_$CLASS”.
3. Now, use a copy/stamp loop to isolate each piece and let the cookie sop do it's magic. It works best when cookie'ing one piece against another, as ed mentioned earlier in this thread.
4. To clean up, use the “Clean SOP”
5. If this doesn't fix it, you'll need to keyframe the jitter. There's no way around this, really. You'll inevitably get some errant frames.

Hope this small brain dump helps someone out there!

-Frankie