Processing 1.0 - Processing Discourse - opengl-mode so ... slow

chrismale

opengl-mode so ... slow - how come?
Mar 12^th, 2006, 4:16pm

Hi there!

Well, I'm currently lookin' around for 3d-programming-realtime-rendering-environments (dunno how to describe it other than that).

Now, while using processing in opengl mode, all i get out of my machine doin 24 frames (without having to calculate something frame by frame, just camera-movements) is about 30.000-50.000 vertices per frame. Which is far too little for complex 3d graphics.

My hardware (nvidia gforce4 ti 4600) is not up-to-date, i know. Friends with the same hardware using max/jitter, virtools or vvvv are able to generate fluent output of up to 2 million vertices/frame, though.

How come? Is it just a matter of opengl vs. directx? Or is something within processing slowing down 3d graphics that much?

If anybody could tell me I'd appreciate that. I love the processing environment with all the interfacing possibilities, expandability and community. But if it's too slow, it's too slow.

?

currently into everything

fry

Re: opengl-mode so ... slow - how come?
Reply #1 - Mar 12^th, 2006, 4:32pm

it may be a bottleneck of processing being built on top of java, which is often just not great at moving that much data around.. i've not personally tried to see how much performance we can get out of the OPENGL renderer, so i can't say what things should be able to do.

perhaps post a bit of code and we can also see if there are slowdowns there?

in general, processing isn't as great with just zillions of objects since it's tuned more for building things quickly, so it may just not be what you're looking for if you wanna do super vertex heavy stuff.

chrismale

Re: opengl-mode so ... slow - how come?
Reply #2 - Mar 12^th, 2006, 4:47pm

thanks a lot for the quick answer, mr. f!

here's a bit of just-for-speed-testing-purposes-code i manufactured, here it slows down with more than 30000 for totalVertices:

import damkjer.ocd.*;
import processing.opengl.*;

//initialize with settings:

int totalVertices = 3000;
int totverts = totalVertices/3;
float camrot = -TWO_PI/200;
int maxVal = 15000;
float camDist = maxVal*2;
color vertCol = color(100,50,50,255);
boolean lighting = true;
//initializing:

Camera cam;
int[][][] verts;

void setup()
{
size(1000, 600, OPENGL);
framerate(25);
verts = new int[totverts][3][3];
for(int i=0; i<totverts; i++)
{
for(int u=0; u < 3; u++)
{
verts[i][u][0] = int(-maxVal/2 + random(maxVal));
verts[i][u][1] = int(-maxVal/2 + random(maxVal));
verts[i][u][2] = int(-maxVal/2 + random(maxVal));
}
}
cam = new Camera(this, camDist);
}
void draw()
{
background(0);
fill(vertCol);
strokeWeight(2);
stroke(50,50,50);
noStroke();
if(lighting)
{
lights();
}

for(int i=0; i<totverts; i++)
{
beginShape(TRIANGLES);

vertex(verts[i][0][0], verts[i][0][1], verts[i][0][2]);
vertex(verts[i][1][0], verts[i][1][1], verts[i][1][2]);
vertex(verts[i][2][0], verts[i][2][1], verts[i][2][2]);
endShape();
}

cam.circle(camrot);
cam.feed();
}

// Vec3D - simple 3D vector class
// processing.unlekker.net

class Vec3D {
float x,y,z;

Vec3D(float _x,float _y,float _z) {
x=_x;
y=_y;
z=_z;
}

Vec3D(Vec3D v) {
x=v.x;
y=v.y;
z=v.z;
}

void set(float _x,float _y,float _z) {
x=_x;
y=_y;
z=_z;
}

void set(Vec3D v) {
x=v.x;
y=v.y;
z=v.z;
}

void add(float _x,float _y,float _z) {
x+=_x;
y+=_y;
z+=_z;
}

void add(Vec3D v) {
x+=v.x;
y+=v.y;
z+=v.z;
}

void sub(float _x,float _y,float _z) {
x-=_x;
y-=_y;
z-=_z;
}

void sub(Vec3D v) {
x-=v.x;
y-=v.y;
z-=v.z;
}

void mult(float m) {
x*=m;
y*=m;
z*=m;
}

void div(float m) {
x/=m;
y/=m;
z/=m;
}

float length() {
return sqrt(x*x+y*y+z*z);
}

void normalise() {
float l=length();
if(l!=0) {
x/=l;
y/=l;
z/=l;
}
}

void rotateX(float val) {
// Floats are not precise enough, so doubles are used for the calculations
double cosval=Math.cos(val);
double sinval=Math.sin(val);
double tmp1=y*cosval - z*sinval;
double tmp2=y*sinval + z*cosval;

y=(float)tmp1;
z=(float)tmp2;
}

void rotateY(float val) {
// Floats are not precise enough, so doubles are used for the calculations
double cosval=Math.cos(val);
double sinval=Math.sin(val);
double tmp1=x*cosval - z*sinval;
double tmp2=x*sinval + z*cosval;

x=(float)tmp1;
z=(float)tmp2;
}

void rotateZ(float val) {
// Floats are not precise enough, so doubles are used for the calculations
double cosval=Math.cos(val);
double sinval=Math.sin(val);
double tmp1=x*cosval - y*sinval;
double tmp2=x*sinval + y*cosval;

x=(float)tmp1;
y=(float)tmp2;
}
}

currently into everything

fry YaBB Moderator Offline Posts: 2623 mass, usa	Re: opengl-mode so ... slow - how come? Reply #3 - Mar 12^th, 2006, 5:36pm there's nothing glaring in the code that shoudl be causing too much trouble, i'm curious where the speed is getting lost, i guess it'd have to be run under the profiler. it may be that java just isn't made to do this sort of thing

