Why does Glue Adjacent shelf tool fetch the object from the DOPnet

[magneto]

Hi,

 

I am not sure if you have noticed but the Glue Adjacent shelf tool setups a network that fetches the geometry from the DOP network, and causes a magnitude of issues regarding cooking. For example any change in the DOP network regardless of what it is, triggers the whole glue network in SOPs to be recooked from scratch. Playing the animation does the same every frame.

 

This reduces the interactivity significantly as Glue Adjacent Pieces tool is extremely time consuming. Playing the animation also takes a lot longer because of this.

 

I don't know if this is the best way to setup glue networks but the H13 Bullet masterclass files do not use this setup. They fetch the geometry to be used for the glue network directly from the object geometry in SOPs in unpacked condition, which is what I expected the shelf tool to do. Obviously this doesn't have any of the issues mentioned above.

 

But why do Glue Adjacent shelf tool creates a setup that's completely different than what's shown in the masterclass, that it creates a whole set of issues dragging the performance down the drain? Shouldn't the shelf tool use the same approach as it's more recent than the masterclass? I thought I could always count on the shelf tools to get a good starting point

 

 

Any clarification from the RBD masters would be appreciated

Edited February 26, 2014 by magneto

[Solitude]

I'm not sure what's different in the master class video, since it's been a while since I've dabbled with bullet, but from what I remember the idea was that you would typically fetch the geometry, build the constraint network as you like it, and then lock the constraint network (or cache to disk) on the first frame and use that so it doesn't re cook every frame. That being said, there are times where you might want to update per frame -- so maybe it shouldn't be the default, and perhaps they should include a timeshift set to the first sim frame and/or a cache node.... ?

[magneto]

Thanks Solitude, in the masterclass files, they fetch the geometry from the SOP geometry like you said and build the constraint from there. But there is no locking necessary as the geometry is static and doesn't trigger recooks.

 

From what I have seen in the video, you can modify the constraint network either in SOPs or using the SOP solver in DOPs. If I remember correctly the SOP solver method is suggested for "dynamic" changes to the constraint network.

 

If you have animated source geometry, then I think your constraint network will be recooked which is fine as it depends on it. But I don't know why you would want to bring the transformed pieces from DOP network every frame and recreate the glue network from scratch to then send it back to DOPs? Is that useful?

 

My impression was that could be accomplished using the SOP solver method.

[Solitude]

I think the sop solver method is indeed a bit more 'correct', if you are going to be deleting constraints, but they do mention in one of the older videos (

about 1hr 24min)  how working in a sop solver isn't quite as 'live' for feedback on what you're working with, (which if you've played around with sop solvers you'll kind of get what they're talking about), so they set it up in sops, then copied everything back over to sop solver after. I think it's more for deleting constraints.  I think one example of when you might need to constantly recook is like when you are constantly emitting rbds and need it to glue as it's created or something, but I suppose again that a sop solver setup might work there too... really though, it's not all that much different than going to sops and back. 

 

The thing I noticed in the new video, and after just opening Houdini and playing around was that the "overwrite with sop" on the constraint network is set to $SF == 1  which I'm assuming should only fetch the geometry once (minor testing seems to confirm that for me, as well as looking at the fact that it's an enable solver node inside the constraint network that is linked to that parm). However, if you are in the constraint network sop itself,  it definitely cooks every frame.... so if you aren't actively displaying the glue sop it should really only cook the one time.

[magneto]

Thanks Solitude, I haven't seen the old bullet masterclass because I thought that might be obsolete for H13. Will need to check it out

 

I know exactly what you mean about SOP solvers and prototyping in SOPs and then copy-pasting the nodes into the SOP solver was exactly what I was doing without even seeing that. I figure since the SOP solver in DOPs shows you nothing, there is not much to do.

 

Therefore modifying the glue network in SOPs seem to have more advantages than in DOPs. But if you change the "Overwrite with SOP" to 1, then it will trigger a complete recook every frame. That is if you are using the setup created by the shelf tool. If you actually fetch the geometry from SOPs for your glue network, then there is no complete recook. Only thing that recooks is whatever you are doing to the glue network afterwards such as deleting them, etc.

 

