Sign in to follow this  

Dynamic Line/Point width slowdowns

This topic is 4820 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

Hello, I'm currently testing some Line+Points objects rendering, but i fell upon something weird : to have correct distance ratios for the objects, i added a dynamic Line/Point witdh factor (based upon camera distance, quite classic approach), but for every effective change in "(int)width" i have a BIG slowdown (almost 0.5-1 sec). After this slowdown everything is right, it looks like there is something initialized each time i use a new line width, and this info is kept after. Does this sounds familiar to anyone, is there a way to avoid this (apart from using Quads to display Lines) ? (Sorry for the bad english grammar/syntax, I'm not fluent, hope this is understandable anyway).

Share this post


Link to post
Share on other sites
the bottleneck would probably be the way you´re calculating the width... or simply that you have an old graphics card that doesn't allow hardware switching or something stupid.. :D

I use linewidth switching constantly (every frame, ~300 times/sec) without any noticable slowdown...

What happens if you set the linewidth at designtime? is there still a slowdown, or is it the dynamic thing that slows down?

Share this post


Link to post
Share on other sites
No it's the dynamic that slows down. I tested with only one object in my scene composed of only 1 Line & 2 Points, and there is a slowdown of ~0.3 seconds when i move my character and the linewidth changes from a threshold to another (every step of a fixed length cause a slowdown)

With 15 such objects (only 15 Lines & 30 Points !) the graphic card hangs so long that i have an error reporting that the Hardware had to be reseted, thanks ATI.

Having multiple objects with multiple line widths (between objects but also within a single object) don't slow anything down down (i'm stable at 1900 fps in debug mode) as long as i don't make the step that will change the width ratio.

I really love how the line-points object look & i would really love to know what's wrong (because i can't use them if i can't change their aspect ratio, it's looking too weird).

Share this post


Link to post
Share on other sites
Quote:
Original post by Kaeltyk
Having multiple objects with multiple line widths (between objects but also within a single object) don't slow anything down down (i'm stable at 1900 fps in debug mode) as long as i don't make the step that will change the width ratio.


I don't understand that. Having multiple objects with multiple line widths means that you do change the line width between objects using glLineWidth, right? And this is not causing slowdown, but if glLineWidth is used for distance, it slows down? Can you post the code of that example?

Also, it would be useful to know what card you're working on.

Share this post


Link to post
Share on other sites
I use a radeon 9800XT.

Here is the sample code i use :

//_______________________________________________________________________________________
GLlinemesh::Render(float fDist)
{
// glDisable(GL_BLEND); // Disable Blending
glEnable (GL_LINE_SMOOTH); // Enable Anti-Aliasing
// glLineWidth(2.0f);
for (int i=0; i<NumLines; i++) // Loop Through Each Lines
{
glLineWidth((int)Vertices[Lines[i].VertIndex[0]].Size*fDist); // Unfortunatly don't work inside glBegin/glEnd block :(
glBegin(GL_LINES); // begin drawing Lines
glColor4fv(&Vertices[Lines[i].VertIndex[0]].Color.C[0]); // Send the Color
glVertex3fv(&Vertices[Lines[i].VertIndex[0]].Location.X); // Send The Vertex Position

glColor4fv(&Vertices[Lines[i].VertIndex[1]].Color.C[0]); // Send the Color
glVertex3fv(&Vertices[Lines[i].VertIndex[1]].Location.X); // Send The Vertex Position
glEnd(); // finishing drawing
}
for ( i=0; i<NumVertices; i++) // Loop through each Vertices
{
glPointSize((int)Vertices[i].Size*fDist); // Unfortunately don't work inside glBegin/glEnd block :(
glBegin(GL_POINTS); // begin drawing Points
glColor4fv(&Vertices[i].Color.C[0]); // Send the Color
glVertex3fv(&Vertices[i].Location.X); // Send The Vertex Position
glEnd(); // finished drawing
}
glDisable (GL_LINE_SMOOTH); // Disable Anti-Aliasing
// glEnable(GL_BLEND); // Enable Blending
}

if the fDist Factor (for each GLlinemesh) object don't change, then no slow down (when i 'strafe', as the distance ratio don't change).
but if i go for/backward, then the slowdown happens for every step of a fixed distance.
In fact i see that the whole Lines/Points textures (rendered) are corrupted after several of these steps, and the Rendering process take more and more time from the card when rendering these corrupted Lines/Points. if i go back to my starting position, then i regain good textures & good framerate.

That's really like if the card where creating some textures for rendering Lines/Points for each size to render & that i do go over the limit because i claim more and more different sizes. I never heard of these kind of behavior.

Share this post


Link to post
Share on other sites
I tracked (by removing lot of gl colde) the bug down to :

glEnable(GL_POINT_SMOOTH);

if i comment this, then no more slowdown. I really wonder if the GL_POINT_SMOOTH don't use a buffer to store the textures to be displayed...

I'll have to switch to Textures points or sprites, too bad this was exactly the look i wanted.

Share this post


Link to post
Share on other sites
The pb is that my GeForce2 GTS (I do program from 2 computers, one wit a 9800 XT, the other with a GF2) don't have support for lot of extensions, and i'll have to check that this is really supported... else i'll turn to std textured/colored Quads like old sprites.

Share this post


Link to post
Share on other sites

This topic is 4820 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this