new compositing app - early stages

[buddamint]

hey all,

looking to cut together a compositing app, which will be free, and most likely will have an advanced commercial version added later. it will be entirely based in OpenGL-- the UI, as well as the processing-- to increase speed dramatically over AE/Shake/etc.. The project codename for the app is; *emergence, but that may change. the compositor will be node-based.

I already have much of the code already for processing blurs, blooms, upscaling, image loading, etc., and a base for the UI already implemented. may need a bit of advise about how to cut it all together (haven't made any freestanding apps in many years, this will be my first in OpenGL).

already have code for OpenEXR handling (read and write), and 8 bit, 16 float and 32 float RGBa happening. also already have HDR images able to be loaded with basic gamma correction in the basic app core, but am having problems with the control implementation. i have clocked the ability to load 211 frames of 16bit float images per second on my athlon x2 3800+ in the base app.

as this is my first real app, I'm wondering how many people in this forum would be interested in possibly helping out to get it going.

here is a mockup of the GUI thus far (subject to change alot);

http://img.photobucket.com/albums/v251/buttachunk/emergencemockupcopy.jpg

it is very simple-- designed to take the GUI out of the artist's way. it's monochromatic focus is to draw the attention more to the images rather than the 'overall picture' perceived by the artist. it may include some python scripting capabilities in the pro version, but for now I'm focusing on building the app to work basically first, and to be streamlined and fast as hell.

[VFXTalkDotCom]

check out the openlibraries at www.openlibraries.org and openlibraries.sf.net we are using them as the core for jahshaka v3 and they are very powerful... would save you a lot of time :)

[Hugh]

Do be careful about using OpenGL for processing everything.... A renderfarm might be made up of machines without graphics cards, on which OpenGL won't work.... (I believe)

[VFXTalkDotCom]

a cool feature in the openlibraries is the ability to write plugins that work on both the cpu and the gpu - allowing you to use the gpu version of a node on your workstation and the cpu version in your renderfarm...

[buddamint]

Jah,

thank you-- will look into those ! right now, I'm trying to figure out how to create and link the nodes within the interface. I already have the code for many nodes,,, any suggestions on how to create and link them within the interface ?


Hugh,

thank you. the idea is that this compositor will be fast enough that you won't need a renderfarm to render-out comps. The tests so far show the ability to playback the equivolent of 9 layers of 1080p OpenEXR float RGBa in realtime on an average Athlon X2 3800+ with a very modest geforce 6100 (my internet computer), with no 'rendering'. With more advanced hardware, this will increase dramatically. I also have the code for bicubic 32x32 sampling within OpenGL for final high-quality sampling.

[ShadowMaker SdR]

How modest is the disk array you need for that? :-)

[buddamint]

Shadowmaker,

it's a hardware-simulated test of the framebuffer. Basically-- it can be this fast, as long as the harddrives feeding it are able to provide the data.

[buddamint]

To clarify my above statement, I've tested/simulated various permutations of GPU buffering. The data above is a essentially a memory speed test (not a GPU/processing test) reading an image from system RAM (simulating read from disk), directly to the GPU. for those who think "well, why can't a get XX app to run anywhere near that fast ?", it's because many apps cache the images in the RAM which involves yet another step back to the RAM and back to the GPU, which can slow performance by up to 50%, not to mention GP cycles used for fancier interfaces and processing other features slowing down the whole deal.

[jdboyd]

Do be careful about using OpenGL for processing everything.... A renderfarm might be made up of machines without graphics cards, on which OpenGL won't work.... (I believe)

Actually, you can use Mesa (software only implementation of OpenGL). Reportedly Autodesk's Burn uses Mesa. But Mesa doesn't support shaders, which may make using it more complicated.

Another problem with using OpenGL is that results are inconsistant across cards. Flame and Smoke people get different visual results rendering on SGIs versus Linux workstations (Nvidia graphics) versus Burn (Mesa). Mainly this means that if OpenGL is used for rendering, you have to be careful how you mix and match clips from different render sources. A possible way around this would be to offer Mesa on all platforms for doing final renders. If one does this, it would be nice if they made it optional. I'd imagine that users with only a single workstation and no farm would rather not have to wait for a Mesa render.

[VFXTalkDotCom]

well you dont really need mesa - ati and nvidia have native drivers that rock on linux and run the full implementation of opengl on linux, why anyone would use mesa is beyond me as you mentioned there is no supoprt for pixel shading etc...

there are also efforts out there to reverse engineeer the nvidia drivers, ati has released osss drivers and intel has released oss drivers...

we started building a node based compositor using the openlibraries and all the infrastructures is there that you would need for this project if you check it out - also its under the lgpl so you can grab cvs and play around...

we also implemented cpu fallbacks for gpu rendering - to allow you to render on renderfarms and to support effects on systems that dont have up2date opengl drivers or full horsepower etc

[jdboyd]

well you dont really need mesa - ati and nvidia have native drivers that rock on linux and run the full implementation of opengl on linux, why anyone would use mesa is beyond me as you mentioned there is no supoprt for pixel shading etc...

And those native drivers do you no good if your renderfarm has either no graphics cards, or something pokey like Rage graphics, like quite a few Opteron servers out there have.

BTW, aren't drivers from Intel, as well as the OSS ATI drivers based on Mesa?