I just had the warning after I linked this thread to another one … :-D

Happened when I searched a subnetwork for some nodes, double clicked (which deleted the search window) - the warning popped up again.


Marc

P.S. That's in 18.0.430 btw.

According to this thread [www.sidefx.com] the Qt warning about WM_DESTROY should have been resolved in daily build 430. Pretty sure that the lost shelf tools are unrelated to the Qt warning.

@Robin: Maybe you could try renaming your Houdini-18 settings folder (with Windows that's in your personal documents folder) - quit Houdini, rename that folder, restart Houdini. See if that fixes things, if so, you could copy over what you consider important.


Marc

Moin, Robin,

the shelfs are configured for the various desktops or contexts. Have you tried resetting your current desktop?



In theory that should rebuild the shelf for your desktop.


Marc

Moin,

I don't understand the content of this thread:

> I mean that do you agree that Houdini's cooking system should be faster?

… what exactly do you mean by that statement? The “cooking system should be faster” has no technical meaning - if by “cooking system” you mean that Houdini “cooks” (compiles and/or executes) “nodes” (or functions) when necessary. There is no “faster” to this, except for “more often” (which you probably don't mean) or “within shorter reaction times” (near real time reaction?), which most likely would only result in milliseconds earlier cooking start.

If you are talking about the compilation of nodes - please do say so. Please point out exactly what kind of nodes you have in mind and what precise compilation you are having issues with.

If you are talking about execution times of nodes - please do say so. Please point out exactly what kind of nodes you have in mind and what precise compilation you are having issues with. Keep in mind that a compiled VEX node has a different performance footprint to those horrible, ban-deserving, patience-killing Python-nodes. Unfortunately, nowadays more and more features all over the world are being done in Python making everything slower and more error-prone. But that's a different topic altogether, for there are evangelists for Python out there one just does not want to mess with.

If you are talking about simulations - please do say so. Please point out exactly what specific situation you have in mind and also show your performance metering showing WHERE things go slow and where things go fast. Houdini provides the tools to do that, use them, please.

Let me just pick this line of yours:

> Dropping down RBD Material Fracture takes about 10 seconds on a six core machine to prepare (depends on your machine it takes more or less)!

… you are already stating that “it takes more or less on different machines” - so what's your claim then? If your hardware isn't up to your demands, why not start there?
I am running a five-years old quadcore machine here that is nowhere near “top nodge” and just dropped down an rbdmaterialfracture node. It took 1.5 seconds (one point five seconds) - which, too, is a completely non-informative thing to say. It has NO MEANING. What has meaning is: What happens in the background? What is DONE when you drop down a node?

For sure, a lot of functions in Houdini could benefit from an overhaul, no doubt, maybe some need a “rewrite from scratch”. But simply saying “Houdini needs to be more faster” (I like that phrasing) is the same as saying “me wife needs to be more prettier”. At least for the latter man invented alcohol.


Marc

P.S. Don't get me wrong. I want things to be faster all the time. If I can endure a Youtube video, chances are that I play it back at 2.0 speed because people simply talk WAY TOO SLOW in order to make more money. But you really need to be specific, you need to do some basic research about what is HAPPENING and then send RFE to SideFX to help them understand your usecase and maybe even come up with solutions for your specific needs. They are QUITE GOOD at that. They actually care. Just give them a chance to help you - by being constructive.

Moin, unknown/anonymous user,

Houdini's IK is bones-based, many other tools use a joints-based rigging approach. FBX is, too, a “joints rig” supporting format, therefore you have to convert the rig from nulls to bones.

I have done just that and documented the WIP here [www.sidefx.com]. Depending on your desired workflow, an alternative approach (if you don't need to use Houdini's IK) could be to not create bones while importing and instead create handle-/control geometry for the nulls, posing directly on them.


Marc

Latest version includes:

- alphabetic sorting of morph names
- zero morphs function
- improved bone linking
- updated help :-)
- auto-sized control handles (wrist balls)
- some minor tweaks and improvements (runs a bit faster, two “hits” caught where the script would stop)

I've removed the HDA from this forum because of lack of feedback. Still giving it away for free (or a donation, if you will, to NGOs), all I am asking for is the courtesy of being TALKED TO.

Marc

Moin,

what's “x”? If it is undefined, it's definitely a non-numerical value (note that you are escaping from your quote in the parm().set() sequence, probably intentionally so).

One way to debug something like this is to set variables you use manually in a python shell (Houdini offers that conveniently) and step by step recreating the expression until you get the error. Then the last step/change you made is the culprit.


Marc

Hello, “Thank you”,

you may be confusing Qt (which Houdini uses for rendering its UI) and Python (which Houdini uses for working with data in the background). Python does not support “drag and drop”, since it is not a UI system but a programming language, Qt does.

If this helps in your usecase: You can add a path parameter to your node's (HDA's) parameter panel, into which you can use drag and drop from a node in the network view (which then automatically gets converted into a path).

