OpenGl in Avisynth!

[Gavino]

Youka, thanks for this - it looks to have a lot of potential.
What would make it even more powerful and flexible would be the ability to pass in more than a single source clip.
Also the ability to pass parameters to the lua script, or some way of accessing avs variables inside it (eg something like get_avs_var("x")).
Are those a possibility for later versions?

BTW, I have discovered that the plugin will not load on earlier versions of Windows (one of my machines is still on Win 2000, and for various reasons I don't want to upgrade it). I expect this is because it has been compiled with Visual Studio 2010 - any chance you could release a version compiled with say VS2008 or the ICC compiler?
(Of course once the source becomes available, I can compile it myself.)

[Youka]

Originally Posted by Gavino

What would make it even more powerful and flexible would be the ability to pass in more than a single source clip.

Thought about it, but didn't needed it before (picture-for-picture method for short clips was enough until now). Maybe later, maybe another one want to join und write it.

Originally Posted by Gavino

Also the ability to pass parameters to the lua script, or some way of accessing avs variables inside it (eg something like get_avs_var("x")).
Are those a possibility for later versions?

Don't understand, why variables of the .avs script couldn't be written in .lua script directly. A bit too much luxury

Originally Posted by Gavino

BTW, I have discovered that the plugin will not load on earlier versions of Windows (one of my machines is still on Win 2000, and for various reasons I don't want to upgrade it). I expect this is because it has been compiled with Visual Studio 2010 - any chance you could release a version compiled with say VS2008 or the ICC compiler?
(Of course once the source becomes available, I can compile it myself.)

Compiled with msvc++ 10 express. Forgot the connection to .net 4. Will change it next version.

[Gavino]

for posting the source code.

Originally Posted by Youka

Don't understand, why variables of the .avs script couldn't be written in .lua script directly. A bit too much luxury

Suppose I want to write a general Avisynth function for some effect, like say your cube example. Attributes like the cube size and rotation speed are hard-coded in the lua script file, whereas I would like to have these as parameters of my Avisynth function and somehow make them available to the lua code.

[tin3tin]

Just found some OpenGL code for making custom transitions for iOS.

A YouTube video showing the transitions: http://www.youtube.com/watch?v=69Tbd...layer_embedded

I'm not that familiar with OpenGL code, but the gl code looks similar to FLuaG: https://github.com/Split82/HMGLTrans...5fa5f1e#diff-3

Would it be insane to think that the actual transitions could be ported to FLuaG?

[Youka]

I'm not that familiar with OpenGL code, but the gl code looks similar to FLuaG: https://github.com/Split82/HMGLTrans...5fa5f1e#diff-3

It's written in objective-c, so it calls OpenGL functions like the standard C api. FLuaG is in Lua, so C arrays are tables and pointers don't exist, but i tried to define all gl* and glu* functions similar to C to allow copy&paste of C code without to change a lot.

Would it be insane to think that the actual transitions could be ported to FLuaG?

Yes, it would be. FLuaG has enough functions to overview (becomes more with newer OpenGL versions), so it wouldn't be good to add combinations of them for limited effects. A collection of code snippets as templates is a better idea.

[Mr VacBob]

You'll probably be better off in terms of future compatibility (and look more like WebGL) if you expose ES2 API instead of the old OpenGL 2-style stuff.

[tin3tin]

@ Youka
Please, keep us posted on you development of that great plugin you're working on and thanks for working so hard on it.

[Youka]

Originally Posted by Mr VacBob

You'll probably be better off in terms of future compatibility (and look more like WebGL) if you expose ES2 API instead of the old OpenGL 2-style stuff.

- glBegin/glEnd blocks are faster than arrays. Converting a lua table into a c array needs more time than the win of rendering speed.
- Display lists are important! Drawing convex polygons, like text, with tesselation again and again is slow.
- ...
- Summary: too many limits (see here).

Originally Posted by tin3tin

@ Youka
Please, keep us posted on you development of that great plugin you're working on and thanks for working so hard on it.

Firstly i'm using/testing it for karaoke effect creation
Currently i'll just fix what i find. I'll continue when i've more time.
Alternative:

Originally Posted by Youka

Would be fine if someone want to support development.

Source i'd posted.

[Youka]

Plans for next FLuaG version.
Release and some example videos + scripts follow next week (i hope).

[tin3tin]

Good to hear that you're making progress. Looking forward to your next release.

(btw. you should proberly make a new thread on your plugin here at doom9 - your plugin can do so much more than OpenGl)

[Youka]

The next version + material will start in a new thread (wish of splitting this thread was ignored ).
Extend it to other libraries than OpenGL... i think graphic is one thing. For audio there could be another plugin.

[tin3tin]

For audio there could be another plugin.

Wow, madness.

[wonkey_monkey]

I've been trying to put some of the stuff in this thread into practice using freeglut (a static build in this case), and I've almost, but not quite, got something that works:

#include "windows.h"
#include "avisynth.h"
#define FREEGLUT_STATIC
#include "glut.h"
#include <stdio.h>

class glsynth : public GenericVideoFilter {   
private:
	void display();
public:
	glsynth(PClip _child, IScriptEnvironment* env);
	~glsynth();
	PVideoFrame __stdcall GetFrame(int n, IScriptEnvironment* env);
};

#define RND (float)(rand()*(1.0/RAND_MAX))

void glsynth::display() {
  glViewport(0,0,vi.width,vi.height);
  glClearColor(0.0f, 0.0f, 0.0f, 0.5f);
  glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

	glBegin(GL_QUADS);
		glColor3f(RND,RND,RND);
		glTexCoord2f(0.0f, 1.0f); glVertex3f(-0.5, -0.5,  0.0f);
		glColor3f(RND,RND,RND);
		glTexCoord2f(1.0f, 1.0f); glVertex3f( 0.5, -0.5,  0.0f);
		glColor3f(RND,RND,RND);
		glTexCoord2f(1.0f, 0.0f); glVertex3f( 0.5,  0.5,  0.0f);
		glColor3f(RND,RND,RND);
		glTexCoord2f(0.0f, 0.0f); glVertex3f(-0.5,  0.5,  0.0f);
  glEnd();

  glFlush();
  glFinish();
}

glsynth::glsynth(PClip _child, IScriptEnvironment* env) : GenericVideoFilter(_child) {
	if (!vi.IsRGB32()) env->ThrowError("glsynth: input must be RGB32");   

  char *argv[]={"foo","bar"};
	int argc=2;

  glutInit(&argc,argv); glutInitWindowSize(vi.width,vi.height);
  glutInitDisplayMode(GLUT_RGBA);
	if (!glutCreateWindow("")) env->ThrowError("glsynth: couldn't create OpenGL context");
}

glsynth::~glsynth() {
}

PVideoFrame __stdcall glsynth::GetFrame(int n, IScriptEnvironment* env) {
	PVideoFrame dst = env->NewVideoFrame(vi);

	unsigned char* dstp = dst->GetWritePtr();

  display();

	glReadPixels(0,0,dst->GetPitch()>>2,vi.height,GL_RGBA,GL_UNSIGNED_BYTE,dstp);

	return dst;
}

AVSValue __cdecl Create_glsynth(AVSValue args, void* user_data, IScriptEnvironment* env) {
  return new glsynth(args[0].AsClip(),env);  
}

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
  env->AddFunction("glsynth", "c", Create_glsynth, 0);

	return "`glsynth' glsynth plugin";
}

If I pass it an RGB32 clip it will display a coloured rectangle as expected in VirtualDub, and the colours change as I step through the frames. But if I hit play in VirtualDub, the OpenGL window no longer updates and the VirtualDub video display flickers between old frames and black frames (a little like what you get if your plugin fails to write anything to a new frame). Anyone have any ideas what's going wrong?

It also crashed VirtualDub on exit but I'm not so bothered by that yet.

David

[Youka]

Originally Posted by davidhorman

  glFlush();
  glFinish();

Try to remove them. Both together are senseless anyway and you don't have to flush data before glReadPixels.

Originally Posted by davidhorman

glReadPixels(0,0,dst->GetPitch()>>2,vi.height,GL_RGBA,GL_UNSIGNED_BYTE,dstp);

From Avisynth, you get BGRA with RGB32, not RGBA.

Originally Posted by davidhorman

  char *argv[]={"foo","bar"};
	int argc=2;

  glutInit(&argc,argv);
  ...
	if (!glutCreateWindow("")) env->ThrowError("glsynth: couldn't create OpenGL context");

It's dangerous to give a window an empty name and glutInit a static array pointer.

[wonkey_monkey]

From Avisynth, you get BGRA with RGB32, not RGBA.

Yeah, I tried GL_BGRA but the compiler didn't recognise it. Once I get it working properly I was just going to pass the textures backwards.

Giving the window a name doesn't make a difference and I'm not sure what you mean about the static array pointer - glutInit seems to work as it is since the plugin is correctly producing frames on a frame-by-frame basis. I guess there must be something different about the way frames are fetched when VirtualDub goes into "play" mode.

David