Sop Solver Problem

[B.Walters]

I'm trying to use the SOP Solver to cut holes in a torus with a Cookie SOP and a particle network (simulated in DOPs). It's not working.

sopsolver.hip

What makes it interesting, if you go into /obj/dopnet1/cook_torus/ and unbypass the polyreduce1 SOP then, jump back into DOPs (and bypass, unbypass any DOP node to force a recook), and hit play - you'll see the simulation is successfuly reducing the geometry of the torus.

Also, if you play through the DOP simulation, then jump into the cook_torus SOP network and play it, you'll see the torus have the appropriate holes cut into it.

Any ideas as to what is wrong?

[bensimons]

Hey B.

I took a quick look at it.

Firstly, IMHO, it's waay too complicated. You should simplify it first -

especially if it's not working... Especially if someone's going to take a

look at it! :-)

I un-wired the sop-solver for starters, and took a look at the pop/rbd

part. Lots of sops were removed: the fractal sop, the polyreduce sop, the

copy (stamp) sop. I made the sphere sop just a regular 0.1 radius sphere

(get the idea...?). I changed the location1 pop to birth just one particle.

It seemed like the polyreduce sop was just triangulating the doughnut.

The same could be done by simply spec'ing "triangles" on the torus sop,

and get rid of it. But this is not right - it turned out to be more subtle

than that! More on that in a minute.

A better pop collision result was achieved by un-checking "Fix Signs"

on /obj/dopnet1/torus (in the Collisions->Volume tab, where it calc's the

SDF). Not so sure about the sense of this change, but that's what worked.

Anyways - that kept the torus from disappearing. It spins on the y-axis when

hit by the particles. Nice.

The rest took some nutting out - the bottom line is I think the point count

must not change: and that was the problem. The cookie sop would change

the number of points in the geom when it cut a hole. Damn huh?

In the hip file (attached) I put in a bunch of switches in DOP's for

experimentation. One switch pins a 3rd constraint (to stop the torus

turning - so you can see what is happening - or not happening!). The other

switch swaps between two SopSolver Dop approaches - the other is the "demo"

(modified for this case) which uses a MAGNET SOP. Note that the magnet sop

doesn't change the point count (nor prim count for that matter. heh.).

Note the way the geom is brought in on the Object Merge with a "Stamps"

expression! A careful read of the Doc's for the SopSolver Dop reveals the

useful expression (there's a kind of feedback/stamping needed, in backticks):

`stamps("../TORUS_OUT", "DATAPATH", "../..:torus/Geometry")`

Pressing the Reload Button on the DOP's Viewport is needed a lot during

experimentation. It doesn't alway go yellow when the there's been

user-changes to the SopSolver's sopnet "cook_torus". The torus just disappears.

I tried a resample sop in "cook_torus", with the rough idea of trying to keep the

same number of points after the cookie sop. I didn't really work out. There's probably

another way to keep the geom consistent. Like.... Errr... a PolyReduce SOP

(wo hoo!). My guess is the PolyReduce SOP was (for a time) keeping the

geom consistent (point count, etc). In the hipfile You'll see I also experimented

with the "Number of Polys" option in the PolyReduce SOP, but the changed geom

didn't seem to get passed back in via the sop solver. Oh well.

Hopefully the attached hip file is useful.

cheers,

ben.

sopsolver1.hip

[B.Walters]

Thanks ben - I'll take a look!