SOP solver method doesn't have this issue. Whatever you do inside it, doesn't recreate the glue network from scratch.

 

It gets very confusing though.

[Netvudu]

I agree with you Ryan. I also noticed  the different setup on the masterclass example files, and it also makes more sense to me. I would like to know the reason for this too...maybe it´s done this way in case you deform the geometry in DOPs (with other solver), and thus altering the initial positions of the points for the network?

Edited February 26, 2014 by Netvudu

[rayman]

Well it`s probably related with the way shelf tool is working. If you have several geometries each one in its own transform node all of them referenced to simulation, then the setup have to search for each piece`s path, then have to filter pieces by name from selection. It is easier just to fetch geo from dop and filter them by name. All inside one node.

Also, this way pieces have correct names and ids.

 

You can always merge pieces from sops. I prefer it this way and it works fine.

[magneto]

Thanks guys. I know a few other people who are having the same issues and can't figure out the right way. So the more people, the better

 

The masterclass file also merges multiple nodes from SOP network using a single merge node. I thought the shelf tool could do the same easily. Otherwise I feel there is too much dependency going on.

 

Right now I am just using the shelf tool and then replace the dopimport with an Object Merge.

[cwhite]

The main reason for this is to handle regular RBD objects. For those types of objects, the constraint network's 'name' point attribute references the DOP object's name, and so you need to set up the DOP network first before you can correctly build a constraint network (and if you change a DOP object's name, the constraint network must be recooked). It's also possible to adjust the initial transform of the object in DOPs, and so importing the geometry from the DOP network also handles that case correctly.

 

This generally isn't necessary for packed objects (unless you're adjusting their initial transform inside of DOPs), which is why I set up the files the way I did in the masterclass. For packed objects, the packed primitives' 'name' point attribute is used by the constraint network to attach constraints, which allows you to build the constraint network geometry without first setting up a DOP network.

[magneto]

Thanks Cameron, it's great to get your insight. That makes a lot of sense. I will use your method for RBD packed objects, and only use the DOP method for regular RBD objects. I really like the packed RBD approach. Thanks for giving us that

 

Just one question though: I can now understand that changing things in DOPs triggers a recook. But it happens even if you change things that do not affect the constraint network, such as the color of the Ground Plane. Is it because Houdini doesn't allow granular updates or is it because the DOP context doesn't have a good dependency graph? Because in SOPs, things only seem to cook when something like an expression, a node, etc depends on another node. So I assume it keeps a dependency graph. That's why I am wondering if DOPs do not have the same dependency system in SOPs.

[edward]

Just one question though: I can now understand that changing things in DOPs triggers a recook. But it happens even if you change things that do not affect the constraint network, such as the color of the Ground Plane. Is it because Houdini doesn't allow granular updates or is it because the DOP context doesn't have a good dependency graph?

 

In older versions, DOPs sort of bootstrapped itself in an ill-defined manner onto the dependency system but they've been mostly removed now. The problems currently stem from the fact that the basic dependency system isn't granular enough to precisely handle specific caching situations. In particular, when caching is used with dependency graphs that change with time. eg. Switch SOPs inside SOP Solver DOPs. If you modify something that is currently on the "inactive" branch of the Switch SOP, then the DOP network doesn't know that it has to invalidate the cache.

[magneto]

Thanks alot Edward. It helps to get these insights from SESI I hope these systems get more granular so we can see explosions of performance improvements all over Houdini. It seems SOPs are better at this than DOPs then, right? Because with SOPs, I don't remember seeing these issues of recooking when something unrelated is changed. I didn't pay attention to time dependent stuff in SOPs though.

[edward]

DOPs is special only because it caches over time. In SOPs, the two most common nodes which cache are the Cache SOP and the Trail SOP. With the Cache SOP, it never uncaches unless you explicitly tell it to. The Trail SOP however, tries to invalidate the cache if an upstream dependency was modified just like the DOP cache. So one can reproduce the same situation with the Trail SOP just like DOPs.