|
iniTree - draw your own recursion treeHello there, I just want to share with you a simple that draws a ternary tree. The algorithm is very simple and uses recursion. Here is what it does in pseudocode (for n-ary tree):
As you can see, I used glRotate/glTranslate and glBegin(GL_LINES)/glEnd() calls, in old OpenGL style. Maybe this is the reason why with more than 8/9 levels I don't obtain good performance. Using vbo will result in better performance, but I'm still not sure about how to do that. It is a very simple plugin, but if used in audio-reaction compositions I think it can produce interesting results. So let me know if someone use it in some cool way! :) Download(plugin and example composition)
|
Cool Stuff indeed LukeNeo :-)
Wow ! Great !
Thanks for sharing !
This is really nice looking, I love it.
You can really do a lot of push/pop matrix stuff to move things around and get pretty good performance, for high iteration counts.
Some things that maybe you could do are to examine if anything that's strictly unnecessary to happen in the loop isn't happening there - that will sap fps for sure.
Also, GL_Lines generally don't perform as well as some other objects, but I guess this can be a bit gpu specific... there's been a decent amount of noise about this on various apple developer lists recently. I've actually had quads (and quad strip) perform quicker, which is sort of crazy considering that you have to emit more vertices. That's not a QC thing, but a mac thing (and maybe just a "thing" in general?).
Apple tends to use what's called a GFList for this kind of thing, and theoretically that should give some better performance, but I've rewritten some stuff to take advantage that, and haven't seen tremendous gain, and sometimes no gain.
... I think an interesting first test on the fps issue might be for you to try rendering points instead of lines and see if the fps picks up alot.
It would also be interesting to totally re-do this as a provider (I can see that will require a decent amount of re-jiggering...basically a total rewrite). Once you've generated the structure, the plugin won't have to execute again until an input changes - it will just hang on to that last struct you generated, and maybe you can take advantage of other renderers, like the mesh creator/mesh renderer, which is pretty stupidly fast most of the time (for some darn reason), or gl tools structure stuff.
Thak you George! :)
..I don't think to do something other than strictly necessary to draw the tree: the code is very simple. :\
That's true. In the attachment you can see that I updated the plugin with a new input: primitiveType (0:GL__LINES, 1:GL_QUADS, 2:GL_POINTS). And.. performance are near the same for all three primitives, even if the amount of vertices in the scene are two times in case of lines or four times in case of quads!
That's a good test. Yes, it would be a grate change in the code, but I'm not sure about how to manage a custom-plugin structure output in the right way: according to Apple, I need to create an NSDictionary with 3 NSArray - one for each coord - containing vertices positions, am I right?.
I'd like to start also with a basic custom plugin that renders N vertices using VBO in the right way, and see how many vertices QC can manage without lose performance.
iniTreeStructure is what you suggested. :)