anim

that all being said, you need to think twice if this is the workflow you want all nodes of the same type are sourced only from your preferred library per hip file so if you change the path to the type definition, it will switch this to all the nodes of that type (as they all share the same definition) this can be dangerous and is not suitable for versioning tools that you want to keep multiple versions of in the same hip file however it can be beneficial for the utility tools that you want to keep up to date all the time and don't really care that they may break backward compatibility (as it will change all existing nodes to preferred definition) on the other hand, versioning by namespacing the type, will allow you to have multiple versions in the same hip file and even if you open the old scene with an older type it will be intact, so it's much safer workflow for that

you can set it using hou.HDADefinition.setIsPreferred() to get the list of all installed definitions for certain type do hou.NodeType.allInstalledDefinitions() so overall you would do something like this: import hou node = hou.node('/obj/path/to/my/node') type = node.type() defs = type.allInstalledDefinitions() # and then set whichever one you want defs[1].setIsPreferred(True) obviously you can use the list of definitions to find desired path in there by library path and if found then set it as preferred, or whatever you plan the logic to be

on your generator CHOPs you can set Channel Range to be Use Current Frame Some CHOPs have also the Time Slice checkbox but it ultimately depends on your CHOP net and what's happening in there, if you are grabbing Geometry, channels, how you are exporting it back to your scene, etc.

they are showing because your geo is way denser long Y axis than along the horizontal Z so it receives much more detail from the spectrum in Y and therefore it looks like horizontal lines try to have more or less uniform density on your mesh resolution, so for example set your subdivide2/Depth parameter to 1 and convert2/V to 7 however this should not be a problem once you use the spectrum at rendertime as a displacement as the mesh will be rediced currently you have only N on your mesh, inherited to points, and the reference frame is computed using up of {0,1,0} for all the points, which especially in this scenario may cause points X axis to flip when N aligns with up vector and passes to the other side you can see the point reference frames when you put display flag on oceanSpectrum node

yes, the colors may be confusing - it all depends on what is the node's default scripting language (shown top-right next to cog icon) - if expression on the parameter is the same language, it is green, if it is other language then purple

it's just small tweaks: - delete N from your geo before applying Ocean Evaluate - increase Ocean Spectrum/Grid Size to maybe 5 - make sure you are not scattering points on deforming surface, scatter on single held frame, and use Attribute Interpolate to interpolate their positions and N - also make sure the point reference frames are stable during your deformation and that the axes point in directions as described in that thread or in the masterclass, to get wind in the correct direction

it's grayed out, because you don't have any keyframe or existing expression there, if you had one, you can convert you can also set your node language to Python and then when your parm is in expression editing mode, you can just type it in and it will create expression keyframe for you but this should work too, what errors are you getting?: yourParm.setExpression("2+2", hou.exprLanguage.Python)

you can watch this masterclass it has a lot of information about ocean spectrum, wave instancing, hero waves, ... https://www.sidefx.com/tutorials/houdini-16-ocean-tools/ also you can have a look at this for wave instancing examples

your pasted code snipped is broken (missing [] when calling member from neighs array ), but the code in the screenshot is ok, and in the viewport it looks like it works so I assume your problem is that your Group SOP is set to Primitives instead of Points and that's why you don't see the group in the menu same in the viewport, you probably have Prim selection instead of point selection also you can MMB on the node to see if your group is created and how many points it has

in H17 you can append Point Velocity SOP or Attribute Noise SOP to add noise to your points velocity attribute

that's not the case you geometry that has i@disableself or i@disableexternal at 1 will ignore those collisions regardless of the solver level settings as attributes are more granular the problem that you are hitting is that all the vellum geometry is self and any other object in the same dopsim is external as far as I know there is no way to do collisiongroups to distinguish individual pieces within vellum geo and define more granular collision pairing, I may be wrong though as Vellum is still being actively developed

you can try to increase cache memory for your sim if the dopnet has all frames cached in the memory up until where you stopped it should just continue if you ask to render from there, unless something is invalidating the cache upon hitting the Save To Disk Button so it may be dangerous as you are always risking that you can also just do your initial cache by hitting Save To Disk In Background, which will do the sim in a separate thread so in your scene you will be able to read and see how the sim is progressing, if you like it just let it finish or keep checking as the frames are being simmed if you don't like just kill the background process

its defined in here: $HFS/houdini/vex/include/bsdf.h the weight is based on the returned energy, well, you can see all math in there if interested BSDFs are not maps, but bidirectional functions, you may need to do some research even outside of the scope of Houdini to learn more as it's pretty extensive topic

https://www.sidefx.com/forum/topic/60379/?page=1#post-269763

running it how? run over Primitives: i@n = primvertexcount(0, @primnum); should return correct number for you per primitive it's true that it will return number of vertices and not points, and those can differ based on type of the curve and how they are constructed, but for most common polygonal curve primitives they usually match