Hello list, maybe you can help me: I want to render a big amount of points in opengl. Maybe you can help me to increase the frame rate. I need more than I have at the moment, if possible. At the moment, I''m using glDrawArrays to draw them. My data type for each point consists of three 32 bit floats and three additional 32 bit floats for the normal. Yes, I need the normal because the points have to be lit. The rendering consists of: glVertexPointer(...); glNormalPointer(...); glDrawArrays(...); Not very much, but: I need to draw MORE points if possible. I also made sure that no sensless renderstates are set. This is the setup of my render states: glDisable( GL_CULL_FACE ); glEnable( GL_LIGHTING ); // As mentioned, I need lighting glEnable( GL_DEPTH_TEST ); // Sorry, I need it as well glDisable( GL_BLEND ); glDisable( GL_NORMALIZE ); glDisable( GL_DITHER ); glDisable( GL_POINT_SMOOTH ); glDisable( GL_ALPHA_TEST ); Some other things I checked, without success: glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST ); glHint(GL_POLYGON_SMOOTH_HINT, GL_NICEST ); glHint(GL_POINT_SMOOTH_HINT, GL_NICEST ); My current speed: 50fps for 320.000 points with point size one on a AMD XP 1800+ with a Geforce 4 TI 42000. I also tried to put the points into a display list. But the speed is even slower: 29fps for the configuration mentioned above. Rendering with single calls to glVertex3fv, glNormal3fv etc. results in a frame rate of ~32. Any tips how to increase the rendering speed? Thanks in advance! Lyve _____________________________________ http://www.winmaze.de, a 3D shoot em up in OpenGL, nice graphics, multiplayer, chat rooms, a nice community, worth visiting!

Try removing all the G_HINT functions. On some of the newer drivers they can cause your video card to crap on itself. Don''t know why though. Seems that nobody know why.

The only other thing I can think of: Use Vertex Buffer Objects (VBO''s) to create a write-only buffer in video memory and render those. That''s about all I can think of with the little code you posted.

One question though: Why do you need so much points anyway? It look''s like massive overkill to me.

Sander Maréchal
[Lone Wolves Game Development][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]

GSACP: GameDev Society Against Crap Posting
To join: Put these lines in your signature and don''t post crap!

>Try removing all the G_HINT functions.

Checked it, no speed increase.

>The only other thing I can think of: Use Vertex Buffer Objects >(VBO''s) to create a write-only buffer in video memory and >render those. That''s about all I can think of with the little >code you posted.

This is not possible for us because the positions of the points is changing frequently.
Anyway, thanks for the tip, I will check it with my co-workers, maybe we can come up with a solution. Sometjhing like storing points into video memory temporary while they don''t have to be touched.

>One question though: Why do you need so much points anyway? It >look''s like massive overkill to me.

No, it''s not overkill, I''m sorry. I''m working in a company that simulates milling operations in realtime. We have a workpiece as quad that consits of ton''s of very little points.
The number of points that I mentioned is even not very much. We have large objects of more than half a meter here that has to be simulated with a resolution with more than one needle per millimeter.
We need power, power, power. MORE power, if possible.


_____________________________________
http://www.winmaze.de, a 3D shoot em up in OpenGL, nice graphics, multiplayer, chat rooms, a nice community, worth visiting!

quote:

---

>The only other thing I can think of: Use Vertex Buffer Objects >(VBO''s) to create a write-only buffer in video memory and >render those. That''s about all I can think of with the little >code you posted.

This is not possible for us because the positions of the points is changing frequently.
Anyway, thanks for the tip, I will check it with my co-workers, maybe we can come up with a solution. Sometjhing like storing points into video memory temporary while they don''t have to be touched.

---

I still recommend them. If you create a write-only video buffer for your VBO, you will get the speed of rendering from video memory wile still being able to update the information inside it. That''s the nice thing about VBO''s. It is only slow to read from video memory. Writing is pretty fast :-)

By the way, are you sure that the rendering pass is the slowest part of your app? Have you profiled it? What did it say? How about updating all the positions? For math: try to eliminate any and all sqrt() sin() cos() and similar function. There are much faster alternatives for those, depending on how much accuracy you need. Inline everything. Use a lot of const''s and pass by reference. Avoid unneccecary (sp?) creation of variables. Use ASM wisely.


Sander Maréchal
[Lone Wolves Game Development][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]

GSACP: GameDev Society Against Crap Posting
To join: Put these lines in your signature and don''t post crap!

Do you have a link to a sample where VBOs are used? The only information I get is directly from sgi, not very intuitive. The website from ATI doesn''t seem to carry their sample anylonger.

First thing google coughed up: Delphi3D. Grab the top most zip file. There was another article that specifically created the read-only VBO but I can''t remember which one right now. I''ll post it if I can find it.

Sander Maréchal
[Lone Wolves Game Development][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]

GSACP: GameDev Society Against Crap Posting
To join: Put these lines in your signature and don''t post crap!

Hi Sander!

I''ve finished my implementation for VBOs, I''m impressed how easy it was. However, I don''t get any speed increase on my Geforce 3 here at home. I''ll check it tomorrow at my workplace with the GF4.

Thanks for all the help!

Lyve

Are you sure you created a write-only VBO? There are many ways to create VBO''s. Some are faster, some are not. If you created a VBO that you could read from, this would explain why you don''t see any increase in framerate. Maybe your card just doesn''t go any faster.

I checked the nvidia site. The geometry limit for the GeForce3 isn''t listed (my best guess: about 40 million vertices / second). The limit for the GeForce4 TI is about 113 million. Those numbers are for unlit vertices however. You render 16 million lit vertices per second. Looks like you have not reached the limit yet. Here are a couple of things I can think of. Not sure if they work but might be worth a try:

- Render GL_QUADS instead of GL_POINTS. It could very well be that the video card is optimized to handle triangles as they are the most important geometry type. A quad is automatically split into 2 tri''s so you can still put it all in one buffer. It will increase your geometry and bandwidth four times but the card might optimize it a lot better.

- Drop the lighting and do it manually. Use the GL_COLOR_BUFFER to set the final color of the particles manually. This will work if you are not CPU limited but GPU limited.

- Get a GeForceFX. The 5900 has a geometry limit of 338 vertices a second. That''s trice yout geForce4 TI.

- Choose a different PixelFormatDescriptor. 16 color bits. No stencil. No alpha. 8 bits of depth. No additional buffer. Only 1 backbuffer.

- profile, profile, profile. Maybe you can speed up other parts of your app, like the particle updates (math).


Sander Maréchal
[Lone Wolves Game Development][RoboBlast][Articles][GD Emporium][Webdesign][E-mail]

GSACP: GameDev Society Against Crap Posting
To join: Put these lines in your signature and don''t post crap!

Is that 320 or 320000 points. The decimal point is confusing.

Anyway, a few things that I had to optimise on my voxel engine (used points or cubes, and up to 24 lights) was using a few changes to the code, and also using a 3-way (get that thought out of your head) linked list, and also ONLY rendering the VISIBLE surface.

The visible surface bit is the important part. if you have lets say a cube.

the cross section is

0 0 0 0 00 0 0 0 00 0 0 0 00 0 0 0 00 0 0 0 0 

you sure as hell don''t want to render all of them, so instead render

0 0 0 0 00       00       00       00 0 0 0 0 

I hope that didn''t go all skewy.


Another one is instead of using use

Another is to re-write your math code. This is really helpful for lighting.
Software lighting is also really handy (eg, the 24 lights mine had) and it allows you to loose some detail if you wish to speed it up.

You can change some of your math functions to use lookup tables. Sin, sin^1, cos, cos^1, tan and tan^1 lookup tables with 65534 entries are pretty effective

Another tip if it is still too slow is if you have a static, or atleast a very slow moving light (or one that only moves if you rotate the block) is to have the normals for the lights preset. Basically the lighting will be static, as opposed to dynamic (what it probably is doing now since I think you are calculating the normals once per frame)


Oh and the best thing is to use a cute font, and really spiffy looking buttons



Oh, and optimise your GL code. change states as few times as possible etc, if you can use pointers to the floats (which you are doing) etc and also you may want to fiddle with things like
glFlush
if you have it on by not using it and so on.
If the bottle neck is both your code AND the frequency of your monitor it can effect it.

Lets say your monitor is doing 75hz. If you have OpenGL waiting for it to finishe the blit, and lets say your code cycling is at 3000hz, then that basically means your actual frequency should come out at 73.2hz.

if your monitor was set to 60hz, and your code was cycling at 1000hz, then your overall frequency would be 56.6hz.

if your monitor was set to 60, and you code was only capable of a cycle of 200hz, then you would be capped at 46.1hz.

and so on.

But lets say if you didn''t have your opengl set to waiting for the refresh to end, you would only be restricted by the lowest rate (in most situations the monitors refresh rate) which in the above examples is 60.

I guess by yours since you are getting a refresh around 30, it is rendering code that is causing the bottle neck.

All the same, if you stop opengl from waiting (by default usually) you can gain one or two fps.

Anyway you get the drift

Here is a link to the voxel program I wrote.
http://members.optushome.com.au/jlferry/download/voxel_sfx.exe

currently the model is around 61600 voxels.
default is 6 lights.
click on the ? for instructions