current state of openFrameworks in TD

Hi guys,

just a quick one here - openFrameworks still only supported with 32bit cPlusPlus CHOP/TOPs?

currently trying to build a device interface, and using an oF addon to do it is gonna save me a load of time → but if I can only go down the 32 bit route, I might be best taking the time to try and interface with it with native c++.

Thoughts?

O.

:smiley:

openframeworks 9 supports 64 bit. There are some changes to the steps in getting it to work as a Cplusplus TOP, but wiki has not been updated yet for this new openframeworks version and/or VS2015. Results in getting it to work in TD vary so far in the forum. If someone has a simple working ofx 9.0 64 bit example we should post that on the wiki.

cool.

i managed to get oF 0.9 compiling in vs with the c++ chop 64bit example. i haven’y yet tried implementing any oF functionality yet - but will be looking into it tonight.

with some success will post a project back here for people to have a look at.

would be good to see someone do the same with the TOP :slight_smile:

O

i managed to compile OF 9.0 in VS2015 in 64bit with the c++ OpenGLTOP example (rotating squares). But OF functionality does not really work so far it seems - need to investigate further. If anybody has a TOP showing OF 9.0 functionality, that would be much appreciated!

I’m working with 0.9.3 but the openFrameworks draw functions don’t do anything. But at least it’s not crashing, and it works well in debug mode (just press F5 in Visual Studio and it should launch TD). After I get the rectangle drawing to work, or if I can just pass-through the movie-file-in, I’ll work on instantiating ftOpticalFlow. You’ll see that it’s currently commented-out in a few places. If you can improve it in any way, please do a pull request. Thanks!

[url]https://github.com/DBraun/OpticalFlowTOP[/url]

It seems like oF might be changing GL contexts behind the scene somewhere. I had only briefly tried to track it down but couldn’t find anything obvious in the oF code.

I translated a few examples provided by openFrameworks so that they work in TouchDesigner, namely shader/04_simpleTexture, shader/08_displacementMap, and math/particlesExample.

In the provided examples an ofAppNoWindow is used to prevent openFrameworks from creating an OpenGL context (we want to use TouchDesigner’s). However the problem is that ofAppNoWindow creates an ofNoopRenderer which as the name would imply, doesn’t actually do any rendering. This means that any draw calls (or similar) will either crash or do nothing because those functions are querying for a renderer that is missing some crucial functionality.

Basically any image or shader draw (and other) functions act as an interface to the renderer. Because the ofNoopRenderer isn’t particularly useful, the function calls must be more explicit; skip the shader/image (or whatever) function calls, and just call the renderer functions directly. Some additional setup is required that is illustrated in the examples, such as glewInit().

Download the attached zip and put the examples into apps/myApps in your installed openFrameworks. The .sln is setup to build .dll’s at the moment, and they can be found in /bin. Open the .sln file and build and you should see the .dll there. When you run the .toe of the example, simply import the appropriate .dll.

A couple more things to note: openFrameworks by default looks for the /data directory in the same directory as the executable, which in this case is the installed TouchDesigner. You can get around having to put the /data directory in your installed TouchDesigner by using ofSetDataPathRoot(relative_path_to_new_dir) to set the new directory containing your /data. relative_path_to_new_dir will be the relative path from the TouchDesigner executable to your new directory. In addition, your openFrameworks and TouchDesigner should be located on the same drive because openFrameworks is not capable of setting new path roots across drives.

If you have any issues getting the examples working let me know, and hopefully this is enough to get you started! I’ll be working on updating the wiki with this, and any additional information.

Cheers,
Eric

Examples can be found on the wiki:
derivative.ca/wiki088/index. … Frameworks

EDIT: Modified the example to error on compile, just so it’s apparent after download that the new path needs to be set with ofSetDataPathRoot().

Eric this is fantastic news. I have been trying on and off for the last months to get openframeworks 9.x to render anything in the correct Touchdesigner FBO, was banging my head on the table why normal c++ opengl code worked and openframeworks rendered into nothing :unamused:
Thank you so much for your help - will try immediately.

Then I still don’t really understand why older examples using ofAppNoWindow.h (such as this facetracking example) did work out of the box - the ofAppNoWindow of openframeworks 8.4 and before also created a ofNoopRenderer?

The function that causes everything to break down is ofGetCurrentRenderer(). I had a look at the old ofxCvColorImage::draw and ofxCvGrayscaleImage::draw, and they don’t make that query. They appear not to actually use any of oF’s renderers, and use ofTexture directly.

Since then, this has been more and more abstracted using things like ofGetCurrentRenderer() and ofGLProgrammableRenderer.

thanks for explaining!
Do you still see any option in your setup to set the openGL window size always automatically to the current C++ TOP resolution?

You can grab the resolution width and height of the C++TOP in ::execute using:
outputFormat->width
outputFormat->height

Then use these to values automatically update resolution:
ofSetupOpenGL(&myWindow, width, height, OF_WINDOW);

It’ll take a little rearranging to get it working; I’ll update the attached examples and wiki with this!

Eric

Thanks for setting me in the right direction. For your example, this works without specifying the TOP path in the C++ code.

[code]void
OpenFrameworksTOP::execute(const TOP_OutputFormatSpecs* outputFormat,
OP_Inputs* inputs,
TOP_Context *context)
{
if (width != outputFormat->width || height != outputFormat->height){
width = outputFormat->width;
height = outputFormat->height;
ofSetupOpenGL(&myWindow, width, height, OF_WINDOW);
plane.set(width, height, 10, 10);
}
context->beginGLCommands();

// shaders must be loaded within the TouchDesigner context
if (!isSetup)
{
	setup();
}

begin();

////do your stuff

end();

context->endGLCommands();

}[/code]

Getting to try this now, thanks Eric, that’s awesome :slight_smile:

I’m curious as to cook time results you’ve all had. The texture moving and displace map example take about 24ms/frame and the particle example takes about 60ms/frame. Running those examples from oF native, they’re quite fast. Any thoughts on where this extra overhead is coming from?

Are you running it with the debug dll by any chance? That could cause a considerable slow down.

Running the release dll’s in TouchDesigner I get around 10-13ms for each of the examples.

Eric

Ah yes, release seems quite a bit faster. Will continue testing.

Hello,

Thank you so much for providing the source code! I am running into some errors when I am trying to compile the code in VS2015. The OF directory is placed within the Program Files Directory with the Derivative directory.

When I try to compile in the x64 platform, I get the following error:

Error LNK1181
cannot open input file
‘C:\Program Files\of_v0.9.3_vs_release\apps\libs\openFrameworksCompiled\lib\vs\x64\openframeworksLib.lib’

I had put the libs folder inside the apps directory instead of the default location.

Please let me know if more information is required. Thank you and regards.

When you open up the .sln do you see a openFrameworksLib? That will need to be compiled alongside the example project, and it will create your .lib in /openFrameworksCompiled.

It’s trying to link with the Release/x64 .lib, so compile the openFrameworksLib under that as well.

Eric

Hello Eric,

Thank you for the quick reply. So, this time I did compile the openframeworksLib. Now I am getting a diff error. Here is a screenshot.

Regards.

That error is due to you trying to run a dll as an executable. Currently the .sln is setup to build a dll, which can’t be run on it’s own.

After you build the dll in Visual Studio, you can open up the respective toe file and import the dll as a parameter in the C++TOP.

If you are getting that error it means that the project was already built, and you can find the dll in the bin directory.