Unity plugin progress?

[Julio Jerez]

Ok sweenie I am moving the conversation to this thread.

I now have the fist hinge compiling, no test yet but is should work.
I when the long round, not deriving form the CustomJoint class, instead making it joint a dat member.
no ideal but is works.

I will try to make a joint scene so that we can start adding functionality,
then the rest is straightforward.

I think a good strategy will be build up one joint like the hinge and then we add the rest on demand.

[Julio Jerez]

Hi I saw the wrapper class used it in unity, however, the result was indeterminstic because you used update, I think you should switch to fixed update(Has been tested, giving out deterministic results)

I think you have backwork, using the unity FixUpdate will not give you deterministic result believe me.
what you want is the physc update running at a fix step that is independent of the graphics, usually higher.
we test the Fix step and for what I can see unity fix step is arbitrary.
we can do that because we support sub sampling, for now we want the simulation be the same every time.

[Julio Jerez]

Ok In managed to get the joints stuff work, but for some reason the called

Code: Select all

public class NewtonHinge : NewtonJoint
{
    public override void Create(NewtonWorld world)
 

I added this log Debug.Log("xxxxxxxx I am here");
at the beginning and it does not print, instead this unrelated error message is printed

Couldn't call method UNetDomainReload because the class NetworkIdentity or method couldn't be found.

I hard for me to find out sine I has never been able to debug the unity part.

also I get a crash on exit, but I believe it is because the component is no initialized properly.

[Julio Jerez]

Ha success, I forget that we set it up in a way that all component are created by the works initialization, not by the start function since that are call out of order.

I add the part that create all joints component and is work like a charm.

now we nee to add a gizmo so that we can edit the joint parameter, right now place at the origin of the body.
after this I believe we and on our way.

[Sweenie]

Awesome.

I think something is a bit off with the collider code though.

The dumbBell doesn't behave as it should and I think I know whats wrong.

The colliders position and rotation are offset relative to the owning GameObject.
So if both are zero the collider is centered on the GameObject.

The dumbBell has three colliders.
The bar which is a cylinder component directly attached to the dumbBell GameObject.
The two weights are chamfered cylinders attached to two child GameObjects.
But when adding the weights(chamfered cylinders) to the compound we ignore the child game objects transforms. So I think the weights end up in the middle of the bar.

If a collider is attached to a child game object we must take the child gameobjects transform into account as well.

Tilt the dumbBell a bit and you will see what I mean.

Basically the user can position the collider in two ways.

A) Add the collider component directly on the GameObject and control the position and rotation offset using the position and rotation parameters.(No gizmo to edit the offset)

B) Add the collider component to an empty child gameobject and control the position and rotation using the child game object's transform. This way you can use the Editor gizmo to control the position and rotation.

Option B makes it easier to control the offset by using the Gizmo, but adds a little extra overhead since an extra gameobject is added to the scene.

Maybe we could do the same for joints.
Adding the hingejoint to a child game object and use the child transform to position and rotate the joint.

[EDIT]
It is possible to create custom gizmos but it would take alot of time. Even the Unity team haven't done it. They use the child gameobject technique as i described above. A least for colliders. For Unity joints they only allow the joint component on the GameObject containing the RigidBody component so they don't have any gizmo for placing the joint. You have to position and rotate the joints by changing the parameters by hand.

But first of all we need to add debug rendering for the joints so we can see them in the editor.

[Julio Jerez]

Maybe we could do the same for joints.
Adding the hingejoint to a child game object and use the child transform to position and rotate the joint.

that's the approach I am taking, I believe is the easier because for most joints the parent is almost always the parent of the hierarchy. Them we define the joint parameters in child space.

In fact we can use for example that by defualt other body is set to the parent,
in the case a joint is a loop or is connect to some other body we can always override the parent to whatever entity is in the scene.

I committed part of the gitmos for the hinge, an I am stocked on the transform
I am having some problem trying to figure out the order of matrix opperator

this twp operation function yield wrond result
Matrix4x4 matrix = localMatrx * bodyMatrix;
Matrix4x4 matrix = bodyMatrix * localMatrx;

I look over the forum and it seems the operation itself is wrong.
https://forum.unity3d.com/threads/matri ... zy.354073/

how do you multiply two 4x4 matrices in unity?

[Julio Jerez]

yes the dumbbell does no look right, we probably do no want to make them entity just to have a collision, I can see who this could cause big problem with many objects.
on the other hand, for some like a scene with the many entities we may wan to make the actual game objects.
Maybe we nee tow type of collision one that define compound and the part are simple components.
and another for scenes collision when the child shape are actual game entity.

