Hello there
In Softimage(R.I.P) there was an Script editor, which was responsible to show each script action based on your action.
For example when I create a cube from shell, this window will show following python code:
Application.CreatePrim(“Cube”, “MeshSurface”, “”, “”)
This will help a programmer to find all python's command easily and so fast.
In Houdini I found the Python Shell but it did not show any code based on use's actions.
Does houdini support it? If no, how can I find all commands of python?
Could you help me on this issue?
Where is the Script Editor?
11072 8 4- PooyaEimandar
- Member
- 6 posts
- Joined: 3月 2014
- Offline
- svenito
- Member
- 31 posts
- Joined: 8月 2010
- Offline
There's not really anything like that AFAIK.
The docs however cover creation of nodes
http://www.sidefx.com/docs/houdini13.0/hom/intro [sidefx.com]
The full details of the houdini python module are here:
http://www.sidefx.com/docs/houdini13.0/hom/hou/ [sidefx.com]
also if you get an exisiting node for example with
>>> n = hou.node('/obj/box/box1')
you can then type
>>> n.
in the python shell and after a short pause, it will pop up with a list of that object's methods
The docs however cover creation of nodes
http://www.sidefx.com/docs/houdini13.0/hom/intro [sidefx.com]
The full details of the houdini python module are here:
http://www.sidefx.com/docs/houdini13.0/hom/hou/ [sidefx.com]
also if you get an exisiting node for example with
>>> n = hou.node('/obj/box/box1')
you can then type
>>> n.
in the python shell and after a short pause, it will pop up with a list of that object's methods
./Sven
- goldleaf
- スタッフ
- 4200 posts
- Joined: 9月 2007
- Offline
- AdamJ
- Member
- 268 posts
- Joined: 7月 2005
- Offline
You can also get the creation script for the node/networks with asCode().
>>> hou.node('/obj/chair1/subdivide2')
<hou.SopNode of type subdivide at /obj/chair1/subdivide2>
>>> for x in n.asCode(brief=True).split(“\n”): print x
…
# Initialize parent node variable.
if locals().get(“hou_parent”) is None:
hou_parent = hou.node(“/obj/chair1”)
# Code for /obj/chair1/subdivide2
hou_node = hou_parent.createNode(“subdivide”, “subdivide2”, run_init_scripts=False, load_contents=True, exact_type_name=True)
hou_node.move(hou.Vector2(-5.32534, -0.998593))
hou_node.bypass(False)
hou_node.setDisplayFlag(True)
…….snip……..
>>> hou.node('/obj/chair1/subdivide2')
<hou.SopNode of type subdivide at /obj/chair1/subdivide2>
>>> for x in n.asCode(brief=True).split(“\n”): print x
…
# Initialize parent node variable.
if locals().get(“hou_parent”) is None:
hou_parent = hou.node(“/obj/chair1”)
# Code for /obj/chair1/subdivide2
hou_node = hou_parent.createNode(“subdivide”, “subdivide2”, run_init_scripts=False, load_contents=True, exact_type_name=True)
hou_node.move(hou.Vector2(-5.32534, -0.998593))
hou_node.bypass(False)
hou_node.setDisplayFlag(True)
…….snip……..
- edward
- Member
- 7899 posts
- Joined: 7月 2005
- Offline
- PooyaEimandar
- Member
- 6 posts
- Joined: 3月 2014
- Offline
- old_school
- スタッフ
- 2540 posts
- Joined: 7月 2005
- Offline
We get this question a lot. I'll try my best to explain why we seem to do the reverse.
Houdini is architected to animate anything at any time. No active cache required. This means that every node is written to take in any input at any time. No caches what so ever. You can save steps to disk and load with File SOP Geometry nodes but you can also keep the original nodes around as well.
Most other apps were architected as modellers where they work and update a cache of the geometry. Then you tack on scripts and in some cases you can keep the node tree around to recalculate as required. Ultimately everything ends up in a cache (shape node if you may). This means that some scripts modify the geometry and are not recorded as discrete steps as residual nodes. This means you absolutely need a command echo tool to trap those actions to re-create in a tool or to repeat. In Houdini, you just copy/paste nodes to get a similar result.
One way to see this in action is to look at saved file sizes. Hip files are quite a lot smaller than other app scene files because, if you don't lock SOPs (bake in geometry in to Houdini a la shape node), then the file remains relatively light. All the nodes do all the heavy lifting making the files small relatively speaking.
Now how does this relate to the commands?
Well when you write a script to do an operation, in Houdini you are either adding nodes or modifying nodes. Nothing is ever baked. No steps are lost in the ether after doing their work. Everything ends up in the nodes. I guess this is why we first create the networks, then use the “hou.asCode()” python method or the “opscript node_path/node” approach to return the commands to reconstruct these nodes and use that as the basis to construct a tool.
So you prototype with nodes, get your work done and then when you see a tool to reuse somewhere in there, you can quickly get at the commands from the various nodes and build a tool from that.
Hope that helps.
Houdini is architected to animate anything at any time. No active cache required. This means that every node is written to take in any input at any time. No caches what so ever. You can save steps to disk and load with File SOP Geometry nodes but you can also keep the original nodes around as well.
Most other apps were architected as modellers where they work and update a cache of the geometry. Then you tack on scripts and in some cases you can keep the node tree around to recalculate as required. Ultimately everything ends up in a cache (shape node if you may). This means that some scripts modify the geometry and are not recorded as discrete steps as residual nodes. This means you absolutely need a command echo tool to trap those actions to re-create in a tool or to repeat. In Houdini, you just copy/paste nodes to get a similar result.
One way to see this in action is to look at saved file sizes. Hip files are quite a lot smaller than other app scene files because, if you don't lock SOPs (bake in geometry in to Houdini a la shape node), then the file remains relatively light. All the nodes do all the heavy lifting making the files small relatively speaking.
Now how does this relate to the commands?
Well when you write a script to do an operation, in Houdini you are either adding nodes or modifying nodes. Nothing is ever baked. No steps are lost in the ether after doing their work. Everything ends up in the nodes. I guess this is why we first create the networks, then use the “hou.asCode()” python method or the “opscript node_path/node” approach to return the commands to reconstruct these nodes and use that as the basis to construct a tool.
So you prototype with nodes, get your work done and then when you see a tool to reuse somewhere in there, you can quickly get at the commands from the various nodes and build a tool from that.
Hope that helps.
There's at least one school like the old school!
- PooyaEimandar
- Member
- 6 posts
- Joined: 3月 2014
- Offline
- Sadjad Rabiee
- Member
- 1391 posts
- Joined: 12月 2010
- Offline
jeff
We get this question a lot. I'll try my best to explain why we seem to do the reverse.
Houdini is architected to animate anything at any time. No active cache required. This means that every node is written to take in any input at any time. No caches what so ever. You can save steps to disk and load with File SOP Geometry nodes but you can also keep the original nodes around as well.
Most other apps were architected as modellers where they work and update a cache of the geometry. Then you tack on scripts and in some cases you can keep the node tree around to recalculate as required. Ultimately everything ends up in a cache (shape node if you may). This means that some scripts modify the geometry and are not recorded as discrete steps as residual nodes. This means you absolutely need a command echo tool to trap those actions to re-create in a tool or to repeat. In Houdini, you just copy/paste nodes to get a similar result.
One way to see this in action is to look at saved file sizes. Hip files are quite a lot smaller than other app scene files because, if you don't lock SOPs (bake in geometry in to Houdini a la shape node), then the file remains relatively light. All the nodes do all the heavy lifting making the files small relatively speaking.
Now how does this relate to the commands?
Well when you write a script to do an operation, in Houdini you are either adding nodes or modifying nodes. Nothing is ever baked. No steps are lost in the ether after doing their work. Everything ends up in the nodes. I guess this is why we first create the networks, then use the “hou.asCode()” python method or the “opscript node_path/node” approach to return the commands to reconstruct these nodes and use that as the basis to construct a tool.
So you prototype with nodes, get your work done and then when you see a tool to reuse somewhere in there, you can quickly get at the commands from the various nodes and build a tool from that.
Hope that helps.
Wow , Really thanks Jeff for your great discussion :shock:
-
- Quick Links