I would have to at least echo the concerns of tab menus becoming VERY large if all contexts were unified. One nice advantage of the current structure is that it is quite clear if you are working on one context or another (makes discoverability much easier too).

maybe a more appropriate solution is an easier way to bridge contexts? i.e. dops to sops feels seamless, but sops to cops is a bit of a drag (although not impossible)

arctor
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!

I couldn't agree more, id rather have contexts that the mess that is outliner !

I imagine a 3d app where one of the fundamentals is “data is data”. For example you read an image, and it creates a matrix that stores pixel data like a slice of a volume.

You apply operations on it such as rotation (transformation matrix), arithmetic operations, blur, sharpen, etc. You can apply the same operation to fields. This is one of the design decisions that could allow extreme optimizations as you can push certain operations to be done on the GPU.

This is only one aspect of the 3d app design I have in mind but an important one.

grayOlorin
I would have to at least echo the concerns of tab menus becoming VERY large if all contexts were unified. One nice advantage of the current structure is that it is quite clear if you are working on one context or another (makes discoverability much easier too).

maybe a more appropriate solution is an easier way to bridge contexts? i.e. dops to sops feels seamless, but sops to cops is a bit of a drag (although not impossible)

This won't be an issue as the amount of ops will be consolidated, multiple operators replaced with a single one.

1600+ operators is alot. Also if you have an operation i.e. a Wrangle SOP, you can't directly use it in POPs and vice versa whereas it will be a copy paste of the exact same thing.

I think twod's plan could be good. Data flow is harder to follow when jumping between screens! Overall the goal imo is to lose the ‘Choose Your Own Adventure’ feel:

If you are affecting the surface, turn to page Sops.

If you want to dynamically simulate this, turn to page Dops.

If you are ready to render this, turn to page Rops.

:twisted:

arctor
so you'd put a net box down in order to create a context?

You could, but aren't forced to. You could just as easily plop down a regular container OP as you do now. These might just be a convenience, for a 2-3 node network that might easily fit within a netbox container. Just an idea

If this could be made an option, I'd be all for it. Almost like the way you can collapse and expand subnets, but betterer.

I suppose an analogy is nuke groups; you can either open the contents in a graph, which drops you into a separate pane, or expand contents, which opens them up into the current context.

This'd have to be pretty solid though; maya containers are a similar concept, and they're terribly executed. Netboxes in houdini aren't great either to be honest, they're twitchy enough that I tend to avoid them. Make netboxes stable before basing any clever single context view stuff on the same code! :wink:

mestela
This'd have to be pretty solid though; maya containers are a similar concept, and they're terribly executed. Netboxes in houdini aren't great either to be honest, they're twitchy enough that I tend to avoid them. Make netboxes stable before basing any clever single context view stuff on the same code! :wink:

+1k

arctor
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!

While you mentioned net boxes, it would be nice if they were actually fixed . Houdini artists at work are avoiding them on purpose due to usability issues in large networks that could make use of this feature. I would post this in my “small things that matter” thread but that's overzealously locked down when it was showing constructive feedback from people who use Houdini in production full time, and was even supported by SESI programmers and Jeff Wagner.

It just creates bad outer impression IMO (Several colleagues were reading the topic and giving direct feedback).

this kind of nuke like “one” canvas workflow is simply inevitable.
It is from a user experieicnce/usebility the future. A blind person kan see that…

Have you ever seen a Nuke artist grouping allot of networks in to each other? No? guess why. Because it is counter intuitive and lets the artist loose overview. And no, it does not matter if you you do work in FX or comp. It is a pure Interface design problem.
But it will have to be solved sooner or later!

SideFX could solve this simply by having a subcontext similar grouped like netboxes. Just that they are “open” containers like DOP's or SOP's…
Certain nodes could only be created on these Netboxes/backrop's.

…a sidenode on the netboxes. They are very clumsy, have a look at nuke, they should be exactly like the backdrops.

bjoern
this kind of nuke like “one” canvas workflow is simply inevitable.
It is from a user experieicnce/usebility the future. A blind person kan see that…

Have you ever seen a Nuke artist grouping allot of networks in to each other? No? guess why. Because it is counter intuitive and lets the artist loose overview. And no, it does not matter if you you do work in FX or comp. It is a pure Interface design problem.
But it will have to be solved sooner or later!

SideFX could solve this simply by having a subcontext similar grouped like netboxes. Just that they are “open” containers like DOP's or SOP's…
Certain nodes could only be created on these Netboxes/backrop's.

…a sidenode on the netboxes. They are very clumsy, have a look at nuke, they should be exactly like the backdrops.

+1k

I think SESI is going the non-subnet flat workflow direction with the new For Loop SOP/VOPs so I hope they do the same for other subnets.

twod
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.

This is great idea. I think Katana is doing something similar in Groups Nodes.
(http://thefoundry.s3.amazonaws.com/products/katana/releases/2.1v1/Katana_2.1v1_UserGuide.pdf [thefoundry.s3.amazonaws.com] Page 83)
You can “unpack” node to see its inner nodes. It's not diving in, it's just like switching between minimized version of netbox and it's full size.
But it would require some smart node movement to avoid nodes layered over other nodes like Blender's auto-offset: https://vimeo.com/135125839 [vimeo.com]

bjoern
Have you ever seen a Nuke artist grouping allot of networks in to each other? .

Yes, often. Most time into “gizmos” and “precomps” nodes.
When something gets more complex there is need to separate it to pieces to keep sanity or spread the work over more people to do it on time.

gizmos does not apply as an example. Cause that would mean we would also flatten out HDA. Which makes of course no sense.

And with precomps, yes I agree. But that is usually a minimal amount of space and nodes compared to the rest of the comp.

I agree that less jumping is better.

Btw: I hate flat, isolated, all in one context of the Softimage ICE with “context switching” nodes or mess that could happen in Maya nodes so I prefer to separate networks to tasks as small as possible (for better reuse and debug).
But I can see why getting flat context is more preferable as one have monitor big enough to see it all.

The Katana Group's feature I mentioned could be seen around 1:40 in this video:
https://vimeo.com/60693308 [vimeo.com]

pezetko
I agree that less jumping is better.

Btw: I hate flat, isolated, all in one context of the Softimage ICE with “context switching” nodes or mess that could happen in Maya nodes so I prefer to separate networks to tasks as small as possible (for better reuse and debug).
But I can see why getting flat context is more preferable as one have monitor big enough to see it all.

The Katana Group's feature I mentioned could be seen around 1:40 in this video:
https://vimeo.com/60693308 [vimeo.com]

Ive used Katana extensively and the group feature although nice for keeping things tidy got very frustrating as it pinned itself open on the screen and you still have to use short cut keys to jump in and out. I really don't see the difference between that and subnets / contexts / hda's . If anything Katana is trying to be more like Houdini , but lacks the elegance. You cannot even rename a light and have it ripple through your scene/

I think contexts could be linked in a far more efficient way.
Imagine there were literal LINKs that can cross contexts. Click a node with such a link, click a button under the parameters and it takes you directly to a completely different part of your network. If you set up your network with a bunch of such links, you will be able to quickly and efficiently follow your data through the network.

Technically it is really simple: On button-press a script would change the address in the last active Network view to an address specified in a string parameter. I guess this could be easily implemented already. Somebody please make this happen!


- Contexts and subnetworks are good tools to keep your procedure relatively clean and organized.