I think I know what's going on. It could be that when installing MSPhysics some files failed to overwrite. I suggest you delete MSPhysics and AMS Library from the plugins folder and do a fresh install. The details are listed in the main post.

Hello, Daniel,

I'm currently working on 1.0.0 and it may address this issue. So, you can wait a bit until I release it. But so we're sure it's fixed, I would appreciate if you PM me the model that causes that.

Regards,
Anton

Alright, thank you! I assume it's all legal unless I'm planning to write a new softwate/app.

I'm planning to write a plugin for SU that I will sell.

The plugin will use SO/Bundles compiled with visual studio and xCode.

I have a couple of questions, regarding permissions and rights:

1. Do I need a Pro SU licence?

2. Do I need a non-free Visual Studio licence for the SOs?

3. Do I need a non-free xCode licence for BUNDLEs?

I could use free versions but not sure if it's legal for commertial plugin purposes.

Thanks

Hello, Bert,

@delchrys said:

Ultimately I want an overview of the instalation with a bit of walking around. Then fly in the gripper tool. See it attach to the pipe by closing the gripper and putting in the pin. Then rotating it with the msphysics animation. Then zooming out to overview.

It can be done with MSPhysics, but it won't be simple. It will require adding scripts and other things... I would suggest you use Animator by Fredo6 for animations and camera transitions. It also allows rendering your animations with Thea Render and some other modern rendering programs, which is what you ultimately want.

@delchrys said:

Can I create some more hinges and actions in msphysics. For instance a slider to push the upper pin in and out and another hinge for turning the gripper around the bottom pin?

Yes!

@delchrys said:

This way I must use some of the same hinges for different purposes. Is that even possible? Maybe I can use servo motors. And trigger them by button presses.

And yes, that is possible. I will upload your model with such features tomorrow.

Regards,
Anton

Yes, you're correct, the collision geometry covers up the hole, as MSPhysics generates convex collision for all linked faces. You can fix this by subdiving the group even into more convex sub-groups, like in the image below:

For more accurate convex subdivision, you can use Convexify by fredo6.

But then, either way, your model will endup with multiple geometries, ruining the view. What you can do about it is have another, hidden layer, calling it "MSPhysics Collision", where all the convex subdivisions will be stored. Then have the original, non-subdivided versions of the groups be visible and set to MSPhysics->State->Ignore, so they don't interact with MSPhysics simulation.

Here is how it should be:
Table Saw Carriage test V1.0.skp
You can enable the "MSPhysics Collision" layer to see the collision used for simulation.

@synsuka3d said:

erreur Masse !!!! v1.0.0
no reset position ! big masse

There are two types of buttons to end simulation: one is reset and the other one is stop. If you press the stop button, the group positions will not reset. If you press the reset button, group positions will reset. No I'm not sure if it was an error or you pressing the wrong button. A sample model that causes that error would be appreciated.

Edit: Oops, I didn't know it was an gif animation, not just an image. So, yes, assigning huge masses results in an error. I will ensure that this is fixed in the final release of 1.0.0. Thanks for the report.

Hello, Trent Perez,

First rule: Groups that should act as one object must be grouped into another group. In your model, you should endup having 3 groups; the frame and two arms.

Second rule: Groups that have concave geometry must be divided into convex sub-groups. If you enable the collision wireframe you will see whats wrong. Basically, one of the arms must be divided into two sub-groups, even though that's not how it will look when you go about designing it.

Here is how the fixed model should look like:
Table Saw Carriage test V1.0.skp
I also enabled and adjusted min and max limits for the two hinge joints for a more proper behavior.

Regards,
Anton

Hey, y'all,

I just made a tutorial on making collision based and joint based copy-able chains. It's in Russian, but a picture is worth a thousand words...

Here is the chain model basing on collision:
https://drive.google.com/open?id=0B3qg8f4WrNdHTWFYOWtkZ3g0RUk

Here is the chain model basing on joint connections:
https://drive.google.com/open?id=0B3qg8f4WrNdHU2NxYnNWTXgxLWc

So, if you're interested in making chains, you should definitely check it out.

-- Anton

Hi, Ecati,

@ecati said:

Thank you for your reply. The cylindrical piece moves up when I press play, what could be the reason?

I answered that in my prior post.

Generally there are two ways to do it.

1. Divide the concave thingy into convex sub-groups. Using Convexify plugin by Fredo6 should do it for you. You must ensure that the group you divide is initially a solid group. You can use CleanUp along with Solid Inspector by ThomThom to help you fix it. Then once the group is divided, the collision should generate properly. I did it for you, so you can see what I mean: ruffler çizim - way1.skp
2. A more advanced approach is to have the model rely on joints and have the collision be ignored. I'm not going to explain it in depth, but basically you utilize the curvy joint to have the cylinder move along the curve. If you enable the joints layer, you will see it. Here is the model: ruffler çizim - way2.skp

Regards,
Anton

Ecati, the reason it doesn't work as expected is that the collision generated for the concave group is improper. You must divide the concave group into sub convex groups. Use convexify by fredo6 to do it for you. The link to the plugin is at the main post. Also, to see the actual collision generated for shapes, enable the Collision Wireframe in MSPhysics Simulation UI.

Nice! If you change joint solver model to iterative 64 passes, the wobbling should be reduced by a bit.

Hello, Bert,

@delchrys said:

So i kind of remodelled a bit, but can't seem to understand why the pipe continues to rotate even when the grippers are open. It kind of get momentum because of the rotation, how can i stop that. So when the cylinder moves back, the grippers open and let go of the pipe and it stands still.

To fix this, you need reduce linear friction of the Plane joint from 100 to 1. This will the pipe to require less force to move along the plane. Also, setting the angular friction of the Plane joint to 0.01 should prevent the backward rotation of the pipe.

