Add Deformable Joints

[janga1997]

Do be sure to install the addon Add Curve:Extra Objects before trying out this PR. Just type extra in the search bar of the Add-ons tab, and you should find the add-on.

[janga1997]

turns out, we don't need a modifier after all. If we just change the dimension spring along its length, it "stretches".

[janga1997]

The only thing I am concerned about is scaling in deformable elements. I tried messing around by scaling the parent node1, and it did mess up the motion of the spring.

Can we ask the user to scale nodes only using our scaling operator, in #23 , and not even using the interactive scaling using 'S', because we can scale back the children effectively this way.

Scaling the elements doesn't matter, because they affect only themselves. However, I think we should lock scaling along the z axis of the spring, and only allow scaling across the cross section. That should be easy.

[zanoni-mbdyn]

When trying to spawn a deformable displacement joint, check if the method you use from Add Curve:Extra Objects is found. If not, alert the user that he should activate that addon.

I tried your changes, but the only thing that I see upon loading a deformable displacement joint is a really big Empty object, albeit at least oriented in the correct way with respect to the constitutive law of the element. I can't see any spring.

Also, in the console a lot of these messages are printed:

...
<Vector (0.0001, 0.0000, 0.0003)>
<Vector (-0.0003, 0.0000, -0.0010)>
<Vector (-0.0002, 0.0000, -0.0011)>
<Vector (-0.0001, 0.0000, -0.0008)>
...

[zanoni-mbdyn]

About the scaling: no, I don't think it is acceptable to force the user to not use S as the primary scaling operator. It simply goes too much against the normal Blender workflow...

We have to find another way.

[zanoni-mbdyn]

Also, please use deformable_displacement or deformable_displacement_joint as the joint type, defdifp seems a bit lazy ;)

[janga1997]

I tried your changes, but the only thing that I see upon loading a deformable displacement joint is a really big Empty object, albeit at least oriented in the correct way with respect to the constitutive law of the element. I can't see any spring.

I'm assuming you just pressed the Add all elements to the scene? I don't know why, but it doesn't load that way. Select that individual elements again, and press Add element to the scene

[janga1997]

@zanoni-mbdyn The console messages are the deformation vectors. I put in the print statement while debugging.

[zanoni-mbdyn]

I'm assuming you just pressed the Add all elements to the scene? I don't know why, but it doesn't load that way. Select that individual elements again, and press Add element to the scene

nope, I imported only one joint in a couple of different models

[zanoni-mbdyn]

@zanoni-mbdyn The console messages are the deformation vectors. I put in the print statement while debugging.

OK, I thought that was the case. Just remember to take it out of the code once you're ready :)

[janga1997]

nope, I imported only one joint in a couple of different models

And no spring shows up at all? Could I have one of those models to see what's going on?

[zanoni-mbdyn]

I've sent an email to you with an MBDyn repository snapshot, that contains a lot of test models. I can provide you with some more models if you need them.

Also, can you post the model that you were using, so that I can cross-check? Thanks

[janga1997]

Here is the model spring_mass_damper_2.txt

[zanoni-mbdyn]

Animating your model, I can see the springs, but two things are not clear to me:

• the deformable displacement joint in the MBDyn input file is connected to Node_Ground and Node_Mass without offsets, but I see some offsets in the Blendyn animation;
• the three springs deform in a rather funny way, stretching not only along their axis but also in the other directions (their section becomes oval).

Maybe it'm my fault: I'll try to make a Blender model to visualize how I think the deformable displacement should appear.

[janga1997]

@zanoni-mbdyn That's my fault. I pushed a commit just now, which scales the objects only along the z axis. Do pull the latest commit, and it should fix the "oval" shape of the springs.

[zanoni-mbdyn]

OK, now the shape of the springs is retained. Sill, the overall behavior is not what I had in mind. Please see the .blend file attached.

The objects f1 and f2 represents the attachments points of the deformable displacement. The f1 object is rotated with respect to Node_1: the orientation of the axes of f1 defines the reference frame in which the constitutive law of this element is defined.

The d line represents the relative displacement between the two attachment points. It might be visualized, as I've done here, exactly in the same way as we do for the rod element, although it is not strictly necessary (but it won't be too much trouble, since we already have the code for the rod).

The three springs visualize the components of d in the reference frame of f1. Let's suppose that the components of d in the f1 reference frame are d1x, d1y and d1z. Then the first and last point of the axes of the three springs d.x, d.y and d.z should have these coordinates (also in the f1 reference frame):

• ax1_first = (0, 0, 0), ax1_last = (d1x, 0, 0);
• ax2_first = (d1x, 0, 0), ax2_last = (d1x, d1y, 0)
• ax3_fist = (d1x, d1y, 0), ax3_last = (d1x, d1y,d1z`)

so that the first axis is a line segment connecting ax1_fist and ax1_last, and the same for the others.

In the second layer of the file that I have attached, you see how a simple straight line through the spring helix could be used to deform the string in the correct way: I used a "curve" modifier on the helix (be careful to switch on the option Stretch on the axis line curve properties) and hooked the vertices of the axis to a couple of empties. We could spawn three of these springs and then simply move the empties using an update operator.

For simplicity, we could just use this spring as a prototype and isert it in the joints.blend library file.

defdisp_concept.zip

[janga1997]

The objects f1 and f2 don't show up at all. And neither do the objects d, and its hierachy, d.x, d.y, d.z Is this intentional?

[janga1997]

Ok, I think I get what you're trying to say. What I did was, the centres of the three springs were at (d1x/2, d1y/2, d1z/2) , with lengths d1x, d1y, and d1z.

Using a curve modifier would certainly make the job of "deforming" the spring objects easier.

But we would have to use the Simple Deform Modifier for the deformable hinge ? i don't see a way around it.

And for the deformable joint, we would have to use both the Simple Deform Modifier, and the Curve Modifier part you laid out.

[janga1997]

I have just one last doubt, is the point ax3_last = (d1x, d1y, d1z)justf2? (I assumef1andf2` are the offset points from Node1 and Node2 )

[zanoni-mbdyn]

