Search - User list
Full Version: A few things I could not find when I made the switch
Root » SI Users » A few things I could not find when I made the switch
grayOlorin
Back in the day when I made the switch, there were certain items that were easy to find in XSI but felt sorely missing in houdini. Later, I found out that they are actually available, and in a very flexible and powerful fashion in houdini, albeit hidden and not as simple to use. Some of them I feel they are not quite there yet (could be reproduced but with a LOT of work and expertise)

I would like to add these recommendations to sidefx as part of this initiative:

- Mesh information transfer as texture bakes: This is the usual albedo transfer/occlusion transfer/normal map transfer/etc, which in SI is called the ultimapper. In houdini, you do this by using a material in your target mesh with a gather loop (or any ray based operator) to transfer ANY surface variable you want (hence the amazing flexibility). Then you bake these to UVs by simply enabling UV rendering in the mantra node. I recommend a shelf tool to do this (with an equivalent OBJ digital asset) which encapsulates the gather loop functionality to generate typical bakes (color, normal, occlusion, height, displacement, etc.). This will facilitate entry level users, as well as educate people on how to do this (by allowing them to dive into the node). I actually learned about the powerful lookup CHOP by using the set driven keys shelf tool . I actually built something like this for my studio and it is not terribly difficult for anyone experienced in houdini (low hanging fruit)

- Mesh attribute transfer: I cannot remember if you have a shelf tool for this, but SI users will equal this to GATOR, which in houdini is the attribTransfer SOP.

- Polyreduce: Would LOVE to see the Houdini polyreduce SOP being able to yield the same quality as the SI polyreducer (which has been stolen by maya 2014). This is a best in class clean topology polyreducer. Even a remesh method which uses this same algorithm would be great..! I can provide more info on this if needed. You could repro this in houdini to some extent but it would not be trivial..

- drag and drop into houdini from explorer: This was not in SI, but I feel it could help a LOT for new people. Basically define bevaiours in houdini based on dragging and dropping files from OS into it. For example:

- If you drag a hip file, it opens the hip file
- if you drag an obj or bgeo or vdb file, it automatically drops a geometry node with the file sop referencing that file and switches the viewer to scene view
- if you drag an image, it automatically adds a file cop referencing that image, and switches the viewer to composite view
- if you drag an audio file, it automatically adds a file chop referencing that file and switches the context to motion view
- if you drag a cmd or py file, it automatically runs them
- you can define custom drag and drop behaviours using python

- Edge loop group sop and edge ring group sop with the correspondent viewport equivalent tools would be nice

- a MeshBuild interactive SOP for free plotting of meshed points and/or primitives (similar to the add sop, but more gear towards interactivity)

let me know if you have any questions…!
grayOlorin
almost forgot…!

- add to the transform SOP and the OBJ context ability to rotate pivot in addition to translating it
edward
grayOlorin
- add to the transform SOP and the OBJ context ability to rotate pivot in addition to translating it

Could you expand on this? The “pivot” is normally the origin position that is used for rotation. Do you mean a “pivot for rotations”, or do you mean to actually rotate this “pivot position”?
tomsvfx
grayOlorin
- drag and drop into houdini from explorer: This was not in SI, but I feel it could help a LOT for new people. Basically define bevaiours in houdini based on dragging and dropping files from OS into it.

Funny, I yesterday made an RFE for this feature.
sekow
nice. thats money!
Rob Chapman
- drag and drop into houdini from explorer: This was not in SI, but I feel it could help a LOT for new people. Basically define bevaiours in houdini based on dragging and dropping files from OS into it. For example:

yes its been a while for you in Si then as we have had drag and drop for quite some versions

but yes I confess the first thing I did with all these wonderful .hip file gifts to be found everywhere is to (try) drag them from my downloads folder into houdini.

also with ICE compounds they can be made a link on a web page and downloaded directly into an ICE tree. very user friendly!

Ciaran (hello!) also wrote us a pointcloud cache drag and drop from inside Softimage's own internal browser. so yes automatic file type association and relevant import behaviors are very welcome speed enhancements
grayOlorin
grayOlorin wrote:
- add to the transform SOP and the OBJ context ability to rotate pivot in addition to translating it


Could you expand on this? The “pivot” is normally the origin position that is used for rotation. Do you mean a “pivot for rotations”, or do you mean to actually rotate this “pivot position”?

Hey Edward, actually rotate the pivot position. The desired result is the ability to translate or scale an object along a coordinate system that may not be parallel to the world coordinates (without having to use parenting or a previous transformation, basically encapsulated in a single transform node)
pezetko
I really like how simple is the transformation space in Houdini instead of hidden pivot thing in the Softimage XSI. It's terrible pain to figure out what are transformation operation that user does with pivot of the object and what he reset or freezed. Also ICE global/local space switch in visualisation is very confusing. I often ended up freezing all transformation to get quick working prototype instead of trying to figure out what Kinetic States (transformation) are hidden in object transform in SI. The auto Kine Local recomputation is just trick that Softimage does under the hood and it couse that sometimes you ended up rotating and keying all axes instead of just one becouse somebody rotated that pivot 90 degrees in wrong direction.

