|
|
Kineme GL code ToolI was thinking about a cool patch and a really cool challenge for you :) A GL code patch ... This patch will work like javascript, GLSL and CI patches. With dynamic input and code in the setting. I think it will be more efficient in term of speed to draw multiples lines, polygons, or points than to do it with an iterator or multiple patches...however it will be very usefull to test code and a wonderfull open GL newbies tool.... Do you it will be difficult to to it ? regards. yanomano
|
This would be really cool (better than some of the gl ideas we've had for complex geometry), but extremely difficult.
Writing programming languages is a bit difficult, but we might be able to reuse an existing one (js or something).
The real difficulty comes when you attempt to texture polygons. The GL code to texture things is very different from the code used in QC to texture things. Doing this in GL would probably be slow, unless there's a clever way around it...
[P.S. I'm also very anti-Inspector Panel, since there's No Limit to the number of problems they introduce...]
I'am not a code guru, so I see it much simply... Perhaps too much...:) see the PDF ...
yano.
:) :)
The blue boxes in your pdf are 'compiled' code. The stuff that gets put in the inspector panel would be interpreted (or, we could compile it on the fly, but that's non-trivial). Unfortunately, you can't just put the contents of a text box into an executable somewhere, there are intermediate steps.
For example:
So while it looks very simple (and it should, it's mostly automatic), there's a lot going on behind the scenes :) we could use the same pieces (gcc's the main frontend program that works all that magic), but it's still a bit tricky to modify code on the fly. There are languages that'll lt you do this, but they tend to be interpreted, not compiled.
I'm still thinking a lot about how to implement this... it's an awesome idea, and it would be amazingly powerful. Difficult to do the 'right way' though :)
Thanks for this details... The interpret VS compile thing come to me ten minutes after my post...:) and I have a good laugh about myself...:) Do you think something like P.O.L 's GL slang patch is the way to go ?
In another way do you think that you can publish an xcode project QC patch for Open GL things...
yanomano.
GL Slang isn't OpenGL, but the OpenGL Shading Language. POL's GLSL patch (I'm assuming this is what you meant by glslang) is for vertex/fragment shaders, not gl commands (glBegin, glEnd, and friends).
There already exist GL bindings for lots of interpreted languages (Python, PERL, PHP, ...).
Maybe we build a QCProgrammablePatch for one or more of those languages and make sure to include the GL bindings?
We still have to deal with getting textures in and out. And with adding bindings for CGL.
Textures are the show stopper, honestly. And not perl. That's not possible, for better performances :)
I was also entertaining the QCProgrammablePatch avenue, and you just gave me another idea: additional programmable patches (to subvert javascript's iron fist). but that's for another thread.
The CGL Macro binding will be ugly and labor intensive (we'd have to expand all the macros manually, since they add parameters to the C-function equivalents...) when populating the binding, but it should Just Work (famous last words). So, as long as we can supply our own binding function set, we're good. (This was totally worrying me a few minutes ago, thanks for the ideas to get this working :)
We can wrap the texture stuff, now that I think about it (I discovered how to assign gl textures with certainty using QCOpenGLPort_Image in order to fix the textured glPoint thing working earlier today), so we could maybe silently wrap that up and cheat. looks like it's not too unrealistic.
[edit: GL bindings are not useful here, now that I think about it: we're going to cook that interface anyway, so as long as we can create our own binding, we're in business]
I'm in agreement that we should avoid PERL if at all possible, for better sanities. :^)
Of the three languages, the PHP GL bindings seem to be the least mature... But I'm kinda leaning toward starting out with PHP, because we're both way more familiar with that language than with Python.
And, yes, let's try to keep QCImages/textures as opaque objects and create our own bindings for applying them to the context.
And, to fix all the stupid "stateless" interpretation hacks that the js patch needs for persistent objects, perhaps we should have an init section (called in setup) and an execute section (called each frame, etc)? A little more complex, but sane stateful operation of programmable patches could allow for some really useful patches. (Not sure if we should venture into saving said state though... then we'd need a few more functions to serialize/unserialize.... )
yes, definitely something like init/fini/execute methods rather than just a singular execute function.
state saving in version 2.0 :^)
A guy does some interesting succesfull experimentations...take a look ...
http://blogs.sun.com/sundararajan/entry/exploring_opengl_java_binding_by
Javascript patch hack to include GL binding possible ?...:)
OpenGL binding for Java
http://osx.hyperjeff.net/Apps/apps.php?f=opengl
yanomano.
The more commonly used Java/OpenGL binding I've seen used is "jogl" (it's a bit farther down the page).
JiggleScript is a development enviroment that combines the well-known web programming language JavaScript with OpenGL, the standard graphics API used in modern 3D games. http://www.jigglescript.com/
I worked a lot on this before the GLTools 0.4 release, but couldn't get anything useful working -- the javascript patch expects to be a green patch, not a red patch (red patches cannot have outputs, otherwise QC quits), and this alone causes quite a few problems. It's a much larger hack that I first expected :)
I'm a bit torn between figuring this out, and just implementing some other generative geometry patch for Kineme 3D... both would be ideal.
Ex : GL pointS with 2 ports : points quantity and one structure input
with a javascript patch to generate the structure like : entry0 = new Object; entry0.x = 1; entry0.y = 0.5; entry0.z = 0.5;
entry1 = new Object; entry1.x = 2*inputs[0]; entry1.y= 0.2; entry1.z = 0.5;
outputs[0] = new Array(entry0, entry1);
Since maybe GLTools v0.2 we've wanted to add structure input support... Almost exactly as you've described (though adding texture coords and maybe normals). This isn't nearly as difficult as modifying the JS patch, so it should be available sometime in the near future (not sure how soon, I'm so busy lately!)
This will be very cool....:) Because single objects patches are GPU consuming...:) Structures can fly in QC... and we can code "a la processing"....
I love near future !