lots of triangles...

Performance Tuning
#1

Hi all,

I need to 2D/3D display numerous samples (let’s say 1,000,000 points) in a triangulated surface form. As it will kill performance to have an Object Oriented design, I guess I have no choice to use an Array Oriented design.

I found an interesting one from visad (at the moment I am not interesting in the algorithms): http://www.ssec.wisc.edu/~dglo/docs/visad/Delaunay.html. The Delaunay class has public array fields: Tri, Vertices, Walk, Edges, numEdges, which is what I intended to do (more or less). You could find explanations of these fields from: http://my.unidata.ucar.edu/content/staff/russ/visad/msg01869.html

So, how would you do 3D representation of this class? Of course I don’t want to build Triangle objects, as deal with million objects is far too much. Do you think I could use a low level OpenGL tool (lwjgl, jogl…) to do the representation?

Perhaps I could replace arrays of the Delaunay class by DirectBuffers in order to avoid memory duplication in the GL side??? And also use the jdk1.5 new feature annotations (but don’t know how actually)???

Thanks a lot for all your upcoming advices (and sorry for my not so good English). I know there are some very competent guys around there.

andiqo

#2

You are lost.

Object oriented design doesn’t mean to avoid arrays.

You should know how much points you would have in that program. In fact it might kill performance in any design, if you’d not use VBO. (vertex buffer objects)
You’d like to have a nice memory duplication in GFX card memory, if not it will CRAWL.

My lastest attempt of something so simple was at TNT2 with 32 MB RAM, it was just xxxxx triangles with few lights and it crawled too. Actually that GFX card seemed to have a problem with more than 10000 triangles. Of course fully lit. (and there was shades as well…, I don’t believe there was more than 3 lights on of a type…)

#3

You are lost.

No i am not :stuck_out_tongue:

Object oriented design doesn’t mean to avoid arrays.

Yes it’s true but one could admit that some implementations use arrays of indexes to refer to the geometry as a large array (geom[0][…]=xs, geom[1][…]=ys, geom[2][…]=zs) with only one class, others use Point3d objects with Triangles objects with… But the semantic is not the important point.

You should know how much points you would have in >that program. In fact it might kill performance in any >design, if you’d not use VBO. (vertex buffer objects)

Ok, I know nothing about GL. I’ll try to have a look at these vertex buffer objects. Thanks.

You’d like to have a nice memory duplication in GFX card >memory, if not it will CRAWL.

In the GFX i can’t avoid the memory duplication. But i guess GL is written in C and my program is in java. So without the use of nio.directbuffer i’ll have Java part / C part memory duplication. But I guess GL bindings like lwjgl or jogl extensively use nio…

#4

[quote]No i am not
[/quote]
Yes, you are. ~_^

"geometry as a large array … …with only one class "

Some of others, for example my programs, use yet another aproach. Dipping.

[quote]In the GFX i can’t avoid the memory duplication. But i guess GL is written in C and my program is in java.
[/quote]
It depends on implementation of library for interfacing with OpenGL and on implementation of graphic driver. In extreme case you might have 3 cases of duplications. :slight_smile:

If such arrays would be just integers it would be 341MB 12MB * 3 36MB of RAM. If these would be doubles it might be at most twice as much. Because you’d not transfer all vertices to OpenGL, just these that are possibly in a viewport, you’d have even less amount to transfer. Of course you can say 12 MB of vertices isn’t killer so I’d throw them up all at the GFX, and let GFX sort things up (PS2 way).

It sounds like premature optimalization. In fact with little care it might work even with Graphics2D (depends on the GFX, and VM). If you’d have so much points you might like to use OpenGL to avoid possible problems. You’d have a nice reason to learn OpenGL and that might be useful.

#5

Keep in mind that if youve got a world of (to quote carl sagan) billions and billions of triangles, you are going to run ionto problems OTHER then simpel storage.

A cullign mechanism is going to be essential in your render pipeline. Withotu it your just nevre going to be able to pump what you need through the grphics card.

In order to do thinsg liek view-frustrumn culklign efficiently you need to store your data in appropriate datastructures.

Im not srue what your problem space is but it sounds pretty damn ambitious for someone who has little previous 3D graphcis rpogramming experience…

You may want to tackle a smaller idea first to get soem of that experience.

#6

Thanks for you replies.

Jeff you’re absolutely right.

I am currently working on the datamodel part of a geoscience software, and the 2D/3D is the responsability of another person in my company… I was just wondering if I could avoid memory duplication using directbuffer in my Geometry class.

Probably a thing like discrete Level Of Details would be a good idea.

Thanks!

#7

Depending on how much you can predict ahead the next data you need and how fast you need the data, you might want to consider a disk-bsed scheme and using memory mapped files.

#8

Ouch TB of datas. I remmember when I counted that my game would have theorethically at least 2 TB of data. Then I reduced it by losseless compression to 20 GB.

Are you using triangle maps, or quads?

For majority of geo software sure it would. And multiple LOD index files as well. (at least virtual.)