We (https://www.human.film/) look for someone to help us with creating 2 total (areal) shots of rather small medieval city, partially from provided assets/textures. You can render it by yourself or hand us procedurally created set already shaded and textured. You can do it all or cooperate with our modeler and texture artist. Houdini procedural set dressing in a nutshell. PM for more details. This is ASAP with 2/3 weeks span.

Hi,

Human Ark is Warsaw based animation studio, with +12 years of both original projects and commercial service and its belt. We look for junior and senior pipeline engineers (or TDs ) to help us with what's ahead of us. Mostly feature animation and VFX. We are typical Linux/rez/Shotgun/Houdini/Maya/Nuke/Python/bash studio. We do most of 3D in Houdini.

We are OK with remote work in case of experienced persons, novice people probably should be on site. All typical requirements apply, but we are not strict about anything. If you look for a place to learn new stuff, we can talk.

Human Ark is currently working on feature animation which is probably the funniest film you've ever heard of. We also do some Netflix features, series, and commercials. We are small, open and flexible, you will work without much supervision on many things at the same time. Sounds like fun, isn't it ?

PM me if case you're interested.

Szymon.

aghiles
Now, we are almost done with the installer for 3Delight for Houdini. In a day or two you will be able to install it with a click

Thank you for supporting Houdini Aghiles!

Something like:

I'm not sure about edge cases though…

render -p gives a sorted list of nodes + dependency and frame list.

Checkout ASAD Light/Shadow SHOPS as they are comprehensive source of information on how to write custom light shaders.

Ziva FEM solver is specifically designed for muscle simulation which enables many optimizations. Main challange for the solver in case of muscles is interpenetration and collision between muscles, and in fact this is the slowest part of Houdini FEM. We run sims with 50+ muscles in minutes without piecewise collisions. I can't really complain. Typical scenario is using SDF approximation of muscles for fast collisions with a very little lost of accuracy in terms of volume preservation. Houdini, being general FEM solver, doesn't do that (it's a pity FEM solver does't allow micro solvers for custom collision handling, but this might be technically tricky as I presume since collision response has to be efficiently injected into finite elements matrix).

Personally I don't see big advantage of Ziva over Houdini muscles. And as always, Houdini flexibility will be huge win for any advanced system. Do any complicated character with skin, mixed muscles with linear skinning, post process corrections and blend shapes, and you will see the difference.

And yes, Vellum (XPBD) is a new chapter for muscles in Houdini.

malbrecht
That said, I am pretty sure Houdini's docs say that Houdini uses tets and tets exclusively for FEM - and I *think* I remember it also saying that a FEM cloth is being created by adding virtual thickness

We are talking about the same thing. Virtual thickness can be modeled by placing additional vertices (labeled ghosts as they don't collide) around triangles to form tets with them. The only controversy we have here is whether these tets are formed from the original mesh (thus following its density), as I speculate, or built upon some parameters as in case of Solid Object (as suggested by you afaik). I've not seen such possibility for cloth object, thus my confusion. I think we have to wait for SESI to answer this. Also birds say there is new solver coming, so our findings might quickly become obsolete.

Yes, Houdini uses tets solely, but general concept of FEM allows other elements too. You could model and simulate cloth from triangles or quads without any virtual thickness, but then you need a way to model 3rd dimension behavior of cloth material.

malbrecht
I am not at a Houdini-fied system right now, but if I remember correctly: When you create a FEM object, the embedded tets get their own “node-thread” inside the mesh/geometry network (outside the DOP network), there is a parallel “render geometry” and a “FEM tets” thread after you created a FEM based simulation.

The “cloth” shelf tools are not “100% FEM” if I remember correctly. I asked SideFX about what simulation type 16.x is actually using for cloth, since the shelf-tool-cloth sims don't behave like PBD and don't behave like FEM. I think it actually is a kind of hybrid when you use those tools.

Marc

OK, I see now where this misunderstanding came from. I aware of embedding geometry in solid object, but afaik FEM cloth uses different schema in Houdini.

FEM itself doesn't imply any specific element type, as you may know. It can work on triangles, quads, tetra, cubes, but 2d element type doesn't allow you to model easily physical properties of a material (like bend).

I don't know what SESI solver is actually doing, but in a typical setup (used in papers and source codes I've seen) the way you model 3d behavior out of 2d object (approximating thin plate) is by placing so called ghost vertices around the mesh which form 3d element (tets or cubes) on top of it. You can even compute spring forces with PBD with such elements or do full FEM simulation. Hairs are usually modeled for sims this way (most probably in nCloth for example).

I assume Houdini does something along this line. Otherwise it would have to arbitrary re-discretize mesh - what apparently isn't happening(?) (thus this conversation leads us to the conclusion of the importance of the quality of initial mesh. Another subject is how this quality influences collision detection and false positive hits).

Interesting observation is that some solvers (marvelous) actually requires UV to exists on a mesh, and by enforcing elegant 2d space you're giving your solver a lot of understanding in how to treat deteriorated polygons, and how to repair the mesh for a sim…

I should probably leave this subject long time ago knowing someone who has actually written this awesome solver might stumble upon this thread… I'm now embarrassed.

malbrecht
You can actually display the tets making up the simulated “blob” in Houdini.

Oh, this is interesting. I was suspecting it's intrinsic for a solver, as I've never seen it in the spreadsheet. There is ShellModelData DOP for setting properties of the shell (which I thought was created straight from provided polygons). Could you point me to the example on how to see tets for cloth objects? This must be totally useful for work.

malbrecht
(…) Which, with FEM, is to be expected, since FEM stands for “Finite Element Method”, your mesh gets “replaced” by the specified amount of (finite) elements. That's the whole magic. So it doesn't matter how many polygons your mesh has: FEM is replacing it anyway.
Marc

I'm hardy an expert, but I wouldn't expect FEM solver is re-discratizing mesh it creates elements on. I would rather assume it builds elements (tetra, cubes, whatever) based on provided polygons. In that sense the denser mesh is, the more elements end up in a solver and this does influence execution time obviously. The magic of FEM you mentioned AFAIK comes from the mathematical fact of Galerkin methods that density of discratization of the function domain hardly influences accuracy of PDE solves, the solution of the problem approaches the continuous (ideal) value. It's only smoother, but not biased (similarly to how unbiased monte carlo estimates value of a function minus high frequency of it).

In case of cloth I presume the problem is that less polys causes less elements which makes collision response less accurate or false positive. It injects a lot more energy/noise to the system, and makes solver's life harder (more iterations per step).
Speculating again .

As much as I would like to agree with most skeptical comments above, I have (recently) found Houdini's cloth manageable as long as optimal conditions are met.

We were able to get decent results after carefully preparing meshes. Beside intersection free initial state, polygons can't be too small or stretched - which at sight makes it hard to apply on typical cloth mesh with folds on a sleeves and such). They basically should be similar shape and size (because solver makes volumetric (tetrahedral) representation internally I presume and solving PDE iteratively requires solid numbers - me speculates). You can get nice speed up just by that.

I don't think we are in a place where I would use Houdini cloth without hesitation on every project, but I managed to finish not-so-hard character shots without pain in hours, where FEM cloth with polygon collisions was faster than FEM with volumetric collisions, and only 2-4 times slower than PBD. The quality was superior from any other thing we usually use (Qualoth, nCloth, PBD), which is expected from FEM (albeit old Syflex turned out to be also very accurate).

Interestingly, once your mesh is optimal the solver doesn't seem to care much about polygons count. I think I was simulating 140K poly cloth with no need to downres it as it was easier to just let it go a little longer rather than going down and up with the proxy.

I was specially surprised that collision proxy mesh (body) end up faster than volumetric one at the moment its density was chosen right.

Generally speaking we do recently a lot of FEM solves, and I'm totally amazed by the speed of that thing (compared to a couple of open source solvers I've tried (Vega, simit, ebb, Cubica++) and previous releases). Apparently the missing part is how solver handles deteriorated meshes and collisions. Cloth needs extra care to make it feasible (like merging small polygons?).