@delchrys said:

Did i do the pipe right by giving him a plane joint and only allow it to rotate???
Either the tool should move or the pipe should move for the grippers to work properly, presumably even in real case scenario. Above, reducing plane linear friction, allows the pipe to move.

@delchrys said:

PS is ther a plugin for SU2016 to import 2017 files or a simple converter??? I cannot install 2017 at work due to lack of administrative rights

Click onFile->Save As and in the Save As Type, choose the desired SU version.

Regards,
Anton

So, for a circle/arcs, you right click on them and select "Find Center".

Hi, Bert

Here it is:
delchrys - gatorator.skp
Now it rotates along the pipe, like desired.

I also made it compatible with MSPhysics 0.9.9. I assigned all bodies a mass of 1.0 so that the joints are robust. This won't be necessary in the final MSPhysics, version 1.0.0, but that's what required in the current version. I also added grippers to the clutches. The clutches themselves are ignored, but the grippers are collidable. If you enable the MSPhysics Joints layer, you will see the grippers. I also changed the solver model to iterative 64 passes, once again, for a more stable behavior of joints in the current versions of MSPhysics.

Regards,
Anton

@pilou said:

Can you see the 2 gif animations above?
(because they are on the Su French forum section)

Nope, I don't see them. It says I'm unauthorized to view them...

@pilou said:

PS Sorry for the MS "Untouching" Physics!
I will remember that for the next time!

I'm not offended by that in any way. Neither is Ms Physics

Hello, Faust,

@faust07 said:

This worked in version 0.9.9 but after opening with v1.0.0 all former mass values
were displayed in density and the bodies then behaved strangely...

Yes, that was another change I made. I basically renamed the attribute, so it describes the Control by Mass/Density property more accurately. After version 1.0.0, new releases will usually include backup compatibility, but while MSPhysics is still in 0.x.x stage, I don't make changes compatible.

@faust07 said:

It would be good to know the dependence of the strength of the joints on the density
/ mass of the connected body parts. For the walking person, I have to adjust the
triple weight for all parts of the body in order to reduce the wobbling and trembling
to a tolerable level.

In the current versions, joints are the most robust when two linked objects have identical masses. But since linked objects usually don't have identical masses, simply assign realistic mass ratios to objects, and that will usually, too, guarantee strong joint connections. For example, the torso of your robot could have a mass of 1.0 kg, the arm of 0.2 kg, the hand of 0.05 kg, and etc...

@faust07 said:

An oscillation of previously 60 frames now appears to correspond to a value of 1.0.
Does the oscillation refer to real time or simulation time?

Yes, that was changed too. Now the oscillator accepts frequency in seconds of simulation time - number of times to oscillate per simulation second; no longer depends on frame. This change was made to keep the oscillation value persistent when changing the simulation timestep.

@faust07 said:

The start rotation direction of the joints changes sometimes? I guess the cause is at the oscillators starting point at -1.0.

I added another function, called oscillator2, which starts at 0.0 and oscillates from 0.0 to 1.0. See the documentation for details. Also, since 1.0.0 isn't released yet, the documentation is local. To open it, select some group, open MSPhysics UI, activate the Script tab, and select MSPhysics link. From there, click on CommonContext too see all functions you could use as controllers.

@faust07 said:

What is the influence of setting "Kinematic" or "Dynamic" to the simulation? Where
can I find the script overview?

After opening the local documentation, click on Overview tab. There should be a small topic on that.

@faust07 said:

Right now, I'm just trying to figure out what the simplest method is to copy a
complex MSPhysics conglomerate like a person (with Curvy Piston and scripts) and let
them act independently.

This can be done by selecting the entire robot, and enabling the Connect Closest Joints state. Then you can copy it, along with the curvy joint, as many times as you want.

@faust07 said:

The improper phasing till persists:
The elimination of movement phases of individual bodies is still present. This,
however, seems to be due to the amount of transformed emitters (drops, splashes,
etc.). Without the many emitters, the body movements of my "Little Richie Gear" (I as
a boy with a lantern...) are smooth.

Send me a private message with the model so I can see what could be done to improve MSPhysics and/or the model.

Regards,
Anton

Hello, Pilou,

There is an onUntouch {|toucher| ...} event for that. Basically when squeezing wall stops touching the stones, you want them to become static, right? To do that, you have to assign this script to the wall(s):

# Triggered when the wall stops touching a body.
onUntouch { |toucher|
  # Ensure that only touchers named, 'stone', are set static.
  next if toucher.group.name != 'stone'
  # Set static
  toucher.static = true
  toucher.set_velocity(0,0,0)
  toucher.set_omega(0,0,0)
}
# Triggered when the wall starts touching a body.
onTouch { |toucher|
  # Ensure that only touchers named, 'stone', are set movable.
  next if toucher.group.name != 'stone'
  # Set toucher 
  toucher.static = false
}

Make sure to name all stones, stone.

However, I think that for cluttering a lot of stones it would be better to manually set them static, say after pressing key, S.
Assign this script to the wall:

onStart {
  @set = false
}
onTick {
  if key('s') == 1 && !@set
    @set = true
    simulation.world.bodies.each { |body|
      if body.group.name == 'stone'
        body.static = true
        body.set_velocity(0,0,0)
        body.set_omega(0,0,0)
      end
    }
  end
}

This, too, requires that all stone objects are assigned a name, stone.

FYI, it's not "Ms Physics" it's "MSPhysics", standing for Math Science and Physics.

Regards,
Anton

Hello, Bert,

That's indeed a better model! I made a YouTube video on how to add MSPhysics to it:

Here is the model:
delchrys - gatorator.skp
Regards,
Anton

These are amazing! Great work Aaron!