new compositor - very early stages

#1

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 written 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 started.

#2

no replies yet ?

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

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.

emergence will be cross platform, due to its OpenGL / C++ core.

#3

Hi.

I’ve been playing around with the very same idea for a while but I thought it’s too large task for one person only.
It’s good to see that someone has guts to get into it :slight_smile:

Please let me know if I can help You in any way!

M

#4

I’m curious.

What is a compositing app? What would a user do with it?

Thanks!

#5

Bill,

http://en.wikipedia.org/wiki/Compositing

Used for combining/layering images. Some are written in a 3d environment. After Effects, Shake, Nuke, Digital Fusion, Combustion, Flame, Flint, Inferno, Toxic, etc., are all commercial examples.

#6

well, it looks very nice, i like the UI, i think you are right about the draw the attention to the work itself. Do you have a date to realease an alpha o beta stage ? I´m not an advanced user, i use After effects but i´m starting with Fusion 5 and sounds that this app may work like this. Well i hope you kepp developing this app., i´ll be watching your thread to see how it goes. Good luck. :thumbsup:

#7

Thanks for the link.

#8

Jesus, thanks for your reply. I’m currently exploring OpenGL more to make this compositor run as fast as possible. It won’t have every function of some other compositing apps, which become slow and cumbersome at times-- this will be very streamlined and efficient, and as fast as possible.

I want the GUI to basically frame images like artwork-- like a painting, not like a speadsheet, like many other compositors do. Also, in terms of the processing, it will be very artist-friendly-- like a moving canvas, with some unique tools to create a very different type of flow for compositing. I realistically hope to have a free alpha version available in December of this year.

Bill, you’re welcome.

#9

Interesting. No idea about programming but I would like to test it.

I would like to see controls rather below the preview window, which needs a possiblity the split up in two pictures(for better comparison) or the controls on one monitor and the preview on the other.

Subscribed

#10

Ohhh gosh, I like to play from time to time with code, and I’m starting with OpenGl too. Can you point me to some paper or information on the same subject (make a compo application) ?

BTW your interface looks great to me!

Gian

#11

scrimski, thank you. yes, I eventually want the controls to be a transparent floating window. unfortunately, GLUT does not support this (as far as I know).

liquidik, thank you. yes, I am trying to make it very artist friendly-- like a moving canvas. many of the tools will be implemented differently than other apps.

#12

If you are doing this with OpenGL are you going to do the actual operations using Cg (or equivilant GLSL etc) language? It would be really good if you had the option to write your own nodes.

I guess there would have to be another file to define the interface too.

I think the biggest hurdle with a node based system is getting your DAG working and actually connecting them together rather than the interface.

Looks nice though so far!

Simon

#13

As simon said, writing a compositor is easy. It’s writing the DG/caching stuff that’s hard.

Since you’re going to be leveraging the GPU for compositing operations, be careful how “flashy” you make the GUI: you don’t want to waste fp cycles drawing buttons and sliders.

I’d start sketching up your node interface soon as well, and how that interfaces to the viewing window. You don’t seem to have left anywhere for it to go in your mockup :slight_smile:

You mentioned having pyhon support in the “pro” version. I’d strongly advise writing as much as possible in python and only writing the slow bits in C++. Most of the gui logic could quite happily live in python for example.

Good luck!

#14

What kind of help are you looking for? I can certainly use my C-Fu to dump GLUT and swap over to SDL. So long as you keep everything technically within the Window Manager window (or full screen) I can already think of a couple of ways floating semi-transparent windows and controls could be implemented with p-buffers or SDL surfaces.

Is this going to have audio support or is it purely visual?

Also, what dev platform are you using? Visual Studio, CBuilder, MinGW, Dev-C++?

#15

Hey! Just a thought, but I remember starting a thread on ‘node-based’ programming for a 3d app ages ago, and there’s lots of stuff in there that might be helpful …

Enjoy!

#16

Interesting project, looking forward to see how it will develop.

:slight_smile:

#17

Thank you very much everyone !

