|
|
Unsupported — We cannot guarantee that this software will work properly on Mac OS 10.8 and above. Please be careful.
Release: GL Tools, v20080220
Release Type:
Beta
Version:
20080220
Release Notes
This GLTools beta introduces the glOrtho patch.
Iterators are the worst way to make sphere-grids :) Half of them are inexplicably missing too for the screenshot. Probably due to system load or something. But you get the idea.
Installation InstructionsPlace the plugin file in 
A set of patches for drawing GL primitives and modifying the GL environment. Source code is available on GitHub. CreditsLogo by @usefuldesign.au. Known issues
|
thanks you so much ! Faster than light as usual .....
btw, when chaining Matrix patch + Ortho patch, it is now possible to make perspective correction (ex. : looking UP while keeping the verticals aligned --- sort of). This is AWESOMELY usefull. Thxx again
...one day i'm figure out precisely whats wrong with them.
I've set up some synthetic tests, and iterators looks way snappy except for one use: anything that pumps out opengl primitives. the line patch (even apple's), the sphere patch, the cube patch... they all drop the composition to its knees. Looks like I need to accelerate the structure-driven gltools patches ;)
please please do so. I'm struggling with 100 wireframe cubes inside iterators. It is dreadfull. btw, to my opinion, the best software to handle multiple copies of objects is vvvv, with its spread concept, is far beyond anything else...
I'm using an iterator containing another iterator that renders cubes, and it seems alright (yes, it's a cube grid!).
The thing that really kills iterators is billboard when no input is present. That's been a bit of an issue for me of late, because I had a font generator supplying a font structure to an iterator which rendered some animated text. Because the iterator starts before the font is fully generated, you either get SERIOUS slowdown (like down to 10fps with almost nothing on screen) or a nice line of animated white boxes, depending on how it's configured.
If you get unexpected slowdowns, check for billboards in iterators :)
And this reminds me again to check Toby's font generator, to see how that deals with these issues (I have them sorted in my composition already, but it'd be good to simplify a lot!)
Billboards should be slightly simpler than cubes (billboards are rendered as quads, and cubes are rendered as 6 quads), so I guess it has to do with how the billboard handles (or doesn't handle?) images? weird weird.
I've see glPoints in iterators slow to a crawl (see the Particle System demo smokris made a few days ago), and lines crawl as well (though I think line speed is due to driver issues more than iterator stuff).
Either way: by using structures to drive the render stuff, we save all the redundant GL State swizzling that normally happens when a renderer executes for each frame. This should help dramatically in the proper cases.
Thanks for another data point :) perhaps once enough are collected we'll know what to avoid in future development :)
Billboards work fine (I've had around 100 running at 60fps, with a different texture on each) with iterator, it's just when there's no image input to them (so they have nothing to render) that the slowdown happens.
With cubes, I think the amount of additional processing has more effect that than the number of cubes.
For example, I have 64 (maybe 100 actually, can't remember) running no problem at 60fps. I can add lots of extra stuff as well without problem. The cubes each have a different colour and x/y/z rotation based on iterator variables + math + lfo. If I add an extra math + lfo for say x rotation (so it goes from iterator variable ->math ->lfo ->cube to iterator variable ->math x 2 ->lfo x 2 ->math addition ->cube) the frame rate drops instantly to around 20fps.
The extra math is negligible compared to the rest of the stuff, so I think there could be some limit on the complexity of what you have in the iterator, and performance drops fast when you pass it.
I've seen the same with billboard btw - if I render 50 billboards, each with a blur filter in an iterator, it runs at 60fps, even if the amount of blur varies per frame. If I vary the blur for each billboard (yes, depth of field!) it drops to 10fps. I can only run 10 billboards with DOF at a decent frame rate.
This could of course be some kind of caching issue, where it caches the blurred billboard image and reuses it as the iterator runs through if the blur isn't changed per billboard.
I have 2 other methods for DOF to try out, so it should be possible with a complex scene at decent speed with one or the other :) It reminds me though - is there any kind of z-buffer to image feature? It could be handy...
That was the reason I made the GLReadPixels patch (though there's no depthbuffer reading yet, it's a simple matter). The catch is that there are some bugs in QC regarding grayscale images (as in: they don't work at all), so I have to write a manual converter. That'll be really slow. There are other ways to pull data out of the depth buffer I think, so I'm casually looking into those as well. (this was for DOF on our end as well :) Looks like everyone wants to rewrite Crysis or something ;)
CI stuff (the blur filters) only operate when their input changes, so if the images are static, it does the blur once only.
Can you make a simple corner case where the iterator performance sharply drops (as you described with the additional match patch stuff)? Might help isolate what's going on (I really should just jump in and disassemble the patch, but I feel like playing by the rules for a bit I guess ;)
I had a quick go at reproducing the 'corner' case, but without luck. 100 cubes, no problem, with animation, no problem, with more math + animation, still 60fps. The speed scaled down nicely as I added more cubes too.
I guess the sharp cutoff was to do with the composition I'm working on, which unfortunately is really complex and cutting one part out isn't easy.
Worse, I just fired up my composition thinking to see how many patches are being traversed etc. As soon as it starts up with the statistics panel showing in the viewer, it causes a complete system hang! I've tried it 4 times now, 3 times the interface locked up (everything looks right, the mouse cursor moves, but you can't do anything and eventually a permanent beachball appears), the other time even the mouse cursor disappeared. Forced shutdown was the only way to get it back. Arse.
sometimes, the bugs in QC make me smile :) I'm sorry it's crashing stuff for you.. that's really crazy.
I decided to build a city generator. Really, it's just a grid of objects, but each object is either a cube or cylinder, with varied dimensions and texture. I'm building a structure that holds primitive type, dimensions, etc. with javascript, and using nested iterators to generate the object (one to handle rows, the next to render an object in each column in the row).
I'm getting 60fps with 250 objects, it drops to 30fps if i increase it further, which is pretty reasonable (using an older white imac with x1600 graphics).
There's surely a better way to handle objects though, iterating through the grid seems really inefficient for a static object. Is there another way of doing it that I've missed? I think it'd be best to store the entire city as one object and render that, but can't see a way to do it. How about an object save patch? Useful?
I could also change the structure so it's a list of objects instead of a list of rows containing a list of objects, and just iterate once. But I'm not sure how much that would improve things, and it would make other things more complex... I wish I had more time to experiment :)
Kineme3DObject patches store arbitrary geometry, and they upload it to the video card once and reuse it when rendering the same object in subsequent frames. I'm not sure what the scope of your "object save" idea is (There's no way to get native QC object data), but it might be useful once I understand more.
If you're rendering 256 Cubes, you're only rendering 3072 Polygons per second. There's no reason why you couldn't increase that by at least an order of magnitude (2560 cubes or more) on a modern video card without dropping frames. Even my lame Intel GMA950 can pump out 40960 (~41 thousand) polys per second at 60fps (with no mesh optimization). So that drop you're seeing: that's the iterator overhead and redundant state swizzling.
Yeah, kineme gl would be a better option (and having geometry other than cubes and cylinders would be a massive bonus!), but I'm conscious of time. Breakpoint is in 29 days, and I still have a lot of work to do.
The 'object save' idea would be to save qc objects into a structure, or perhaps as a combined object that could be saved to disk. The 'usefulness' of that would be that you could generate really complex structures that won't run anywhere near realtime, save the vertex data to disk, then load it back in and render it as an object. Not too practical if there's no access to the qc 3d data though like you say.
What would be the best way to use the kineme patches to store a bunch of textured shapes?
Can't you do this with an XML file ? ( = storing objects' coordinates , scale and type ...)
Something like: Object Type (cube, cylinder, custom object) / Position / Rotation / Scale / Texture ID / Any data you need ....
Note: XML reading is no problem. Writing XML is another something. You would have to: 1- ask K to make an XML writer plug (or code it by yourself) 2- ask K to allow text file writer patch to accept structure as input (i haven't tested this)
There's a structure-to-file patch we made floating around here somewhere.... it would probably explode if it didn't contain strings, numbers, and structure though (i.e. images are a bad idea, as are kineme3d objects and any other fancy type)
[edit: found it - http://kineme.net/FileToolsPatch20071211beta ]
This new patch is a very cool add to GLTools ! Thanks Christopher. However i have a little request to improve it...:) When constructing a 3D scene, we always switch from differents views: perspective, and the ortho ones(bottom, front etc....). Do you think there is a way to add a special switch in the GL ortho patch to bypass it without disable all the think inside ...:) ?
Clipping planes are very cool to. I think a GL Clipping plane patch with rotation, origin and "close volume"option( don't know if this is possible) for the plane would be interesting
yanomano.
Perhaps what we need isn't an enable/disable feature, but a different patch all together.
In OpenGL, there are 2 matrices used to project points: The projection matrix (what ortho uses), and the model view matrix (what the Matrix Mult patch uses). If we made an interface to both of those (possibly from one patch?), you could change projections on the fly with much more than just Ortho/non-ortho. I don't know if there are enough different projection types to justify this (I can only think of perspective and ortho, but I'm not a 3D Modeler guy so I'm pretty inexperienced with that stuff).
There would be some math necessary to handle the new matrices, but those could be placed in JavaScript or in a macro patch to take care of it simply.
Thoughts?
I have a vague idea of the low level process with red patches, so it is difficult to know of what I am talking about...:) BUT : The possibility to switch from perspective to ortho and "vice versa" is what I want to explain ! a bolean somewhere : 0 we are in perspecive 1 we are in ortho something like a pointer in the code to bypass the glOrtho command....
yanomano.
I know what you mean :). A bool input to skip the function. It's a 1-line-of-code change (my favorite kind! :).
However: what I was referring to was a more generic approach: For example, let's say you had a 3d scene that you wanted to be visible in Perspective, Ortho, and some kind of weird FoV mode. Each projection modifier would need a bypass input, and you'd have to publish the port to the parent.
So rather than have a zillion inputs (if each camera had a slightly different fov, for example), it would be more compact to have a generic "model/project matrix" patch that you could feed various matrices (the camera parameters etc) to. I don't know if this is over-engineering it or not though... so I'll hold off for now.
I'll try to add the bypass input to the patch for the next beta, probably early next week.
The one line of code is ok for me ! With the 3D GUI macro it will work like a charm !
yanomano.
that sounds like the mozilla foundation's patch processing speed. The small patch I wrote Still hasn't made it into the distributed version, and it's been 8 or 9 months now... http://fdiv.net/2007/05/15/the-secret-life-of-a-thunderbird-patch/
I just fired off a custom build to see if it does what you want. If there's any additional interest in this feature, let me know and I'll make a proper beta. Otherwise, I plan on adding structure support to points and lines before the next beta (hence the delay :)
I read the button story and it make me laugh...:) And for structure with lines and points....woooo ! that's (how to say ?:) The bypass button is ok and work as espected thanks !
yanomano.