ikoon

Hi, you are right. I didn't realize it but it could behave much better. I think we cannot fix this. Would you please RFE it? Btw I have previously RFEd unnecessary horizontal and vertical scrollbars. Often a tiny enlargement of this popup is enough to make the scrollbars disappear. If you also happen to have those unnecessary scrollbars, please mention them in your RFE too. I was told that it may be due to my specific dual monitor setup (and some test with swapping monitors led nowhere).

Hi Jim, do you use .sim files? Enable Save Checkpoints and if you want to stop at any frame (not just after Checkpoint Interval), then you might like the Checkpoint Trail Length http://www.sidefx.com/docs/houdini/nodes/obj/dopnet.html

Hi Bobby, I was also trying to solve this issue. I am freelancer, so I don't know how bigger studios solve this. Here is a thread discussing it: https://forums.odforce.net/topic/39743-file-cache-sop-checking-for-dirtiness/ I was considering many approaches, but I ended up with a simple "manual" solution. I search for dependent caches, with a script like the following. If you are interested in this "manual" solution, I will clean it up and post here (and on my blog http://lex.ikoon.cz) def fc_downstream_filecaches(node) : global dependents global filecaches candidates = list(set( node.outputs() + node.dependents() )) for candidate in candidates : if candidate.type().name() != "filecache" : if candidate not in dependents : dependents.append(candidate) fc_downstream_filecaches(candidate) else : # filecache, don't iterate filecaches.append(candidate) fc_invalidate(candidate) # If candidate's parent is a dopnet, check also dopnet, # because Dop I/O is dependent on Dop Object, # which is often independent. parent = candidate.parent() if parent.type().name() == "dopnet" : if parent not in dependents : dependents.append(parent) fc_downstream_filecaches(parent) def fc_invalidate_dependents() : dependents = [] filecaches = [] node = hou.selectedNodes()[0] fc_downstream_filecaches(node)

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.