So the controversy continues…

For sure one of the most interesting and elusive topics I have dealt with the last months has been the idea of porting processing libraries to jitter. I’ve gotten a lot of feedback from different friends that are( by far) more proficient java users.
But first an important question: why bothering porting libraries from an applet-based programing language into jitter. Many possible answers can be given, some of them as simple as to say it is an interesting challenge. However, the tool of having java inside jitter provides an interesting window to some of the functionalities that are not ‘native’ to the way jitter handles visuals. Let’s put as a very simple example the traer physics engine: it is a very simple and elegant way to handle physical modeling. So why not using such nice facility within jitter?
Second interesting point to deal with is the way things should be implemented. As far as my understanding goes jitter manages only planar arrays( not multidimensional). There are two basic methods to assign the value of each one of the members:
-copyArrayToVectorPlanar
-setcell

so far I am not sure which one of the methods is better. Or even better, as both methods seem to be quite efficient their usage criteria falls more into specific needs.
Take the next example:
case 1-a random cluster of lines. Then to have something like this on the bang() method:

int plane=0;
int dim=0;
int[] offset=new int[]{0};
int count=amount;
int arrayoffset=0;

for(int i=0;i<amount;i++){
x[i]=(float)Math.random()-0.5f;
y[i]=(float)Math.random()-0.5f;
z[i]=(float)Math.random()-0.5f;
}

gl1.copyArrayToVectorPlanar(plane,dim,offset,x,count,arrayoffset);
plane=1;
gl1.copyArrayToVectorPlanar(plane,dim,offset,y,count,arrayoffset);
plane=2;
gl1.copyArrayToVectorPlanar(plane,dim,offset,z,count,arrayoffset);

from here it would be easier to use the sketch object providing ‘raw’ gl commands. Notice that each plane is filled with an array of values coming from the for loop( don’t forget to declare your arrays or containers!).

case 2- using a wrapper to gain a more ‘literal’ version of the processing original patch into jitter’s matrixland. So for instance:

public void toMatrix(JitterMatrix jm) {
if (jm == null) { return;}
final int size = (jm.getDim()[0] >= _particles.size()) ? _particles.size() : jm.getDim()[0] ;
if (_particles.isEmpty()) {
populateParticleList();
}
Vector3D vec = null;

for (int i = 0; i < size; i++) {
vec = _particles.get(i).position();
pos[0] = i;
jm.setcell(pos, 0,(vec.x() – 200.0f) / 200.0f );
jm.setcell(pos, 1,(vec.y() – 200.0f) / 200.0f );
jm.setcell(pos, 2,(vec.z() – 200.0f) / 200.0f );
}
}
/**
* run once in setup, after all elements of the system are created
*/
protected final void populateParticleList() {
for (int i = 0; i < _ps.numberOfParticles(); i++) {
//
_particles.add(i, _ps.getParticle(i));
}
}

So far I am still trying to put my hands on this approach( thanks Panos for the eye opener!). Not sure if this is more efficient or easier( this type of implementation relies deeply on overriding methods).

We will see, I will try to post more examples as soon as I can!

P.S.By opening the source of the traer physics I was kinda of amazed how old the java lang used on the package seemed to be. There are not even containers on them! Still the library is super cool!