Ok, here is a deal. We all love procedural approach of doing things, we love openness and flexibility of houdini tools. But there are class of tools that shouldn't be build this way. I'm talking about H14 new grooming tools, Curve Groom sop in particular. This asset contains 200+ operators, including foreach sop! It slow as hell on production level character. My question is - why? I doubt that this asset intended to be modified, especially by artist, they really don't care whats inside. From my point of view - this tool is solely for artists, and it should be reliable and fast. At my studio we wrote this kind of tool in HDK and it's blazing fast on thousands of curves!

So, how decisions are made at SESI? Why such a performance critical tool is made of 200+ nodes? :roll:

You don't suppose you could get your studio to release it secret tools to me, i won't share it, promise.

I while might not share the same tone i agree with the sentiment. I have spent a lot of time trying to make it work, with unsuccessful results sadly. :cry:

Stalkerx777: Can you post some like-for-like comparison stats please. fps, amount of hair groomed - better yet - a screen recording

Thanks!

I have to agree with you Andrew , the first port of call needs to be support if something is substandard and does not work. It can then get addressed and quickly !

Rob

Many years ago i was sure that making HDA is the only right way of doing tools and “black box” operators is evil and should be avoided. I thought: “Oh, this thing is definitely should be HDA, because one may want to unlock it and tweak!”. Guess what? They don't.
HDA is amazing, we have a tons of hda-based tools, but not for interactive work.

Simple scene with torus and a couple of shelf tools click (Draw Hair->Plant Guides->Draw Hair->Clump Hair) will result in 1500+ nodes and almost unusable performance!
len(hou.node('/obj/torus_object1_hair/guides').recursiveGlob('*'))

Hair grooming is such a creative work, and unfortunately current implementation is very very slow.

An example of interactive grooming is maya yetti plugin [youtu.be]

Stalkerx777: Can you post some like-for-like comparison stats please. fps, amount of hair groomed - better yet - a screen recording Smile

I'm not promising, but i'l try to make a little screencast.

Gotta start somewhere, many tools have started out slow (voronoi fracture). While I don't know the answer, here are some ideas that might help inform some expectations:

- many tools have started this way (voronoi) then improved
- Houdini often starts with flexibility first (if they have to choose), then make it fast (see FLIP, PYRO)
- Many users/pipelines are built around this flexibility first mentality, then either through feedback or custom development speed up shore code/node paths
- it's easier to maintain OTLs vs c++ DSO ( one of many reasons, I think, we'll see more vex nodes like point deform and pop grains)
- it was good enough for the small number of testers at first
- Bug reports and RFEs more numerous in other areas/features

Like has been said many times, submit bug reports and rfes! Hopefully developers generously being so active on the forums doesn't stop folks from submitting them!

Stalkerx777
At my studio we wrote this kind of tool in HDK and it's blazing fast on thousands of curves!

Source code or it didn't happen.

coming from developing many tools as HDA first, then becoming hybrids of HDA/HDK, I must say that the gradual approach is best. Generally you realize that your whole tool does not have to be HDK, but only a few subcomponents do (ehm.. foreach networks)

that said though, I do hope SESI invests the next few releases in developing parallel (multithreaded) graph processing. I do feel many things that require a foreach in merge mode/copy are SUCH a strong candidate for multithreading, and unfortunately there is no easy way to do so currently

If SESi implemented this, almost every single HDA we have will get a huge boost on interactivity

Some of jait's notes on Parallelism in Houdini (for those who haven't seen it yet):http://www.multithreadingandvfx.org/course_notes/MultithreadingHoudini.pdf [multithreadingandvfx.org]

Last tool I made have more than 40 SOPS. More than 20 are for guide visualization, to make it more user friendly.

I didn't checked hair yet, but probably ton of things there is for visualization, that probably adds up a ton of additional nodes. Probably this would be first stop on the way to speeding up tool.

its easy to implement the tool using nodes, then ppl can try them call improvements, bugs etc… then move to code it.

I do like the idea that ppl can dive in a see how things are going , learn new tricks and implement them somewhere else.

I do like the idea on how Houdini implemented the hairs, are even some feature that I wanted and some that I ask as RFEs.

the artistic side is great concept for playing around, in production, when characters change topology, they F up the UVs. some rigs will have changing topology, supervisors will come and ask diferent thing each etc….

been able to have Houdini is the best since you can use all sort of tricks for keeping it togheter, attribute transfer, base on many things etc… etc…

now with the new method and using bdb voxel advection is great. the internal nodes could be coded but I still like the way is done currently.

yeti even do that is “procedural” just let you connect certain things. nodes, and every one do the same connections all the time.

It's not a question whether it's implemented in nodes or code. We would all appreciate nodes for their obvious advantages provided minimal assumptions about usability are met. These tools are simply too slow to be useful for production assets.

