Do s and Don't s?

OpenGL Development JOGL Development
#1

Hi,

My scene start to grow more and more big as i am developping it, when displaying on my computers i have a feeling that there might be something i am doing wrong as the CPU usage rise up to 100% directly.

However i don’t think i am using that much of drawing efforts, i made the count that my scene contains

more or less 2400 Quads, 50 triangles, 200 cylinders
30 disks, 18 torus and 4 spheres all textured

I do not think it is that terrible at all, but on a geforce 4 420Go with 32MB on a P4 machine the animation (moving with mouse and keyboard arrows) is not fluid anymore. But on my other stronger machine it is fluid but the CPU is 100% used.

My scene consits of differents buildings and for each the drawing method is put into a display list and only the display list is called at run time.

So i have a couple of question about whether there are some practice that should be avoided in display lists.

Is making "for " loops inside display lists something to avoid?

I tend to create java methods when there is some structure in the building is repeated. Then i call it that method as many times as i need to put this structure.

Is it something to avoid to do into the display lists?
if so is it better to change it into loops?

If you want a visual see to make an opinion of whether it look like heavy i can put the jar on some website for someone to try it.

#2

Hi,

First little question to ask I guess : “Are you using the Animator class?”

If the answer is “Yes I do”, then you will always have 100% CPU used whatever the hardware you can dream of!

#3

why?
im using the animator for a simple programm and it caps the fps on my monitors refresh rate…
and it only uses 10-20% cpu time…

btw:
but if i draw into the the framebuffer and copy it back to a texture (256 or 512) my programm gets realy slow and uses 100%cpu time :confused:

texSize = 512;
gl.glCopyTexImage2D(GL.GL_TEXTURE_2D, 0, GL.GL_RGBA, 0, 0, texSize, texSize, 0);

#4

Yes i do use the animator class, i thought the cpu usage going that up might be a sign of something wrong happening.

In fact my main concern is whether or not the amount of things i am drawing could be the reason for having a slow animation of the scene when moving through it with the mouse and keyboard.

I use 22 different textures and i have checked about using as few state changes has possible as i have read that this is the most expensive step in openGL.

Most of the textures are 256px256px except one or two that are 512512.

Does someone want to give it a try so i sent him the jar file to have a see?

#5

I tried it on another machine with also 32MB memory graphic card and it is much more fluid but still not perfect.

I guess it might be because that machine as an Intel Xeon processor and twice more memory that the other laptop that is completely crawling.

Maybe let’s see the problem under another aspect, what would be a list of things that kill the performances of an application?

PS: is there something to do to clean the graphic memory as it seems under linux after i killed my application if i do not restart the computer any graphics tools seems crawling too.

#6

If someone is interesting to test my app, to see whether the performance a really poor, you can pick it up at

http://www.ccp4.ac.uk/fr45/jogl/Hege3Dtest.jar

use keyboard arrow to strife left and right or go forward and backward,

mouse pointer act as your eye.

Use F to start/stop fullscreen mode.

Esc to exit.

If anyone can give me some feedback about it, it would ne nice. If you suspect any source of a possible issue do not hesitate to tell me. I really want to make it good and efficient, to deploy it and show JOGL rocks!!

#7

Hi, with a really quick test I think your application is not so slow… With a really bad graphic card i can move around and walk quite easily with no really big slow down…

Should spend more time to look at it…

#8

I am using display lists with sometimes many loops containing GlVertex.

Does anyone think that modifying the code using Vertex arrays or Vertex buffers Objects might make a clear change in speed?
If it is likely to be the case i am willing to do it.

#9

I suggest you not use the Animator. Your demo is 100% CPU usage on my P4 2.4Gc, Nvidia 5700LE. When nothing changes, it should not keep drawing. :slight_smile: And I don’t think VBO will improve this unless you abandon Animator .

#10

