MSPhysics tests and questions
-
Shark body contact - and a little bit of water splashes.
I slowly reach my desired results through MSPhysics and small improvements of my scripting capabilities...
It would be desirable to be able to start the simulation at a specific frame (MS Physics calculates the model until then in "the dark").
In addition it would be fine if we could save to Replay, export to the renderer and start rendering at the end of the simulation with default settings automatically (in the case of time consuming simulations).
-
These are amazing! Well done
-
Thanks Rich
-
We are listening seagulls!
-
Oh yes! Sound is the next step. No problem with MSPhysics...
-
That's a fine piece of rendering, faust!
-
Thanks, Anton! This is a great piece of plugin!
-
-
I could not resist to render a new desktop background picture for my PC ...
MSPhysics, indigo RT (path tracing, 7 minutes), removal of the fire flies with image editor.
-
Happy Feet!
-
Test model as an example for large replay data stored in the MSPhysics 0.9.2 separate replay file.
The data are produced with onTouch and transforming various emitters to the touch points.
This principle is useful for other physics applications: tire tracks, landslides etc.
The advantage over the Particle effect is, that you can render it.
Please let the simulation run till frame 500 or longer, save Replay, exit the model, load it again and test what happens.
-
Anton, here a long time me nagging question:
How can I prevent that usually at the beginning of a simulation, transmitted Thruster objects rather accidentally fly into the air at an increased rate?
This initial speed exceeds the set Thruster impulse by several times and can lead to problems with the viewport.
Properties of the initial object are: non collidable, collision shape: Null, Thruster Controller: 30, Lock to Body Axis, Mass: 0.015
Also setting the non-collision per script at the start does not work (onStart { this.collidable=(false) }).
What is the reason for and what can I do to avoid this?
Thanks in advance!
-
How can I use joints or some other way to combine two or more groups/components to form a stiff structure so, that each will have different weight/density and the combined object's center of mass is correct?
My specific problem is that I'm designing a table that has wooden tabletop and steel legs. I'm testing different kinds of steel structures as the legs. Then I'm placing weights on the edges of the table to get some kind of an idea what weight would cause the table to tip over and modify the legs' positioning if needed.
I tried different kinds of joints, but they all seem to make the table to stand no matter what kind of weight I put on the table edge. The only way working so far for me is to use no joints at all, make the whole table a single component and set approximate weight that I calculate myself. But that will cause the center of mass to be incorrect and afaik affects the results of this simulation somwhat.
Any help is much appriecated, thanks!
-
Edit: Duplicate post, see my question in next post.
-
Please post your model (reduced, without textures, scenes, stiles etc.) and we will find a solution.
-
Thanks for the reply faust07. Here's one of my designs, reduced, I hope
Table design to test what weights cause table to tip over -
In this case it seems to be the right approach to take all the parts into a component.
Joints are possible but not very helpful here. (You could test it with the "Fixed" Joint)
What I've changed:
Table legs and feet broken down into individual subcomponents. Then the collision geometry is more accurate. You can see it if you activate Collision Wireframe in Debug Draw in the MSPhysics UI.
The base plate I have assigned the material Concrete and I have the axis position of the cube weights corrected in order to prevent that the parts sink into the ground.
The axes were far outside the cube. But I do not know whether this significantly affect the behaviour of the body.
The best way to prevent sinking is to increase the value for the material thickness (to 0.10) in the UI. Please test it.
-
Hi Anton, short question: how can I make up for the differences between controller and scripted input? With the same pre-set parameters why arise the differences in the results?
Model slightly reduced to test it.
-
Here is an approximation of the setting of a servo joint (oscillator) with controller or script.
The oscillation about 180° in both directions corresponds to the number pi in the script. Seems somehow to be logical ...
-
Hello faust,
Nice coding there. So, when you assign value via script, i.e
some_servo.controller=, the value is assumed as some angle in radians. Whenever, you assign it via controller, the angle is assumed as the angle in preset angle units, which are by default in degrees.Now, instead of iterating through all servos to assign their controller, a more reliable way would be to use a variable. Control the variable through script and change servo angle via controller. Here is what I mean:
onStart { @p3_head_osc = 30 set_var('wing', 0) } onUpdate { set_var('wing', oscillator(@p3_head_osc) * 30) }Paste this in the controller of a desired servo:
get_var('wing')Other than that, I'm amazed by your improvement in scripting. Keep it up!
Anton
Advertisement