I don't think this was a conscious decision, Alexy - to choose nodes over c++. It looks more like intern's exploration or developer toy project to check new possibilities. It shouldn't be advertised as a new feature of H14 but rather prototype.

The thing about interactive/artists tools is that, afaik, they are particularly hard to develop without constant production insight, so shaping them with nodes must be very handy I guess…

Good points but I would be sending in bug reports too. So far the OsX version has already sped up considerable for the draw hairs tool ,by doing this.

Having the same experience with the new fur system. The tools are great and im able to do pretty good grooms with it, but when i have 300 strokes the experience get very bad. Undo is a pain, taking 30sec and more with lots of strokes.

Is there any good reason for keeping every stroke btw? Is slowing it down?
When i groom its a destructive process I dont want to go to stroke 154 and remove it if it looks bad, i rather just groom some more to fix the part thats not looking good.

I guess sesi is aware of the slowest part of the system and it will be faster in future releases like many other thing implemented for the first time in houdini.

I think your concerns are valid but I generally agree with the approach Side FX takes regarding new tools and work-flows for these tools.

Starting with a heavily optimized version of a tool can dead-lock development early on. It's often better to use a more modular although slow approach to tool development to get a better idea of what works and how people would like to use the tool and iterate on those findings.

Making a special tool at a studio to account for probably only a few cases works fine for smaller environments. Getting a tool ready to be used by many users around the world is a totally different ball game. As mentioned before, many tools started out slow but grew over time, not only in speed but also functionality. Both go hand in hand and I really like the way Sesi pushes new ideas and takes it's time to evaluate community feedback to improve the tool for a next release.

For this reason older tools got ditched (old grain solver for example) and replaced by new techniques such as the Position­Based solver. The Pyro 1 environment got completely replaced by Pyro 2 and the RBD tool set has improved dramatically over the years by correctly implementing Bullet but also the set of tools around it (from a SOPS point of view).

Just give it some time

First kick at this guys. Looking for optimizations as it progresses for sure. Keep the feedback coming! If you profile the asset, you'll see where the slowdowns are inside.

If you find that the groom is getting a bit slow, partition your work and copy/paste as many groom SOP setups in to a Merge SOP as you need.

If you have tufts of hair weaving on top of each other, again copy/paste your groom SOPs, wire output to Merge SOP, reset the pasted SOPs and go.

One of our clever interns figured this out for herself. That is how she was able to do 20+ weaving layered tufts of hair interactively and with lots of control. 20+ sets of grooms merged up and go. Super-easy to manage by selecting node in network and then use shelf tools to modify. The shelf tools aren't currently set up to support this so you will have to rewire one of the inputs but still simple to do.

Again first gen of tool so we'll take all the feedback we can get.

Only cook what you select. Template what you don't. Go. Partitioned parallel workflow. OldSchool Houdini usage at it's best.

It's actually a very cool workflow for hair sculpts.

One example I saw there for Z-Brush, the user had to partition the scalp in to sections and paint one section at a time to get interactivity with complex grooms. From that standpoint, copy/paste of our SOPs is fantastic as you can sculpt anywhere, not just limited to the partitioned patch.

The behaviour node slot on the top level asset is what makes this work as well.

Thx for replies guys. I understand your point of view. Assuming this tool is a proof of concepts, it's good to have implemented in nodes, it's very good source of knowledge inside I hope it will get more attention in future release.

Stalkerx777
Thx for replies guys. I understand your point of view. Assuming this tool is a proof of concepts, it's good to have implemented in nodes, it's very good source of knowledge inside I hope it will get more attention in future release.

SESI generously gives you an opportunity to do some cool stuff by yourself. Ideal software would be so boooooring
But I agree, in most of the cases there are only two main factors: speed and flexibility. As to me a tool that can't be “modified” is not necessary a black box. Unless it can't communicate to other tools. In some “industry standard ™” softwares there is a difference where geometry comes from. So even if we have geometry imported from some in-house format, we still can't paint an attribute on it because the standard tools have no idea about the data structure we are going to work with. It wasn't the case in Houdini before the introduction of custom primitives. Even now if I'm not mistaken it's enough for developer of some custom primitive to provide basic virtual methods in order to let other tools know how to work with that primitive (sure it can be not as simple in the end but I think it should be close to reality).
From this point of view C++ed operators can't be called black boxes. And the fact that they are non-editable is not that big deal. Speed wise they are good. Flexibility wise? Add CVEX based workflow on top of the tool and here we are. This is how I see it.

I think he means blackbox in the way that you don't have any knowledge of its internal workings.

IMO unless the inner workings of the tool is not supposed to be modified i.e. delaunay triangulation, etc, a hybrid approach is much better as it provides both flexibility and speed. So the parts that take a lot of time should be implemented as compiled operators where it makes sense not only from a performance POV but also the intent, i.e. reusability.

This way you can have the best of both worlds.

Agreed to this, in every presentation / class I teach I highlight the layered development approach of Houdini as a unique strength of the program