
OpenTK lagging due to thousands of points
Posted Thursday, 15 July, 2010 - 14:37 by adityatan inHi there:
I just plotted a thousand points in OpenTK window. I also have created a first-person camera on that window. As I tried to maneuver, the window lagged so bad.
Do you think the lagging is possibly due to my code, or is it due to the capacity of OpenTK? (Things were fine when I only plotted hundreds of cubes.)
FYI, I'm trying to make a stress-strain-force-displacement visualization of a pile. So, if OpenTK cannot handle my coordinates, I might as well just switch to another platform.
THank you for your help.
Aditya


Comments
Re: OpenTK lagging due to thousands of points
Using VBOs, I have been able to render tens of millions of polygons at interactive framerates. A thousand points should not be a problem for a modern system, even using immediate mode (i.e.
GL.Begin()-GL.End(), which happens to be the slowest rendering method).Re: OpenTK lagging due to thousands of points
Here's a piece of my code.
I bought my desktop last year; so, I think my devices are fine. Thanks for helping.
Aditya
Re: OpenTK lagging due to thousands of points
Ok, you are loading a file, converting to/from strings, doubles and character arrays every single frame. This is going to be slow no matter the framework or implementation language.
Your best bet is to move this code to a setup function that is called once on startup (OnLoad event). Store the results of the setup function and have OnRenderFrame work on those results directly.
Moreover, do not convert to/from strings in performance-sensitive code. OpenGL works best if you pass floating point values directly.
A faster version of the code might look something like this:
Edit: some code fixes.
Re: OpenTK lagging due to thousands of points
What Fiddler said.
Even if you have 10,000 PLT (tecplot?) files to read in, it's far better to cache those up-front and just change a pointer to which plot you want to display at a given time in a timer of some sort. 10,000 files * 1000 points * 3 floats * 4 bytes per float is still trivial to pre-cache.
Off the topic
... a stress-strain-force-displacement visualization of a pile.
Do you know what you say?
Sometimes I think, it is worth a consideration to divide OpenTK.Development into
A) themes which have to do with OpenTK, and
B) themes a la "Why can OpenTK not write @"Hello World"" (what has also to do with OpenTK :-) ), and/or
C) themes like: "Why not load thousands files in OnRenderFrame?", what means: "Microsoft has said, I am a programmer; well now I am a programmer, why not does OpenTK , what I want?".
Fiddler, you can stop correcting me here, I know what you must say, I know the sides and books too.
--
The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: Divide and conquer.
Re: OpenTK lagging due to thousands of points
All, thanks for the help.
@Hortus: I'm new to C#, OpenTK, and also English as a language. Sometimes my civil engineering world gives me difficulties with its jargons.
I will be back for more questions, for sure. Thanks again.
Aditya
Re: Off the topic
Fiddler, you can stop correcting me here, I know what you must say, I know the sides and books too.
Where did he *start* correcting you? Do you know what you say, and if so, why?
And is it necessary to post a reply in such a rude manner?
Re: OpenTK lagging due to thousands of points
I had very similar code sitting around, so I thought I'd offer a fairly complete solution.
One catch if you're new to C#: don't try to modify the values of the Vector3s once you've added them to a list.
Re: OpenTK lagging due to thousands of points
The solution does not give me the same plot as if I used my old method. Any idea why?
Aditya
Re: OpenTK lagging due to thousands of points
You're still responsible for setting up your matrices prior to calling any of the render functions we've provided. If you've implemented Fiddler's solution, you'll need to include the following prior to the GL.Begin/End pair:
A screen shot of how the two differ would be handy in troubleshooting.