ikoon

Hi! Have you tried to use the @mass point attribute?

There is the hqnode.ini on the client computer, but afaik client should "read" info from the hqserver.ini and update itself Are you following this? http://www.sidefx.com/docs/houdini/hqueue/installation.html

I had difficulties when I had PC addresses defined as names. Now I have everything set as IP numbers and it works fine.

It is off by default. You may need to turn it on and resimulate:

Thank you very much for a confirmation, Mark. So I did a script, which creates .py file for each selected ROP and also creates .bat file, which launches hython for each created .py to run them simultaneously. I will investigate the possibility to assign different GPUs to each hython (HOUDINI_OCL_DEVICENUMBER variable is not taken into account here). # create .py script for each selected ROP, to render it # create .bat file, which renders all the created .py with hython simultaneously def batch_script_rop () : import os path_hip = hou.expandString('$HIP') path_hipfile = hou.expandString('$HIPFILE') path_hython = hou.expandString('$HB') + '/hython.exe' path_scripts = path_hip + '/scripts/' if not os.path.exists(path_scripts): os.makedirs(path_scripts) script_bat = 'REM This batch file runs multiple .py scripts at once \n' for rop in hou.selectedNodes() : # .py script script_rop = '# This .py script opens a file and renders single rop\n' script_rop += 'hou.hipFile.load("' + path_hipfile + '")\n' script_rop += 'node = hou.node("' + rop.path() + '")\n' script_rop += 'node.render(verbose=True,output_progress=True)' # write .py to disk path_py = path_scripts + rop.name() + '.py' file_py = open( path_py, "w") file_py.write(script_rop) # .bat script script_bat += 'start "Render: ' + rop.name() + '" "' script_bat += path_hython + '" "' script_bat += path_py + '"\n' # write .bat to disk path_bat = path_hip + '/_render.bat' file_rop = open( path_bat, "w") file_rop.write(script_bat)

I solved it by creating windows batch... I thought, that I have to run hython from Command Line Tools ... but when I run it with full $HB path, it seems to work fine. This is the contents of batch.bat: start "just title: bat1" "C:\Program Files\Side Effects Software\Houdini 17.0.382\bin\hython.exe" C:\Users\info\Desktop\bat1.py start "just title: bat2" "C:\Program Files\Side Effects Software\Houdini 17.0.382\bin\hython.exe" C:\Users\info\Desktop\bat2.py Those two "start" are there to run both hythons simultaneously. The bat1.py contains: hou.hipFile.load("Q:/bl/5 houdini A/bl - A - v07.hiplc") node = hou.node('/obj/rop_OGL/strict1') node.render(verbose=True,output_progress=True)

I use OpenGL ROP a lot, and I usually have more of them. They usually can render simultaneously without decrease of speed, usually run single threaded, hundreds of frames. I am on windows 10. The simplest way I found so far is to manually start Command Line Tools (CLT), generate the following script from selected ROP and paste it into CLT window ... and the render starts in that CLT. hython "Q:\bl\5 houdini\bl - v07.hiplc" node = hou.node('/obj/rop_OGL/strict2') node.render(verbose=True,output_progress=True) Please, is there any way to automate this better? Can I run new hython instance from Houdini UI, and pass appropriate script to it? Ideally, I would like to edit the houdini.env for each new hython, so I could use all of the GPUs (I can do this with python)

Hi, Nick Taylor did this and shared on his patreon: https://www.patreon.com/posts/kaleidoscope-16980758 But it seems that non-patreons do not see it. The same thing is previewed here: https://twitter.com/_Nick_Taylor/status/963528664813129730 If you buy it, you can dig into his technique. He uses Clip SOP, if I remember correctly. So it is not entirely done in vex. You can bind your own geometry into his technique.

My intention with this "toolset" was to build long sims (I do dancer performance synchronized visuals, something like "ENRA Visual Dance"). From my client, I have recording of the dance. I prepare lots of forces, sources, pops, pyro, pop drag etc, animated "invisible" objects etc ... and then I keyframe those impacts. So I use the .sim files as some "checkpoints". I edit the keyframes only in the preview range ... when it looks good, I move one or more ".sim step" further. I am not sure if it is the best workflow, I will work further on it.

So, I made few little scripts to work with my .sim checkpoint files. So ... it is useful for long non-heavy sims, with keyframed behaviour. Now I work on a background animation for a dancer event performance which is ~ 7200 frames. I plan to make the scripts even better ... to reset multiple DOPs with one hotkey press. http://lex.ikoon.cz/sim-files-toolset The script contains os.remove(file_path), so check it before use.

If those tunnels are not animated, you could separate it into more steps: - somehow manage to keep the particles inside the tunnels, and make them reach their goal, even if their speed and behavior is not exactly what you like - generate their trails (Timeshift to the end and loong Trail) - finetune these trails in SOPs (Smooth, Resample, Point jitter ... and VDB Advect Points can also help to push them into the center of tunnels) - finally Slide points along edges, so you can art direct the speed l am curious about other approaches, this is interesting topic.

SDF is a scalar field. You could add a Volume Analysis SOP (Gradient), which will give you the "normal" direction of your SDF, and then use this normal vector to push the particles to the center of your sdf (POP Advect by Volumes) http://www.sidefx.com/docs/houdini/nodes/sop/volumeanalysis.html You could also generate Collision from your sdf, to keep your particles inside the tunnels. But I think, that those forces will be too tricky to keep the particles in the center of those "tunnels" and art-direct their speed. I would rather fake it in SOPs ... generate centerlines, smooth, multiplicate them, give them some position noise, Slide points along edges (as Matt does it here) The "generation of centerlines" issue remind me of this link: https://houdinigubbins.wordpress.com/2017/07/22/fiedler-vector-and-the-medial-axis/ Unfortunately I am not skilled enough to reproduce that "centerline" setup and source is not included there.

Please, is there any way to view the "time spent on this file (or project)"? Or have you heard about such a tool for Houdini?

The Stash SOP should help you? Quote: You can modify or overwrite the cached geometry with hou.Geometry objects through scripting. You can link the geometry parameter to a parameter on a parent asset. This allows assets to inject geometry into a network without making the contents editable. http://www.sidefx.com/docs/houdini/nodes/sop/stash.html

In vex, we cannot specify geometry as relative path. a. You may wire the MUDGUARDS into the second input, and the vex will be: point(1,"name",0) b. If you don't want to wire (or you cannot), you can add a spare input, and change vex to: point(-1,"name",0) c. Another solution, worse than b. Rewrite your vex to this: point("op:/obj/yourgeoname/MUDGUARDS","name",0) But this is probably bad, because if you rename anything in the path, vex doesn't update the code automatically, so this path gets broken. As regards spare input, it is described here: http://www.sidefx.com/docs/houdini/model/compile More is here: http://www.sidefx.com/docs/houdini/io/op_syntax.html