A generic piece of advice - it may not help but you still to do this nontheless. Run your program through a profiler. At the very least run it with -Xrunhprof. You will see right away what calls take most time and other nice stuff like that.
Another piece of advice. Don’t post jar files to run and never run files that you got online from untrusted source. Put source out- 1) people might actually have tips on optimization 2) much less chance that the program will format your drive.
Rest depends on the platform and features that your card supports (if you are using something that it does not suport and GL has to perform software rendering it is going to take forever).
BTW, I don’t think Animator is doing much; it is just a thread that calls display() and swapBuffers() in the loop. For performance optimization you might want to ditch GLU (cylinders, disks, etc.) and use pure OGL. If you want to stick with GLU, make sure your tesselation (however it is spelled) is not set to too detailes level (one sphere could produce hundreds of thousands of polygons).
Here… Hope it helps :slight_smile:

#11

To ZhaoYou,

Since i am using a keyListener and MouseListener i guess i can make them call the display method rather than having it continously called when not moving, is it what you mean?

To Gverig,
Your idea of passing it through a profiler is interesting but i have to admit i know nothing about profiler … :-[ maybe you can give me hint or information about where to find and how to do.
Concerning the GLU quadrics, you think that creating my own method for drawing disks, Cylinders and Sphere would be more efficient rather than using the library ones?
I have in mynd that they are only shortcuts for polygons generation and rendering.
I the code i am using a couple of Torus also, would you suggest the same or GLUT is not a slow down? BTW thanks for the advice about posting files :wink: i will a more secure archive type to enable people to have code.

#12

Malek:
I actually already did give you a tip about profilers :). I should have been clearer though. Check out http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/java.html#options and loog for -Xrunhprof. This is an option you can specify in Sun’s JVM to ask it to spit out provfiling information. Second option- use Google :). BTW, Google is one of the foremost tools in modern software development :). I found following link after the first attempt http://java-source.net/open-source/profilers
Good luck!
As for GLUT, just make sure you are not generating millions of polygons by one of those calls. I don’t think your implementation of disks and cylinders will be faster, at least not at the moment.

#13

I guess i will try running my application through profiler on my quick machine later, if i try on the one whose slowness make me annoyed it take ages to even start the application…

Anyway i am still investigating about vertex arrays and Buffer Object for future use as the complexity of my application will grow again and again as in final it should be able to contains something like 100 differents buildings style and you can guess how many more vertices and so on it will be.
My question is, i understand how vertex arrays and buffers objects make the memory usage easy to manage and make the speed much quicker than calling thousands of glvertex glnormal gltexcoord.
How should i deal with my cylinders, cones, disks and torus. Should i put their drawing in display lists? (which might be quicker but seems to take more memory as said in opengl website) Should i simply use loops to draw repeated structure? Or should i use another existing way (that i might not know yet) to make their use smooth and efficient. (N.B for one disks, cone, cylinder or torus i currently never put more than 20 rings and 20 slices, i.e 400 quads per objects).

#14

To Malek:
I mean if you leave the event handling to the system, i.e., the rendering thread of JOGL controlled by the system rather than manullay called in the Animator, things will go smoothly.

As to your last post, I didn’t undertand much.
Do you mean that after you used VBO for your torus and cylinders then what kind of calling methods you should use?
If you don’t have tens of thounds of objects I think you can just call them with glDrawElements, and instead, if you want to get better ( but maybe a little better) performance, you can use display list.

And to gverig:
Google is the biggest PhD supervisor in China now :slight_smile:
One can found answers of most of his problems in Google, however, forums and mail lists are very important too.

#15

No i mean that i will use VBO for every polygons i was previously generating with glvertex etc… in loops, making thousands of calls to these functions. But for cylinders, disks, sphere and cones, i am using gluquadric since they have the texture binding enable very easily, for the torus i am using glut. Since every thing except these will be turned into VBO i was wandering how i should deal with them now. Should i put the calls to gluquadric() into display lists (with memory usage more important), only put them in loops (with the lack of efficiency due to the increasing number of them) or give up gluquadric to some other methods that would be more efficient?

#16

I think you can try display list and compare the performance difference for you don’t have much choice :slight_smile:
I don’t know if Xith3D has similar functionalities you want, I think if Xith3D can support cylinders and torus well you many use Xith3D for Xith3D can support VBO well. Or maybe you generate these shapes manually?

#17

Thanks to gverig, by finally looking to all my calls to glu quadrics objects i finally found it !
One sphere that was generating 40 000 polygons unnecessarily!
6 cylinders that were generating 10000 polygons unncessarily.
Just like a magic trick the speed of my application suddenly got back to the quick normal speed it should have!!