Hi,

maybe I am missing what you mean by “moving the primary null” (I used the “master_ctrl”), to me, moving the rig up is looking fine:





Marc

I would like those 1-post-heroes to mention in their rants that they are generally working for free for anyone and only require a minimum percentage of an employer's income if that employer makes more than a given amount of money.

Because that is exactly what these anonymous superstars are saying: If they are expected to pay money for other people's work, the “world is off”. Everyone should provide their tools to these people for free, so they can make their first dime.

Oh, and in the supermarket, you should get everything for free, too, and only have to pay if you are making actual money from cooking what you bought. If you are only eating your meals yourself, it would be “off” to have to pay for it. Same goes if you are only cooking for a bunch of friends and every friend is only paying you a small fee, say a thousand dollar per meal. Because from a thousand dollar a meal you don't get rich, do you. So that should be free, too.

Not to forget that buying cars should mean you get a car for free if you are not using it as a paid taxi. Uber doesn't count because Uber is making more money from you driving that car than you are. So cars should be free for anyone.

And if the tool you are sell… you are giving away for free to all those rainbow unicorns, you HAVE TO provide all the training for free, too. And you have to be available for support needs. And you have to adjust your tool to the very specific, highly unskilled abilities of aforementioned one-post-celebrities. Because … well, erm … because.

Really, it's all so off. The offest is that money even exists in the first place, it should be freely available to anyone BUT bankers.

Marc Albrecht

> What could cause this?

a thousand things. Quite hard to tell without more details.

One thing that comes to mind is: By parenting one object to another you are creating a local space environment for the child object. If that one is animated (maybe from a previous world-space animation?), it is now moving in local space, combining the parent's object's animation with its own.

You could also have local space animation on the mesh itself.

Or you could have constraints working against you.

Or … so many things. Why not simplify the scene (cube, sphere) and upload it here?

Marc

Moin,

you may need to link the transforms on your target (to be animated) rig to the source (loaded after the fact) rig, which I would probably do with a few lines of Python.

If the rigs weren't identical, you'd need to retarget, but using the same setup a script should be straight forward.


Marc

V0.5 supports cloth layers (fully rigged), hair, eyelashes AND also converts those to matching single-hires OBJ versions. Of course, morphs/blendshapes that span multiple layers (e.g. eyelashes deforming according to facial features) are handled as well.

This version adds a bunch of workarounds for bugs in Houdini's FBX importer (bugs either crashing Houdini or making imported layers unusable). Since this is considered “third party” by SideFX, discussion about how to deal with these issues will continue elsewhere, obviously.

Marc

P.S. Note that this Re-Rigger tool is in no way limited to “DAZ” stuff, I invested a lot of work to make it “FBX” compatible and working with exports from various sources. The IDEA was and still is to provide an import-system for Houdini that not only converts joints-based rigs to bones (and obviously, by exporting, back) but also deals with hires-variants of meshes, mutli-layer FBX/clothing/add-ons etc. I am merely using DAZ exports for examples because they are simple to create and provide a lot of issues that need handling.

Hi, Brad,

you can either “force” a material assignment (“shop_materialpath”) to a geo through the “global” material tag - or you can assign shop_materialpath to individual groups (points or primitives/vertices) using a material node (or attribute wrangle).
Have you had a look into your node tree whether there's a wrangle (or material node) that does the assignment? Have you had a look in your geo spreadsheet to check if the shop_materialpath has been assigned in the first place?
You might also have a shader that does “manual” material assignment upon render time …


Marc

I have had this problem a lot when using Redshift. Most of the times I managed to get around it by breaking the simulation/deformation, often it was some mismatch of groom/guide/rest geometry that wouldn't cause any harm with Mantra but went bonkers with Redshift. At times I *thought* it might be a scaling thing, as it didn't happen when NOT using any scale in the scene (or not using any object-merge, which I use *a* *lot*).

Unfortunately, I cannot provide a robust solution, but I can confirm that it *feels* like a Redshift thing.

Marc

Hi,

apologies for being imprecise. If you are SURE that your Redshift plugin MATCHES the Houdini build you are using (you are not providing that information), then please try to REMOVE the Redshift plugin. See this post [www.sidefx.com] for confirmation of my theory.

The best idea is to not use Redshift anyway, but that's my very biased personal opinion and unrelated to this problem.

Marc

Looks like you're using Redshift. Might be a Redshift thing - try disabling it and see if the problem goes away. Or/And make sure to use a matching combination of Redshift plugin and Houdini daily build.

Marc

Hi, unknown user,

there are several approaches to creating a bone “heading” for the “right” direction. One way is to use a lookat-constraint (pointing to your target position), which would, obviously, limit the way you can handle the rig.
You could, however, use a lookat, grab the world transformation matrix, extract the rotation and put that into your bone's pretransform, then delete the lookat (basically “cheating” your way around constructing the matrix yourself).
Or you construct the transform matrix from head/tail positions, extract rotation values and write them to the bone.

