Unity plugin progress?

[Julio Jerez]

of I think I know what happened with the scale

when I change some of the prototypes functions for taking a void pointer to take a copy of the argument I did not change everything some virtual function suddenly started to call the wrong pattern of calls.

an example of that are thes funtions.

virtual void dNewtonCollision::SetMatrix(const dMatrix matrix);
changed to
virtual void dNewtonCollision::SetMatrix(const void* const matrix);

and that cases class below to be nullified. and that si the base calls for shape like cylinder and capsule.

Code: Select all

class dNewtonAlignedShapes: public dNewtonCollision
{
   public:
   dNewtonAlignedShapes(dNewtonWorld* const world, dLong collisionMask);
   void SetMatrix(const void* const matrix);
   void SetScale(dFloat x, dFloat y, dFloat z);
};

as soon as I fix that it should be fine again, but I also want to fix the problem wit combine scale in child shapes which think to be broken even before that.
but I believe this is no because of newton is the way Unity apply the scale, which I believe is incorrect. you can see it is the fact that the use tow scales, and the can no possible be correct because scale is a full 3 x 3 transform matrix that can only be diagonal when
the scale is uniform or when the scale is not uniform and the object is a root object in which case it is a special case of a body with a unity matrix as parent.
other that that when the scale is a child transform I becomes a full 3 x 3 matrix and is not possible to have it as a 3 x 1 vector.

Maybe I can figure out the erroneous expression they are using and can emulate it so that we match their scene hierarchy at all time.

[Sweenie]

This page explain a bit how scaling behaves in Unity.

https://docs.unity3d.com/Manual/Transforms.html

Scroll down to the part Limitations with Non-Uniform Scaling & Importance of Scale

[Julio Jerez]

I figured there was something wrong there. anyway I think I have it now, including child scales.

when they say this:

Limitations with Non-Uniform Scaling
Non-uniform scaling is when the Scale in a Transform has different values for x, y, and z; for example (2, 4, 2). In contrast, uniform scaling has the same value for x, y, and z; for example (3, 3, 3). Non-uniform scaling can be useful in a few specific cases but it introduces a few oddities that don’t occur with uniform scaling:-
Certain components do not fully support non-uniform scaling. For example, some components have a circular or spherical element defined by a radius property, among them Sphere Collider, Capsule Collider, Light and Audio Source. In cases like this the circular shape will not become elliptical under non-uniform scaling as you would expect and will simply remain circular.
When a child object has a non-uniformly scaled parent and is rotated relative to that parent, it may appear skewed or “sheared”. There are components that support simple non-uniform scaling but don’t work correctly when skewed like this. For example, a skewed Box Collider will not match the shape of the rendered mesh accurately.
For performance reasons, a child object of a non-uniformly scaled parent will not have its scale automatically updated when it rotates. As a result, the child’s shape may appear to change abruptly when the scale eventually is updated, say if the child object is detached from the parent.

you know what that is, that's been an apologist for PhysX and is what really bother me, about what NVidia has done to the integrity of the people who are working on this field.

In order to get thing running really fast the has deluded and has no regard for physics and mathematical correctness. but they do not say is so up front instead they spend lots of money in propaganda that target less inform people that they are doing some kind of new form of brand new physics formulations. These people are snake old salesman.

The other day I saw a Unity video of one of these know nothing self appointed engine expert giving a seminar about using Physics in unity.
he was saying hat now the are using a new version of the physx engine that whet the called
"Adaptive Force" is no longer a magical core for box stacking that now the have a new technology call long distance constrain.
Never he mention that he mislead the user for more than ten year with et no scene while misrepresenting and maligning any one who at least try to do it right and or admitted that this was not right. on the video he finnaly say that the simulation was quiet wrong doin that what he does no say is that the simulating is even more wrong by doing what the are doing now.

on another video he is repetiing the same falsehood that Mr Pierre Terdiman was saying,
where he say phsx is 10 time faster, them he shows a chart for the Peel tool where she show physx really fate that older version, and way on top he show bullet, be like 30 time slower,
this what I mean when I say the give that those tools to developers with these that serve as scare tactics an representing the competitor the worser possible way.

here is my question do you think that they are no show havoc and Newton in those internal presentations.
what these people is dishonest and no different that a corrupt politician or run of the mill thug
and the do it just because Nvidea can fund these dishonest tactic to the tune on million of dollar a year. it is one those videos similar to this, I see if I can find it.
But is funny to watch these dude bending lie a pretzel explain all eh possible way that Phsyx is wrong and how to work around it. They push the problem to the end user.
https://www.youtube.com/watch?v=kJxVCiFn3mA

This is apologetic at it finest to the tune of several hundreds of thousand of dollars. most people on that audiance left the room thinking that the actually learned something valuable.
Notice the trick of this brand new law of physics they called "the infinity inertia that make stuff stable" I explain it here:
https://www.youtube.com/watch?v=ejdbYssqaL4&t=21s

