siLib: The Mission

[Andy Nicholas]

Hi all,

Welcome to siLib!

So this thread is to start the discussion on what the problem is that we're trying to solve, rather than coming up with solutions at this stage. Any discussions heading off in the direction of the "how" should be avoided where possible.

This is an important step for an open source project. It should help focus us on what we're trying to do and help collaboration in the long-term.

So, I'll get the ball rolling. Here's some problems I'd like to see addressed:

• There are gaps in Houdini's basic functionality that could do with closing (e.g. the example that came up on the XSI list: finding the minimum in an array) that are across many different contexts, i.e. VOPs, SOPs, DOPs, POPs, etc. If these were closed, it would save people having to continually reinvent the wheel and hopefully speed up prototyping of effects and rigs.
• There's a lack of homogeneity to many of the nodes. Some are uber nodes that do many different things. Some do things that are contrary to intuition (e.g. the Divide SOP being used to merge polygons, the Add SOP removing primitives)
• Some workflows in Houdini are quite complicated, particularly in DOPs. For example, I'd like to be able to emit RBDs all over the place with a few simple nodes.
• It's too easy to get bogged down in solving technical details in Houdini that can often take a few hours to solve through trawling through forums.
• Related to, and often a cause of the previous point, error reporting in Houdini leaves a lot to be desired.

So those are my main gripes. What are yours?

Cheers,

Andy

[Rob Chapman]

my biggest gripe is the disparity between the shelf nodes and opening up one of these and is hardcore spaggeti junction inside.  Unlike in ICE, there was some thought for the artists, there needs to be some logical intermediete nodes that can be read more clearly the flow of logic from start to end.  Am happy for the spaggetti junction to be there nested deep - it cannot be helped, but it seems each shelf tool is built by a seperate person and no consistency in the logic or the techniques or flow of logic between nodes and is made up brand new, of all the end granular math nodes and not the more intuitive intermediete stepping stone ones that can summarise core functions that can be easily reused in other projects or prototypes.

[Andy Nicholas]

Yep, have to admit that the new Principled shader kinda blows my mind. I haven't looked at the layer connection type yet which is an added complication. Have to admit that I'm not a big fan of these blackbox abstractions, particularly when a lot of the documentation isn't there yet (I get a 404 for the Surface Exports node, which from what I can see is pretty fundamental to manipulating the layers). That really annoys me!

The old school Classic shader is much more understandable and I frequently go back to that. Some of it's components lend themselves much more to re-use, but you'll only be able to access them by doing a cut and paste from there, as I think they've been removed from the Tab menu. Generally materials/SHOPs have always felt a bit transitory. The Principled shader is fine for "real" materials, but not so much for when you have to have complete control for more specialised effects.

[Andy Goehler]

While the goal of the principled shader is noble, it's not the end all be all solution introduced by Disney.

SideFX acknowledges this by having the now called 'classic' shader around, as it's so much more flexible.

Here are the Siggraph papers from Disney about the principled shader in case you haven't seen them.

https://disney-animation.s3.amazonaws.com/library/s2012_pbs_disney_brdf_notes_v2.pdf

http://blog.selfshadow.com/publications/s2015-shading-course/burley/s2015_pbs_disney_bsdf_notes.pdf

Andy

[Andy Nicholas]

Thanks for the links Andy.

[Andy Nicholas]

Okay, I've had a bit of time to contemplate this, I think the big risk right now is that we cast the net too wide and end up not getting anywhere. So, let's start off small. Let's just focus on a few tasks that will get the ball rolling and let people get involved.

Here's the proposal.

1. I'll start a new thread here with a list of things we want to create. I've already got two things I'm currently looking at. People can chip in with ideas etc.and we can see where we end up.
   
2. Once we have that, I'll create a page on the Github siLib Wiki.
   
3. People can volunteer to start working on implementations. If there's something you want to try to make, go ahead! Give it a go! Just let everyone know via this list. Your name will be added beside the tool on the Wiki page so people know what's being worked on and by whom.
   
4. As tools start to be created and submitted, we'll go through a process of optimising, tidying, and unifying. Don't be offended if something gets adjusted, tweaked, or rejected, that's just part of the process. We can discuss any issues on here and hopefully we'll all learn something along the way.
   

Every piece of software written has its own style, and even though we're dealing with a library of tools for Houdini, this is no different. Since I'm looking after the repo, that means I have final say. Decisions will be made purely on keeping the quality of tools high, and maintaining a level of standardisation across them all in a way that is aligned to standard Houdini practice. What those standards are will gradually become clear as we move forward, and will ultimately be documented on the Github siLib Wiki.

Do have a look at the qLib Wiki here: https://github.com/qLab/qLib/wiki In particular, have a look at the Developer Guide (https://github.com/qLab/qLib/wiki/Developer-Guide) as a great example of the sorts of standards we'll be sticking to. We won't necessarily be slavishly following those, but I suspect it'll be pretty close. 

One of the biggest challenges of setting up a Houdini tool library that contains digital assets is version management. Anyone who's dabbled in this, will know what I'm talking about! The qLib guys have their own particular method which is okay, but there are some concerns I have which I'm still thinking about how best to address. That's a whole new thread in itself which I'm sure will be started soon.

As a heads up; qLib is looking at doing a major reorganisation of the library, and is one of the reasons we won't start by following their example regarding the "base", "future", "experimental", and "graveyard" method of partitioning the digital assets (see https://github.com/qLab/qLib/wiki/Introduction). This may or may not change later. I've contacted them to see where they're planning on taking it, and I'm still awaiting a reply. Will keep you posted.

Cheers,

Andy