I've recently used a bit of TOPs for the first time and while I can see it's got a lot of potential, it's been hard. I'm a pretty experienced Houdini user, but figuring out how TOPs works for me has been rather confusing. I've talked about it to people I work/have worked with and their responses have generally been along the lines of “seems like it could be cool, but I had a look and I'm not touching it again”.

This is a shame because IMO it's small generalist studios without established pipelines or lots of technical R&D staff who can potentially get the most value out of TOPs, however it's just not very accessible to them.

I'm confident that the tech behind it is solid but the usability and discoverability is letting TOPs down right now. On top of this there are quite a few inconsistencies with the way the rest of Houdini works, which adds to the confusion. Here's a few ideas on things that can and should be improved, and potential solutions.

Discoverability

TOPs should have its own top level context but that's been mentioned before already. But at the moment, if you do put down a TOP network and start poking around in the tab menu adding nodes, nothing works. It's very confusing! Turns out you need to add a scheduler, which is non-obvious and inconsistent (other networks in Houdini don't work like this).

At the very least there should be a local scheduler added by default when you create a TOPnet (like the copnet inside /img). Seeing this unusual floating scheduler node immediately would go some way towards communicating how TOPs works differently to other Houdini networks.

Discoverability (Execution)

Also on discoverability, it's also very unclear at a glance how to make the TOP network actually do anything. Other networks in Houdini have a visual UI element which triggers a cook, but there's nothing like that for TOPs. These are the most important actions, which are needed to actually making TOPs work, but they're hidden away in right-click menus and hotkeys. No other networks in Houdini work this way either (you never RMB to cook a SOP or render a ROP) which makes it even less likely that people will stumble across it.

TOPs really needs a consistent, visual, obvious way to trigger a cook. For SOPs this is the display flag (kinda), and ROPs have the Render button which is easy to find, right at the top of every ROP node. TOP nodes could have something similar on every TOP, which would be easy to understand for people already familiar with ROPs (eg. see image attachment)

Terminology

The idea of ‘dirtying a graph’ is a highly technical programming/graph theory term which means absolutely nothing to a huge proportion of Houdini users.

Can we please change ‘Dirty’ to something like ‘Reset’ or ‘Clear’? Eg. ‘Reset and Cook Selected Node’?

UI/Parameter Layout

Usually Houdini's parameter panes are organised top to bottom, with the most important often used parameters at the top, and lesser used (or parameters dependent on higher ones) further down the bottom. This is good since when you're trying a new node, you have a sense of what's important and what you should start poking at.

Many of the TOPs on the other hand have the ‘Work Item Generation’ and/or ‘Cache Mode’ parameters always at the top. These seem rather obscure to me - maybe these were more important in earlier versions of TOPs but with the ‘Automatic’ mode it seems like something that rarely if ever needs to be used in the course of day to day work. These parameters could then be sent down the bottom or to a consistent secondary tab so they're not always the first thing you see when you select a TOP node.

There are also a few cases where things could be clearer with better parameter naming. One thing that I didn't understand immediately was ‘Evaluate Using’ on the ROP Fetch, which didn't mean much to me. Perhaps this could be changed to something like ‘Generate Work Items’: ‘One per Single Frame’ / ‘One per Frame Range’


Anyway, that's just a few things I came across initially, will mention more as I get deeper. I also want to make clear that I do like TOPs and the potential for what it can do. Some of the other UI bits like the visualisation of work items is fantastic, I just would love to see it more accessible and easier to get into and make use of.

Great Comments!!

I think one of the things that will be very very helpful is to release some of the examples that sidefx showed at the H17.5 release. Or even a Masterclass on this. I know that this tech is game changer and that's why we need more useful examples.

Right now I'm working on a project and I'm taking a pure TOP centric approach to solve some shots, its a nice experience and very useful, but still so much doubts that make the transition/adoption very hard, its like walking blinded, but still I think its very important to do it because it speeds up the workflow nicely and you can make wedges very quickly.

Anyway I really hope this tech continues to evolve, as a freelancer this is a game changer because I don't need an army of programmers or even an over-complicated pipeline to work faster, and more important to have fun viewing how those little green dots get processed!

Cheers!

mattebb
At the very least there should be a local scheduler added by default when you create a TOPnet (like the copnet inside /img). Seeing this unusual floating scheduler node immediately would go some way towards communicating how TOPs works differently to other Houdini networks.

I just found that this is actually a bug when creating a TOP network inside a ROP network. Creating it inside Sops or OBJ does indeed make a local scheduler by default. So it just seems like just a simple oversight, which is good! I've logged the bug with support.

Thank you guys for this very useful feedback. A lot of it is very much on point. A master class (in fact, one of several) is on its way. Our usability folks are also taking this input and discussing it. We'll update here once we've reached a conclusion.

^^ “seems like it could be cool, but I had a look and I'm not touching it again”

i had the very same experience. for me the biggest issue is how to distributing/managing jobs on my cpu threads.

i think it could be great, but it needs better usability.

we are switching our tool set completely to TOPS right now, still keeping our old submission tools available. The PDG system is quite new and I guess it will evolve quite fast. that keeps one busy but I think it is totally worth it. So far I just love it, but having a fall back is kind of relaxing.

We are not using tractor or deadline, but muster as a scheduler. and the muster developer is picking up stuff quickly, but I do have some rather basic questions, as the tool right now is heavily work in progress on the scheduler side.

When I cook a top it seems to be bound to the houdini running it, is there a way to submit a top tree to be processed in a more old school way.

To be more specific and that is just my impression, right now the top cooking is bound to the current houdini session, that's very cool for fluid working and developing, but I miss a way to just submit a dependency tree to the farm, and then I can close houdini or open a new scene. while the top processes are calculated on the farm.
Is that possible in hqueue already?
Am I missing here something or is that right?

thank You

sanostol
To be more specific and that is just my impression, right now the top cooking is bound to the current houdini session, that's very cool for fluid working and developing, but I miss a way to just submit a dependency tree to the farm, and then I can close houdini or open a new scene. while the top processes are calculated on the farm.
Is that possible in hqueue already?
Am I missing here something or is that right?

thank You

There is a 'Submit Graph As Job' button on the hqueuescheduler node. This submits the TOP cook as a hython Job, which is standalone. You can then close houdini and watch it from the farm UI.

My, a lively discussion around this thread

Ok, some notes from our earlier meeting on what to do about the usability issues. This is not the whole list, but just what's relevant to the discussion on this thread.

1. All agreed that the current cooking mechanism in TOPs is a bit hidden, and should be improved. We thinking about maybe a tool bar or control panel HUD … the exact mechanism is TBD, but something highly visible with some high level status and controls, like “cook the graph” or “cancel the cook” etc.

2. Yes, we should have a TOP context, and we will do it. We just didn't have time at the end of the last release.

3. Creating a TOP network inside a ROP network doesn't have the local scheduler by default - this is just a bug, and will be fixed.

4. Terminology & UI layout - we will continue to study those and incrementally improve as needed.

Roadmap: the bigger feature currently being developed is the ability to separate the compute of PDG from the UI. Once we are done with this, you will be able to submit a graph even during it's cook to the farm, and then attach to that headless session to visualize it's state.

“seems like it could be cool, but I had a look and I'm not touching it again”

At the moment I still get more speed & control from python via shelf-tool or using vops/vex… without any dependencies, env fuckery, or redundant UI.

I also like the idea of putting this kind on work into nodes, and do it already with vops, but tops just isn't low-level or logical enough; its too un-Houdini-like. I'll be interested if we get vex/C++ micro-tops under the hood and can work at that level. Also an equivalent to the awesome geometry-spreadsheet.

kenxu
Ok, some notes from our earlier meeting on what to do about the usability issues. This is not the whole list, but just what's relevant to the discussion on this thread.

That's great to hear, thank you very much!

I think one of the stumbling blocks for TOPs is how it's so different to the rest of Houdini. I think the more that these potential changes/solutions could be more consistent with other aspects of Houdini the easier it will be for people to start picking it up.

cheers