Kineme GL code Tool

I 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

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

cwright's picture
Cool, and hard :)

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...]

yanomano's picture
GL CODE PATCH Simple !

I'am not a code guru, so I see it much simply... Perhaps too much...:) see the PDF ...

yano.

PreviewAttachmentSize
GLCODE patch.pdf88.76 KB

cwright's picture
Interpret vs Compile

:) :)

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:

  • The blue boxes are just like code we write in x-code (in fact, it might even be the tiger GL Point patch, if I'm not mistaken :)
  • In XCode, we do a 'Build', which does the following:
    • preprocesses the source to include headers, including system frameworks (which are very complex with #defines et. al).
    • compiles the preprocessed source to assembly (machine code) for all the configured platforms (4 in our case, ppc, i386, ppc64, and x86-64)
    • assembles the output (this isn't too difficult, relatively speaking) into an object file, which is almost an executable/loadable bundle
    • the object files are then 'linked' to form a usable binary. This includes gluing all the different architectures together in a fat binary.

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 :)

yanomano's picture
Thanks for this

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.

cwright's picture
glslang

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).

smokris's picture
existing interpreted language + bindings?

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.

cwright's picture
textures

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]

smokris's picture
Python vs PHP

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.

cwright's picture
multi-part

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.... )

smokris's picture
definitely.

yes, definitely something like init/fini/execute methods rather than just a singular execute function.

state saving in version 2.0 :^)

yanomano's picture
OpenGL Java Binding by Scripting

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 ?...:)

yanomano's picture
gl4java osx

OpenGL binding for Java

http://osx.hyperjeff.net/Apps/apps.php?f=opengl

yanomano.

cwright's picture
jogl

The more commonly used Java/OpenGL binding I've seen used is "jogl" (it's a bit farther down the page).

yanomano's picture
jigglescript

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/

cwright's picture
Extremely difficult

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.

yanomano's picture
GL patch with structure input ?

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);

cwright's picture
we've wanted to do this actually :)

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!)

yanomano's picture
more powerfull than iterator !

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 !