Hi,
I’ve a scene full of triangles. There are more than 30,000,000 edges. But I can not see all the edges in the scene. I know that none of the edges covers the others. I want to know if there is any limitation for the number of edges (vertices) in openGL ?
I would be so thankfull if any body help me.
Short answer is no.
OpenGL is pipelined so once a triangle is rendered OpenGL can forget about it, but this is only true as long as you feed the triangles to OpenGL, if you want to use display lists or vertex arrays it must all fit in memory.
Mikael
But you’re probably unable to render 30 meg triangles on any display, because there is only a limited resolutions.
That is, if you’re running 1024*768 pixels that is 3/4 meg pixels.
There is no way to draw 30 million triangles on that display and have all been actually rastered if they don’t overlap.
Thanks for your answers,
I’m so sorry but I’ve put one 0 more than reality. My mesh has 3,000,000 edges. But It seems there are limitations.
I’ve spilte my data to 4 diffrent glBegin/glEnd sessions and without any problem I got the results.
So it seems, at leaset for GL_LINES there is somehow a limitation.
Refere to Mikael’s answer, I’m using display lists (but single one for that purpose), but it makes no change.
Don’t you think that this problem comes from type of vertex counters (variable over flow)?
It’s possible that there is some limtation on the amount of vertices you can put in one begin/end session. You have to check the spec for that.
Mikael
Sorry, but what are you talking about? How do you want place 3,000,000 different edges on a screen? You have to have nice resolution on your monitor. About 2000x1500. And then every edge would be one pixel.
OpenGL can’t have a limitation, because the vertices you draw are not stored (positions of them).
Yes Erazer,
You are right, but it is possible. Whenever you want to handle a big data set you have such a problem. But it is one of the aims of CAD softwares.
In addition, I’ve seen the specification (MSDN) of glBegin/glEnd. They said that there is no limitation. But at least I’ve got such a problem and I said before how I resolved it.
Also EraZer, I should add these:
I think it is not a problem of memory (the memory which OGL allocates). It may be the problem of counters or the problem of my OGL version (1.1).
Anyway, It works when I split the data to some sequential glBegin/glEnd sessions.
But if you have a better idea let me know.
Thanks
Hi !
You should not look at the MSDN docs of OpenGL for anything but the syntax of the function calls, you have to look at the OpenGL spec (available on this website as .pdf files).
Mikael
From what I know the spec is a bit vague about the size of displaylists. As far as I recall the spec doesnt define a minium or maximum size for a displaylist, leaving it up to the implementation. That of course means different implementations (SGI, Nvidia, Ati, …) will have different limitations.
Unfortunatly there is no “nice” way to query the maximum size the displaylist can have. The “ugly” way would be to generate a dummy displaylist and add verticies to until you hit an glError(). Not nice and it may not work in all cases.
Personly I would not put more then 64K verticies into one displaylist because I seem to recall that some implementations did not handle big displaylist very well because they had to swap out textures/other displaylist/etc… from the video ram in order to make room for the “big” displaylists thus slowing down rendering tremendously.
Ya, it is a good idea to split up the vertices. But I want to ask, if I split up the vertices, does it cause any difference?
for sure it cause an over head (calling diffrent display lists), but I mean more extra processing efforts or even using much more memory ?
Putting more than 65k vertices in one begin-end is very uncommon. You might have hit a bug in the OpenGL implementation you used (1.1 looks like Microsoft’s?).
Instead of splitting into multiple display lists as Honk proposed, it should also work to use one display list and split the primitives inside it into chunks of less than 65k vertices each. In my experience this is better than one huge primitive and actually built and ran faster.
Actually I think it would be best to generate multiple displaylists and wrap those into another displaylist (nesting level 1).
This way the driver dosent have to handle one giant displaylist but only smaller displaylists that where just called from one “uber” displaylist. That should help reducing vertex/texture/etc. swapping.
Thanx
I think the idea of Honk is so useful and I’m going to use it. Also it is so useful if I want to change some of the edges (editing).
Just a word of warning. Displaylists are meant for static data only. Putting data that you want to modify into displaylist is bad, in this case you are better of using something like VAR’s or VBO’s.