Render; “It would be really good if you had the option to write your own nodes”. Yes, they are GLSL currently, will be adding more Cg with the pro version (adding 3d camera, mappable geometry, 3d tracker and such). I will release the the app here (and elsewhere), in binary and source beginning soon (alpha, and later beta) to gain feedback. I will be creating an online repository for shaders/nodes during beta. “getting your DAG working and actually connecting them together”. Yes, this is my bottleneck right now, and where I need quite a bit of help to implement properly.

Playmesum; “writing a compositor is easy. It’s writing the DG/caching stuff that’s hard”. I agree. Currently, I have 3 classes for nodes; 1. creators (file in, perlin noise gen., particles, etc.) 2. shaders (bicubic filtering, blurs, gamma, paint, etc.) 3. layer (with simplish photoshop-style A/B overlay modes). These have all been simply tested by themselves, though not integrated yet. To gain max. speed, I am forgoing pBuffer callbacks to system RAM. Caching will simply exist in the form of writing nodes to disk (right click in node view), so no RAM caching will take place. The current flow is; Image in(from disk)>scene file input>downstream nodes (shaders)>render to screen. In the DAG, I will be creating 2 states for the nodes: view and edit. The user can happily view one node while editing another. “You don’t seem to have left anywhere for it to go in your mockup” In the upper left corner of the image window, there are 3 buttons; image, node, graph. These will be selectable with numeric keypad (1,2,3), or by simply clicking on the buttons. The graph editor will also have a smaller image-viewing window. I don’t want to have them all scrunched together for a variety of reasons. The primary reason is to have the image viewing area be more like a moving artist’s canvas, free of spreadsheet-like clutter. “Most of the gui logic could quite happily live in python for example” Will look into this today-- have written more Python than C++ lately, but have an extensive library of C++ code, and not yet sure exactly how to integrate the Python-- will look into it. Cheers !

Odubtaig; “What kind of help are you looking for?” Feedback/suggestions are extremely valuable. I will be posting many more questions, and code, in the coming weeks. If others would like to help with coding/integration, I willl gladly add their names in the app’s credits (if desired). This could be beneficial in many ways, including giving the app more accessible and open architecture. “I can certainly use my C-Fu to dump GLUT and swap over to SDL.” Excellent-- would like to forgo GLUT for a variety of reasons, probably during beta phase. “Is this going to have audio support or is it purely visual?” My focus with this is purely visual throughout beta. If you want to add audio once the code is available, that would be very appreciated as well. “what dev platform are you using?” Visual Studio now, looking at Novell’s Mono for cross-platform.

DLWarder; “I remember starting a thread on ‘node-based’ programming for a 3d app ages ago”. Thank you for the link ! Will be reviewing that info extensively.

Thanks again everyone !

#18

Hi,
I’m writing node based compositor, too, but I’m not as far as you are. Mine is basic, but it’s working except for viewer:sad: I’m writing it in hope of getting a job in the industry and it’s a known fact that you automatically get a job when you write one of these, right?:D:scream:

And your compositior is looking good so far:thumbsup:

#19

H3ro and T-bat, thank you !

Update; looking into the Boost libraries, particularly graphviz and python for the node structure handling and for C++/Python integration.

Cheers !

#20

SDL is entirely cross-platform with Win/Linux/OS X. It’s originally intended for more games/multimedia type purposes but a lot can be done with it, a lot more than GLUT anyway.

With something that relies so much on performance, I’m loath to go with something quite so OOP as Mono/C#, I’d prefer to stick with something a little more low level.

SDL very much negates the need for the Windows API compatability of Mono and adds the advantage of being Mac compatible. If you stick with OpenGL, SDL and standard C/C++ then cross compatability won’t be too much of an issue. Visual Studio might be a sticking point as I only have a student license but then programming with SDL is a little different from your usual Windows programming, no winmain() for starters. Of course, once you get into cross-platform programming of this style, you’re going to lose half the advantages of Visual Studio anyway.

The only real problem I’ve found with Xplatform OpenGL is doing anything past OpenGL 1.2 in Windows, all those extra bit to legitimise proper OpenGL commands are a PITA. :banghead: