Is there a Houdini-like 2d app similar to Photoshop?

[magneto]

I am never a fan of Photoshop for a lot of reasons ranging from the worst scripting API to very cumbersome workflow, i.e. hotkeys and crammed functions all over the UI. I shouldn't even mention the bloatware™.

Is there an app that basically works like Houdini but meant for 2d tasks similar to Photoshop, GIMP, etc?

I am not sure if Nuke would be considered as I never used it, but I feel like their focus is not exactly that, so some fundamental features might be left out.

I feel this is an untapped market that if were to be realized, would destroy the competition. How awesome it would be to have some procedural operations on an image where the file size is very small, not like Photoshop storing multiple copies of the image per layer. Also AFAIK there are no steps that you can backtrack like Houdini.

I know Combustion has some vectoral painting tools, but I think there are a lot of gaps in these tools that prevents them to be used effectively in place of the traditional 2d applications.

Houdini's COP context is close I think but not sure if every standard feature in these 2d apps is provided. I think painting is missing for example.

Thoughts?

EDIT: Here is a wiki link that compares the expected features for raster graphics apps (scroll to features section):

http://en.wikipedia....raphics_editors

Someone should add Houdini in there too, it has most of those features

Edited May 1, 2013 by magneto

[br1]

There a a few softwares trying to go to that direction.

the first I've seen, a few years ago, was Naked Light.http://www.naked.la/ (Osx and now on iOS) . Then there's also nodewerk, http://nodewerk.com/

Nodewerk looks interesting but I wonder if there's any painting involved.

I actually do most of the work with nuke when I have to do 2D stuff, opening Photoshop only to add text with blending effects. Photoshop is so destructive with it's layer approach that I try to avoid it as much as possible. I find it really painful when your work with renders, if you re-render your stuff you have to redo everything in Photoshop, you can't just swap your sources which to me is really stupid.

I'd really love to find a working node-based Photoshop clone, in the meantime I'd stick to Nuke or Fusion.

[dulo]

I often use fusion as a replacement for photoshop and I quite like its non destructive node workflow. especially color correction and masking is really fine.

they should offer a light version because the full version is quite expensive and most of the features i dont really need ..

[magneto]

Thanks alot guys. I also came across nodewerk when I was doing some searches online. I haven't tried it yet but it looks interesting.

Although after reading the thread below, I don't think it's likely for PS to be node based even slightly:

http://feedback.photoshop.com/photoshop_family/topics/why_dont_like_unke_dfusion_software_with_flowchat

It's shocking it's coming from their developer. A lot of made up "facts". They should meet the SESI devs, because they have been doing it for 25+ years

[ben]

I think you want to have a look at Substance Designer. It use to be a tool to deal with procedural textures only but now it also support bitmaps.

You can composite, batch render, input meshes, use psd, vectors... and much more.

It mostly target game market, but it's not only good to bake stuffs and guess It can be use for any texture work.

It's way cheaper than a composting app (nuke/fusion) and a LOT of (game) companies are using it now.

http://www.allegorithmic.com/products/substance-designer

[galagast]

Adding or maybe extending the COPs context in Houdini to challenge Photoshop sounds intriguing and exciting

Maybe to further augment from the idea, some of the resulting painting functionalities could branch out to the possibility of having a Zbrush-like feature inside Houdini.

Although seeing how the Sculpt SOP has been in Houdini for quite a long time now.. maybe the implementation of a procedural 2D image editor has more demerits than merits.

Just my 2 centavos : )

[Erik_JE]

On the mailinglist for Krita it was discussed about making it available as a node in Nuke. Would be really cool if that happend.

[magneto]

Thanks guys, good insight.

@Ben: I will have to check that software too, but looks pretty good.

@Erik: Never heard of Krita, but that also seems like an interesting software. If they want it, then I assume Nuke lacks painting too?

@Jeff: You touched a good point. I will talk about this below

To me image editors revolve around a few major functionalities where additional features are derived. I would say these are painting, effects/filters, selection/masks, layering/compositing/blending. Things like healing brushes, clone, stamp, burn, smudge tools are an extension of painting and filters.

I think it's fair to say that the keying/selection capabilities of compositors are far beyond the best selection tools in image editors. So compositors already have an upper hand here IMO.

The main area COPs are missing is painting, ignoring keying for now. I think that has to do with the extensibility of Paint SOP. I am not sure but can Paint SOP be used to create Zbrush/Mudbox style sculpting tools? If we had the to do this, then with the addition of a Paint COP, we could take the same idea and create all kinds of brush based tools.

Of course the capabilities of a 2d painting system would have to be very extensive similar to or better than Photoshop. Not sure if their painting system is intuitive in this regard. I would also propose a separate COP for natural painting like Corel Painter. IMO their or let's say Fractal Design's painting tools are unmatched. They are unbelievably realistic.

With these two 2d paint systems that allows to be used as a base for any brush based tool, I see no reason why Houdini wouldn't be used for all 2d image editing tasks.

Thoughts?

[galagast]

Great insights there Ryan. I do agree, a 2D painting system is probably a great next-endeavor for Houdini.. also imagine if something like this is integrated, they could maybe release just the Painting Context as a separate version for the public. If this happens, Houdini really is on it's way to becoming the "Complete" package.

I'll try to cite some general advantages from using a node based system versus a layer based system (IMHO).

Node Based: (AE/Nuke/Fusion/Houdini)

• Non-destructive
  
• Keyable/Animatable
  
• 3D support (For layering matte paints - I think Nuke excels in this? AE's Element 3D and Cinema4d integration is also opening 3D up a bit more for the masses.)
  
• Filters are more interactive (and animatable)
  

Layer Based: (Photoshop/Corel/Gimp)

• Painting Tools / Bruhes
  
• Fast turnover (edit/paint away to your heart's content)
  
• 3D support (Paint textures on 3d models)
  
• Tons of Filters
  

I probably missed a couple more points in this regard, but the above notes is close to how my workflow depends on both systems currently.

I really can't say much about the extents of what COPs can do (being very new to Houdini), I've only skimmed the surface from a couple of tutorials. From a non-programmer stand point, I wish I could say that Houdini should integrate a more comprehensive Painting tool where we could maybe access Stroke attributes for modification etc. But peeking at the possible technicalities it could shoulder, I believe it would just outweigh its effectiveness due to constraints like memory, speed and ease-of-access. Yet I'm still very much optimistic that maybe some coders out there can do the magic.

On a side note, maybe Houdini could also look into Vector Graphics.. I'm not sure if there are node based programs to create Vector Graphics like CorelDraw and Inkscape. It would help open up the Curve SOP to whole new level. 3dsmax recently even added Vector_map support which is quote cool (It would be a fun little project to maybe build a node based system on building up the vectors for this).

[chippey]

Ryan, Nuke does indeed have a painting node (and it's gotten a lot better in the last few releases!).

Also from the foundry, there's Mari, which internally is node based. I don't know how serious it was, but I know there was some talk to make a '2D' paint mode, instead of just painting on models. There was also some talk (again, I don't know how serious), to expose the underlying nodes in a node graph interface.

One thing I think it'd really be cool to do in Houdini, would be able to design your own brush physics/solver (ie, create your own bristle dynamics), and then be able to use it in a paint COP.

[Erik_JE]

@Erik: Never heard of Krita, but that also seems like an interesting software. If they want it, then I assume Nuke lacks painting too?

It's pretty awesome for painting with. Also got builtin OpenExr and OpenColorIO support. Another big plus is it's open source and free. As mentioned i think Nuke have some paint possibilities but I am not much of a comper.

[magneto]

@Matt:

That's good to know about Nuke.

Designing your own brush dynamics/solver sounds very cool. I have never done anything like that but AFAIK Painter does that with its own brushes. That's why they feel so real with their behaviour and color mixing. Don't think Photoshop does that.

SESI would know more about how feasible something like that for Houdini is I think.

@Erik:

I will give Krita a try, looks interesting. I tried Nodewerk for 15 minutes, and it doesn't seem that great. I know it's not much time, so I will see if I can learn its workflow, but Adobe AIR doesn't seem like a good platform to write an app like this IMO.

@Jeff:

Very valid points. I think COPs are really powerful. IMO the hardest part is the fluidity of the workflow and the intuitiveness. Houdini being very uniform, I think this is one of its strongest asset.

I am not sure what the best design for a painting system would be without doing some research but if it allows complete freedom for extensibility and customization, I think it might be enough.

We need to be able to replicate any brush we want, not just as presets for a given brush type, but also as completely new brush types i.e. new operator types. So there would be some properties that all brushes would inherit like Size, Opacity, etc but you can also add your own properties.

I am sure if SESI designed a painting system, it would redefine what digital painting really is

[syme]

Black ink from bleank is node based. Not photoshop but interesting nonetheless. http://www.bleank.co...ckInk-a115.html

Edited May 29, 2013 by syme

[magneto]

Thanks syme. That application looks very interesting. Almost like a NLE for painting of some sort. I will have to give that a try too. I couldn't try anything much yet, but will post my findings when I do.

Btw another thing really makes me curious often times is this: Why is the compositing context called COP2 and not just COP? I assume this is to do with something where the entire compositing context had to be redone from scratch and due to not being able to preserve backwards-compatibility, they abandoned the original COP context.

Am I far off from the truth?

Would love to read some history from the big guns

Edited June 1, 2013 by magneto

[old school]

Btw another thing really makes me curious often times is this: Why is the compositing context called COP2 and not just COP? I assume this is to do with something where the entire compositing context had to be redone from scratch and due to not being able to preserve backwards-compatibility, they abandoned the original COP context.

Am I far off from the truth?

Would love to read some history from the big guns

Got it right.

Way back in in the 90's there were several applications wrapped up in to a product called PRISMS. Action was the 3D component (commonly referred to PRISMS but actually this was Action). Mojo was the stand-alone 2d morphing app along with a few others. And then there was ICE, the stand-alone 2D compositor.

When Houdini came about, we decided to embed ICE in to the environment, unique at the time. At some point there was the desire to thread the compositor but needed to keep backward compatibility for a few releases so we created a new network type and that is where the "2" came from. I don't remember the specific release but I believe it was around H4.

I believe we were the first fully threaded tile-based compositor available off-the-shelf for sale in case anyone cares about such things.

[symek]

Is it true that you did sell some technology to Sillcon Grail at that time?

[old school]

I am not aware of the specific details but Silicon Grail got a drop of ICE after which they poured a lot of goodness in to the product. It was then consumed in the Shake-Apple deal if I remember correctly.

[symek]

Yes, Silicon Grail just after release of Rayz was bought by Apple. They knew what people will do after they had removed Shake from Win/Lin market... It was really awesome, had tiled renderer, and even its gui looks familiar...: http://www.linuxjour...om/article/5933

Edited June 3, 2013 by symek

[magneto]

Thanks oldschool. I love reading historical details like that I regard COPs just as capable as any other, even though I know certain capabilities are missing, i.e. tracking, high-end keyers, stabilizing, etc. The COP context is an important piece of the puzzle IMO.

Also are you and Kim the ones who first came up with the initial idea of PRISM? I don't know if PRISM worked like Houdini but I am talking about the idea of operators, proceduralism, different contexts and how it all ties together, i.e. the essence of Houdini. Because coming up with this 25+ years ago is mind blowing to me, when everyone else were developing software with destructive workflows.

Nowadays people are using the node-based approach when they can, but not at the core (XSI's ICE for instance). To me that's like coming up with electricity when everybody else was using gas lamps

[old school]

Also are you and Kim the ones who first came up with the initial idea of PRISM? I don't know if PRISM worked like Houdini but I am talking about the idea of operators, proceduralism, different contexts and how it all ties together, i.e. the essence of Houdini. Because coming up with this 25+ years ago is mind blowing to me, when everyone else were developing software with destructive workflows.

Oh no. I was very late to the PRISMS party. And even then, I'm just a glorified support jockey hanging on for the ride.

Kim (current President and CEO of Side Effects) and Greg are the co-founders of Side Effects. They purchased the code that was PRISMS out of the bankruptcy of Omnibus Computer Graphics in 1986-87. Omnibus had offices all over the world but was founded in Toronto. Kim and Greg were active developers of PRISMS and were still writing code when I joined btw but moving to c++ saw them eventually move on to managing and running things full time. The first employee was Mr. Mark Elendt and what a visionary he was and continues to be. He is the key architect of the core that is Houdini: geometry. And on and on...

You can google and read up on Omnibus as there is a fair amount of info available.

We just had our 25th anniversary last year btw. I've only been at Side Effects since 1994.

As for just how influential PRISMS was to the industry? Well I'll refer to Action as that was the 3D animation software within PRISMS at the time.

Let's see...

Action had an operator stack that you manipulated the inputs from other nodes in the stack.

Action was pretty flat and didn't have the networks that we have in Houdini though.

Action had a separate channel list linker that you referenced in to from the node parameters.

Action had a pretty complete scripting language.

Action had no viewport selection or manipulation. You did everything with nodes.

If you squint pretty hard, you can see a couple of these things in other 3D softwares that are pretty popular in the industry today.

The flatness of PRISMS was a limitation that was addressed in Houdini by moving to a true folder system that was inherently more procedural/object oriented and allowed for a certain elegance as a developer and a user. This is also what allows Houdini Digital Assets to be the amazing things that they are and no we did not have assets in mind per se but we sure did take full advantage of things.

We still haven't got to the "heterogeneous"network bit (just too much too soon at the time) although Greg at Derivative has implemented heterogeneous networks with Touch Designer where you can pace different node types in the same network and wire sensible things together. Hopefully one day...

Striking to the core and looking at core philosophies, Action inside PRISMS was designed to animate anything at any time. This is what drove it's procedural node-based philosophy where each node is a true programme operator that is designed to take any input and work on it in turn. Action was inspired and initially developed as unix pipes between separate unix programmes. Fyi a unix pipe or | is where you can direct the output of one programme in to the input of another programme if they are designed as such. Instead of using scripts to control the pipes, Action was created to offer the animator an interface where he/she could place these operators on a stack to control the flow through and pipe the various operations together. And so it began as I have been told. This evolutionary progression makes good sense to me.

----

Barring a couple new apps to the game, the big players are modelers first with procedural workflows tacked on top. And it does show. Create and maintain a cache and pound away at it with operations and run in to the dreaded "oh my I better save off a copy before I wreck things" heart stopper. The day I moved from AutoCAD (architecture that is) and PA to PRISMS, never have I ever had that dreaded feeling.

Compare saved scene files to see which apps cache their "working" dataset and which ones don't. Saved scene sizes speak volumes here. Average hip file is around 500k but can grow to 2GB and anything beyond that, you are doing something really wrong or you have a LOT of nodes (which is really interesting), locking way too many SOPs, or one of those hip file bloat bugs that spring up once every few years almost like clockwork. We had one recently btw so we're clear for another few years.