FAQ
Cover
This is the archive Discourse for the Processing (ALPHA) software.
Please visit the new Processing forum for current information.

   Processing 1.0 _ALPHA_
   Programming Questions & Help
   Syntax
(Moderators: fry, REAS)
   need for speed
« Previous topic | Next topic »

Pages: 1 
   Author  Topic: need for speed  (Read 529 times)
st33d

WWW Email
need for speed
« on: Feb 6th, 2005, 3:10am »

This is an odd request.
 
I've been playing around with the tron light cycle idea. Seeing what patterns I can get out of some light cycles that always hang right at a wall. So if you have a screen full of them you get a groovy pattern:
 
http://www.st33d.net/processing/tron.html
 
Or you can set them to slowly dodge and burn as they travel, and start to hang a right when they meet a threshold wall that's been burnt too dark or dodged too light:
 
http://www.st33d.net/processing/liteDark.html
 
Then I think, "hey! what about 3D". And I figure out the three dimensional version of always hanging right (look at the code). But to render it on screen I need a pixel-cube type object. And it's slowing everything down a treat:
 
http://www.st33d.net/processing/liteDark5.html
 
Any suggestions for how I could speed it up?
 
Code:

torch [] t;
float [][][] pix;
int xm = 50;
int ym = 50;
int zm = 50;
void setup(){
pix = new float [xm][ym][zm];
for (int ix = 0; ix < xm; ix++){
for (int iy = 0; iy < ym; iy++){
for (int iz = 0; iz < zm; iz++){
pix [ix][iy][iz] = 0;
}
}
}
size (400,400);
t = new torch[10];
for (int i = 0; i < t.length; i++){
t[i] = new torch(random(xm-2)+1,random(ym-2)+1,random(zm-2)+1,int(random(4)));
}
 
}
void loop(){
for (int i = 0; i < t.length; i++){
t[i].trace();
}
background(0);
translate(200,200,250);
rotateX((TWO_PI/width)*mouseX);
rotateY((TWO_PI/width)*mouseY);
//rotateX(PI);
drawCube();
}
void drawCube(){
for (int ix = 1; ix < xm-1; ix++){
for (int iy = 1; iy < ym-1; iy++){
for (int iz = 1; iz < zm-1; iz++){
stroke(pix [ix][iy][iz],pix [ix][iy][iz],pix [ix][iy][iz],pix [ix][iy][iz]);
point(ix-25,iy-25,iz-25);
}
}
}
}//draw;
 
class torch{
float x,y,z;
int d;
boolean light;
torch(float x, float y, float z,int d){
this.x = x;
this.y = y;
this.z = z;
this.d = d;
}
void trace(){
int xp = int(x);
int yp = int(y);
int zp = int (z);
//println(xp+" "+yp+" "+zp);
float c = pix[xp][yp][zp];
if (d == 0 && pix[xp+1][yp][zp] < 245){x+=1;
}else if(d == 0 && pix[xp+1][yp][zp] >= 245){d = (d+1)%6;}
if (d == 1 && pix[xp][yp+1][zp] < 245){y+=1;
}else if(d == 1 && pix[xp][yp+1][zp] >= 245){d = (d+1)%6;}
if (d == 2 && pix[xp][yp][zp+1] < 245){z+=1;
}else if(d == 2 && pix[xp][yp][zp+1] >= 245){d = (d+1)%6;}
if (d == 3 && pix[xp-1][yp][zp] < 245){x-=1;
}else if(d == 3 && pix[xp-1][yp][zp] >= 245){d = (d+1)%6;}
if (d == 4 && pix[xp][yp-1][zp] < 245){y-=1;
}else if(d == 4 && pix[xp][yp-1][zp] >= 245){d = (d+1)%6;}
if (d == 5 && pix[xp][yp][zp-1] < 245){z-=1;
}else if(d == 5 && pix[xp][yp][zp-1] >= 245){d = (d+1)%6;}
xp = int(x);
yp = int(y);
zp = int(z);
if (pix[xp][yp][zp]+ 10 < 245){c =255;}
if (x > xm - 2){x = 2;}
if (x < 2){x = xm - 2;}
if (y > ym - 2){y = 2;}
if (y < 2){y = ym - 2;}
if (z > zm - 2){z = 2;}
if (z < 2){z = zm - 2;}
xp = int(x);
yp = int(y);
zp = int(z);
pix[xp][yp][zp] = c;
}
}
 

