Will this likely to happen in our lifetime or is it a pipe dream?

Recently I was talking about it with a fellow Houdini guy, and it sparked some interesting discussions.

Currently we have so many similar operations separately defined for points, particles, volumes, images, etc. I also feel Houdini could use a massive change, getting rid of all contexts and unifying them under one. I think this can be done. I mean the nodes could take certain types or polymorph if the operations are substantially different but they should allow flowing of any data from one into another.

For instance if you want to apply Color Correction to your points, colors, particles, volumes, etc you could specify a channel and the right operation is executed. You would have the ability to restrict an HDA to a specific type so your use of certain functions wouldn't fail and make it clear to the users that this OP only accepts volumes. The inputs would have different colors (probably a little bigger inputs for visibility) and the wires would indicate what kind of data is flowing through them.

If I want to fit a volume into 0-1, this OP should also work with images and attributes. You could have a channel, and if it's an attribute, it would work with attributes. If it's a volume, it would work with volumes, or images.

You can do this right now. I have my own AttribFit SOP, which detects attrib class and type. It could also see if it's a volume and use a Volume Wrangle instead. Or even mix and match.

There are so many opportunities this new paradigm would bring, it's pretty exciting.

What's your opinion on this topic?

As Jeff would ask, yay or nay?

This sounds fantastic. Would be really great to unify all contexts. And not only this but what about integrating a node based approach for expressions into the same network. World machine does this nicely. The data that flows through the network is pixel grids but at the same time you can use nodes to modify the parameters of the nodes that work on the pixels. These can have all the data types. Would be an alternative to Hscript.

best Manuel

But isn't this already possible with VEX to at least some extent?
You could make a color correct VOP that you can use in SOP's, COP's and Mantra shader.
You only have to wrap it into a VOP network of that context.

cheers,
benS

Let me throw my ¢5 for what is worth around here.
I don't have the deep understanding of Houdini's inner workings to predict the eventual problems that might arise which surely will arise and that's not to say that they can't be solved, but I can say that from here seems like a good idea.
Until then and especially if this is never going to happen, can we please at least have the contexts accessible via buttons instead of a drop-down? I've said this before, I know, but maybe it has been forgotten? You know what, I'll just file a RFE for this just to be sure.

Unifying is a great idea but would sit below other improvements imo. i.e. modelling & selection tools, materials, viewport Udims, FEM optimisations etc.

tnsor
This sounds fantastic. Would be really great to unify all contexts. And not only this but what about integrating a node based approach for expressions into the same network. World machine does this nicely. The data that flows through the network is pixel grids but at the same time you can use nodes to modify the parameters of the nodes that work on the pixels. These can have all the data types. Would be an alternative to Hscript.

best Manuel

Can you eloborate how world machine works in this regard? I never used it.

Node based expressions sound interesting. There should only be a single expression language IMO.

ben5ch
But isn't this already possible with VEX to at least some extent?
You could make a color correct VOP that you can use in SOP's, COP's and Mantra shader.
You only have to wrap it into a VOP network of that context.

cheers,
benS

In a very limited way. You can't work with attributes in a generic way for example. Not all VOPs are available in other contexts, COPs are isolated further from SOPs.

Also suppose you have some VOP that does something and want to do it for each volume, attribute, image, etc, the approach will break. You will have to create a different OP for each context. This creates a lot of overhead, not just in the software but mentally as well. I would rather see 300 nodes that work with each other than see 2k nodes with tons of overlap.

There are more practical gotchas that will force you to handle each case differently so it's less than ideal. Even then you will be isolated in VOPs and miss out on complex higher level nodes found in other contexts.

What I am thinking of is each high level node will take any data it can work with like an image and is specified to be worked on, and will modify that and pass it along with the rest.

They will be smart nodes to transform data quickly and efficiently, i.e. converting, renaming, remapping, fitting, randomizing, compositing, copying, creating, deleting, transforming (into volumes, etc), blurring, sharpening, normalizing, transfering, etc.

I'd rather SESI spent time improving Houdini overall and adding new features. This seems just like a quality-of-life thing, probably nice to have but I'd much rather have shiny new toys to play with.

It's a personal preference. I would rather have a better platform since I build my own tools anyway.

sounds like Fabric to me
it would be at least cool to have proper object oriented VEX that can process anything in the whole scene, rigging would be much easier

OO in VEX would be very welcome

What SESI can do IMO is to provide the new unified context along while still keeping up the old contexts and slowly bring the functionality into the new context with the ability to get data in and out to other older contexts for portability. Even with partial functionality it would be a game changer IMO.

I've (we've?) talked to friends at SESI about this before and from what I can recall it basically entails the vast majority of the application be rewritten, essentially creating a brand new application.

I definitely think this would be great and would like it a lot but I just file that idea away into the very highly unlikely pile.

If CHOPS were extended a little bit wouldn't it be possible to use it for this purpose? I already use it this way when it makes sense.

