pickled
Have you tried to influence the toolset and workflows in Houdini amm? By publishing solutions for public analysis and followed by thorough RFEs?

As I said, it's possible to build one, what I'm talking is based on personal experience.
Such functionality is a bit exceptional, influenced by taste of artists, how and where you'll do it. That is, it has to be confirmed by end users first, *then* it comes to RFE-ing and such. There are dozens of scripts-plugins for Maya xGen able to something similar on xGen guides, no one is included in Maya releases.
Otherwise you'll have a few more nodes usable for robots, maybe, over a few thousands (I think)of already present in H.

NNois

amm
You have to build the thing, just like in ICE. I guess you didn't used factory ICE hair interpolators for stacking. Everything is there in H, starting from basic math nodes, geometry queries and such. It can go without single line of code (that's first hand experience), while there are significant differences between ICE and Houdini, when it comes to methods for creating something hair - like. Also, definitively there is no such offer of streamlined solutions around, like it was in ICE times.

Building what exactly ? I found just using hairgenerate in serial are working very well no ?

BTW If we ever could get our hand on that … https://vimeo.com/301068099 [vimeo.com]

If I understood the original post, it's about something like… using the output of one Fur SOP as input of next Fur SOP. That is, stacking. This definitively won't work good (even if someone would get this to work) with something really really basic in options like H Fur SOP. But it's possible to build (and get a way faster, btw).
Other than that, sometime around H 14 I just stopped with any view-port interaction in H except rotating the camera, and any shelf tool as well, for personal mental sanity. In other words, I just don't care about their brushes, handles and else. Too much different than rest of 3d world when it comes to viewport interaction, while user base is miniature. Hard to learn, easy to forget. There are other things to do…

You have to build the thing, just like in ICE. I guess you didn't used factory ICE hair interpolators for stacking. Everything is there in H, starting from basic math nodes, geometry queries and such. It can go without single line of code (that's first hand experience), while there are significant differences between ICE and Houdini, when it comes to methods for creating something hair - like. Also, definitively there is no such offer of streamlined solutions around, like it was in ICE times.

McNistor

amm
Just for info, Maya doesn't.

I dug up some info on this and apparently, there isn't something in the interface by default, but one can open the Tool Settings floating window and there you'll see the axis orientation displayed. And changing it is easily done with a ctrl+shift+RMB menu.

amm
As we all know, Maya Tool Settings is one *huge* window, created to accommodate things like weight painter or such, and info about coordinate system is lost whenever any such tool is activated. ctrl+shift+RMB is at least weird, imho there should not be any combo with more than two keys, anywhere. It's so easy to forget these ‘easy’ things in Maya, after few days of using something ‘normal’ (normal = not influenced by Linux or TDs from big studios) like Blender, Max or Cinema. Long story short, info about cord system, or position of selected anything ( object, vertex ) should be accessible permanently.
Back to Houdini, I have to admit that in nodal part, networks and so on, hopefully they don't following the Maya path - but, when it comes to viewports and interaction, H seems to be a full of unpleasant similarities.

McNistor
Not my intention to pull out the “others have it” argument, but they do have it (XSI, 3dsMax, I think Maya too).

Just for info, Maya doesn't. It also is not showing the selected vertex position. At least not in out-of-the-box version. ‘Combined’ move and tweak tool is Maya ‘specialty’ as well. So unfortunately, yeah it is a kind of negative, of “others have it”. It seems they choose the worst possible ergonomics as reference, that is, Maya one, or to say precisely, no reference. As far as I know, Maya developing ‘philosophy’ when it comes to modeling tools, it is to avoid any significant effort, any change in UI exactly for that purpose, and Houdini seems to admirably follow that style.

Zirnworks
I am also considering Grasshopper within Rhino as an alternative to Houdini, although I am not very experienced with Rhino and it is not intended for a game/illustration pipeline. But if Grasshopper is designed for generating static forms, and if it takes significantly less time to get up and running in for that, maybe I should bypass Houdini for now?

According to Grasshopper nodes [rhino.github.io], actually I'm not sure is it GH *itself* a shortest path compared to Houdini. Even basic GH set, without all these addons, is looking like a vector math wonderland, compared to comprehensive, but still generic ‘DCC style’ set in H.
However, there are another parameters, like general background. Imho Houdini is more about ‘beauty of code’, where resulting model or render is a kind of representation of ‘node art’ or ‘code art’ - plus of course simulations, solvers and such. So that's reason for optimistic ideas, how Houdini is ‘ideal’ for everything procedural, actually people just don't care that much.
Rhino and Grasshopper are coming from very CAD environment, so I'd be pretty sure you'll be able to find much more of practical tutorials for your goals, how to create this or that, possibly skipping the technical parts, at least when you're close to CAD world. Perhaps not so flexible, but don't forget that flexibility in Houdini is not granted, it's your job to enable it. It's not going without price of long times to evaluate, where any small inconsistency somewhere in graph of hundred nodes, could create unwanted result.
While ago I was experimenting with similar [forums.odforce.net], space ships and suits stuff. Today I'd probably choose a mix of any classic modeling 3d app, Blender or else, and CAD nurbs app (Rhino and Grashopper, MoI and Elephant, F360, whatever). Partially because CAD NurbS engines are far stronger than in any DCC (and Houdini nurbs is not best one, nicely to say, even in DCC). Mainly, because they are just up to task.
When it comes to learning the vectors and such, I'd go with Houdini, definitively. Also, H is unmatched in creating a beautiful networks

szmatefy
I'd like to achieve results similar to this:
https://vimeo.com/228238370 [vimeo.com]

And here the author says he uses SDF and also show his Volume VOP as well. The thing I want to avoid is the use of texture, and the issue present with polygonal objects around the corners.

For his final ‘cliffs’ showed around 12.00 it seems he used polygons to ‘displaced edges’ phase, including that one. Something like scaled voronoi fracture, re-mesh and some noise over everything. A bit of noise is added to VDB at the end of the day, and imho exactly that phase is not looking very realistic, it's more like calcified mud ( Ok, technically this is stone as well).
Volume VOP I've noticed at 07.24, worley noise randomized by something and such trickery, seems to be more for basic formation, but not used for his cliffs.
All in all he got nice result, however, entire story is too much occasional, 90's style approach where certain popular method is looking like something in nature in certain case and it completely fails in another case, like specular shading pretending to be reflection. From something like Houdini I'd expect more ‘geologically plausible’ approach, let's say to start with constructive elements like calcification, erosion, abrasion, cracking…
Btw nothing wrong with Volume VOPs except they are slow as hell.

hello Szabolcs,
as you're noticed, modulating the SDF distance is different thing than displacement, if we are considering displacement as ‘pushing along normals’. In case of modulating the SDF distance, 3d procedural texture is shifting the zero threshold, used later for converting to polygons - however, texture is placed on volume, strong shift could create overlaps or some else strange thing.
Now if you want ‘pushing along normals’ this could be a VDB Reshape SOP with alpha mask, while texture has to be taken from something polygonal, to avoid volumic ‘overlaps’, like in attached file.
Anyway, once the plain pushing is enough, that is, you don't need cavities and such, it's a way faster (several times, probably) to do this on polygons, converted from VDB.

If company is not offering the all paying options like other companies in same field, then yes, that's unusual and not good for that company. It's looking like one man band trying to sell something.

BabaJ
What's unusual about using a credit card to buy software?

It seems you didn't read previous posts.
By the way, as far as I know there are only two 3d related apps, not possible to buy through PayPal: 3d Coat and Houdini.

There *should* be PayPal option as well. Three times, when I bought H Indie license using credit card, people from local bank called me next day to confirm payment to ‘certain’ SideFX, where that name was somehow especially accentuated.
Perhaps this told me that I'm only one their client who's dealing with ‘SideFX’ thing, while local bank is a part of one huge European bank. When you're using unusual methods, unusual things are going to happen on the road…

wildruf
https://friedasparagus.co.uk/ [friedasparagus.co.uk]

Thanks for link. Definitively it sounds promising as survival plan for Houdini rigging. While still it is not saying anything on how to compete against Maya GPU evaluation and displaying of deformers, without read-back overhead. What's considering as Maya parallel, actually is a set of methods [download.autodesk.com], some of them relying on Maya VP2 - not just a ‘put the deformer to work on OpenCl’.
And all that is only a technical part. In reality, animators will have to say something positive, too. Here, if app wants to compete against Maya, first it has to support Maya features or at least to respect them, like Blender does. Let's say Maya interaction mode could be a good starting point.