Final remark is that we really do a lot of character related work in Houdini right now and I would love to do even more. Our animation lead considered even skinning in Houdini, as biharmonic makes it super easy to apply on Maya's rigs. Having solid support for character effects would be really a game changer. Today's realm is that we pass almost every animated mesh from Maya through Houdini to add secondary motions, clean up, merging different caches, and doing fur and hair obviously (although I can't imagine how grooming in Houdini could become so slow again).

Sorry for a long post,
Szymon.

SiRpRoHxO
(…) I hoped there would be a better solution.

You can specify texture as a geometry primitive http://www.sidefx.com/docs/houdini/shade/overrides.html [www.sidefx.com] which will overwrite material parameter, so that Mantra will use a single shader with multiply textures. Super powerful yet tedious for simple task might be Material Stylesheet:
http://www.sidefx.com/docs/houdini/shade/stylesheets.html [www.sidefx.com]

SiRpRoHxO
Besides that: what is the best texture Format for houdini? The model had .dds-textures which I converted to tif; but is there a prefered texture type which Houdini will benefit from?

.RAT. Always use Rat file.
http://www.sidefx.com/docs/houdini/shade/convert.html [www.sidefx.com]

You can measure it yourself [software.intel.com], except this would be meaningless You get amount of GB/s but you don't know what application was actually doing to make this number big or small.

One needs to know the theoretical throughput of the computation in question and compare it with actual traffic. Something along that [codearcana.com].

mbbuckley
Hey symek,

Thanks for your reply. I left an ambiguity in my description and you misunderstand me.

Well, perhaps I should figure out myself that you must think of second one, more sensible option of applying 26 transformations

mbbuckley
cwhite,
Yes, I had considered transferring the transform matrix as an attribute on some carrier geometry, but that seemed like not the most elegant solution. I think it would be really cool to have some kind of python command that can just make a transform sop directly from a given matrix. Its a bit silly that doing something very fundamental in 3D graphics is not so straight forward.

Making such function is 5 lines of code. Not exactly a biggie, isn't it?

You're clearly trying to bend Houdini into programming environment, which is close to, but not exactly the same thing. Houdini tries to balance a couple of values in its design. It enables many nice features - being procedural & safe & interactive & performant at the same time. Pure programming doesn't allow that.

What cwhite proposes it is actually very elegant way in Houdini of dealing with multiply instances of a geometry with own transformation applied. It saves memory and CPU. It allows fast GPU handling of geometry and so on.

So making it more houdinish, you should create a point per geometry copy, create an 4x4 point attribute called transform and use CopyToPoints SOP to apply those you your geometry.

mbbuckley
(…)
So I want to just apply the matrix directly to the points of the sop through the shell. I would also be fine if I could create a transform node and then just give the transform node the matrix directly. This seems like something houdini would be able to do. Is there anyway I could do this?

You can't modify geometry outside the node which owns it. Period.

In your case, you could just multiply those 26 matrices by them self first, then create a single TransformSOP, and use hou.Matrix4.explode() [www.sidefx.com] to apply effective transformation to your geometry.

www.sidefx.com/faq/download-and-installation/#faq3


Seems like you didn't extract houdini installation from a tar file (judging by the title of script editor in you screenshot). You first need to extract it, then double click on houdini.install or run the script from terminal (as explained in faq).

also, looks like you double click houdini.uninstall, not houdini.install

Ryu Ku
Are these things - the same Kernel doing different things or these are two different Kernels named the same accidentally??

https://en.wikipedia.org/wiki/Kernel [en.wikipedia.org]

This is because GA_Primitive::beginVertex(const_iterator &i) [sidefx.com] was tagged as depreciated in Houdini 16.0 and removed recently. I've fixed the code for 16.5 just now, thanks! albeit I wouldn't take it as a template to anything

Cheers!

I understand if you could just hit go and run it in a houdini that would be easier (…)

That was the point I was making. Thank you.

Richard Costin
Really, how so? All you need to do is set you assets to be packed on disk for speed and turn the driver checkbox on with a path. Also, are novice users really needing to distribute renders to a farm/multiple machines (for most cases)?

Yes, novice people, like small houses starting using Houdini have problems with adoption of two stage rendering. I've encountered it many times, since I was hired helping them installing Houdini in their pipeline. Doesn't bother you, doesn't bother me, bothers them.

Also, not quite sure how they would pressure an IT department?

Packing assets is a perfect situation, often not possible (not to mention bugs, which might force you to unpack your assets in a middle of the show). If you work with assets with multiply groups and shaders applied to them coming from Maya, rest assured sooner or later you will be forced to unpack geometry, or your artists will find some reason for you. IFD requires scratch, scratch has to be cleaned, cleaning isn't that easy on snapshot systems, ergo either scratch requires second file system or scripting for cleaning with elevated permissions on a server, which might not even be on the same location or might be mirrored on remote location. List continues.

People are complaining that things might be easier to setup for them as they are today. I just wanted to give them support, so if we've already reached consensus (first line above), could we not continue?


edit: I meant not continue on point out how great IFD files are, since we all already know that.