#### Archived

This topic is now archived and is closed to further replies.

# Fastest Rendering Solutions

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

## Recommended Posts

I normally render all my objects trough the glDrawElements() function wich works perfectly & all Now I come up with the following issue-> I have An AMD XP 2000+(~1.7GHz), with a GeForce FX 5200. I made some tests today-> I rendered 204 800(thats 103 041 vertices and 614 400 Indices ) with lighting and no textures at all, and I get around 12-15 frames. Is this normal/maximum I can get ? Second point, I tryed using ->GL_EXT_compiled_vertex_array As Ive seen its not much differnt, the use of glLockArraysEXT/glUnlockArraysEXT is equal to nothing because nothing happens ->GL_EXT_draw_range_elements_ I understood why its better but I havent seen its effects, and the limitations they talk about, those GL_MAX_ELEMENTS_VERTICES_EXT GL_MAX_ELEMENTS_INDICES_EXT are uh... not to be used, I mean 4096 vertices ?? I use 25 times that and more... ->Display Lists At this sizes, you cant actually see the difference, or at least I havent, the framerate is still the same... maybe when I insert texturing Ill see the performance. Im trying to better more solutions, these are just the first I stumbled upon... have you found other solutions ?

##### Share on other sites
Try GL_ARB_vertex_buffer_objects!

--------------------------------------------------------

There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

There is another theory which states that this has already happened...

##### Share on other sites
Ok thanks, I knew that stuff existed, its just that I didnt had the time to look over it, its the first thing Ill try next

By the way whats the performance increase if youve tested it already ?

##### Share on other sites
Not a rendering specialist, but you have to be aware that for optimal performances, you have to limit the number of vertices that you send to the card

##### Share on other sites
quote:
Original post by cippyboy
Ok thanks, I knew that stuff existed, its just that I didnt had the time to look over it, its the first thing Ill try next

By the way whats the performance increase if youve tested it already ?

Substantial.

You have to remember that you''re unique, just like everybody else.

##### Share on other sites
[python_regious] Im sorry to dissapoint you but that extension is... crap, at least for my needs it is...

I just made tests with that thing and guess what ? while using at every frame the BindBuffer/Null Vertex Array/Draw elements I get around 1-2 frames at that huge model. What I tryed next was to insert all this into display lists... So I get back at those 15 frames that I normally get with the normal ussage of the glDrawElements.
At a second though, maybe its my code thats buggy right ? ok heres a piece of the diplay list calls(remove comments to get in list mode)

void RenderBufferObjects(MODEL3D *M){		static UINT bID=0;	static bool b=0;	if(!b)	{		glGenBuffersARB( 1, &bID );							// Get A Valid Name		glBindBufferARB( GL_ARRAY_BUFFER_ARB, bID);			// Bind The Buffer	// Load The Data		glBufferDataARB( GL_ARRAY_BUFFER_ARB,M->Object[0].nr*3*sizeof(float),M->Object[0].V, GL_STATIC_DRAW_ARB );// where M->Object[0].nr is the number of vertices		delete [] M->Object[0].V; M->Object[0].V = NULL;			b=1;	}int y=0;static UINT LID=0;static bool comp=0;//if (!comp){	//LID=glGenLists(1);   //glNewList(LID,GL_COMPILE);   glEnableClientState(GL_VERTEX_ARRAY);   //   glBindBufferARB( GL_ARRAY_BUFFER_ARB,bID);   glVertexPointer( 3, GL_FLOAT, 0, (char *) NULL );   //	    		glColor3f(1,1,1);   glDrawElements(GL_TRIANGLES,M->Object[y].nrI,GL_UNSIGNED_INT,M->Object[y].I);//nri->indices and I->the index array, it renders corectly no doubt...   //glEndList();   comp=1;}//glCallList(LID);}

##### Share on other sites
I may be wrong, but i think that you should only generate the buffer once, otherwise, you''ll be generating them whenever you render an object.

##### Share on other sites
quote:
Original post by python_regious
quote:
Original post by cippyboy
Ok thanks, I knew that stuff existed, its just that I didnt had the time to look over it, its the first thing Ill try next

By the way whats the performance increase if youve tested it already ?

Substantial.

You have to remember that you''re unique, just like everybody else.

It was higher than 100% for me but it was a xform limited scenario with no fancy per-pixel math or the stuff.
Take this numbers with some salt (application specific, almost 1 year ago):
MultiDrawElements: <5fps
MultiDrawElements with VBO (same data): >20fps (maybe it was around 23, not sure).
Static geometry, with a simple vertex program loaded. No blending, no antialiasing (even with AA on it doesn''t change too much, looks like it was xform limited), some simple texturing.

##### Share on other sites
quote:

[python_regious] I`m sorry to dissapoint you but that extension is... crap, at least for my needs it is...

No, you''re just not using it correctly.

Creating and filling a VBO *every* time you render something is of course going to totally destroy your framerate. Start using it properly and you''ll start seeing results.

Just to give you an incentive... I rendered a similar number of poly''s on my Ti4200, and I got a 50-60% speed increase (100->160fps) by using VBO ( well, it was VAR at the time, but it''s the same sort of thing ).

You have to remember that you''re unique, just like everybody else.

##### Share on other sites
quote:

No, you''re just not using it correctly

I don''t know, his code looks messy but correct. He''s using a static bool to determine if the VBO has been already created or not.

Y.

1. 1
Rutin
67
2. 2
3. 3
4. 4
5. 5

• 21
• 10
• 33
• 20
• 9
• ### Forum Statistics

• Total Topics
633420
• Total Posts
3011793
• ### Who's Online (See full list)

There are no registered users currently online

×