MJV

Yes. I can't figure it out.

So I decided to test the above theory and it was much simpler said than done, and working with dynamics was much more difficult than expected. I used Xpresso to determine direction of travel and then place steps immediately in its path, and hoped that dynamics would take care of the rest. In practice dynamics doesn't really take of it as much as you have to take care to dial in just the right settings that make it work. Also I couldn't get the dynamics to work at all beyond a certain short distance range. For example the ball just stops dropping at the very end of this test render. Here is a link to the file if anyone wants to have a look at why the dynamics simply stop working after a short distance: https://www.mvpny.com/MusicBoxMV39.zip

Ok ok but how is the student version coming along in 2042? 😄

Hmm. It's an interesting project. I too have seen these online and wondered how it might be done. It seems like you would only need to generate an object immediately in front of the ball's path for every note, then no matter the shape of the collider or the direction of travel, the animation should work perfectly.

So, this is as far I got, the best result to date, using cloth and rigid body together without baking the cloth animation or other tricks. The video below explains it all. File here in case anyone else wants to have a go at it. https://www.mvpny.com/SolarSystemPracticalGravitySimMV54b33core.zip

Still working on this.

As you correctly noted, simulating real planets in space was not my stated objective. I chose this project originally to test rigid body-cloth dynamics in Houdini and just coincidentally became fascinated in the subject at the same time. Some of my Houdini friends here are already familiar with the project and my interest in it. I revived it to test the unified dynamics in Cinema-20024, but admittedly I haven't gotten it working yet because, in my findings, cloth and rigid dynamics share the same single damping value (which being unified would seem to make sense) but no way to offset damping for one or the other when, as in this case, sharing the same value doesn't work because it's either too strong for one or weak for the other. If you watch Why All Planets are on the Same Orbital Plane above, they show purely 3d simulations at the end, but use the cloth example first to help set up the detail to come . The nice thing about recreating a practical effect such as this marbles on cloth experiment is that you can compare results to your immediate physical environment. For example, we can compare the number of times the marbles orbit the weight in our simulation with how many times they orbited the weight in the classroom test, then compare how well the simulation conformed to the actual result.

Excellent! Thanks for your contribution. Did you use the grain packing method for the marbles? My Houdini subscription is currently inactive but I plan to resume it once Houdini r20 is released in November and I will definitely check out your file first thing then. I found your comment about damping particularly interesting because I tried the exact same thing in Cinema and could not make it work. In my case the cloth becomes unstable as soon as the damping is reduced to the level suitable for the marbles. No matter what I did the cloth became unstable, so it's interesting that it worked for you in Houdini, especially as they both seem to use the same underlying Bullet Engine. I think I will make a separate video to explore that more. I am particularly puzzled as to why there is no control of damping on a per cloth basis, as it seems to be the only real control one has over cloth, even though all cloth abviously is not the same or should behave the same.

This test shows how even in a computer simulation of a real world practical simulation, the theory about why all planets are on the same orbital plane and orbit in the same direction (reposted below) is the result of collisions cancelling out everything else until everything resolves to one orbit direction. Notice in the Cinema simulation how all the marbles are orbiting in the same direction by only the one third mark.

I faked the rigid body dynamics working simultaneously with cloth here.

Here is the file as far as I got with it so far. SolarSystemPracticalGravitySimMV43.zip I discovered that there is no way to do both the cloth and the rigid body simulations at the same time because of what seems like a limitation. Every cloth simulation I tried required a high damping value in project settings. So maybe a damping value around 12% at least to get stable and realistic cloth. The marbles on the other hand, in order to roll realistically (for longer than a few seconds) in this scene require a damping value of not above about .25%. Cache the scene after download for full effect:

I made this short screen recording to show how fast a cached file plays with the Octane Live Viewer open and well the motion blur renders even as the file plays.

Thanks. I remember I toyed with that a bit at the time but was a novice so may not have, probably didn't, set it up correctly, but I would be surprised if that worked with the efficiency needed for the expected result. I don't know for sure though.

Thanks. Not at first but aoktar over at OTOY Forum enlightened me. Once I cached the sim it works great and even much better than I expected, as I reported to aoktar. Once cached I discovered that the motion blur renders blazing fast and I can be seen clearly even while the file plays in the live viewer. It's freaking amazing!

Thanks for contributing. So the spheres in this animation are soft bodies with a shape match constraint. Yes?

In case any Octane users are reading this thread, I discovered yesterday that Octane render Cinema 2024 Beta cannot render motion blur when using the new rigid body dynamics. I've reported this to Otoy and hopefully they can fix it, but this throws a serious crimp in my plans to render this with Octane, as it's meaningless to have dynamics, no matter how good they are, that can't be correctly rendered. Test file attached below: OctaneMotionBlurMV3.zip

No not yet. What you see so far is all rigid body dynamics except that the net was deformed first as a soft body but then was converted to a hard body. Keeping the net as a soft body introduced too many variables at a time for me to know what caused what. Now that I have it basically working at least as a rigid body sim my next step is to try to keep the soft body. I'll post any results I get.

Here is what I have so far playing while Octane Live Viewer is active.

I got this far with the simulation after freezing a cloth deformed object and making it a collider. I don't have it working with cloth directly yet but I am still learning the basics. For example I just learned the secrete to getting the bearing balls to orbit a realistic number of times was setting the damping to zero. This is just a learning experiment to me so I don't mind sharing whatever I come up with and therefore attached is the file if anyone wants to explore along. SolarSystemPracticalGravitySimMV1.zip

Well well. The folks at Houdini FX seem to have some thoughts on this topic, and it appears they think weight does have meaning and is very relevant to a dynamic simulation being relatable to the real world: "Density is specified as kg/m3" That is just amazing clarity where Cinema offers none at all. Cinema's dynamic solver seems even more up to date than Houdini's current version 19.5, so it seems like just a nomenclature problem and not a problem of the solver itself. The issue for users is that it is not going to be easy for a Cinema user to make sense out of it conceptually unless real world units are used, or the mass value is described in terms of kilogram or pound weight. I guess kilogram makes the most sense because of SI units as noted in Houdini's description above. It's just not easy to relate anything to the real world unless mass is described in terms of weight and density is described in terms of weight per cubic meter.

This is a brilliantly concise summation of density and mass in Cinema. Cleared up a lot for me. If you give something a custom mass, the object does not get heavier (or more massive) with size.

Here is some interesting reading I found that addresses the question of Mass vs Weight https://physics.stackexchange.com/questions/161719/if-you-are-on-earth-are-your-mass-and-weight-the-same This answer near the bottom addresses the value of thinking in terms of weight instead of mass, even though they're not the same, they are enough.

You don't need a default gravity setting. Gravity is set in the project settings so no matter how or what it is set to, it is nonetheless always a known quantity.