tnsor
This sounds fantastic. Would be really great to unify all contexts. And not only this but what about integrating a node based approach for expressions into the same network. World machine does this nicely. The data that flows through the network is pixel grids but at the same time you can use nodes to modify the parameters of the nodes that work on the pixels. These can have all the data types. Would be an alternative to Hscript.

best Manuel

I think something like DOP's would also be a good candidate to unify different contexts.

But I just don't see how the same node could be used to delete a point attribute or an image channel. And I don't think I want COP nodes in the same network as my SOP nodes.
The current ability to have any network manager in any other network context is something I use a lot. I just position, color and name them to show their relation to the host context.
In theory unification is good but dedicated GUI is more practical I think.
It's all the secondary options on the delete nodes that makes them a one node solution. The GUI is more tailored for the specific context.

Houdini internally could use the same functions and the parameters should have a unified behavior and naming across contexts.
But that is already the case right now and enables us to have this discussion I guess.

But then I'm that guy that always turns on “Color Pane Headers with Network Context” in preferences as soon as he installs a new Houdini :wink:

cheers,
benS

graham
I've (we've?) talked to friends at SESI about this before and from what I can recall it basically entails the vast majority of the application be rewritten, essentially creating a brand new application.

I definitely think this would be great and would like it a lot but I just file that idea away into the very highly unlikely pile.

I am glad you guys at SESI were at least talking about it. I think a major rewrite would be inevitable as well which is a lot of work for sure, but on the up side, if a great design is created on paper and implemented as bare bones, then porting the existing OPs will be much faster as the hard work for the OPs are already in their code.

It's just a matter of changing the code to use the new way of doing things with the new “API”.

jparker
If CHOPS were extended a little bit wouldn't it be possible to use it for this purpose? I already use it this way when it makes sense.

I also think CHOPs are close to achieving this than other contexts.

ben5ch
I think something like DOP's would also be a good candidate to unify different contexts.

But I just don't see how the same node could be used to delete a point attribute or an image channel. And I don't think I want COP nodes in the same network as my SOP nodes.
The current ability to have any network manager in any other network context is something I use a lot. I just position, color and name them to show their relation to the host context.
In theory unification is good but dedicated GUI is more practical I think.
It's all the secondary options on the delete nodes that makes them a one node solution. The GUI is more tailored for the specific context.

Houdini internally could use the same functions and the parameters should have a unified behavior and naming across contexts.
But that is already the case right now and enables us to have this discussion I guess.

But then I'm that guy that always turns on “Color Pane Headers with Network Context” in preferences as soon as he installs a new Houdini :wink:

cheers,
benS

There are definitely certain operations that will only make sense for certain data types. Those can be distinguished visually and internally code wise.

Though deleting an attribute, an image channel, or a volume using the same OP makes sense IMO. You might not agree as the current delete node has tons of options which should be their own OPs. I sent a similar RFE to break down Group SOP into individual OPs, and SESI agreed.

So deleting a range of volumes from 1 to 5 might not make sense for volumes but Delete by Pattern would IMO. That's why we should have Delete by Pattern, Delete by Range, Delete by Bounding Box as separate OPs IMO.

Every operator should only have one purpose, and all the options it has should only help to achieve this goal.



Another thing though not exclusive to unifying the contexts is I have another idea of using Contracts in nodes:
http://research.microsoft.com/en-us/projects/contracts/ [research.microsoft.com]
http://rise4fun.com/SpecSharp [rise4fun.com]

I already submitted as an RFE but what it would do is, for any node, you can have a number of contracts that enforces, verifies, etc certain things. For instance you can add a contract to your OP stating the topology doesn't change, and not only this communicates the user what kind of operation is being done, but would also allow Houdini optimize the operation as it provides runtime guarantees.

There are a lot more opportunities with this concept.

yearly bump

It's odds-on that that world-class modelling will occur before context unification

Context unification can mean many things.

Heterogeneous networks where you can work with nodes of different types has been bantered about for years.

Have a look at Derivative's Touch Designer as it has heterogeneous networks where you can wire operators of different types together. As well the nodes themselves construct the parameter UI amongst other things. It's designed for real-time performance so has a different set of criteria to meet than Houdini.

http://www.derivative.ca [derivative.ca]

Thanks Jeff - I would class it as working with ‘no diving’ into different networks.

Cops would be brought into Sops, that would then be very similar to Nuke.

That screenshot shows something that could really be a function of the network editor. The netboxes would be implicit OP managers, and the net editor could just show them as a flat view. Internally it'd have the same parent-child structure between the netboxes and the nodes, the network editor could just show it differently. That'd also solve the TAB menu item explosion problem you'd get with including OPs for all contexts, it'd be keyed to the context you're currently in.

so you'd put a net box down in order to create a context?
and the TAB menu would reflect the context?
ugh.
personally I like diving in and out of contexts…I find it forces a bit of structure to my scenes
yes it can be annoying sometimes…but it's better than a 200 foot Outliner listing everything…

Context Team Unite (ironically)!
Fight!