Fco Javier
What software does it offer at any time in the modeling, send only a fragment of the modeling to any operator for the particles to happen or any other madness? I think that is the essence of Houdini. I do not think they change to make it parametric, Houdini has what it takes to model, in his own way.

A bit of nit picking, it is possible in Softimage ICE to some extent, however I don't remember that people were so excited by multiple dependent networks all around. On contrary, built in ICE particle system was allowed to do as much possible from single network, even it will be more ‘natural’ for ICE to use something like at least two, similar to Houdini SOP-DOP relation.
Have a personal experience here, was running a few free systems based on ICE, it always been demand for as much compact structure, despite the complexity of ‘one network for all’ solution.
Perhaps because users were animators or modelers, focused on final result, not on ‘beauty of code’ or network structure. Houdini user base seems to be somehow different…
On positive side, widely used procedural approach was a post process of direct modeling, relying on Softimage ‘construction modes’, things like shrink wrap executed after modeling, as an effective re-topology method, or custom symmetry options based on ICE ops, finally a ‘clone’ option, as end result of construction history of one object used as starting point in another object. In Houdini that's a full ‘object merge’, while option is possible and reliable in other apps as well, like ‘instance reference’ in Max.
One really nice implementation of post process is Blender's ability to do non destructive beveling by keeping the bevel modifier at top of stack, based on edge properties created in ‘edit’ mode, before any modifier stack.
And, even nicer example of effective, viewport based procedural approach, IMO is Autodesk Fusion 360 [www.youtube.com] around 8.00 they showing how it's possible to jump into various stages of NurbS construction.
Now back to Houdini, while it's possible to setup probably everything mentioned, in practice is different story. ‘Object merge’ is prohibitively slow when used as post process of direct modeling, Edit node behaves rigidly, it's always added on end of tree, Houdini is not recognizing the existing Edit node in middle of three and proceeding with that one (or at least this was last time I've tried in first H 16 or so).
In short, when it comes to direct (viewport based) modeling, seems to be similar story with Maya, where existing network is actually too wide, too general to allow imposing the effective viewport based rules and control over it. In same time, framework is already adopted by facilities, so they can't change it (that is, simplify it), just for sake of something almost not existing in H, like direct modeling. So only way seems to be Maya path, to implement something simple like Silo in Maya today, basically unrelated to rest of app, except a plain in-out connection somewhere in network. Better than nothing, but also not competitive to free app like Blender, today. (Long time ago when Maya started its long journey toward polygonal modeling, Blender was a way behind commercial apps).
Anyway just personally, I don't see problem there. I'm already feeling confident with three polygonal modelings in other apps, don't see any reason to put fourth one in mix, actually I'm trying to reduce that number. Houdini alone is able to keep live connection with imported geometry, so that's it, model in something else, import or reload in H.

You should use quaternion slerp node (spherical linear interpolation node in H) instead of plain mix in your ‘blend orient’. Maybe there's similar result when normalizing the output of mix node, anyway, slerp is what you need, here.
In any case, anywhere, quaternion will flip (or precisely, return back to remainder) when delta is more than 180 degree, considering all three axes. If less than 180 degree is not enough, you can create a ‘real’ ribbon,
using the NURBS patch and sampling the orientation at several points along patch, where angle between two neighboring samples is expected to be less than 180 degree. Then you'll be able to calculate the summary of all angles.

PaQ WaK
We (I) badly need a subdivision display mode the doesn't just mix a cage display with the subdivision result.
Once in sub-d display mode (-, it's very difficult in Houdini to select points or edges, as they might be under the subdivision surface.

If helps, you're not only one who tried subd display in H 16.5, hehe. It reminds me to Maya Smooth Proxy (or something called like that) from 2002 or so…. Funny enough, now it can't do ‘display all subds’ mode anymore, probably not used that much by modelers, but usable for checkout by people who are creating animated deformations. Hopefully I got the habit to never ever uninstall the old version. Still 16.0.7 here…
Otherwise, with all due love and respect to H, don't know what to say, it seems to be multiple chicken - egg problem with anything ‘direct’ in H, including animation. From ‘chicken side’, Side FX should be waiting for real response first, from ‘egg side’, they seem to have a great talent to keep the app 5-10 years behind the rest of 3d world, at least when it comes to ‘direct’.
Yeah it's better than it was in times of H 13 or so, but starting point was a somehow catastrophic mix of ‘unique solutions’ like old Bend deformer, not able to turn plane into cylinder (and more, like ‘soft selection’ based on normals, move tool changing into tweak tool by own criteria, so on), and unbelievably weak engines like nurbs in H, asking to manually control the marching steps.

Perhaps this is a philosophy of app for developers, first to supply something quarter-done, then to proceed if there's enough of interest for full quality. But this is not how does it works anywhere else…

One day when they'll remove their IMO arrogant comments about tumbling style in preferences, when they'll seriously take apps like Blender, Max, c4d, Modo as an 1:1 reference for direct modeling (that is, anything, but seriously), there will be some hope. Otherwise, just use 3d viewport only as display and everything will be fine, of course with possible activities in that, node only way.

Grendizer
One more clarification :
tx, $TX, $N, @Frame : are they all “attributes”?

Strictly speaking, I'd say no one, tx is parameter, others are variables.

By docs, attributes are named values stored on geometry, like point position, normal, weigthmap, or custom attributes. Parameter is option on a node, like transforms, rendering or viewport visibility options. So, naming and functionality is similar to Softimage, where word ‘attribute’ means ICE geometry attribute.
Attributes are ‘physically’ stored on geometry. If you use Attribute Create SOP (or something else) to create let's say my_attr attribute, and you save that piece of geo to hard disk as .bgeo file, using File SOP, my_attr attribute is saved too, you can use my_attr by loading .bgeo in another scene.
Now, variable… usually this means a named storage space in memory that contains a value we can read or write. In Attribute Create SOP, there's ‘local variable’ option. If this is left blank, Houdini will initialize (initialize = store in memory) a local variable called MY_ATTR. Let's say, variable is a virtual child (whatever that means ) of attribute, raised into memory for immediate use by app - while variable could be created by something else than attribute, which probably is case with @Frame.

Yeah I think it is explained in docs, while it's not short story, perhaps because of historical reasons.
In practice, let's say if you apply Polywire SOP over something polygonal, it will show something like $NSEG in expression for controlling the segment scale. If I'm correct (could be wrong) $NSEG (number of segments) is a ‘child’ of certain attribute, created by Polywire SOP.
Local variable (uppercase thing) has to be created, to allow h expression to be able to access the data. This is the ‘old way’.

'New way' is in Polyextrude SOP - if you want to control the scale of extrusion distance, you create a zscale primitive attribute using Create Attribute SOP (of course this one goes before Polyextrude SOP), and enable ‘zscale’ into ‘local attributes’ tab of Polyextrude SOP, and that's all.

This was all about mesh components like vertices, points, primitives, details.

When it comes to transforms and channel expressions, local (in parent space) transform is as you said, tx or such, lowercase without $. You'll use $ if you want to access something and combine it with tx. There's expression cookbook [www.sidefx.com] in docs.

$TY is Y position of point (vertex in Maya), dollar sign belongs to hscript expressions, gradually phased out from H.
Local and global expression variable is about Houdini structure, how Houdini handles the data, it's not about transforms. Let's say global expression variable $F is current frame.
When it comes transforms, H is similar to Maya. rz or ty are local (in parent space) z rotation and y translation. Global transform is not exposed all around like in Softimage, you have to compute it somehow, probably by CHOPs.

Simple way to link parameters (without remapping) is RMB over parameter name, ‘copy parameter’, RMB over another and ‘paste relative references’. Later, you can edit the created expression.

Hello

I think it's something like this. Shouldn't be hard to checkout in ICE (my XSI is ‘conserved’ on old machine).

carldrifter
If I undstand correctly,vector4 is a basic type but quaternion is a special type of vector4.Therefore,I can define vector 4 with any 4 floats as I want but not all vector4 type can be quaternion. Quaternion are related to transform and rotation~

A bit of nit picking, actually any vector4 can be quaternion, but not ‘meaningful’ one as definition of orientation, or, as data used later by Houdini. I'd go with jsmack explanation, that quaternion, normal or color for example, is a *tag*, telling Houdini how to use data.
Perhaps a bit of visual help could explain more. In pic bellow, first small network is an usual method for isolating the rotation around x axis, while in order to work properly, vector4 has to be normalized. That's typical use for defining the orientation.
Second is more a practical use, as fourth input dimension for curl noise, where it has nothing with orientation.