Jump to content
  • Advertisement
Sign in to follow this  
thinhare

better way to paint hundreds of constantly updated moving objects

This topic is 3155 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

hi, folks, I am working with animation, the ideas is to display hundreds of objects (eg. cubes) with each moving around on the screen on its own path, by constantly updating their locations and repainting them. I have tried the display list method, but seemed it did not help much because basically every object had to be repainted again instead of using the data in the display list. When I reduced the number of objects, it animated smooth, so it was CPU, I supposed, the bottleneck for the performance. I was wondering if there is anyone of you who have encounterd this problem before, and what was your solution if you have? many thanks!

Share this post


Link to post
Share on other sites
Advertisement
You can look into something called instancing, which allows for tens of thousands of objects drawn like that.

Hundreds usually shouldn't be a problem though, unless you do a lot of unnecessary state changes. How do you set their positions and animation?
Exactly what changes with every object?
I would use vertex arrays (VBO), and try to make it so that only the transform matrix changes for every object. If it's still slow, I would use instancing or similar. Do you use shaders?

Share this post


Link to post
Share on other sites
hi, Erik,

I created a display list for the object, and each time when the location and the heading of the object change, I did the translation to the location, and rotated to the heading, and then call the display list to paint the object. Is this the right way to do it?

I will look into the instancing later, and try to give feedback ASAP.

Share this post


Link to post
Share on other sites
System: Windows Vista Home Premium + Geforce 9500 Graphic card

From some experiments, I guess it is the CPU that has causes the performance bottleneck.

Share this post


Link to post
Share on other sites
If you don't already have the latest drivers, I would recommend starting with installing the newest ones from http://www.nvidia.com/Download/index.aspx.

Also, what compiler are you using?
Are you compiling in Release mode? (This can be very important)

I think your problem is in another place though, as hundreds of cubes shouldn't be a problem at all. How many triangles do you use per object, and do you draw them with any special properties, like shaders or changing textures?

I tried just now drawing cubes with simple glBegin/glVertex3f and I can draw 5000 before noticing any slowdown (I have a GeForce 8800GT though which is a bit faster). This is also pretty much the slowest method. With vertex arrays you should be able to draw several thousand objects without noticing much of a performance impact.

Share this post


Link to post
Share on other sites
actually I am not using any compiler, it is JOGL (OpenGL with Java) that I am using. I have done some tests on VBO and it seemed quite fast, but there are still something to be figured out, until then I cannot be sure if it is a better solution than display list, because of when it comes to the case I described above, I still have to modify the vertex data for each time repainting the screen. I'll let you know when I finish the tests.

Share this post


Link to post
Share on other sites
Quote:
Original post by thinhare
actually I am not using any compiler, it is JOGL (OpenGL with Java) that I am using.


Java is a compiled language (it just compiles to JVM byte code instead of machine code), so what you are probably using is Sun's javac compiler or perhaps an integrated compiler like Eclipse uses.

Aside from that, calling OpenGL functions is always expensive and something you want to limit as much as possible, even more so from Java because going through JNI makes them a bit more expensive.

Aside from that, if you have to update the content of the VBO every frame you are probably doing something wrong in regard to what you are putting in there.

Share this post


Link to post
Share on other sites
Quote:
Original post by thinhare
I have done some tests on VBO and it seemed quite fast, but there are still something to be figured out, until then I cannot be sure if it is a better solution than display list, because of when it comes to the case I described above, I still have to modify the vertex data for each time repainting the screen.


As the above poster said, you should definitely not have to change the vertex data. Most animations can be done with changing matrices instead (rotations, scaling, translation, and combinations thereof). Even so, do you mean change the vertex data once each frame, or for each object?
Once per frame shouldn't make much of a difference for a VBO, but once per object is not a good idea.
If it's still slow, try posting your render-loop and perhaps we can see something that might cause a slowdown.

Share this post


Link to post
Share on other sites

hello, Erik and BitMaster,

Thanks for response.

I am still experimenting with VBO, and having a very weird problem, which you may have seen in a new thread because I think it is another topic. If you know what it is about, please help me out.

In the scenario, the only thing that does not change is the shape of an object, so I put it alone in display list, but the location and the heading of the object is changing constantly, and what I did to that was translating and rotating, which was actually changing the matrices internally. The result was only slightly faster than immediate mode, and was way too far from my expectation. that's way I am trying VBO techniques. Or you have better solutions for this, please shed some lights...

Thanks!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!