next »

[LeoMaheo]

(This is a continuation of a threading issues discussion; I started another thread, because topic has changed.)

You will have zero influence to Sun's vecmath lib. And you won't have out-of-the-box pools in Sun's vecmath at all. OpenMaLi has many more features, that you don't have in Sun's vecmath, such as read-only instances, static final instances like Colorf.RED, etc. and many others.

Actually, those read-only instances and dirty flags frighten me off a little bit. Yes read only instances are good to have, but I'm a bit worried about memory usage:

Code:

public abstract class TupleNf< T extends TupleNf< T > > implements TupleInterface< T >
{
    private final int N;
    protected final float[] values;
   
    protected final int roTrick;
   
    ...

    protected final boolean[] isDirty;

Memory usage, and the possibility that computations are a bit slower because of array access (instead of direct x y z field access),
makes me a bit hesitant to use OpenMaLi.

I just did some measurements (with Netbeans memory profiler),
and it seems that, on my machine, OpenMaLi's Vector3f uses 3.0 times more mem than a simple
Vec3f { float x, y, z; }.
If each float[3] and boolean[1] is shared between a read-only Vector3f instance and a mutable instance,
memory usage is 2.2 times higher than for the same number of Vec3f{x,y,z} instances.

(Interesting to note, perhaps, is that Vec3f { float x,y,z; Vec3f readOnlyPeer; } on my machine requires no more storage than a simple Vec3f { x, y, z }.  )

Performance measurements would also be relevant, to find out if e.g. those array access here:

Code:

    public final Quaternion4f mul( Tuple3f t, Quaternion4f out )
    {
        out.set( ( getD() * t.getX() ) + ( getB() * t.getZ() ) - ( getC() * t.getY() ),
                 ( getD() * t.getY() ) + ( getC() * t.getX() ) - ( getA() * t.getZ() ),
                 ( getD() * t.getZ() ) + ( getA() * t.getY() ) - ( getB() * t.getX() ),
                 -( getA() * t.getX() ) - ( getB() * t.getY() ) - ( getC() * t.getZ() )
               );
       
        return( out );
    }

makes the operation slower than had simple   float a, b, c, d;   fields been used.

If there's anything, that you would like to be in OpenMaLi, it can easily be added.

That's important, but actually also frightens me off a little bit. If I can do that, then... many other people would also be allowed to do that. And I have no idea how stable and functional their code would be.
Right now I feel that I have no idea what functionality in OpenMaLi is stable wrt crashes, and correct wrt maths computations.
I suppose vecmath2 is stable and correct.
Were I to use OpenMaLi I would split it in two JAR files: one (vecmath2) for usage by the game core, and also for the end users of my application; and another internal JAR file containing the rest of OpenMaLi. Which I don't know how stable or well-tested it is -- but I wouldn't bother that much; it's [possible end users of my application] that must be exposed to well-tested code only.

(If this is really an issue, I don't know how it could be solved. I suppose people would have to write unit tests, and... other people had to verify that the tests were correct, and they would have to be very familiar with the relevant maths calculus. Hmm.)

Regards,
Magnus

[Marvin Fröhlich]

The additional memory usage has never been a problem. There aren't thousands of instances stored around your app. And a few kb of additional consumed memory is nothing, that you would have to care about.

I thought about moving back to plain internal float fields instead of the arrays, since this internal implementation is completely hidden behind the API. So this wouldn't be problem of a changing API. I didn't do it so far, since vecmath2 is really stable nd working. And I would risk to introduce bugs, that might be hard to track. So I left it as is and the performance hit on the entire app is quite negligible.

The other code (apart from vecmath2) might indeed contain bugs. Though all the important packages are well tested just because they are actively used. There are some classes, that might not even be worth to be kept in the API. But I think, they wouldn't be used anyway and we shouldn't care about them at all. If there is a bug, we can fix it. So you don't need to be afraid of exposing OpenMaLi to your users. And you can still write unit tests, if you really want to make sure.

Marvin

[LeoMaheo]

(Sorry for waiting this long with answering. I thought my reply would be fairly uninteresting, but... perhaps I should reply anyway.)

The additional memory usage has never been a problem. There aren't thousands of instances stored around your app. And a few kb of additional consumed memory is nothing, that you would have to care about.

My application will, some time in the future, allocate perhaps 1000 (ragdolls) * 16 (limbs) * (1 (physics engine) + 2 (AI modules with copies of physics engine state)) Transform4f.

That would be 50 000 instances.

(I will use a modified version of Kenji Hiranabe's version of javax.vecmath. I believe memory footprint and performance are that important to the application. This modified version of javax.vecmath will probably be of interest to no one except those that write AI modules for my application (which will probably never be finished). )

Regards, Magnus