Is there some way to express OpenGL instructions in a language-independent way?

Question

The title pretty much says it. I was thinking about making a simple video editor, and I was unsure about the "logistics" of various effects and filters and such. Let's say I want to make it possible for an external program to apply some effect to the image. Does it have to be an executed program necessarily, or can it simply be a set of OpenGL instructions that the video editor can parse, and essentially "pass along" to OpenGL. Technically, that would be a program, but it seems more elegant and standardized than making a full fledged secondary program just to apply an effect. Maybe there's a better way?

Edit: Thanks for the answers guys. Here's a follow up though: How do other video editors implement this? The reason I ask is because the answers seem to be rather negative on the above point, so I was wondering how it is done by professional applications.

Answer 1

Does it have to be an executed program necessarily, or can it simply be a set of OpenGL instructions that the video editor can parse, and essentially "pass along" to OpenGL.

There are several ways to approach the problem ("make video editor with ability to create custom effects").

1. Make your editor support plugins, and provide api for making new video effect plugins. Macromedia Director worked this way. New effect will have to be implemented as a plugin library (dll/.so, depending on your platform).
2. Embed scripting language with OpenGL bindings into your application for making video effects, provide basic functions for interacting with internal state of your application. This will allow faster development of effects, but performance will suffer greatly for certain operations. "Blender" (3d editor) works this way, Maya provides similar framework (I think). Basically, this is #1 but implemented as scripting language.
3. Make your editor load GLSL shaders. This will allow you to make some effects fairly quickly, but other than that it is not good idea - while GLSL has decent amount of "power" (functions/maths), GLSL alone won't allow you to make anything you want, because it won't be able to interact with your application at all (pure GLSL can't create textures, framebuffers, and so on, which will limit your ability to make something more interesting). Most likely you'll be only able to make some kind of filter, nothing more. #1 and #2 will give "power" to end user.
4. Implement node-based effect editor. I.e. there are several types of nodes user can drag around that represent certain operations, they have inputs/outputs and user can connect them. Blender 3D and UDK(Unreal Development Kit) have such feature. I think .kkreiger (site is down, google it) used similar technique to make 96kb 1st person shooter. This can be quite powerful, but programmers are very likely to hate dragging graphical entities around with mouse, unless you also provide the way to make such node graph via scripting language (AviSynth had something similar but not quite like that). This can be as powerful as #1 or #2, but will cost you extra development time.

Aside from that, there is no "language-independent" way to make effect. Either you have to use existing language to make effect plugin interact with your application, OR you have to make your own "language" to describe effect. The only language-independent way to deal with this is to hire a programmer and tell him what kind of effect you want. But then again, that requires natural language.

Answer 2

Let's say I want to make it possible for an external program to apply some effect to the image. Does it have to be an executed program necessarily, or can it simply be a set of OpenGL instructions that the video editor can parse, and essentially "pass along" to OpenGL.

Either thing works. However in the OpenGL standard itself there's no such thing like "OpenGL instructions" or "opcodes". But at least in X11 based systems with indirect GLX this is possible, because GLX actually defines opcodes. And it is possible for multiple X clients to operate on the same context if it is indirect. Unfortunately you won't have that option most of the time, as you probably want a direct context, because you may want OpenGL3 (for which not all operations have opcodes defines, which makes indirect impossible for OpenGL-3), or because you're not using GLX.

So the next option is, that you provide the other process with some kind of command/interpreter prompt for OpenGL. If you're lazy I suggest you just embedd a Python interpreter in your program, together with the Python OpenGL bindings. Those operate on whatever context that's currently active, allowing the other program to actually send some Python script to do its stuff.

And last but not least you could provide OpenGL through some RPC interface.

Or you provide some plugin system, where you load some DLL, which does the deed.

Answer 3

The short answer is no. What you are looking for is a HCI guy's dream DSL which would describe presentation regardless of the underlying technology.

Answer 4

Sure, but it would be basically the equivalent of you creating your own language. You can accept OpenGL "instructions" from the user via some text interface (or if you want to somehow put something together as a GUI), then parse those "instructions", and the underlying implementation would execute those instructions in whatever language your application is written in.

Answer 5

Probably not quite what you wanted, you might want to look at GLSL. GLSL is a C-like language that is compiled by the graphic card driver into native "graphic assembly language".