Bullet, glue seems broken?

[MisterP]

Hi,

I've found a weird glue network behaviour where objects stop in mid air during the deletion of the glue network in sops.

It seems broken to me, or, if I've set something wrong, would you mind pointing me in the right direction?

I'm on 12.5.487.

Thanks for looking

MisterP

Edited August 9, 2013 by MisterP

[MisterP]

Help!

[Skybar]

In your Glue Network Constraint DOP, you have "overwrite with SOP" set to 1. So when the glue gets broken in DOPs by your sphere, the glue then gets re-imported from SOPs where it is still intact - and the pieces are glued together again, even if they have flown away a bit.

If you instead only overwrite with SOP on the first frame, $SF==1, it will work as expected. However, since you are breaking it in SOPs at a later frame, that then won't have any effect. If you want to only break the glue in SOP, then you can set your overwrite with SOP to 1 again - but you will have to set your Strength to -1, so it won't be destroyed in DOPs, and then it will work as expected.

The big problem here is that you are mixing destroying the glue in both SOPs and DOPs. Note that I'm not that familiar at all with this stuff, I only looked at your hip. There might be a way to mix this that I wouldn't know about, maybe with a SOP Solver or something, where you update the glue in SOPs with what happens in DOPs before the re-import.

[Hudson]

the name of your fractured pieces "baseTop1000*" does not match the default name precix "piece*" created in the glue-SOP. try matching those up. Because otherwise the strength on your prims wont be transfered. I can see that the strength off the "piece baseTop10000" is -1 in dops and 100 in SOPs.

[MisterP]

Thanks,

renaming from piece to baseTop in the gluepiece sop hasn't changed anything, the dop objects still inherit -1 strength.

Any ideas?

[MisterP]

Ok I sorted it.

Basically you need to do everything in the sop solver network and set $SF==1 so that the gluepieces network in sop is read only once.

Thanks for your hlep

[Hudson]

It should work with $SF==1 in this situation but if you add more complex animation or changing active/passive objects and changing strength attributes. the same issue might occur. And it is probably because of the name prefix. The name have to be exactly the same. It wont work just to change the name to "baseTop" since the pieces are baseTop0001 baseTop0002 ...baseTop0103... and so on. so the prefix has to be the same.

I am working on a pretty complex scene and I had the same problem. I can't only override the glue_Net_DOP at frame one so simply $SF==1 doesn't work for me.

I am glad it works for your test tho

[MisterP]

Yeah, I suspected something might still be wrong as despite the strength are behaving correctly the dop details lists strength=-1 incorrectly.

But I did change the prefix from "piece" to "baseTop" too. Are you suggesting that the gluepiece sop expect the prefix to all characters up to the first number other than 0?

I assumed that, having numbers to have 5 digits padding the prefix would be baseTop and the number 00001 00002 etc.

The reason for this is the ability to have pieces sorted by number.

I would incur in the problem of pieces sorted not correctly otherwise

piece1

piece10

piece2

....

whereas I would prefer

piece0001

piece0002

piece0003

....

This in order to be tidy and better sort a corresponding list of points in sop in conjunction with an active dop and the expression point("../SOP_WITH_MATCHING_POINTS",$OBJID,"Cd",0) to enable certain objects based on color.

One more thing, is it possible to mix different network glues?

for instance two sets of glued objects to another set of glued objects either in dops or sops?

I don't like the sidefx's implementation of this.

In proprietary solutions I have seen everything is prepared beforehand in sops, you have as many points as centroids of you chunks and the gluenetwork is built without worrying about dopobjectid, just class attribute.

Also I don't like the whole complexity and different way variables are handled and data manipulated in dop, it is a different logic to other contexts making things obscure and harder to manipulate

[Hudson]

I undestand why one would like to have a prefix such as piece0001. I agree with you that to manipulate data in DOPs is a bit tricky.

The main problem using several glue nets in the same simulation will be the fact the object ID will change every time you add och disable an object in dops. since the OBJID is added in dops and reads the objects from left to right it is difficult to simply add a $OBJID-value in a point-expression when you are trying to set active and passive pieces in a active value. You have also cook all the the glue nets in where you expect the objID have chsnged after you inserted a new object in dops or dissabled a node in dops. Thisbis the manual way of doing things.

The better way is not to use $OBJID to refer to a piece in SOPs. there is an expression combitation one of the supervisers where I am doing an internship showed me a few days ago. I dont remember it from the top of my head tho :-/

so yes it is tricky but there are workarounds

[MisterP]

Thanks Hudson, any chance of sharing that expression you mentioned? I'm intrigued

[mawi]

You are looking for the CopyInfo/copynum data.

dopoption($DOPNET,$OBJ,"CopyInfo","copynum") instead of $OBJID when referencing a "piece creation point" in a point expression.

activate.hipnc

[MisterP]

Thanks that's very helpful!

one more thing Hudson/Mawi, I've written another post about it, anyway I bumped into a basic issue where preanimated rbd chunks (deforming) behave erratically once unglued due to the deforming toggle being on.

Basically what the problem is, is that rbd pieces which break off glue should turn their deformation off, unless there's a better way to handle all of this?

http://forums.odforce.net/index.php?/topic/18142-bullet-workflow-questions-animated-passive-objs-etc/#entry110640

Edited August 27, 2013 by MisterP