chrismale YaBB Newbies Offline Posts: 6	Re: opengl-mode so ... slow - how come? Reply #4 - Mar 12^th, 2006, 5:45pm i think for me that means: sketching things in processing further on, but searching for 3d-alternatives. i don't think there really are some... would be great if there is a possibility to gain speed. if there isn't - there isn't. greetings and thanks again, cm
	« Last Edit: Mar 12^th, 2006, 6:56pm by chrismale » currently into everything

toastie

Re: opengl-mode so ... slow - how come?
Reply #5 - Mar 12^th, 2006, 7:03pm

I get really weird slowdown problems with Java and OpenGL as well, but i think its been a recent problem whcih i suspect has something to do with Jogl, since it only seems to happen in applets.
BAsically, for me the problem is that it's almost like it's runnning in short bursts. It's completely smooth and running fine, then suddenly freezes for a couple of seconds, then runs for a couple more, then freezes.

Cristian Gramada YaBB Newbies Offline Posts: 6 Romania	Re: opengl-mode so ... slow - how come? Reply #6 - Nov 2^nd, 2006, 6:20pm I'm having the same issue with smooth \| freeze \| smooth \| freeze on an applet that draws about 100 words in a Star Wars fashion: words are coming at you like you are flying ... The sketch works perfectly when outside the applet.

WebDext

Re: opengl-mode so ... slow - how come?
Reply #7 - Nov 7^th, 2006, 12:16am

I believe this is an issue of too low of bandwidth to your graphics card. The way this code works with OpenGL is that your code is re-sending all those vertices to your card every frame. Each of those vertices has a significant amount of data associated with it and it takes a lot to send all of that to your video memory for it to be rendered.

The solution to this with OpenGL is to use something called a Display List. Display lists essentially accumulate a set of OpenGL commands and data and batch it up on your video card for much faster rendering. Then you just call render on the display list, and apply any transformations you require and it only has to send a few commands to the video card.

The way you are doing it right now is the same as if you had 30k dynamic poly's which most modern hardware would have a tough time handling - however there are ways past these limits with vertex shaders but that's a completely different topic.

I suggest looking up display lists for all your static data, and try to keep in mind, the fastest polygon is the one you arn't drawing - most of the best games out there realy arn't drawing all that much (just occluding alot), they just trick you into thinking they are =)

Jack

JohnG Ex Member	Re: opengl-mode so ... slow - how come? Reply #8 - Nov 7^th, 2006, 1:22am Unfortunately Display Lists require real GL access, so aren't so easy to do in processing. They're also not really all that fast, if you want to get real speed, you need to use Vertex Buffers and the like. And by real speed I mean in the range of 17million triangles/second, e.g. http://www.hardcorepawn.com/Speedy/

WebDext

Re: opengl-mode so ... slow - how come?
Reply #9 - Nov 7^th, 2006, 1:50am

Try this code:

import processing.opengl.*;
import javax.media.opengl.*;
import javax.media.opengl.glu.*;

//initialize with settings:

int totalVertices = 20000;
int totverts = totalVertices/3;
float camrot = -TWO_PI/200;
int maxVal = 15000;
float camDist = maxVal*2;
color vertCol = color(100,50,50,255);
boolean lighting = true;
//initializing:

int testDL;
GL gl;
GLU glu;

void setup()
{
size(800, 600, OPENGL);

glu = new GLU();
gl = ((PGraphicsOpenGL)g).gl;

// Create the display list!
testDL = ((PGraphicsOpenGL)g).gl.glGenLists(1);
gl.glNewList(testDL,GL.GL_COMPILE);

for(int i=0; i<totverts; i++)
{
gl.glColor3f(random(1),random(1),random(1));
gl.glBegin(GL.GL_TRIANGLES);
for(int u=0; u < 3; u++)
{
float x = (-maxVal/2.0 + random(maxVal)) / maxVal;
float y = (-maxVal/2.0 + random(maxVal)) / maxVal;
float z = (-maxVal/2.0 + random(maxVal)) / maxVal;
gl.glVertex3f(x, y, z);
}
gl.glEnd();
}

gl.glEndList();
}

float angle=0;
void draw()
{
background(0);

gl.glMatrixMode(GL.GL_PROJECTION);
gl.glLoadIdentity();
glu.gluPerspective(50.0, 1.0, 3.0, 7.0);

gl.glMatrixMode(GL.GL_MODELVIEW);
gl.glLoadIdentity();
glu.gluLookAt(0.0, 0.0, 5.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0);

angle += 1;
gl.glPushMatrix();
gl.glRotatef(angle,0,1,0);
gl.glCallList(testDL);
gl.glPopMatrix();

println("Framerate: " + frameRate);
}

Cristian Gramada YaBB Newbies Offline Posts: 6 Romania	Re: opengl-mode so ... slow - how come? Reply #10 - Nov 17^th, 2006, 6:05pm Hi I've uploaded my sketch here: http://cyan.ifastnet.com/tags/applet/ (amazon.com most popular tags flying around) but I'm still getting those hiccups even if I decreased the number of rendered tags to 5, especially when moving the mouse Has anyone found a solution to this issue? Thx

fry

Re: opengl-mode so ... slow - how come?
Reply #11 - Nov 19^th, 2006, 6:30pm

on a dual core/processor machine, i don't get the hiccup, which tells me that there's some memory leaking and it's running the garbage collector. i don't see anythign in the p5 code that should be creating memory in this case, so i'm worried that it's in jogl.. however that would be surprising, so i'll need to take it and run with a profiler for a bit to see if it gives away the problem.

fry YaBB Moderator Offline Posts: 2623 mass, usa	Re: opengl-mode so ... slow - how come? Reply #12 - Oct 23^rd, 2007, 6:31pm this issue should be resolved with more recent releases of processing (fixed ~0126).