Forum Replies Created
-
Posts
-
Then something is wrong. Using cgl_ctx for and CGLMacros should always be used, it makes can make a large difference end of day. We can eventually take a look and see whats up.
Quickly, re: FBO’s, I am pretty sure Apple has notes about that, and that you have to do a GLFlush, or a glFlushAppleRenderer (which is a touch more lightweight as I understand it), to get cross thread/context state changes synced. I’m pretty sure that should work.
Nice.
Looking at this, I think checking the context version via the CGLContextObj’s pixel format, which lets you query kCGLPFAOpenGLProfile / either kCGLOGLPVersion_Legacy or kCGLOGLPVersion_3_2_Core.
Secondly, I think state is going to need to be tracked *really* tightly. Shader loading, VAO / VBO /VA attribute caching / re-binding for pointers, error checking, etc. Its a lot.
I am almost wondering if a second compatible share context should be setup, so OpenGL state cannot be corrupted in the parent applications context that Syphon was initialized with. That has drawbacks (state switching, etc), but grants us some potential leniency.
@bangnoise is out until next week – He has done a lot of amazing re-engineering of Syphon, and frankly has better fundamentals than I. I am curious of his thoughts. What is your timeframe for your app, out of curiosity?One thing you can do, is attempt to swap in your Syphon framework in Apps that are Syphon aware, and see how they run. VDMX, Mad Mapper, Resolume Avenue 4, and CoGe all come to mind to test, as they have a lot of different OpenGL state assumptions to juggle.
I was speaking with @bangnoise about this a touch earlier today.
I’m not 100% up on all of the 3.2 nuances, but is there a way to have the same code path work in 3.2 and 2.1 ? My understanding is generic vertex attributes replace all vertex/texture coordinate/normal etc matrices, modes, like OpenGL ES 2.0. This means we’d need a custom shader, shader loading, and additional state management in the framework, correct?
Do you mind putting a giant caveat on the git page for that Syphon Framework that states its not to be used with any shipping code? We’ve tried to do a really good, conservative job with not letting too many pre-release code bases get out in the wild, since compatibility is key. Just saying 🙂
Thanks for tackling this! We definitely want 3.2 compatibility, so any input / insight on this is huge. Thanks again!
This is an interesting proposal. Blitting to/from an FBO is probably going to be faster (assuming that there is no swizzling between formats, and sizes).
Definitely something to look at. Thanks.
I’ve updated the beta download binary, Beta 5, with new features:
*Kinect For Windows hardware support.
*Near Mode
*Depth Smoothing via Kinect hole filling algorithm for slightly smoother profilesI put a newer beta up on http://v002.info/downloads/beta/ – supports multiple kinects, depth unprojection, color rectification and what not.
There is nothing we can do about issue #1, as Jitter actually destroys and rebuilds the OpenGL Context that Syphon relies on. This requires us to tear down and rebuild the Syphon Server.
As for #2 – Ill take a peek and see if that can be fixed.
Yes, I understand that 🙂
However, the OS may be already making a surface out of it, and the new API is used for GPU to GPU screen capturing. What I am saying is this new API may be a faster path. Or not.
Hey Andrea, there may be some faster ways to make this truly OpenGL accelerated. In 10.8, there is a new display capture API (CGDIsplayStream), and in preparation for 10.8, I’ve written a very fast screen capture plugin for Quartz Composer. I wonder if you can use the proxy frame buffer, but then grab the frames off of the GPU (if they ever get there? Im unsure?)
Anyway, its worth looking at:
If you have issues/questions with specific software, you can ask on their forum, but if its some Syphon questions, feel free to ask 🙂
You can easily do that with a few apps, VDMX has full Syphon support. You can arrange layers and make the main canvas larger than each layer, and then positions the layers.
Similarly the new Resolume 4.1 with native Syphon Support, can do the same, and I think CoGe as well.
Quartz Composer, Jitter, Open Frameworks and Processing can all do the same, but you would have to build it yourself. It’d be pretty straightforward to do though in any of them. I’d probably opt for QC.
Hey Colin.
I think this was discussed to death in the Kineme thread, but, to recap:
The OpenEmu QC plugins, are, for now, no longer being actively developed for a variety of reasons. The main one being that OpenEmu has moved to true 64 bits, and that makes supporting both 32 bit VJ applications, as well as both 32 and 64 bit runtimes of Quartz Composer editor pretty much impossible for now, where the code stands. That said, once we get 1.0 out of the door, re-examine some design decisions and see if its possible to do a clean, working plugin implementation, we will do that.
Now, as for the existing OpenEmu QC plugins from 1.0 b7 (1.0 b8 is the newest as of this writing – again which lack QC..) – they should work 10.6, 10.7 and 10.8, provided that you:
Ensure you do not use or run the newer Open Emu – the game cores it installs automatically will interfere with the older B7 QC plugins.
Ensure that you put the old Game Cores from B7 in the right place.
You should be able to run OpenEmu QC. That said, you likely are not going to get support from OpenEmu devs for any issues that crop up.
If possible we suggest using OpenEmu B8, and adopting Syphon. Its much cleaner, and anything that works in the App, can be sent out over Syphon.
Hope that helps.
We are not currently working on one, Niku. That said, since Syphon API and framework is Open Source, anyone can attempt to make one. I am unsure what the Blender plugin api is like, but I imagine it should be doable.
Perhaps post on a blender dev forum and see if any Mac based developers would be interested. We would of course be willing to help, answer questions, etc. Right now however, we aren’t working on one ourselves.
Thanks!