[Julio Jerez]

I give up, I am frailly sure there is a bug on that function in unity.
what I am probably going to do is that I will pass the parameter in local space, and forget about collapsing them into a single matrix.

[Sweenie]

I give up, I am frailly sure there is a bug on that function in unity.
what I am probably going to do is that I will pass the parameter in local space, and forget about collapsing them into a single matrix.

Yep, seems the * operator isn't working as it should as the poor guy in the thread you mentioned tried to explain.
Seems Unity devs thinks working with matrices this way is too advanced for the casual Unity users. They say this in the documentation...
"You rarely use matrices in scripts; most often using Vector3s, Quaternions and functionality of Transform class is more straightforward. Plain matrices are used in special cases like setting up nonstandard camera projection."

[Julio Jerez]

yes I am more than 90% sure that function is wrong, but let us not get hung on that.
I am now passing parameters I local space and it works like a charm. In fact I believe is better this way.

Now we have a way to set hinges and edit the pin from the editor and it all works nice and easy.
if all goes smooth like this, this will be a quite a simple thing to get going.

I will need complete the interface, friction, limits, spring damper, and stiffness.
please try it out al tell me what you think

do you think will be cool to make a fancy gitzmo display to show limits?

[Julio Jerez]

A least for colliders. For Unity joints they only allow the joint component on the GameObject containing the RigidBody component so they don't have any gizmo for placing the joint. You have to position and rotate the joints by changing the parameters by hand.

even is take time having the gizmo to show what is going on is very useful. we are no editing on the screen we edit by manipulating the data, but is good to have a visual feeback.
It seems to work just fine and I am only showing the hinge pin.

also we only need to do it for the most common joints.

also do you realize that we are almost already in the position to make that little box in four wheel that was posted in the video that created the brouhaha with the Nvidia folks?

I want to go beyond that, I want to add suspensions, engine and differential and control.
I will show you how to make a differential later when we get to the relational joints.

[Sweenie]

Yes, a gizmo to show limits would be cool.

It's hard to visualize joints.
It would be cool if the gizmo for a hinge joint actually looked like a hinge but I think lines and arrows will have to do for now.

By the way, I have confused the term gizmo in Unity.
For me a Gizmo was the transform tool that you use to move the objects with the mouse.
But a Gizmo is of course the visual debug rendering of the gameobject/component.

What I was talking about seems to be called Handles in Unity.
https://docs.unity3d.com/ScriptReference/Handles.html

It would nice to be able to position the colliders and joints with a tool instead of editing the values manually.
I will experiement a bit with that but as you said, that is not important right now, first we need the basic stuff to work.

[Julio Jerez]

ha handles, yes that would be nice to have, but we have so much to cover that it will be a distraction.
that will be something we would want for version 1.1 or higher
for now is all about exposing functionality.

[Julio Jerez]

to close the day, I added
hinge now expose limits and spring damper fumtionality.
I also added the Hinge Actuator

this last one is very useful for making robotic stuff,
this one can serve a motor, and as robotic step motor.

as motor, you give a velocity and it will spin at that constant speed so long the load is less that the mas torque allowed.
as actuator you give a target angle and move to that target at constant speed until is reach the angle
as long as the power is below max torque.

I have no hooked all functionality yet, but I will finis tomorrow.

with this tow example, is easy to complete many of the other standard joints.
I will also add some the Gear which is useful for making interesting special effect.
the we will be able to do stuff that people will * on their pans.

[Julio Jerez]

ok I now added properties to the hinge using this style

Code: Select all

    public bool EnableLimits
    {
        get
        {
            return m_enableLimits;
        }
        set
        {
            m_enableLimits = value;
            if (m_joint != null)
            {
                dNewtonHinge hinge = (dNewtonHinge)m_joint;
                hinge.SetLimits(m_enableLimits, m_minLimit, m_maxLimit);
            }
        }
    }

with this any script can modify the parameter that is allowed to change of any joint form anywhere

The reason for the elaborated mode is that is no enough to change a variable, the variable change has to be pass to the support joints in the engine low level.

another way would be to using a delegate callback that is called form the joint callback and the read the parameter right there.
the will probably be simpler and more reliable and event more accurate sine the update will happen at simulation time.

please sync and take a look at the hinge joint tell me what do you think
if we should go with method 1 or 2. or maybe there is an even better way do it.
what do you thin