If there will be added pivot rotation behind the curtain how you can clearly extract this transformation back? As far as I know it's not possible to decompose the transformation matrix that has benn affected by rotated pivot. Usualy we end up with some unwanted shear deformation.

Righ now, when I want to transform any geometry (deformation) in different space the simplest thing to do is add 1st Transform sop to setup pivot (rotation) using centroid expression on the pivot. Then I can add 2nd Transform SOP that is in new “local” space and I can clearly distinguish between this two spaces, turn the transformation off (reset transformation) or put it back (enable the node). And I'm still safe to be in correct global space for simulation.

So yes, it's not for lazy guys but you will get full controll in reward. The way how to setup pivot rotation same way like in XSI is to use Transform SOP inside object in correct way.

If you want local deformation, you can just put transform SOP inside of the object, the math is clear and obvious behind this, just one matrix. If you want offsets, just put couple of transform sops together.

In object space, there is beautiful pretransform that works. If you need more, you can always add parents or constrains.

Please explain more clearly your point of view how the pivot rotation should be done. How it affects changing the SRT order? What would happen if you move your pivot, rotate it, than add some scale, transform and rotation and then you again rotate your pivot? How it affects scale and other transformation that are already in place? How it affect pretransform?
grayOlorin
How it affects changing the SRT order?

the pivot rotation should be computed before the SRT order is taken in consideration. it is like doing an SRT on a coordinate system that is simply not parallel to the world coordinates

What would happen if you move your pivot, rotate it, than add some scale, transform and rotation and then you again rotate your pivot?

it should be the same behaviour that happens with the transform sop if you changed the pivot value while a rotation was already in place. The transform SOP is cooked from scratch to transform the points given the new matrix

How it affects scale and other transformation that are already in place?

see above

How it affect pretransform?

In the case of an OBJ network, my expectation is that it would not affect it adversely right? it would literally behave as if the pivot was being translated in addition to having a pre-transform


I should also note that, unlike in SI where the pivot rotations are “hidden”, my expectation is that pivot rotations in Houdini would be a persistent parameter in the transform SOP and/or object nodes, which can be changed at any time and cause the network to recook

Where this is very valuable is if you are making a digital asset that, for example, slides arm gear down an arm on which the bind pose may not be a T pose, but an A pose. Be able to drive that transformation coordinate orientation parametrically (i.e. with expressions), can open a lot of possibilities which currently are very tricky

Also, note that having a transform SOP's rotation drive the orientation of another transform SOP is not “quite” possible as each transform sop changes the vertex locations, not the orientation of the objects (and each transform SOP simply starts “from scratch” (unlike the OBJ network). interestingly enough though… I did just noticed the Transform Axis SOP, which you can use to transform given an arbitrary axis… perhaps this could meet the need
edward
grayOlorin
the pivot rotation should be computed before the SRT order is taken in consideration. it is like doing an SRT on a coordinate system that is simply not parallel to the world coordinates

I think I'm having a hard time seeing how this isn't just an additional transform at the OBJ level, either as an extra parent object to rotate the pivot, or just baking it into the object's pre-transform altogether?
pezetko
edward - I agree.

In SI users have 3 hidden transformation spaces (parents) in each object (Local space (with auto recomputation), pivot and pivot compensation and you can also add KineState to these) result is that you had to do less parent transformation for easy stuff. On the opposite way you have to do more in the end to have clean transformation and navigate easily. And it goes very quickly into mess if somebody do them in wrong order somewhere in the pipieline. It's really hard to explain to users of other software like Maya or Houdini why there is such mess but XSI does a lot of stuff under the hood that aren't availible to modify later. It's basicly blackbox with 3 different transforms that are somehow connected and you have to figure out how. In the end a lot of animators/riggers use some tools like Gear that do that hard work for you but for TD it ends up harder to debug if something goes wrong.

Try to imagine in it as you have Object Transform and inside Object you have Transform SOP. With Transform SOP inside you will setup your pivot aligment, so you can rotate the space for geometry, so then you can model in different orientation than world space with gizmos in Object Local mode. Then in Object transform you can still have zeroed transformation for animation but your geometry can be tilted or scaled nonproportionaly. That way you can still modify “pivot” = Transform SOP. In SI pivot is separate transform that sits between editable geometry and object transform. I specified editable geometry becouse for Null objects it doesn't apply, for Null object pivot and local transform behaves same and this way when somebody start to scale hiearchy with Nulls in SI it creates mess in the end.

E.g. if you want to add parent object with global offset with same position as original object to the object which was animated in local space (with keyframes) in XSI you have to add two nulls as parents, one that have zero transforms and one Null that have actual offset. Or you need to add animation layer, but that way it modifies your animation curves (fcurves).

Transform axis SOP somehow works, it just need wrap the head around the direction to angle and axis transformation for this SOP inputs.

