I think we are ALL INSANE here, using Houdini. Insanely awesome that is.
Also, it just happened on the creation of a new blast sop w/ selection in the viewport. I was incorrect in saying it wasn't impacting new blast node creation based on viewport selection.
Does this warrant a bug submission or just something that Houdini does once in a while? Thanks.
UPDATE: Submitted a bug report to SESI. Support Ticket: #131246
Found 66 posts.
Search results Show results as topic list.
Technical Discussion » Viewport Selection by Attribute SOP Truncation Issue
- 9krausec
- 66 posts
- Offline
Technical Discussion » Viewport Selection by Attribute SOP Truncation Issue
- 9krausec
- 66 posts
- Offline
Alright.. I rubbed all my braincells together and think I know what's going on.
This video demonstrates order of operations (demo scene attached):
(Happens specifically 40s in)
The switch happens when re-selecting from a blast node! Not on the creation of a new one.
This video demonstrates order of operations (demo scene attached):
(Happens specifically 40s in)
The switch happens when re-selecting from a blast node! Not on the creation of a new one.
Edited by 9krausec - Dec. 23, 2022 21:11:18
Technical Discussion » Viewport Selection by Attribute SOP Truncation Issue
- 9krausec
- 66 posts
- Offline
Running 19.5.435 on Win10
I just made a demo scene to share with you, tried to recreate the issue again... could not. One-hand, I'm confident that I'm not losing my facilities, on the other, it seems to be working now.
Will post here if it happens again. Glad I took screen shots in the OG post to make me feel sane!
I just made a demo scene to share with you, tried to recreate the issue again... could not. One-hand, I'm confident that I'm not losing my facilities, on the other, it seems to be working now.
Will post here if it happens again. Glad I took screen shots in the OG post to make me feel sane!
Technical Discussion » Viewport Selection by Attribute SOP Truncation Issue
- 9krausec
- 66 posts
- Offline
Hello, thank you for clicking!
I'm making viewport selections by attribute. Then, in viewport context, creating a SOP w/ my selection (BLAST in this specific instance). Instead of the group parm of the SOP relaying the attribute selected (@Attr=123 @Attr=456), Houdini is truncating by primitive number.
The below image reflects how I'm making my viewport selection. Selecting by primitive attribute titled "id"
This is what the group parm of the blast SOP reads in this specific example. With prim numbers, not attribute selection
Is there a way to force Houdini to respect the attribute selection and not translate it into primitive numbers on SOP creation? What I'd like the group parm of the SOP to read (in this instance) would be - `@id=1208 @id=1209 @id=1210 ......`
Thank you,
Clayton
I'm making viewport selections by attribute. Then, in viewport context, creating a SOP w/ my selection (BLAST in this specific instance). Instead of the group parm of the SOP relaying the attribute selected (@Attr=123 @Attr=456), Houdini is truncating by primitive number.
The below image reflects how I'm making my viewport selection. Selecting by primitive attribute titled "id"
This is what the group parm of the blast SOP reads in this specific example. With prim numbers, not attribute selection
Is there a way to force Houdini to respect the attribute selection and not translate it into primitive numbers on SOP creation? What I'd like the group parm of the SOP to read (in this instance) would be - `@id=1208 @id=1209 @id=1210 ......`
Thank you,
Clayton
Edited by 9krausec - Dec. 23, 2022 16:05:27
PDG/TOPs » Feedback Loop - Dynamic Partitioning
- 9krausec
- 66 posts
- Offline
Thank you Taylor. I followed the documentation and set HDA Processor TOP node from “Report Error” to “Report Warning”.
The obj is being created by a Python Script TOP call to a third party software. So the obj is not being copied, it is being created.
Perhaps before the OBJ is actually saved out, the HDA Processor (which is a downstream item that ingests the OBJ) is trying to call upon the not yet existing OBJ. Perhaps I need to add a slight sleep delay right after the OBJ is generated to give it enough breathing room.
I'll run the batch test overnight and let you know tomorrow how it turns out.
Thanks again.
The obj is being created by a Python Script TOP call to a third party software. So the obj is not being copied, it is being created.
Perhaps before the OBJ is actually saved out, the HDA Processor (which is a downstream item that ingests the OBJ) is trying to call upon the not yet existing OBJ. Perhaps I need to add a slight sleep delay right after the OBJ is generated to give it enough breathing room.
I'll run the batch test overnight and let you know tomorrow how it turns out.
Thanks again.
PDG/TOPs » Feedback Loop - Dynamic Partitioning
- 9krausec
- 66 posts
- Offline
Thank you for the reply.
In the actual production scenario it's an HDA Processor TOP that is raising the following error when attempting to read in an OBJ file-
The error appears to happen inconsistently throughout the TOPs operation and the OBJs that the system hangs up on open fine via the File SOP, outside of TOPs. I did put in a support ticket this morning for the ‘Expected array object’ error on a seemingly perfectly good OBJ ( Side Effects Support Ticket: #91349 ).
I was able to bypass any raised errors caused by the Python Script by using a Split top to bypass the other TOP nodes in the loop in case of error (which seems to work well enough).
I'll attempt pointing the HDA Processor to a different scheduler for appropriate error handling to see if I can gain access to a hook to tell the system to split out the stream on error, like I've done in the past with the Python Script TOP. Thank you for that advice.
I'll give it a try today and run the TOPs process overnight for a stress test. Again, thank you.
In the actual production scenario it's an HDA Processor TOP that is raising the following error when attempting to read in an OBJ file-
Error: Unable to read file "SCREW;HH;;GB-5782(M10-1.5 x 45).obj".
Expected array object (near byte offset 1, line 1, column 2)
The error appears to happen inconsistently throughout the TOPs operation and the OBJs that the system hangs up on open fine via the File SOP, outside of TOPs. I did put in a support ticket this morning for the ‘Expected array object’ error on a seemingly perfectly good OBJ ( Side Effects Support Ticket: #91349 ).
I was able to bypass any raised errors caused by the Python Script by using a Split top to bypass the other TOP nodes in the loop in case of error (which seems to work well enough).
I'll attempt pointing the HDA Processor to a different scheduler for appropriate error handling to see if I can gain access to a hook to tell the system to split out the stream on error, like I've done in the past with the Python Script TOP. Thank you for that advice.
I'll give it a try today and run the TOPs process overnight for a stress test. Again, thank you.
PDG/TOPs » Feedback Loop - Dynamic Partitioning
- 9krausec
- 66 posts
- Offline
A bit of a pickle here. Example attached.
I need to loop over each work_item one-by-one using a feedback loop, respecting work item order.
When “Use Dynamic Partitioning” for the Feedback loop is turned “off”, order is respect, but if one work_item fails, the entire loop fails.
When “Use Dynamic Partitioning” for the Feedback loops is turned “on”, order is NOT respected, but if one work_item fails, the loop continues regardless.
What I'm hoping to have is respected order of the work_items, but if one work_item fails, to have the loop continue regardless (simplified example attached). The “production” scenario described below.
Production Scenario:
Each work_item is responsible for initiating a subprocess (with arguments specific to the work_item) of a program that can only have one instance running at a time. After the work_item is done with the subprocess, the subprocess is completely shut down and the next work_item restarts it.
So with two work_items in the loop, it'd go…
work_item_0 - Open subprocess
work_item_0 - Close subprocess
work_item_1 - Open subprocess
work_item_1 - Close subprocess
I'd like to do this all without crashing the loop if one work_item fails with a raised dependency error. Thank you for any help!
I need to loop over each work_item one-by-one using a feedback loop, respecting work item order.
When “Use Dynamic Partitioning” for the Feedback loop is turned “off”, order is respect, but if one work_item fails, the entire loop fails.
When “Use Dynamic Partitioning” for the Feedback loops is turned “on”, order is NOT respected, but if one work_item fails, the loop continues regardless.
What I'm hoping to have is respected order of the work_items, but if one work_item fails, to have the loop continue regardless (simplified example attached). The “production” scenario described below.
Production Scenario:
Each work_item is responsible for initiating a subprocess (with arguments specific to the work_item) of a program that can only have one instance running at a time. After the work_item is done with the subprocess, the subprocess is completely shut down and the next work_item restarts it.
So with two work_items in the loop, it'd go…
work_item_0 - Open subprocess
work_item_0 - Close subprocess
work_item_1 - Open subprocess
work_item_1 - Close subprocess
I'd like to do this all without crashing the loop if one work_item fails with a raised dependency error. Thank you for any help!
Solaris and Karma » SOP->LOP Material Workflow
- 9krausec
- 66 posts
- Offline
Rafal, using Geometry Subset VOP LOP as you recommended was far more straightforward (and probably more efficient) than writing it all out in VEX. Got it working. Thank you, thank you.
My setup below for folks looking for this in the future -
Attached parameters.
Vex expression below,
My setup below for folks looking for this in the future -
Attached parameters.
Vex expression below,
string shop_materialpath[] = usd_attrib(0, @primpath, 'primvars:shop_materialpath'); string path = shop_materialpath[@elemnum]; string dir, name; splitpath(path, dir, name); return name;
Edited by 9krausec - Dec. 31, 2019 14:54:52
Solaris and Karma » SOP->LOP Material Workflow
- 9krausec
- 66 posts
- Offline
Good thread! Would anyone have any pointers in how to use a wrangle to partition all USD “Mesh” primitives into “GeomSubset” primitives under the mesh? Recreating the ‘partitionattribs’ functionality of the ‘SOP Import’ LOP, but across all mesh objects on stage.
Going over the vex functions for USD now, but haven't cracked it yet. Thanks.
EDIT: Think I may have figured this out. Will update with solution after I make a solid example.
Going over the vex functions for USD now, but haven't cracked it yet. Thanks.
EDIT: Think I may have figured this out. Will update with solution after I make a solid example.
Edited by 9krausec - Dec. 31, 2019 12:57:51
Technical Discussion » Reading Unicode OBJ File
- 9krausec
- 66 posts
- Offline
Edit: Looks like no unicode support for Houdini on Windows -
reference post [www.sidefx.com]
Hey all, having some issues reading in a file of the following path (windows machine) -
“C:/Users/clayton.krause/Desktop/pack_folder/_output/_part_pool/FC203-B03_3D__cfg__預設.obj”
Changing the name of the file to “abc.obj” fixes the issue, but it's important that the name of the obj stays the same (with the non-ascii symbols). I've tried using expressions with an escaped ascii string representing the file, then decoding it, but that didn't work.
Any suggestions on how to work with unicode filenames with Houdini in this context?
Thank you,
Clayton
reference post [www.sidefx.com]
Hey all, having some issues reading in a file of the following path (windows machine) -
“C:/Users/clayton.krause/Desktop/pack_folder/_output/_part_pool/FC203-B03_3D__cfg__預設.obj”
Changing the name of the file to “abc.obj” fixes the issue, but it's important that the name of the obj stays the same (with the non-ascii symbols). I've tried using expressions with an escaped ascii string representing the file, then decoding it, but that didn't work.
Any suggestions on how to work with unicode filenames with Houdini in this context?
Thank you,
Clayton
Edited by 9krausec - Oct. 15, 2019 12:01:49
PDG/TOPs » TOPs HDA Processor - only 12 concurrent work_items?
- 9krausec
- 66 posts
- Offline
Aduh… HDA Processor requires one thread per process. I had the local schedule set to 1/4 total processors. 24 cores 1/4 of 48 is 12… Got confused as the Python Script TOP seemed was exceeding 12 concurrent processes with the setting in the local schedule set to 1/4. Ignore this.
PDG/TOPs » TOPs HDA Processor - only 12 concurrent work_items?
- 9krausec
- 66 posts
- Offline
It seems as if my HDA Processor is capping at 12 concurrent work_items while other TOPs nodes are capping at 47 work items. Doubtful it's capping due to resource limitations as it's a lighter HDA process.
Anyone know how to make the HDA Processor allow for more concurrent work_item processing or is this normal?
Thanks,
Clayton
Anyone know how to make the HDA Processor allow for more concurrent work_item processing or is this normal?
Thanks,
Clayton
Edited by 9krausec - Oct. 5, 2019 18:38:45
Work in Progress » Instant Meshes Bridge Sop
- 9krausec
- 66 posts
- Offline
Houdini by default should be looking for the instantMeshes EXE in your user preferences folder (“$HOUDINI_USER_PREF_DIR” = environment variable for it). This is usually located in your documents by default - “C:\Users\%USER%\Documents\houdini17.0”
Drop the EXE in there and it should pick up. To see where it is pointing to or change the location the SOP points to, check out the “settings” tab of the SOP.
Drop the EXE in there and it should pick up. To see where it is pointing to or change the location the SOP points to, check out the “settings” tab of the SOP.
Technical Discussion » Python "toolutils.testTool" issue
- 9krausec
- 66 posts
- Offline
Alright, letting this sit with the community for a while, I'm going to open up a RFE/bug report on this.
edit:
Instead of using execfile() to fire off a .py I use as a dev/sandbox I am not actually importing it and locals and globals seem to be handled correctly-
here is what I'm not using in my shelf tool to comply better with toolUtils. Bit long winded, but works all the same. No bug submission as long as there is a work-around that probably is less hacky anyways.
edit:
Instead of using execfile() to fire off a .py I use as a dev/sandbox I am not actually importing it and locals and globals seem to be handled correctly-
here is what I'm not using in my shelf tool to comply better with toolUtils. Bit long winded, but works all the same. No bug submission as long as there is a work-around that probably is less hacky anyways.
import os import sys path = os.path.join(hou.getenv('HOUDINI_CLOUD_PREF_DIR'), 'python2/utils') if not path in sys.path: sys.path.insert(0, path) import hExec reload(hExec)
Edited by 9krausec - Jan. 4, 2019 14:09:52
Technical Discussion » Python "toolutils.testTool" issue
- 9krausec
- 66 posts
- Offline
jsmack
Why not add ‘$HOUDINI_CLOUD_PREF_DIR’ to your houdini path? Then you wouldn't need to use execfile, and you could store shelf tools and otls there too.
As to your problem, I don't know why testTool() would produce different results, but I suspect it runs slightly different context than clicking a tool.
‘$HOUDINI_CLOUD_PREF_DIR' is appended into the Houdini Path. I only use execfile for my Python dev .PY file. Like a sandbox.
If testTool's purpose is to execute a shelf tool via python, then the results should not deviate from hte user manually clicking on the shelf button. I figure this is a bug, but wanted to check the forums before submitting a report.
Thank you for the reply.
Technical Discussion » Python "toolutils.testTool" issue
- 9krausec
- 66 posts
- Offline
Getting some odd results using the toolutils.testTool to execute a shelf tool via Python in Houdini and I'm hoping someone might be able to let me know if it's potentially a bug that needs a RFE submitted or if it's user error.
The tool in question fires an external .py via execfile. Here is the script of the tool-
“HOUDINI_CLOUD_PREF_DIR” is a custom environment variable I work with to move preferences off the local machine and onto a network.
Inside of the testExec.py resides the below Python (example simplified)-
Now, when I click on the shelf tool directly, everything in this script works as expected. module.newModule picks up, ClassModule is imported in fine as CM. CM().testFire() fires an internal function of ClassModule that does a simple print statement for testing.
When executing the tool via “toolutils.testTool()” however, it's a completely different story and an error-
with the following traceback to toolutils-
Would anyone be able to please give me a hand sorting out of I'm doing something weird or if a RFE bug report needs to be submitted? I'd expect toolutils.testTool() to yield the same results as manually clicking on the shelf tool.
Thank you,
Clayton
The tool in question fires an external .py via execfile. Here is the script of the tool-
execfile(hou.getenv("HOUDINI_CLOUD_PREF_DIR") + '/python2.7libs/testExec.py')
“HOUDINI_CLOUD_PREF_DIR” is a custom environment variable I work with to move preferences off the local machine and onto a network.
Inside of the testExec.py resides the below Python (example simplified)-
from module.newModule import ClassModule as CM def tester(): CM().testFire() tester()
Now, when I click on the shelf tool directly, everything in this script works as expected. module.newModule picks up, ClassModule is imported in fine as CM. CM().testFire() fires an internal function of ClassModule that does a simple print statement for testing.
When executing the tool via “toolutils.testTool()” however, it's a completely different story and an error-
"NameError: global name 'CM' is not defined"
with the following traceback to toolutils-
File "C:/PROGRA~1/SIDEEF~1/HOUDIN~1.431/houdini/python2.7libs\toolutils.py", line 1975, in testTool exec(tool.script(), globals(), locals()) File "<string>", line 1, in <module>
Would anyone be able to please give me a hand sorting out of I'm doing something weird or if a RFE bug report needs to be submitted? I'd expect toolutils.testTool() to yield the same results as manually clicking on the shelf tool.
Thank you,
Clayton
Technical Discussion » Radial menu in the network editor
- 9krausec
- 66 posts
- Offline
jandress
That looks fantastic, but I installed in H17 and get:
Traceback (most recent call last):
File “Mouse Event Handler”, line 1, in <module>……..(etc)
Any suggestions?
I can confirm it's working tip top on Houdini 17.0.431. Be sure to place the “houdini_markingmenu” folder and “nodegraphhooks.py” inside the “python2.7libs” in your “documents/houdini17.0” folder (if you are using default env variables).
If you are still having issues you can try modifying the PYTHONPATH variable in the houdini .env file (documents/houdini17.0/houdini.env) to -
PYTHONPATH = “$HOUDINI_USER_PREF_DIR/python2.7libs;”
^I don't believe that should be necessary as python2.7libs should pick up just by being in your user prefs directory.
Sounds like you might be placing the source files in the wrong area. Good luck!
Technical Discussion » Radial menu in the network editor
- 9krausec
- 66 posts
- Offline
Has this officially been submitted as a RFE feature request? Been about a year now since this thread was created and radial menus in ALL contexts would be very welcome.
I have a handful of Python scripts and I find myself visiting the shelf a lot to execute them. A hotbox/radial menu jam in all contexts that a user can map scripts to would be super-duper neato.
I'm about ready to look at smilebox as an alternative - (simlebox git [github.com]), but it would be nice to stay straight Houdini for this.
Cheers.
I have a handful of Python scripts and I find myself visiting the shelf a lot to execute them. A hotbox/radial menu jam in all contexts that a user can map scripts to would be super-duper neato.
I'm about ready to look at smilebox as an alternative - (simlebox git [github.com]), but it would be nice to stay straight Houdini for this.
Cheers.
Technical Discussion » foreach connected breakout to own geo
- 9krausec
- 66 posts
- Offline
Just got around back to this today. Thank you for the reply! Your explanation makes great sense and I didn't think of it in that way. Knowing this will make it possible to do what I was looking to do with HOM. Very handy!
Technical Discussion » foreach connected breakout to own geo
- 9krausec
- 66 posts
- Offline
I'm curious at thoughts on best approach to do the following-
Take one lump of geometry with various poly islands. Run over reach like a foreach connected, output each connected chunk into it's own geo container via object merge, parent under the original geo container.
I can do most of what I'm fixing to do via HOM, but I'm getting caught on how to get multiple outputs from a for loop. If anyone here has ideas on best approaches, I'd appreciate to hear it.
Best,
Clayton
Here's a visual of what I'm looking to do (doesn't make sense, but helps with the understanding perhaps)-
Take one lump of geometry with various poly islands. Run over reach like a foreach connected, output each connected chunk into it's own geo container via object merge, parent under the original geo container.
I can do most of what I'm fixing to do via HOM, but I'm getting caught on how to get multiple outputs from a for loop. If anyone here has ideas on best approaches, I'd appreciate to hear it.
Best,
Clayton
Here's a visual of what I'm looking to do (doesn't make sense, but helps with the understanding perhaps)-
-
- Quick Links