I could murder a pint.
TomC

WWW
Re: need for speed
« Reply #1 on: Feb 6th, 2005, 1:03pm »

I think your drawCube function could do with a tweak.
 
You're currently drawing 50x50x50 points, many of them black.
 
Why not test to see if there's anything there first?
 
Code:

 
void drawCube(){
  stroke(255);
  for (int ix = 1; ix < xm-1; ix++){
    for (int iy = 1; iy < ym-1; iy++){
 for (int iz = 1; iz < zm-1; iz++){
   if(pix[ix][iy][iz] > 0)
     point(ix-25,iy-25,iz-25);
 }
    }
  }
}//draw;
 

 
 
That should be a big speed up.  Also, since you're not using fractional positions or fractional space, you could change everything (x,y,z and pix) to ints which may or may not help (haven't tried it).
 
Hope that helps.
 
st33d

WWW Email
Re: need for speed
« Reply #2 on: Feb 6th, 2005, 6:23pm »

I'm amazed at the pick up in speed from leaving those alpha pixels out. I was sure they'd clog up the display soon enough. Plus I completely overlooked how simple leaving the black ones out would be. Cheers for that. I tried implementing ints (I know the floats are pointless, I just couldn't be bothered to edit them out) but the pick up in speed is almost unnoticable.
 
I was discussing this with the father earlier today and he suggested packing the paths of the particles into arrays. This would give the trails a limited life span but it means I can track out lines as opposed to points:
 
http://www.st33d.net/processing/liteDark6.html
 
It accomodates a bigger payload of particles and a bigger pixel cube.
 
Incidentally, I contacted a LCD manufacturer about using a series of LCD plates to make a semi-3D pixel cube in real-space (say 32 pixels cubed 5mm squared pixels). Although I don't know if the polarised glass in 2+ layers would make this idea completely ineffective. Would be nice to have a 3D display though.
 

I could murder a pint.
TomC

WWW
Re: need for speed
« Reply #3 on: Feb 6th, 2005, 10:04pm »

The father had a good idea. (Do you code in a monastery, or have a dad who likes computer graphics!?!)
 
I notice you copy the position arrays one place backwards each time... an alternative to this is to keep track of the most recent array index, and increment it each time, and cycle it around modulus the length of the arrays.
 
There's an example of this here, actually, though I should really comment the code if I'm going to use it as an example...
 
http://www.tom-carden.co.uk/p5/attractor_z_trails/applet/index.html
 
(currentb is the current buffer position for the trails)
(this is made for Processing 70+, so the draw function will need to be renamed back to loop)
 
st33d

WWW Email
Re: need for speed
« Reply #4 on: Feb 7th, 2005, 12:08am »

"%="
"*="
 
I didn't know those were allowed. I've just started looking at Perl because I've been pondering a Html extractor to create a bot that will research ideas for me and I've only just been introduced to other strange assignment tools through looking at Perl. Is "/=" allowed?
 
Since I made the tron particles go eight ways on a 2D plane I've been trying to figure out a way to implement the same idea in 3D. I can't seem to get my head around the appropriate pattern or how many directions that would be involved (as in x+1, x+1 y+1, x+1 y+1 z+1, what next?!). I've covered two sketchbook pages in zeros and ones and I'm still not any wiser.
 

I could murder a pint.
TomC

WWW
Re: need for speed
« Reply #5 on: Feb 7th, 2005, 11:07am »

The middle of all the faces: 6
The middle of all the edges: 12  
Through each of the corners: 8
 
st33d

WWW Email
Re: need for speed
« Reply #6 on: Feb 14th, 2005, 10:52pm »

Still haven't worked out how to to a combination of x,y,z incrementing, but I have worked out how to make the tron cycles travel through time.
 
http://www.st33d.net/processing/liteDark10.html
 
Instead of x+1,y+1,z+1,x-1,y-1,z-1.
 
It's x+1,y+1,z+1,t+1,x-1,y-1,z-1,t-1.
 
Given the cube is looped, so would a time-cube. The particles either appear static in space, traveling forwards or backwards through repeated time, or travel through a time frame.
 
I think I could easily open this up to five dimensions. Just a pity I can't figure out the combinations in 3 dimensions, then I'd be able to make the time travellers move in other ways.
 

I could murder a pint.
Pages: 1 

« Previous topic | Next topic »