There are times when Houdini will create several nodes when a single node is placed. For example, a POP Network selected from the tab menu will create an entire network inside a DOPnet. Is there any way to tell if a node is automatically created via a script or process like this rather than a single node added by a user?
The purpose is to use an onCreated.py script to run on nodes created by an actual human user, prompting them to enter a name for the new node. I want to avoid this process for anything that is creating multiple nodes as a larger process.
This would potentially apply to even creating a sphere at /obj, which generates a geometry object as well as a sphere SOP.
Thanks
Josh
Found 21 posts.
Search results Show results as topic list.
Technical Discussion » How to tell if a node is created by Houdini instead of user
- goshone
- 21 posts
- Offline
Technical Discussion » SideFX labs plugin is not installing.
- goshone
- 21 posts
- Offline
Houdini Indie and Apprentice » Shaders not showing up in the render view.
- goshone
- 21 posts
- Offline
Houdini Indie and Apprentice » "Wrapping" a principled shader into a Digital Asset
- goshone
- 21 posts
- Offline
jsmack
For now, the only render property that is automatically propagated is the ‘vm_displacebound’ property.
I have noticed that this has an expression (the exact same expression) in the vm_displacebound field, but it references parms that are on the original shader. So essentially, it appears that the properties node does nothing. There must be a reason for SideFX to create this node, but it escapes me. Can I just delete it, or do I need to reference the original vm_displacebound?
Thanks
Josh
Houdini Engine for Maya » Triggering a python script from a houdini engine interface button.
- goshone
- 21 posts
- Offline
Sure thing Andrew. I have actually added a relevant portion of my script.
There are several lines commented out as I was still in the process of testing things.
So what I am trying to do is get values from selected objects and apply them to fields in the engine asset when pressing a button.
Another approach I tried was to re-write this script in mel, however, I couldn't get it to work. I had problems triggering the script, it simply wouldn't run using the callback script command set in asset type properties in Houdini. The mel script works as expected when run from the MEL command line in Maya.
strange
import maya.cmds as cmds
import maya.mel as mel
import time
import os
# cmds lines commented out due to incompatability. Using mel.eval instead
def fromSelectedGuides():
#selection = cmds.ls( selection=True )
selection = mel.eval( 'ls -sl' )
guides_sel = selection[ 0:len( selection ) - 1 ]
fursim = selection[ len( selection ) - 1 ]
# make sets for no duplicates
base = set()
guides = set()
#print procs
# get the relevant guide files from each selected fur groom
for patch in guides_sel:
ref_mesh = cmds.getAttr( patch + '.parmrefCache' )
#command1 = ( "getAttr " + patch + "Locator.parmrefCache" )
#print command1
#pcmd = ( "print( \"" + command1 + "\\n\" )" )
#ref_mesh = mel.eval( command1 )
base.add( ref_mesh )
guide_file = cmds.getAttr( patch + '.parmguideCache' )
#command2 = ( "getAttr " + patch + "Locator.parmguideCache" )
#print command2
#pcmd = ( "print( \"" + command2 + "\\n\" )" )
#guide_file = mel.eval( command2 )
guides.add( guide_file )
# clear the fields current contents
c = 1
while c < 21:
command3 = ( "setAttr -type \"string\" " + fursim + ".houdiniAssetParm.houdiniAssetParm_stdswitcher3_2_1__folder.houdiniAssetParm_groom_files_" + str( c ) + " \"\"" )
#cmds.setAttr( fursim + ".houdiniAssetParm.houdiniAssetParm_stdswitcher3_2_1__folder.houdiniAssetParm_groom_files_" + str( c ), "", type='string' )
mel.eval( command3 )
c += 1
# fill in the fursim engine with relevant paths
i = 1
base_list = list( base )
#if len( guides_sel ) > 0:
#if len( base_list ) > 1:
#print 'There are inconsistent base meshes found on the procedurals.'
#else:
#print ( "Ref Mesh: " + base_list[ 0 ] )
guide_list = list( guides )
#print guide_list
#i = 0
for guide in guide_list:
#i += 1
print ( "Guide Curve: " + guide )
command4 = ( "setAttr -type \"string\" " + fursim + ".houdiniAssetParm.houdiniAssetParm_stdswitcher3_2_1__folder.houdiniAssetParm_groom_files_" + str( i ) + " \"" + guide + "\"" )
time.sleep( .2 )
print command4
#cmds.setAttr( fursim + ".houdiniAssetParm.houdiniAssetParm_stdswitcher3_2_1__folder.houdiniAssetParm_groom_files_" + str( i ), guide, type='string' )
mel.eval( command4 )
i += 1
command5 = ( "setAttr " + fursim + ".houdiniAssetParm_num_guide_files " + str(i-1) )
#cmds.setAttr( fursim + ".houdiniAssetParm_num_guide_files", i-1 )
mel.eval( command5 )
There are several lines commented out as I was still in the process of testing things.
So what I am trying to do is get values from selected objects and apply them to fields in the engine asset when pressing a button.
Another approach I tried was to re-write this script in mel, however, I couldn't get it to work. I had problems triggering the script, it simply wouldn't run using the callback script command set in asset type properties in Houdini. The mel script works as expected when run from the MEL command line in Maya.
strange
Houdini Engine for Maya » Triggering a python script from a houdini engine interface button.
- goshone
- 21 posts
- Offline
Thanks for the reply, Andrew.
I guess that explains it a little, and I remember seeing another post on here about threads and how they are problematic with Maya and python.
The real issue I am having isn't even these print statements, which were really just for debugging. I am performing getAttr and setAttr commands in the for loops, but it doesn't seemt to respect the contents and manipulation of those contents while in (or possibly once outside) the loop. The print statements were an attempt to troubleshoot what happens to the data while inside the loop.
Again, the script I am calling from Engine in Maya works perfectly when run from command line. The loops just don't seem to act properly when launched from a button on the Engine UI in Maya.
I guess that explains it a little, and I remember seeing another post on here about threads and how they are problematic with Maya and python.
The real issue I am having isn't even these print statements, which were really just for debugging. I am performing getAttr and setAttr commands in the for loops, but it doesn't seemt to respect the contents and manipulation of those contents while in (or possibly once outside) the loop. The print statements were an attempt to troubleshoot what happens to the data while inside the loop.
Again, the script I am calling from Engine in Maya works perfectly when run from command line. The loops just don't seem to act properly when launched from a button on the Engine UI in Maya.
Houdini Engine for Maya » Triggering a python script from a houdini engine interface button.
- goshone
- 21 posts
- Offline
I wanted to ask the community if anyone has been doing this successfully.
My experience lately has been baffling and frustrating. The basic idea is to select some geo in Maya, then the engine asset, press a button that runs a python script on disk. The script works flawlessly when run from command line. When I activate the button, the behavior is quite different.
First of all, I had to abandon using the cmds library in favor of the maya.mel library. As a result, it forced me to add a few extra lines of code each instance, as I needed to build a mel string, then run it with mel.eval( melString ). This works for my basic tests, like a print statement or a simple setAttr. However, when I started to get tricky with for loops, it all fell apart. The strangest thing is when I put print statements to test things, it looked like everything is returned in reverse order as expected. For example
list =
for num in list:
print num
this isn't the exact code I am using, but the idea is the same. The result I get from executing this via Houdini Engine button is:
5
4
3
2
1
I have never seen this happen in a loop, where the results are returned in reverse order. Is there some voodoo happening with Engine that would cause this? Any workarounds (code backwards LOL)?
Any help on this topic would be greatly appreciated
Thanks
Josh
My experience lately has been baffling and frustrating. The basic idea is to select some geo in Maya, then the engine asset, press a button that runs a python script on disk. The script works flawlessly when run from command line. When I activate the button, the behavior is quite different.
First of all, I had to abandon using the cmds library in favor of the maya.mel library. As a result, it forced me to add a few extra lines of code each instance, as I needed to build a mel string, then run it with mel.eval( melString ). This works for my basic tests, like a print statement or a simple setAttr. However, when I started to get tricky with for loops, it all fell apart. The strangest thing is when I put print statements to test things, it looked like everything is returned in reverse order as expected. For example
list =
for num in list:
print num
this isn't the exact code I am using, but the idea is the same. The result I get from executing this via Houdini Engine button is:
5
4
3
2
1
I have never seen this happen in a loop, where the results are returned in reverse order. Is there some voodoo happening with Engine that would cause this? Any workarounds (code backwards LOL)?
Any help on this topic would be greatly appreciated
Thanks
Josh
Technical Discussion » crowd sliding
- goshone
- 21 posts
- Offline
Thanks for the reply…
So the mocap data I am using is moving through space, so not walking in place.
The reason for this is because I am trying to push the capabilities of the crowd sys a little. I did remove that offset during the process of baking clips out.
The task was to make a group of agents go from idle, to walking, then after a few cycles, go back to idle. It failed pretty hard.
The blending of clips is painful, and difficult to dial in. Going from a standstill to walk usually requires an in-between clip (idle_to_walk) in massive, for example. Following that idea, it was impossible to get a smooth transition that didn't slide. The agent is basically controlled by particle forces, not necessarily the inherent motion from the mocap (although that is one option). In fact, the only way I was able to get a decent look was to use the ‘lock particle speed to mocap’ setting on the crowd solver.
So that is one problem, getting the agent to match speed on anything other than a single walk cycle.
The other problem is actually controlling the feet placement, after the gross motion of the agent is set. Even with just a walk cycle, the feet slide ever so slightly. One foot will slide forward a bit, another foot will slip backwards.
It also seems like there is some slight blending even between the same walk cycle, which causes a slight pop, which may be the cause of the sliding.
I guess the real question is if there is anyone who has been successful in setting up a crowd on their own with more complex clip blending.
thanks
Josh
So the mocap data I am using is moving through space, so not walking in place.
The reason for this is because I am trying to push the capabilities of the crowd sys a little. I did remove that offset during the process of baking clips out.
The task was to make a group of agents go from idle, to walking, then after a few cycles, go back to idle. It failed pretty hard.
The blending of clips is painful, and difficult to dial in. Going from a standstill to walk usually requires an in-between clip (idle_to_walk) in massive, for example. Following that idea, it was impossible to get a smooth transition that didn't slide. The agent is basically controlled by particle forces, not necessarily the inherent motion from the mocap (although that is one option). In fact, the only way I was able to get a decent look was to use the ‘lock particle speed to mocap’ setting on the crowd solver.
So that is one problem, getting the agent to match speed on anything other than a single walk cycle.
The other problem is actually controlling the feet placement, after the gross motion of the agent is set. Even with just a walk cycle, the feet slide ever so slightly. One foot will slide forward a bit, another foot will slip backwards.
It also seems like there is some slight blending even between the same walk cycle, which causes a slight pop, which may be the cause of the sliding.
I guess the real question is if there is anyone who has been successful in setting up a crowd on their own with more complex clip blending.
thanks
Josh
Technical Discussion » crowd sliding
- goshone
- 21 posts
- Offline
Is there a way to lock footfalls of the agents so they don't seem like they are sliding? Most other crowd packages have a way to deal with this, and I feel it is pretty crucial to getting a convincing crowd. Perhaps it can be similar to the agent projection and terrain adaptation, which is a pretty deep python or hscript file.
I also find it quite difficult to blend between actions and combining that with retiming of the mocap clips. Sometimes you tweak the particle speed, or else you adjust the in-place gate speed.
There is a lot of potential for crowd system, but to be considered, it really should be a better, faster, easier solution, not just different but equally difficult.
thanks
Josh
I also find it quite difficult to blend between actions and combining that with retiming of the mocap clips. Sometimes you tweak the particle speed, or else you adjust the in-place gate speed.
There is a lot of potential for crowd system, but to be considered, it really should be a better, faster, easier solution, not just different but equally difficult.
thanks
Josh
Technical Discussion » pops - weird velocity, what's the backtrack attrib?
- goshone
- 21 posts
- Offline
Technical Discussion » New H11 materials render artifacts
- goshone
- 21 posts
- Offline
goshone
I am still getting this problem. Did it actually get fixed?
using Houdini 11.0.733 on Linux 64bit Fedora
edit: Was exceptionally bad when using an area light and Mantra Shader Builder material. Also found with point lights, but not so bad - was able to remove by increasing noise value as described above. Not visible when using distant light.
So I guess it hasn't been completely fixed, but addressed.
Anyone else sharing my pain regarding this “super duper” shader?
YES!
Technical Discussion » Voronoi Fracture with clustering breaks copystamping
- goshone
- 21 posts
- Offline
Agreed! I especially like the two dopinput nodes method, bypassing the copy altogether, it works like a charm.
Thanks!
Thanks!
Technical Discussion » Voronoi Fracture with clustering breaks copystamping
- goshone
- 21 posts
- Offline
leaving now, but will look at it later tonight. I think there may be a way to force the pivot on each piece via the RBD point object DOP, which I will investigate too.
Technical Discussion » Voronoi Fracture with clustering breaks copystamping
- goshone
- 21 posts
- Offline
Thanks Romance,
I see what you did, and it is good as a workaround, but I wonder…
Why does it work correctly without clusters? Also, it works correctly with approx 90% of clustered pieces. I did see that all the points generated were at the origin, but the way DOPs figured it out works well. If you use my original scene and disable clusters, things work as expected (you may have to recook the DOPnet - which may also be a culprit of this problem - seems like the points could be improperly associated within the DOP cache).
My backup plan was to do almost as you did in your fix file, and place all objects in world space, which works much more predictably.
I am just baffled as to why it works without clusters, and fails with clusters.
thanks again.
I see what you did, and it is good as a workaround, but I wonder…
Why does it work correctly without clusters? Also, it works correctly with approx 90% of clustered pieces. I did see that all the points generated were at the origin, but the way DOPs figured it out works well. If you use my original scene and disable clusters, things work as expected (you may have to recook the DOPnet - which may also be a culprit of this problem - seems like the points could be improperly associated within the DOP cache).
My backup plan was to do almost as you did in your fix file, and place all objects in world space, which works much more predictably.
I am just baffled as to why it works without clusters, and fails with clusters.
thanks again.
Technical Discussion » Voronoi Fracture with clustering breaks copystamping
- goshone
- 21 posts
- Offline
sample file included
I was trying out something so I am using this expression (utilizing $PT instead of $ID) now in copy SOP
dopfield( “/obj/AutoDopNetwork”, “piece`$PT`”, “CopyInfo”, “Options”, 0, “copynum” )
I was trying out something so I am using this expression (utilizing $PT instead of $ID) now in copy SOP
dopfield( “/obj/AutoDopNetwork”, “piece`$PT`”, “CopyInfo”, “Options”, 0, “copynum” )
Technical Discussion » Voronoi Fracture with clustering breaks copystamping
- goshone
- 21 posts
- Offline
So this is a wierd one.
I have a fairly standard voronoi fracture setup, and I want to use the method of copy/stamping the original pieces (or high resolution versions of the original) to transformed points generated by DOPs. This is done by using the ‘create points to represent objects’ option in the Dop Import SOP.
This works as expected right out the box. However, when I enable clustering, many of the pieces begin flying around erratically, like their pivot is off, or they are referencing the wrong point from the simulation. Depending on the number of pieces I generate, the strange behavior only affects a few more or less, but sometimes I can get rid of this completely… It just starts working???
So my questions are:
1. Has anyone else experienced this? Are you able to use this workflow of voronoi fracturing, clustering, and copy/stamping to DOP generated points?
2. Any idea what causes this to happen so I can avoid it in the future? I suspect is is using the wrong point to transform the corresponding piece. I have tried to be exact in the way I link points to pieces, using this expression to get the info:
dopfield( “/obj/AutoDopNetwork”, “piece`$ID-2`”, “CopyInfo”, “Options”, 0, “copynum” )
which is entered into the variable value field for stamping on the copy SOP. I use the $ID-2 to get the proper piece number. Again, this works flawlessly when not using clustering.
I believe that clustering adds new pieces into the mix, and mixes up the point order relative to the piece number. I thought the above expression would fix it.
Any help in this matter would be greatly appreciated.
Thanks
I have a fairly standard voronoi fracture setup, and I want to use the method of copy/stamping the original pieces (or high resolution versions of the original) to transformed points generated by DOPs. This is done by using the ‘create points to represent objects’ option in the Dop Import SOP.
This works as expected right out the box. However, when I enable clustering, many of the pieces begin flying around erratically, like their pivot is off, or they are referencing the wrong point from the simulation. Depending on the number of pieces I generate, the strange behavior only affects a few more or less, but sometimes I can get rid of this completely… It just starts working???
So my questions are:
1. Has anyone else experienced this? Are you able to use this workflow of voronoi fracturing, clustering, and copy/stamping to DOP generated points?
2. Any idea what causes this to happen so I can avoid it in the future? I suspect is is using the wrong point to transform the corresponding piece. I have tried to be exact in the way I link points to pieces, using this expression to get the info:
dopfield( “/obj/AutoDopNetwork”, “piece`$ID-2`”, “CopyInfo”, “Options”, 0, “copynum” )
which is entered into the variable value field for stamping on the copy SOP. I use the $ID-2 to get the proper piece number. Again, this works flawlessly when not using clustering.
I believe that clustering adds new pieces into the mix, and mixes up the point order relative to the piece number. I thought the above expression would fix it.
Any help in this matter would be greatly appreciated.
Thanks
Technical Discussion » Bullet physics implementation and other stuff
- goshone
- 21 posts
- Offline
because you have great interest about this plugin, at the beginning of September, I release beta version of my software for testers, so I can send you one copy too.
Cybermax,
That would be much appreciated. Please keep us posted. In the meantime, I will try your ‘update objects’ solution.
Thanks
EDIT: was gonna suggest a feature if you don't mind (don't mean to be a pest :twisted: ). I would like to be able to extract a single point per object with transforms from the sim. I am currently trying to use the properties data, but there are some inconsistencies (mainly once the geo starts to rotate) with the transformations between these points (with similar geo copied to them) and the output from bullet solver. Perhaps this is unnecessary, but would be nice to swap geo later on after the sim. I could provide example and more if needed.
Technical Discussion » Bullet physics implementation and other stuff
- goshone
- 21 posts
- Offline
Am trying the realflow (real-slow) RBD path now. But in the meantime, I have a rough working version of autofreeze that I added to your otl. However, I am having a bit of trouble with one thing. I am able to interrupt the passing of params like bullet_transform and bullet_v and writing instead my own data ( like velocity of 0, 0, 0 or a static transformation, even setting mass to 0), but things are still receiving transform data from the bullet_solver node. I have tried to do this interrupt before the solver, as well as after the solve (but before the bullet_transform), but neither seems to remove the jitter completely. Cybermax, perhaps you have some insight to accomplish this? Is there some way to remove an object from the simulation (or temporarily make it static), then possibly add it back in to the sim based on some threshold?
thanks
EDIT:
After looking at the ‘kinematic_or_dynamic_body’ in the sample scene, I see that you are doing some interesting things outside of the otl, by piping things back in from OUT_properties, and updating the objects. I am not sure exactly what is going on there, but will try to achieve what I want thru that mechanism.
thanks
EDIT:
After looking at the ‘kinematic_or_dynamic_body’ in the sample scene, I see that you are doing some interesting things outside of the otl, by piping things back in from OUT_properties, and updating the objects. I am not sure exactly what is going on there, but will try to achieve what I want thru that mechanism.
Technical Discussion » Bullet physics implementation and other stuff
- goshone
- 21 posts
- Offline
I am preparing completely new software for simulation, includes rbd(gpu in future), sbd(gpu), fluid(gpu) and I have plan for Gas(gpu). First beta comes in 1month(aprox.).
wicked :twisted:
well, that is good news indeed for the community, but bad news for me personally re: my current project. Oh well, i guess back to standard RBDs in the meantime. If there is anyone that has a better solution to thousands/millions of coins piling up, stacking on top of each other, please share.
thanx
Technical Discussion » Bullet physics implementation and other stuff
- goshone
- 21 posts
- Offline
cybermax
Autofreeze: Yes, bullet include this function, I can implement.
Hi cybermax,
Great job on this by the way. I was wondering if anything came of this? I am getting quite a bit of jitter from resting objects (I am trying to sim many thousand coins). Perhaps there is a workaround in the meantime? I was thinking of just excluding certain objects from updating within the sim, but was unsure how to do this? Would I use ‘update objects’ somehow? I feel that it may need to be done using geo being written/read from disk. Unfortunately, we are not able to use the Digital Asset as it causes our Houdini session to become non-commercial. Any thoughts?
Thanks in advance
-
- Quick Links