Marc

Moin, Fred,

thanks a lot for the update!

I am moving away from Redshift, already deleted all support for that product from my own tools - I am currently looking into alternatives and re-learn how to use Mantra the best. RS is a no-go option now.

Marc

Quick update, on my way out for a few days: This version creates “Handles” on multi-bone-spots (e.g. hands) for easy rotation/twisting. Scale/Size of the handles can be controlled by a slider on the FBX-rig-tab.


Marc

Moin,

there's a bunch of Python modules that would allow you to do parallel processing on data - it depends on your personal taste and the data wrangling at hand which one suits your needs best.
I would, instead, look at VEX or looped code with parallel processing in Houdini. It might be the “easiest” approach to get a faster result.
In theory, you could also think about writing a cache out and “trivially” use your OS' multi-threading to run Python code on parts of the cache in parallel. With 10 minutes current running time, this might be sufficient.

Since this kind of performance-seeking is part of my job, I'll just throw in: You could look at converting your code to CUDA or openCL. Obviously, parallel processing generally expects your data to be independent, if your calculations of one point depend on the outcome of another point's math, you need to look at alternative options for speed-up (probably code optimization or “dirty short cut hacks”).

As for examples, I suggest looking at GitHub and search for python parallel processing or something along those terms.

Marc

HDA attached to this comment. It's a WIP. Be nice :-)

Marc

(P.S. updated version in next post, deleted attachment here)

In your screenshot at the top of this thread, the node is called “tiger_rig_anim1”. Have you tried that?

Marc

My apologies - that's not how Python or Houdini work. If you assign a value to a variable from an external source, changing the value in that variable does not change the setting in the source …

What you want to do is change the value AT THE SOURCE (the node in this case), e.g. by
… no need to read out the value before setting it.


Marc

What are you trying to do?

The result of your comparison “node == 0” might be True or False, but you are not doing anything with that information - so what do you expect it to do?
What you ARE doing is: you are reading out a value from the node's parameter “spine_squat_front”. Then you are comparing that read out value to 0, done. There is no “functionality” in your function.

Marc

Update:

Not an update on the “big one”, but the “convert FBX Joints based rig to bones based” node works:



Export FBX with rig.



Import FBX with “bones created” (those will be used for Houdini-animation).



You can now add Houdini IK chains if you want, the bones-based rig is fully functional. It reuses the original Joints (Nulls) - which, for the moment, is a “workaround” that avoids transferring the weights to bones. I am looking into getting rid of the nulls as well, but … I am quite happy with this.

(This HDA does not take care of materials and does not support the additional HD import that the “DAZ2H” HDA takes care of, this is something to further work on. But it's a “quick and dirty all-purpose-fbx-rig-convert”.)

Marc


——–
Edit / P.S. The good news is that handling the HD version of DAZ characters is straight forward using the same solution the DAZ2H tool uses, just tried it out. Read: I can re-work that HD-rig into this new one and we can animate lores AND hires “el-cheapo” figures.

The first thing that came to mind for me was the shrink wrap tool. That creates a mesh on the convex “outer points”. You could subdivide that a few times, add a wrangle over points and cast a ray in each point's reverse normal direction to “hit” the underlying geometry, then move the point to that hit-point.
With the stone-geometry you have that might work well enough, with highly complex geometry (deep creases/concave areas) it's probably not the best approach. But it's “cheap”

Marc

The word “implicit” is the most important in your statement:
The 3d viewport “display primitive normals” does not mention “implicit” (nor does it say “defined by winding order of points in the primitive”), so one must assume that the same “attribute quality” as with point normals or vertex normals is meant, not an implicit (as in “NOT attribute”) quality.

It may not be a “bug”, but it clearly looks like an irritating if not misleading description in the UI.

Marc

> making primitive v@N won't affect them, but it can be used for shading

… well, according to the geo spreadsheet, you can change them.

Marc

Hi, Olivier,

I just tried the wrangle you quoted and it works for me (looking at the geo spreadsheet). However, there seems to be a bug in the normal display in 3d-view, those don't get updated. They don't get updated when you use a normal-node and invert primitive normals. So you may have to use the spreadsheet for the moment until the bug is fixed (I filed it).


Marc