[Brian Jones]

with Thrausi type objects (a number objects in a Fracture as Thrausi does) to get something to fall dynamics have to be on but if it’s many pieces you have to leave dynamics on but turn off self collision until the first collision of the group with something. Otherwise the self collisions keep separating everything too early as you have seen. Since you have everything with it’s own tag that won’t work since turning off self collisions doesn’t do anything useful.

Place your piano objects in a Fracture object and apply an xpresso tag and feed the fracture object to a Dynamics Collision node as one of the objects then pass the Count from that node to the Dynamics tag/Self Collisions port. That detects the Fracture’s (and by extension any part of the piano) collision with anything in the scene that has a dynamics tag but isn’t the fracture itself since the other Object port is left empty.
The collision count stays zero until a collision happens so it can be passed directly to the Self Collisions of the fracture’s (the piano) dynamics tag and turns it on with the first collision since the Self Collision port is boole and is expecting 0 for ‘off’ and 1 for ‘on’. Fortunately when they were designing xpresso they let you put numbers higher than 1 in (in this case more collisions) and it still interprets it as a 1 so the self collisions stay on and it works like it should.

10610_stopprecollisionseparation.c4d.zip

[Brian Jones]

in Standard renderer shadow color is affected by Transparency color not Absorption color, in Physical it’s a combination of both. the Color Channel (if you are using it) doesn’t affect shadow color at all. So it’s a balancing act between the three places to enter color values. Depends on the renderer you are using

[Brian Jones]

in the Omni light’s Project tab you can set the Mode to Include or Exclude objects in the scene. Sounds like you want to exclude the floor but that depends on what your shadows are falling on.

[Brian Jones]

there was a plugin called rBoole which does booles by transparency. It stopped working in the Standard renderer a couple versions ago but was still working in Physical in R17 (and after a quick test) appears to be working in R18 as well. I don’t know if it’s stable or not but it was in R17.

[Brian Jones]

they do scale if you use the ‘scale’ User Data on the Controller Null – it’s because scale as entered in the Coords is as the Help says
“Modifying the scale of the object using this value equates to scaling in Use Object Axis mode, i.e., the object’s axis system will be modified (see also The difference between the Use Object Tool and Use Model Tool modes).”

If you scale the spline directly with the Object mode (rather than Model mode) it scales the clones too….

I haven’t had time to figure out if there is a way around that myself, perhaps you know…

[Brian Jones]

I wonder (without seeing the file) if the fix for a SubD/HNurb puckering the standard sphere top/bottom would work here too – that’s to add loops at the ends – https://forums.creativecow.net/readpost/19/888809

[Brian Jones]

you should be able to drag and drop an image from your content browser onto any one of the three Texture load buttons (that you usually click to go find a texture)

[Brian Jones]

look for MetaBall fluid tutorials – settings are very important in getting things to show so try a bunch and start small (small numbers of objects or spheres etc) to test what happens. It’s pretty slow though so that much detail (like in the example picture) is likely going to be an exercise in patience. Looking at it again this morning the example you are looking at sure looks like XParticles skinner object on a bunch of XParticles in a fluid sim

[Brian Jones]

that might be xParticles (plugin) but the same sort of thing can be done with Particles or Thinking Particles (with wind/Turbulence to shoe the bunch) emitting spheres (maybe – that’s not the only possibility) in a MetaBall generator. Can provide more detail later but look up the MetaBalls

[Brian Jones]

in your example file set the Priority of the Hair object to Generators 401

From the Help Dynamics/Tips and Tricks: “Internally, the MoGraph Dynamics’ Priority is fixed to Generators/400. Normally, this is a value that you will not have to change. If, for example, Dynamics should affect other areas (e.g., HAIR) the priorities will have to be modified (i.e. those for HAIR):

If objects moved by Dynamics should in turn affect HAIR the Priority must be set to 401.”