Many ways … the “best” depends on your specific needs.


Marc

Hi, anonymous user,

without having looked at your project, the general idea of a “baking” (reproduction) process is to imagine a virtual camera sitting “on the normal” of each (target) texture UV pixel over the (source) object and “attracting” (in the purest sense of the word) that single pixel.
What most people do wrong when reinventing that wheel is to either directly calculate one UV position from the other ad ignoring that you have to “cross over” the target UV map onto the source “virtual camera position” and only at render stage actually USE the source UV map - or they ignore different UV tile rotations (not doing a trace through a camera but trying to calculate the correct pixel offset only on UVs).

The standard approach is to x/y (or u/v) walk over the target UV map, calculate camera positions from P using those UV offsets, offset the camera slightly by the local normal and read the source (source-UV based) texture information (which may be interpolated).

Marc

I would, honestly, suspect June 2020 to be a candidate for 18.5, not so much for 19. But what do I know … :-)

Marc

Hi,

not using MacOS my ability to help is quite limited, I am afraid. However, I have suffered from using ImageMagick a lot and, yes, the way the different command line tools operate has changed over time. Where in the past you could use the “convert” command (a single executable), a standard compilation today will require you to use “magick convert”. It's quite possible that specific commands have disappeared / integrated / combined.

{sidenote:
While I do see the benefit of Houdini using external applications for tasks, using “Open Source” tools in my world has always been a critical and not-for-production choice of solving problems. Open Source tools tend to change their behaviour and “blindly” updating tool versions in a pipeline setup is prone to break everything. My suggestion here really is to replace more or less simple tasks like a “montage” by Houdini-internal solutions (after all, Houdini CAN do image montages) - but that's a hint towards SideFX, not so much towards the user that only wants to get on with their own job.
}

Trying to answer your question: I do not think that you are doing anything wrong. Since ImageMagick is an external tool that is not maintained by SideFX, it is possible (and in fact almost guaranteed) that older example use cases in Houdini's documentation will fail using newer versions of such external tools. Users may have to adjust to that …


Marc

This is a frequent problem for me (Houdini baking when there really isn't anything to bake) and so far my best solution is to use stash-nodes or file-nodes to write out the state at keypoints and manually update them when required.

Marc

Hi, Akira,

two ideas come to mind:
a) Is there really a line break between the two input images to your concatenate command? From your quote it looks like it and this would most definitely be wrong.
b) Have you tried executing the exact command line that is giving you an error to check if it works outside the Houdini context? If not that would be the best bet to figure out what goes wrong. It *might* be that the quotes you are using are misinterpreted by your OS.


Marc

Hi, Brad,

the groom needs to happen on the REST pose, i.e. the input to the groom node needs to come from the original tube geometry, while the input to the deform node (“animated skin”) needs to be the deformed one.



Note that “input skin SOP” on the groom node points to your undeformed original geometry.

Marc

P.S. Hint: You can speed up hair usage in Houdini dramatically if you cache out the groom result to a file (it's a single frame only), that will avoid cooking the groom node on every single frame. Sample applies to deform, obviously, but that's one cache file per frame, so much more disk usage.

Hi,

you're not giving enough information. The initial groom usually only creates a single “state” (rest state), while a “deform node” is taking your animation (point positions) and applies offsets to the initial groom. So a standard setup for groom data is a two-node set: Groom + deform.
If you aren't doing anything to the groom-data (basically curves or groups of points), you are basically “moving everything”.

If you can create a simplified test HIP file of your scenario it might be easier to help.


Marc

… figured out how to get cloths and additional layers over from DAZ to Houdini in “one go”.
Since this thread is now considered “third party”, while it isn't (it's about working in Houdini with FBX rigs), I'll keep quiet and don't pollute this forum with hints about how to get Houdini to work nicely with that specific kind of FBX workflow.

Sigh.

Marc

Don't you just love all those single-anonymous posts by users with very telling usernames …

In the picture that you attached I can see only ONE actual (connecting) seam (between the arms and main body part) whereas the other “seams” actually are hems. You may want (or not) to constrain those areas to your animated geometry, but they're really not about setting the shirt up for simulation.
As for the single seam, please do a search on sideFX' tutorials section or on Vimeo. There REALLY are very well presented tutorials on how to use Vellum's “seams” for connecting parts of clothing.
THEN come up with a sample HIP to post here that shows how far you have gotten by trying for yourself. I am certain you will get help once you have demonstrated that you TRIED.

Marc

Hi,

this thread has been moved to “third party”.

This is not about a third-party app, but about an ongoing project within and exclusively about Houdini. There is no “paid service” around this, there is no “party” involved and there is not “secondary download site where you need to register” or anything.

I am not going to post updates to this WIP in a “third party APP” forum/thread, if necessary please remove this thread altogether.

Marc