Good workflow is to transform the geo into the origin, do your stuff and transform it back.

I like how Modo handles the reference planes in the way to be able to temporaly set up the coordinates based on different object or polygons, and return back without messing the object kinematics and it can also transform whole scene that way for modeling.

I would like to see more interactive workflow for different construction plane aligment during modeling (inside SOP). Actualy Tweak Tool from XSI is very good example how to handle different construction spaces/planes. There is interactive component selection with realtime previsualisation of selected components (It highlights what is under mouse cursor). You can select some components (polygons/edges/points) choose operation (toggle between move/scale/rotate) togle between transform, weld (fuse) and slide component and with middle mouse click on any component you can choose your handle aligment by this component so you are not limited to object or world space only. With temporal pivot offset throught sticky (transient) alt key and strong snapping options with sticky (transient) ctrl key and increment update (throught shift key) it's very powerfull interaction concept not just for modeling.
grayOlorin
perhaps this is a more appropriate concept to be applied on SOP space (i.e. transform SOP), where the whole transformation is baked into the points after the node cooks, therefore it does not affect any kinematics during animation or rigging. In all honestly, if the Transform axis SOP allowed for modifications on that axis correspondent perpendicular axises, it would do the desired result (pezetko, I believe this echoes your final comment right?)

Edward, you are right, in obj level this can be achieved via parenting and pretransform without too much issue. I feel this gets trickier on SOP level, which in some digital assets is needed to give a particular interaction to the user at a particular part of that SOP network (i.e. via an exposed handle for example)
cb
grayOlorin
- Polyreduce: Would LOVE to see the Houdini polyreduce SOP being able to yield the same quality as the SI polyreducer (which has been stolen by maya 2014). This is a best in class clean topology polyreducer. Even a remesh method which uses this same algorithm would be great..! I can provide more info on this if needed. You could repro this in houdini to some extent but it would not be trivial..

Please take a look at the Remesh SOP in H13 if you haven't already. It might not be exactly what you want, but it does a great job imho.
grayOlorin
I am aware and love the remesh sop (trust me, I live by it and use it quite a bit ). The si polyreducer has an optimal algorithm for quad preservation though, which is VERY useful for character LODs. Check out this video, around 1:43. Preserve quads is the parameter of interest:

http://m.youtube.com/watch?v=_aWT2VXtTJA [m.youtube.com]

For game characters, this is SUPER useful as it facilitates character lods. I would love to have this ability in Houdini, so I can mix it with my other sop networks that handle character asset creation
edward
pezetko
In SI pivot is separate transform that sits between editable geometry and object transform.

Thanks for your insightful comments, pezetko! So as an alternative to a Transform SOP, could you branch off another geometry object for the pivot transform display that instead?

Say you had an object chain like this: A -> B -> C
Then if we want to do a “rotate pivot” for the geo inside B, we do this:
- Undisplay B
- Branch off a new node from B, say called B2 and display this new one
- Inside B2, Object Merge in the contents of B without transformations

EDIT: I guess this means an extra object transform though which would mean a performance hit.
Platon
grayOlorin
- If you drag a hip file, it opens the hip file

personally i would much rather prefer for houdini to merge/import my hip file into the current scene, and not open a new one that way you can have useful snippets of scenes and setups in your separate folder/drawer
Dennis Weil
owlYzarc
grayOlorin
- If you drag a hip file, it opens the hip file

personally i would much rather prefer for houdini to merge/import my hip file into the current scene, and not open a new one that way you can have useful snippets of scenes and setups in your separate folder/drawer

How about having a default operation of merging the scene upon dragging and opening it when alt+dragging. Ultimately this should end up the same way the IPR view handles its clicking and dragging events via a python script. This way you are able to define your own behaviors depending on the filetype and the location it is dragged to. I would like a different behavior when dragging over my viewport than dragging it over the network view for example.

Best,
Dennis
riviera
how about a python-scriptable drag-and-drop event handling?
tamte
in regards to the pivot/transform discussion I'm missing mostly Neutral Pose layer rather than Pivot layer of the object transform
Neutral Pose is equivalent to Pre-Transform with one big advantage of being animatable

simply making Pre-Transform accessible/animatable (like SRT parms) would make lots of rigging tasks so much easier since it would be possible to adjust Pre-Transform by expression linking or CHOPs, at least that's how I was using them all the time in SI
edward
If you want an animatible Pre-Transform, then you can insert an additional Null object (display off) as the input?

IMHO, the advantage of having a pre-transform is precisely because it is not accessible. This lets us:
  • Be fast. There are no separate SRT values to combine into a matrix, and there are no parameters that it needs to evaluate. It is simply a 4x4 matrix.
  • It lets us combine arbitrarily many transforms into a single one. If we didn't do it this way, then “clean transform” will either need:
  • To generate a set of SRT parameters that includes shear in order to
    maintain the same world transform, or
  • To generate a new set of SRT parameters (without shear) for every
    “clean transform” operation. There would no way in general to
    combine them if a shear was needed.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB