Yes, I think thats a good idea.

Yeah, that's definitely a very important thing. But I'm not sure, if a simple vector class would justify a whole library. So those things you spoke about like a physics class should get into it as well. Very important is also a good connection to the Processing Matrix class.

Let's make a collection here and maybe we can split up work then...

I thought a while about your examples of a well usable physics environment. That's not that simple, as Processing's objects are only frame based, i.e. they won't exist the next frame. So we would have to build our own objects, which could be anything. Maybe the best is to build an physicsObject class, where you can attach processing shapes and primitives to and that can be inherited and formed to what ever object you want.

Back to the vector class. Which way should we go? In fact I don't see the point in splitting vectors up in 2D and 3D, but I also think that vectors with more than 4 elements (4 for matrix usage) are not necessary for graphics programming.

Sometimes I wonder, if it would be much easier to use and expand things like http://geosoft.no/software/ (under Geometry). All that stuff has been done a million times, so our goal should be more to make it work with all the processing things. Again like your examples.

Very interesting would also be a collision class. Collision of objects, rays and objects, rays and planes, etc...

I've took a quick like into the geometry class of geosoft.no.

We already have most of the stuff.

There are not that much operation you can perform on vectors.

I think that my library ( always give the credits to Robert Penner ) cover most of the operation.

The only limitation is that it only work on 2d ( not that great ) and the 3D.
So we could merge it with David Heubers FVector library. His library can control vector from 0 till N. We already have a great vector library.

Just to enumerate

Add - Substract  - Multiply - Divide - Negate - Scale  - RotateX (deg) - RotateY (deg) - RotateZ (deg) - Rotate XY (deg) - Rotate XYZ (deg) - Normalize - setMagnitude - getMagnitude - update x , y or z - reset - zero - clone - dot - cross ...

His library has then omitting the stuff already listed above

rotateX Y or Z in radians - equals - isZero - squaredMagnitude.
Plus the ability to construct vector from 1 till N

I mean come guys we already have it..

Then mflux has a physics library with methods like

mass - fluidFlow - world borders - affectField - Springs - massRotation - SpringForces ...

Andrew has 3D physics

Gravity - Springs ( people like those ) ...

The only thing left now

it to find a simple but beautiful way to connect all these components.

For my part I will extend my library to accept vectors from 1 till N like the VectorF library.

After thats done. Some people may want to check it cause java isn't my mother language ( <- new expression ) to add some fancy error checking.

After that's done the vector library is ready.

Then someone has to put the physic system above.

Then we'll have to think of a way to connect it somehow to the matrix library of processing ( the tricky part ). Maybe with some help of Ben or Reas.

I'm open to all suggestions. I'm here to learn. I did'nt finish my studies yet. So people with more experience do not hesitate to post some comment or tips.

Well what I mean with linking to the matrices is this.

For Example:

Vector3D v = new Vector3D(10,40,-1); // notice the z-coordinate
Vector3D motion = new Vector3D(0,0,-3);

void setup()
{
//usual stuff here
}

void draw()
{
  v.add(motion); //but since i'm adding the z-coordinate when I draw an ellipse I have to do
translate(0,0,v.getZ());
ellipse(v.getX(),v.getY(),10,10);
}

The same holds for rotation.

Zackasa, you can do that with existing vector classes. What I was saying is we already have 3-dimensional tracking of points, and drawing objects in procesing is straight forward.

//instead of:
translate(0,0,v.getZ());
ellipse(v.getX(),v.getY(),10,10);

// you'd be better of doing:
translate(v.getX(), v.getY(), v.getZ());
rotate(v.getXDirection(), v.getYDirection(), v.getZDirection());
ellipse(0, 0, 10, 10);

* Because if you rotate a shape then you want to have it rotated around its central point which means moving the draw matrix first and then rotating. I added the fictional function getXDirection(); as a way of tracking the rotation on an object. I'm not sure how you'd store this information in a motion vector. Perhaps in the same was as the camera(..,..,..,..,..,.., upX, upY, upZ); variables?

So back to myT's point, we already have functionality for storing vector points but nothing worthy of writing a whole libary for (debatably) - so what motion/physics methods and data-structures can we provide for users?

Also, I believe that most people can agree with me here in proposing the vector library to be completely seperate and independant from the physics library. The opposite is probably not true, as physics is a pain to program without any form of vector constructions...

We might also want to look at existing C++ physics packages written by others. A lot of them focus on easily enabling someone to write things that have articulated skeleton creatures, thus have things like bones, levers, pistons, in addition to springs and simple gravity/kinematics.

Finally, once a library like this is finished, I'd imagine it would be extremely daunting for any sort of beginner to physics (or even vector) programming to absorb. Is there any way to make this extremely beginner friendly? Or is this not even an issue? Basically: what is the goal here? Write a library for developers like ourselves? Or try to build a library so more people (from diverse fields) can enjoy the freedom that we have when working with vectors or writing physics sims?