Mikal

Awesome... Thank you J!

Hi... Am trying to automate the copying of a selection of nodes and dots to the clipboard.. If you copy these items manually using Ctrl-C then then it will correctly paste all the nodes and items together in the same network tree. Before network dots were introduced it was possible to do this in Python using: hou.copyNodesToClipboard(hou.selectedNodes()) - however this doesn't include any items, so the dots aren't included and your network chain breaks if you paste this into your scene again. It also doesn't seem possible to pass the items to the Clipboard with this function using: hou.copyNodesToClipboard(hou.selectedItems()) - returns a Type error. So I was wondering if anyone else has encountered this issue, and if there's a function in HOM I'm missing, or a sensible workaround etc? Feels like if Ctrl-C works there should be something that can be done. Cheers

Hey JJ Is it just that the code fails? You're missing a last semi colon in that example you've paste Do you have an example scene? Might be easier to debug if you have something simple you can share. Cheers

Hey Breadbox I'm sure you could grab the pyro dual rest nodes and put them into the billowy shader, although any exposed parameters should probably be re-created. If you've enabled dual rest fields, you will automatically have detail attributes available to you named (rest_ratio, and rest2_ratio) - which will help you blend the two rest fields together either in a shader or you could build a separate vector field if you wanted. I think... the formula is: dualrest = (rest*rest_ratio)+(rest2*rest2_ratio) If you pump the resulting dualrest vector field into the position parameter of a noise function - you should see the noise advect. Although one thing to remember is the advection strength you simmed the rest fields at, will determine the how closely the noise sticks to any smoke. Cheers

The min and max vectors are returned by the getbbox() function. In H16... you can get the same result with getbbox_center().

Do you mean the transform handles when you're looking through the camera? You're probably best splitting the viewport into two panes. Have one looking through the camera and then you can manipulate the camera through the perspective view in the other window and still see what you're doing. If I understood that right.

Hi.. It's a tricky effect to achieve by displacing a mesh. I'd suggest trying to achieve it by converting your seed to an SDF and advecting it by a velocity field. Attached is a basic example of the method I'm referring too, you should be able to sculpt/create the velocity field to achieve the shape you need. You'll probably need to tweak the SDF compositing to get it closer to the reference. Not sure if this is the best way, but probably the first method i'd try. gd luck. VDBAdvectSDF.hipnc

Hi... I'm looking to attempt some image manipulation using CHOP nodes. Having used the Image CHOP to access the individual pixel data I'm lost on the best way to Export it back to COP context. I'm guessing I could do it with the VopCop2Gen COP, but thought their might be a better (easier) way? Cheers!

Yup... that's great. Thanks!

Sooo... I was wondering if anyone knew how to add RBD objects into a sim dynamically. I assume it's possible but probably difficult - as using the Fracture Configure Object DOP creates new rbd objects upon impact within the existing framework. Basically I have a sop solver that creates new geo that I partition into new objects over 100 frames. I'd like to introduce those objects into the sim as they're created. Who's clever?.. Cheers!

Yeah, I think SESI has a challenge in understanding where it wants to go next - whether they continue to refine and introduce FX components or they try and sell Houdini to other aspects of the biz, and especially to early adoptees - get them building procedural tanks in Houdini instead of low-poly robots in Maya. To be fair SESI has been attempting to push Houdini as more than an FX Tool for a while, and it looks like the recent price cut is a further move in that direction. I think the biggest barriers to getting into Houdini for a beginner are some limitations around the poly tool set and the shading methodology. I would love to see a Hypershade style graph with predicted rendered swatches. Most people diving into the vex context of a shading network for the first time.. go 'what the... $!'... and back out. FEM would be greaaaat, but I wonder as Houdini has the best RBS system available they'd wanna go down that route just yet. I agree about the speed, and most users are willing to forego the extra speed for the functionality Houdini offers. SESI just had their best year apparently, so I think they should go all guns blazing and keep going after modelling/lighting/animation as well as FX.

I think this is pretty bad news for Houdini - but really bad news for Realflow and other 3rd party FX plug-in shelves like Thinking Particles/Fume FX who were looking to expand capability. I think you could expect a Naiad FX shelf in the Autodesk packages in coming releases - with water, smoke, fire, soft and rigid bodies - maybe more? Realflow should be pretty worried - as Naiad by most measures offers superior performance and results, and if it came bundled with a core package it would be difficult/impossible to compete on price. Fume FX - should also be worried, but currently I don't think Naiad/Autodesk have a production quality volumetric renderer, but only a matter of time, surely? Arguably Houdini has increased it's market share since Houdini 9, for a number of reasons - but an important one was the poor FX capabilities of the core packages. I think what's worrying is that most studios are built upon a Maya/Max/Softimage backbone - and then using Houdini as the FX component. I think it's fair to say less people will be willing/or need to make the jump to Houdini from Maya/Max if a Naiad FX shelf could offer very decent FX results in a native package. Houdini luckily retains the advantage of it's procedural approach, which will keep loyalists - and people will still convert because of the functionality you just can't get in the other packages. But for the industry in general it's pretty sad to see Autodesk just acquire another competitor. Anyway... some ramblings..

Thought I would include an alternate example that uses the Dop Import Records SOP to access Impact Point Data to birth particles. Might help. Debris_study_mpp.hipnc

Hi David Not quite sure what you want to do here. Do you want the particles to be emitted as it fractures? At the moment you're emitting on Frame 1, and the behaviour of the particles are set to 'Stick on Collision'... so not sure if you want the particles just left behind as the object falls, or you want the standard emission on fracture?

There is a difference, couldn't tell you exactly what thou. In general: Bullet can be considerably quicker - especially when using implicit volumes. But with more complex pre-shattered geo, especially when using clustering I find RBD is more stable and is easier to direct. If you swap the bullet solver back in it will work and you'll see the difference