Видео

You can do this with the "APEX configure controls node". -Add a control config. -specify the abstract control node's name -Activate the use limits section. -Choose the parameters name and type the type is usually float and the parameters name will usually be either x or y. -You can then specify a min or max.

If the auto completion is not working properly you can try opening a python scripting window and re-importing a library there. That usually fixes auto-completion not registering in the type properties. For the default Houdini library the import would be "import hou".

This is the exact setup that I am currently using. I keep the Python version separate so my Python install is still 3.10.11. Houdini 2.5.3864 still uses pyside2 for the python panels. Have you added the Python install to your PYTHONPATH or the user's path environment variable in windows? What error is VScode giving you? I will also probably need to see your VS settings files.

@@brundlethwaite SO I was able to get it running with python 3.11, but autocomplete works, and doesnt work. For example, when I type “import hou” , that gives me autocomplete, then I continue with “node = hou.pwd()”, that gives me autocomplete, but when I go “geo = node.xxx” autocomplete after “node” doesn’t work :-/ . Any ideas? Btw I have set up everything as you do. Except that I have PySide6 instead of PySide2.

The VS code wasn't finding "hou" module for me too, what fixed for me was manually typing: "python.analysis.extraPaths": [ "C:\\Program Files\\Side Effects Software\\Houdini 20.0.653\\houdini\\python3.10libs" ] make sure your houdini version is the same as the "python.autoComplete.extraPaths"

@@LucasRodrigues-nu5qd cheers, you saved me!

That is really just using an extra shape. So instead of using a start and end shape you create extra shapes that occur between the blend. So instead of A <-> B you have A <-> B <-> C.

"hou" auto complete works.. just the PySide2 not.

Unfortunately that is a limitation of the python code completion. I have not tried other LSPs but the default python setup in VSCode will only give completion when referencing libraries directly.

@@brundlethwaite Thanks for the reply, in case you find something on this please do let me know

Ideally this will be running on the Frimble engine but I do not know If it will ever get that far. This is a prototype so it may never be released other considerations are. - My interest here is animation and Rigging not programming or releasing a game Unity is the easiest to deal with at the moment. - Unity is easy to use, I know it and it is the most fun to work with at the moment. - As this is a prototype Unity is free. - Unreal would be far more expensive than Unity (even if they had implemented that stupid pricing scheme). - If I release the game It would be for consoles Godot has no support and would end up being more expensive than Unity. - Godot does not have Houdini Engine support. - Flax does not support graphics tablets. - Flax does not have native Houdini engine support. - Cryengine does not have proper UI and requires defunct commercial software. - Cryengine does not have native Houdini engine support. - Programming in Unreal is horrible and is it weakest area. - For game logic I do not want to use blueprints as they and not efficient and have worse performance that C++. - I do not want to use C++ I would prefer to work with C, Odin or C#. - Animation is Unreal's weakest area Unity is far easier to work with here. - Animation import and Export it Unreal's weakest area. - Unreal's coordinate... - Unreal's syntax..... ... ... This is a little brief, I start to give some more reasons but I do not want this to become a long list and I do not have the time to go into even the basic reasons as each of them require context and explanation to make sense.

@@brundlethwaite no way! Unreals animation is weaker than unity’s? I spent sometime with Unity and hated C++ until I started using it and now I look at c# as a jumbled mess lol. I do like Unity’s DOTS I almost switch back to it because of that alone.

"no way! Unreals animation is weaker than unity’s?" What relevance does this have? I did not make a feature comparison? This is not a reason or advice on choosing. And it is not relevant to anybody by me, for this specific project. " I spent sometime with Unity and hated C++ until I started using it and now I look at c# as a jumbled mess lol." What relevance does this have? This is not a programming language comparison? These are really bullet points as they applies to this specific project. I am not going to spend days (or for this topic months and years) of my life trying to explain the specifics. You asked me why I am working with Unity you did not ask me why someone else should.

@@brundlethwaite From your first reply "- Animation is Unreal's weakest area Unity is far easier to work with here." I was replying to this. Maybe you worded this wrong? From your first reply "- I do not want to use C++ I would prefer to work with C, Odin or C#. " I was replying to this point. I used to prefer c# now I look at it different after using C++ My question initially was to see whats stopping you from converting to UE. I presented some slight counter arguments to push you towards it. Since your content + Unreal would be beneficial to me. No disrespect to you or unity was intended

"My question initially was to see whats stopping you from converting to UE." You did not state that. You said "What are the reasons you continue with Unity over Godot or Unreal Engine?" which is a completely different question. I am not converting from anything I currently have projects in Unreal, Unigen, Flax, Godot, Cocos2D and Stride and Cryengine. Not all of the projects are fully active but I none are discarded. So if you had asked the first me about converting I would have said that I am using Unreal different projects instead of why I am using Unity in this one. You also chose to ignore the final statement where I said that each of the points was highly contextual. As well as the first statement.

Good to hear. The group and point number issues took me a while to figure out and they can be tricky.

This is limiting the controls not the joints. There is no built in limit to control IK chains (you can make one manually in vex or VOPS). You can force IK chins them to return to an original pose using rest transforms. Using rest transforms will stop you joints from going beyond a straight line as they will always return to the default. I do not think this applies to the IKchains node. As that uses the 2 bone Ik VOP. But if you use the IK Solver VOP you have the rest angles mode.

@@brundlethwaite I`ve switched to apex. I think its to much work to build a costum one as a generalist. so i`ll skip over it for now. THX for the reply !

The character needs to move relative to the camera. So the controller is essentially moving the character in screen space. But the character is not being driven by the controller but is using root motion and is purely driven by the animation. Essentially this is a animation prototype 1st and if I get a good results from that I may turn it into controller prototype. There is also some tool creation that is incidental to the prototypes/

@@brundlethwaite ah, I gotcha. Root motion can be tricky but is well worth it in the long run.

There are a series of videos for the prototype for a bone based rigging system on my Patreon. I am working on a full course but editing and recording takes a long time and I have had a lot of interruptions so it is taking a lot longer than I want. Personally I dislike blendshapes as bone based rigs give much better interpolation so will be a bone-based course. Unfortunately it will have to be a paid course. I cannot justify placing it on RUclips for free as it I too much work to do for no compensation when I have a very limited income.

When you want to extend a rig using the auto-rigging nodes you will need to create scripts like this this is the starting point for doing that.