[Julio Jerez]

you had a script that spawned new objects but I do not see it anymore. can you recreated?

I was looking at the profiler, and you are right the NewtonUpdate, takes about 0.1 to 0.2 ms
but when the garbage collector kicks in, it can takes upto 5 ms and if this is this is what a such small scene, we are in big trouble.

we can do two thinks, use a generic List<NetwonBody> to iterate the list, but that even mode o fteh same even when we can move to the initialization,
or since that each dNetwonBody has a pointer to the d NetwonBody we can just iterate one the array of NewtonBody form the low lever and the cost should be just make the call to get the object.

the Garbage collision in c# does not seems very good. but my impression is the this is only in Mono not really related to other c# implementations, I wonder if mono uses LLVM, they have good CG
what I see in unity is not good at all, 5+ ms for a CG does not make even mediocre class for CG.

[Sweenie]

I have to admit i dont know the low level differences but i know Unity is using Mono with the Boehm GC. There is a newer GC called sGen but Unity havent switch over to that yet for some reason.

Unity was also running an old 2.x version of Mono for a long time due to license issues but i think they upgraded to Mono 4.4 with release 5.5 of Unity.

Then we have the Unity IL2CPP project. Havent read that much on this but i think it converts your c# code to c++.
Alot of things seem to happen in Unity now.

But until then i guess the old rule still applies, dont "overload" the GC. Try to use value types as often as possible for shortlived objects as they are allocated on the stack as opposed to classes which are always allocated in the heap memory and garbage collected.
If you need to use classes for shortlived objects, reuse them by using object pooling instead of creating and destroying them.

[Sweenie]

By the way, the object spawner script is still there (BodySpawner.cs).
Its under the scripts folder and is used in demo 03.

I ran the profiler when I had about 40 objects in the scene(with each having a NewtonScript attached) and that caused about 15kb of GC allocations per frame which caused a 10 ms GC Collect...
So yes, we need to change the way we call the NewtonScript methods.(OnCollision, OnTorque etc)

Iterating through the scene is fine during initalization but way to slow to be done each frame.

[Julio Jerez]

Boehm GC ?
That's was what I thought, because that is what horrendous allocation pattern shows.
It is 2017 and there are still people the using a Sweep and prune memory managers, the Boehm GC is just slightly better that the naïve sweep and prune, even a Generation garbage collector will do better than Boehm GC for a real time application like a game.

there are Trace algorithm that work on real time and do not requires any sweeping, one simple but very powerfull is the thee color marking, which requires the compiler to issue the instigator instruction but todays with tool like LLVM they even has the instruction as part of the virtual language.

I guess is that the people in charge of mono at intellectual morons if the are still suing a seep and prune GC. even language lie LUA and Python today uses some flavor of a three color marking method like Cheney algorithm.

I do not know for a fact but I would be money that C# in Visual studio will no have that horrendous memory asset pattern. It is 100% unacceptable that a local variable crate on the stack excessive a garbage collector, that's the whole idea of language like Java and c#
what they are doing memory allocation for each local variable, no deleting on at function exit and have a function that periodically scan the graph reclaiming memory chunks no linked to the root o the collector. this easily iterate over several hundred of thousand node on a graph.

Oh well it is what it is and we can do much about but this is really disappointing.

[Julio Jerez]

I will try to fix that, and run that test again.

[Julio Jerez]

ok I committed a version that interate over ther array of dNewonBodies
I am not sure if this is any better because GetBody may be exercisingg the garbage collector too.

but is even worse look at the update loop

Code: Select all

        for (dNewtonBody newtonBody = m_world.GetFirstBody(); newtonBody != null; newtonBody = m_world.GetNextBody(newtonBody))
        {
            NewtonBody bodyPhysics = (NewtonBody)GCHandle.FromIntPtr(newtonBody.GetUserData()).Target;

            // Apply force & torque accumulators
            newtonBody.AddForce(new dVector(bodyPhysics.m_forceAcc.x, bodyPhysics.m_forceAcc.y, bodyPhysics.m_forceAcc.z));
....
            NewtonBodyScript[] rigidBodyScripts = bodyPhysics.gameObject.GetComponents<NewtonBodyScript>();
            for (int i = 0; i < rigidBodyScripts.Length; i++)


the inner loop has to iterate one the array of complements, granted there many be only one component, but this still has to create the array.
ideally we would like to go over the array of component without having to make a local array.

please run the same scene to tested before with this update and see if is moving on the right direction.

[Julio Jerez]

I run a quick test and the, and it seem much better, there are not GC spikes, but I believe we could do better. If you run a largest scene test please let me know, before we proceed with the extrategy.

This weekend will do this:
1-Heighfield collision
2-Scene collision (this one is very important for efficient scenes)
3-Ray Cast if I have time

[Sweenie]

Iterating through the scene nodes may be slower than just iterating through a simple list but whats causing the garbage collection is most likely these calls...

in UpdateRigidBody(GameObject root, float timestep)

Code: Select all

NewtonBodyScript[] rigidBodyScripts = root.GetComponents<NewtonBodyScript>();

in OnWorldUpdate(float timestep)

Code: Select all

GameObject[] objectList = gameObject.scene.GetRootGameObjects();


in OnBodyTransformUpdate()

Code: Select all

GameObject[] objectList = gameObject.scene.GetRootGameObjects();

Each frame you create three arrays which are subjects for garbage collection.

[Julio Jerez]

did you sync?
OnBodyTransformUpdate is no creation an array anymore.
this is how it looks now

Code: Select all

    private void OnBodyTransformUpdate()
    {
        /*
                GameObject[] objectList = gameObject.scene.GetRootGameObjects();
                foreach (GameObject rootObj in objectList)
                {
                    OnBodyTransformUpdate(rootObj);
                }
        */

        for (dNewtonBody newtonBody = m_world.GetFirstBody(); newtonBody != null; newtonBody = m_world.GetNextBody(newtonBody))
        {
            NewtonBody bodyPhysics = (NewtonBody)GCHandle.FromIntPtr(newtonBody.GetUserData()).Target;
            bodyPhysics.OnUpdateTranform();
        }


in NetwonWorld there should be only one array created left at update time. this like

NewtonBodyScript[] rigidBodyScripts = bodyPhysics.gameObject.GetComponents<NewtonBodyScript>();

[Sweenie]

GetFirstBody and GetNextBody creates new dNewtonBody instances now instead.
Though they are pointing to the same native object they are still new instances that are garbage collected objects.

I tried the method below and it doesn't seem to cause any gc allocations at all...
Created a member in NewtonWorld...

Code: Select all

List<NewtonBody> m_bodies = New List<NewtonBody>();


Added a function to NewtonWorld...

Code: Select all

internal void RegisterBody(NewtonBody nb)
{
  m_bodies.Add(nb);
}


Inside NewtonBody.InitRigidBody i call this

Code: Select all

m_world.RegisterBody(this);


Now the world has a list of NewtonBodies to iterate through with no gc allocations going on.

It seem to work when I test it.
The body register itself to the world, at start and also at runtime.


The next thing after that is the scripts.
I thought the same thing could be done here, but let the NewtonBody keep the list of it's NewtonScript instead of letting the world keep track of them.

The world keeps track of it's bodies, and the Body keep track of it's scripts.

What do you think, you want me to check in that code or do you think it's a bad idea?

[Julio Jerez]

I totally agree, I though of using a list this morning, and them I realized that we can get that pointer form the dNetwonBody, but I did not realized that this in fact makes a garbage collected object,
my change may very well be slower than before.

please undo my changes, and commit yours.

I was reading about optimization and it seem that using GetCompenent is bad in all context,

5. Avoid reflection (GetComponent, SendMessage, Instantiate, Find, etc.)
Unity offers several shortcuts which allow developers to quickly refer to other scripts or objects. The most common is GetComponent, a method used to lookup scripts attached to your objects. According to the official documentation, there are two variants of GetComponent: one takes the name of the component as a string ( GetComponent(“Rigidbody”)) the other its actual type ( GetComponent<Rigidbody>()). The latter should always be preferred, as referring to an object using its type allows the compiler to spot nasty typos at compilation time. In terms of performance, GetComponent is costly, and using it in the Update method of your script will slow down your game. If you need to access another component very often, the best technique is to cache it.

// Slow
void Update () {
Rigidbody r = GetComponent<Rigidbody>
(); // Invoked every time
}

// Fast (caching)
private Rigidbody r;
void Start () {
r = GetComponent<Rigidbody>(); // Invoked only once

basically we have to take control of the components and cache then in locak array list in eh start.
the we for call the local list like

Code: Select all

for (int I = 0; I < body.LocalList.Lenght; I ++)
{
  Body.ScripList[i].DoSomeThing();
}

or something like that.

[Sweenie]

Ok, try it out. I've checked in my code.

It shouldn't create any garbage for the collector.

I had to comment these lines though...

Code: Select all

            // Apply force & torque accumulators
            //bodyPhysics.m_body.AddForce(new dVector(bodyPhysics.m_forceAcc.x, bodyPhysics.m_forceAcc.y, bodyPhysics.m_forceAcc.z));
            //bodyPhysics.m_body.AddTorque(new dVector(bodyPhysics.m_torqueAcc.x, bodyPhysics.m_torqueAcc.y, bodyPhysics.m_torqueAcc.z));


The "new dVector" constructor causes garbage collection.

We need a function that takes regular floats for AddForce and AddTorque instead of dVector.