I have just one last doubt, is the point ax3_last = (d1x, d1y, d1z)justf2? (I assumef1andf2` are the offset points from Node1 and Node2 )

yes it is

But we would have to use the Simple Deform Modifier for the deformable hinge ? i don't see a way around it.

Uhm... Could be, or maybe we could use a similar technique and display three curved springs (the control curve becomes an arc of a circle). Might be a little trickier, though.

[janga1997]

@zanoni-mbdyn Just for the sake of argument, couldn't we just use the Simple Deform modifiers? (for both displacement and hinge), because we end up using an update method anyway, but by using the Simple Deform modifier, we avoid spawning all these extra objects (Empties and Curves)

I could just rework the spawn method to reflect the behavior you had in mind. AND Are the springs in your explanation always in the direction of the x, y, z axes? I think they aren't.

[zanoni-mbdyn]

Il 27 giu 2017 19:29, "VSN Reddy Janga" notifications@github.com ha scritto:

@zanoni-mbdyn https://github.com/zanoni-mbdyn Just for the sake of argument, couldn't we just use the Simple Deform modifiers? (for both displacement and hinge), because we end up using an update method anyway, but by using the Simple Deform modifier, we avoid spawning all these extra objects (Empties and Curves)

If the result is the same, yes.

I could just rework the spawn method to reflect the behavior you had in mind. AND Are the springs in your explanation always in the direction of the x, y, z axes? I think they aren't.

They are always in the direction of the LOCAL x, y, z axes of the reference frame defined by the first rotoffset w.r.t. Node 1, where the constitutive law is assumed to be defined. If there is anything in this last sentence that is not clear to you, please tell me. In my opinion, it is very important to get this part right in order for the visualization to be really useful.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/zanoni-mbdyn/blendyn/pull/26#issuecomment-311428797, or mute the thread https://github.com/notifications/unsubscribe-auth/AHc7yDVeGjuV6H5SFtFeqR1Up3EZQL7sks5sITwHgaJpZM4OBO35 .

[janga1997]

LOCAL x, y, z axes of the reference frame defined by the first rotoffset w.r.t. Node 1

This is the line I needed, and I do understand it. I will get to work on this right away, because in the current form, the springs are spawned in the global x, y, z axes.

[janga1997]

0000-0500.zip

Here is a video with the latest changes. I think it reflects what you wanted.

[zanoni-mbdyn]

It seems like it is what we want... I'm going to test it in the afternoon.

[zanoni-mbdyn]

Missing file?

Read new prefs: /home/zanoni/.config/blender/2.78/config/userpref.blend
Blendyn: could not find the pygal module. Plotting  will be disabled.
Traceback (most recent call last):
  File "/usr/share/blender/scripts/modules/addon_utils.py", line 330, in enable
    mod = __import__(module_name)
  File "/home/zanoni/.config/blender/2.78/scripts/addons/blendyn-master/__init__.py", line 42, in <module>
    from . import base
  File "/home/zanoni/.config/blender/2.78/scripts/addons/blendyn-master/base.py", line 75, in <module>
    from .baselib import *
  File "/home/zanoni/.config/blender/2.78/scripts/addons/blendyn-master/baselib.py", line 44, in <module>
    from .elementlib import *
  File "/home/zanoni/.config/blender/2.78/scripts/addons/blendyn-master/elementlib.py", line 40, in <module>
    from .defhingejlib import *
ImportError: No module named 'blendyn-master.defhingejlib'

[janga1997]

I'm kind of confused on the math for the deformable hinge.

Now, assuming the springs are in the reference frame f1, (which includes both the Node_1 and the rotational_offsets_1), are these the torsional deformations?

spring_x = n2OBJ.rotation_euler.x - n1OBJ.rotation_euler.x
spring_y = n2OBJ.rotation_euler.y - n1OBJ.rotation_euler.y
spring_z = n2OBJ.rotation_euler.z - n1OBJ.rotation_euler.z

[zanoni-mbdyn]

I know that is that of the deformable hinge and we're testing the deformable displacement for the moment, but please just commit something that is not doing anything but defines all the necessary functions for the rest of the addon to work properly (for example, define an empty parse_defhinge, and so on...)

[janga1997]

Sorry for the mishap. I committed more than one file in the second last commit.

[zanoni-mbdyn]

No problem!

[zanoni-mbdyn]

are these the torsional deformations?

No. The deformation components in this case are the components of the relative rotation vector between the f2 and the f1 frames.

Using quaternions, we could do something like this, i guess

q1h_tilde = Quaternion((elem.rotoffsets[0].value))
q1 = n1OBJ.matrix_world.to_quaternion()
q2h_tilde = Quaternion((elem.rotoffsets[0].value))
q2 = n2OBJ.matrix_world.to_quaternion()

q1h = q1h_tilde*q1
q2h = q2h_tilde*q2
qrel = q2h*q1h.conjugated()
n, theta = qrel.to_axis_angle()
phi = n*theta

so that the deformations are

spring_x = phi[0]
spring_y = phi[1]
spring_z = phi[2]

I'm not sure though if we want to direcly use these to scale our rotational spring elements... You could give them a try, and we see what happens.

[zanoni-mbdyn]

I could not load the deformable displacement:

WARNING - Could not find the import function for element of type defdisp. Element defdisp_11 not imported.

[janga1997]

@zanoni-mbdyn you have to select it individually, and then press Add element to the scene.

Did you pull all my commits on this branch? I did push one Add deformable hinge just now. do a git pull, and try again. I've just tested again on my local branch, and it does work.

[zanoni-mbdyn]

OK, I tried both methods (adding all the elements and adding just the deformable displacement), and then I mistakenly thought that that warning was the result of the latter. This also because doing so resulted in this

Other than the big Empty, nothing is visible. I'm using the deformabledisplacementjoint0 test in tests/joints/deformablehinge

[janga1997]

Ok. Now I understood what's the problem. The problem is, at initiating, the length of the springs is zero (or maybe even for near zero), all three of them, and that leads to them not spawning correctly. Because the radius of the spring is dependent on the length too, it spawns as nothing more than a point.

[janga1997]

If you change the initial position of the second node (set something like 1, ,1 , 1, so that springs in all three directions have non zero lengths), they spawn correctly, and the rest of the animation goes fine.

That's why my example file worked, and this one didn't.

Edit: If I remember correctly, it seems like this might be an issue you pointed out before.

[zanoni-mbdyn]

This is quite a problem, though, because a lot of the times (something like 99.9% of them) the springs will have to be created with zero length, at least along some directions...

Maybe we should introduce a lower limit to the scaling factor: if the domponents of d have magnitude less than a tolerance, we keep the scaling factor instead of reducing it further.

[janga1997]

I was thinking about something like that too. Maybe a radius of 0.1 units (in Blender) should be the limit? That would make the least length 0.33 units. (I used the arbitrary relation of radius = 0.3length)

[zanoni-mbdyn]

That is too much, in my opinion. I'll go down as much as possible to avoid confusion.

[janga1997]

Well, the length would be scaled down as soon as the animation starts, according to the deformation vectors. What we are setting is a minimum radius. I 'll just a push a commit for you to see it in action,

[zanoni-mbdyn]

I'll reduce it a bit more ;)

Anyway: something strange happened when I tried to import different deformable displacement in the same model: see the image attached. The first one is spawned correctly, while the springs for the other ones do not appear.

[janga1997]

Sorry about that again. The springs are in fact loaded, they are just superimposed on each other. Try selecting the second defdisp joint, and drag it out. You should see two.

This was an error I was thinking about fixing last night, and forgot. Pushing now.

Edit: Seems another issue with parenting.

[janga1997]

I added the deformable joint, combining both the deformation vectors (of displacement and rotation) you laid out above.

[zanoni-mbdyn]

A couple of things about deformable displacement joints:

1. I still think that 0.1 is too much for the minimum length of the springs

2. something is till wrong with the import procedure, because springs are aligned with the global axes and not with the local ones

[zanoni-mbdyn]

Also, for the deformable hinge element: we should really give the idea of rotational springs, instead of linear springs.

Using the method I've suggested you (using a curve modifier to stretch an helix) I obtained something that looks right, to me:

I have used a NURBS curve defined by three points located as described here with the middle one having a weight of cos(phi), where phi is the angle at the circumference corresponding to the extension angle of the rotational spring.

I'm thinking about using three springs, each attached to an arc that draws the relative angle between a couple of axes: angle(x2 - x1), angle(y2 - y1) and angle(z2 - z1), all defined in the reference frame of rotoffset(1). It could be a little bit of an headache, but the result should look nice.

[louisgag]

Angular springs can be tricky, have you guys considered what to do for angles above 360° ?

[zanoni-mbdyn]

They certainly are, but how many times do you think a deformable hinge is stretched more than a single revolution in an MBDyn simulation? In some rare cases it might happen, but I think that for the vast majority of the cases we'll be okay.

In the rare case in which more than a revolution occurs, then the rotational spring would start again from null extension when 360° are reached.

Actually I'm not even sure that deformable hinges support that, since they calculate the angular strain based on the relative rotation vector calculated from the rotation matrices of the nodes they connect...

[janga1997]

testing.zip @zanoni-mbdyn For the deformable displacement joint, I think is what you had in mind, where the springs are aligned to the local axes. If so, I have the changes ready, and I will commit them. AND I didn't really think of the deformable hinges as rotational springs, and it definitely is more informative. I will get on it right away.

[janga1997]

While rotational springs look good for a deformable hinge, how would they work for a deformable joint? Because we have to demonstrate linear and angular distortion at the same time, do we spawn three rotational springs, and three linear springs? Because a single spring can't achieve demonstrating linear distortion and angular distortion (the way you demonstrated) at the same time.

[zanoni-mbdyn]

Yes, the deformable joint is a combination of a deformable hinge and a deformable displacement, so it should spawn six springs: three linear and three rotational.

[janga1997]

@zanoni-mbdyn How does the math work for angles = 180deg? The midpoint should then be at infinity. I tried setting a very large distance ( > 100 ) , but the behavior was inconsistent (changing the shape of the curve significantly with values 100, 200, 300).