old school

I agree! Please submit an RFE for this documentation. Just so we have a reminder that this would be useful to have.

I would use the wind tunnel option on the Pyro Object DOP. Enable the wind tunnel option and set the vector as the direction and magnitude of the wind tunnel. Make sure that it is a smoke sim. Disable anything to do with temperature. Set buoyancy to 0. Disable any temperature field in the source volume and the Fluid Source VOP. Get rid of gravity. Make the container size just big enough to run the sim. Very narrow. On the Solver, disable all shaping including diffusion except for confinement. Use lots of confinement to add nice swirling detail. See the attached hip file for one example setup. From my sim comparing to the reference footage, a lot of finessing with either localized sink in the shoe to velocity sculpting or invisible colliders are used around the shoe to get the streamers to do what they are doing which is to be expected. That the streamers would be art directed far beyond a simple physical simulation. wind_tunnel_shoe.hip

Old school renderman shaders used micropolygon rendering and scan lines. Vertices were pre-shaded and yes you could set constant values that only evaluate on the verts and not across the face. All after geometry refinement. Raytracing is not this. Every ray needs to evaluate the shader. It's all firing rays and calculating all shader properties on ray hits. Even constant colors are evaluated every ray hit. Including texture string look-ups. UDIMs with varying texture references per face after refinement... Vex is still pretty loosely typed in that you don't have to specify varying or constant variables as this is determined when shader is compiled. Optimizations applied as they can. ???

I believe what you are asking for is noise functions that are normalized over all dimensions, octaves and roughness. The Unified Noise VOP and Unified Noise Static VOP both return noise that is normalized for you. Both Unified Noise type VOPs inside their code snippet include $HH/vex/include/pyro_noise.h to generate normalized noise results. If you are writing your own vex (wrangles, vex shaders from scratch, etc) you can include pyro_noise.h and then use defined the noise functions within a fit range: nwrap_sine() nwrap_perlin() nwrap_pperlin() nwrap_simplex() nwrap_sparse() nwrap_flow() nwrap_pflow() nwrap_worleyFA() nwrap_worleyFB() nwrap_mworleyFA() nwrap_mworleyFB() nwrap_cworleyFA() nwrap_cworleyFB() nwrap_alligator() They all share the same interface which is nice. What's really cool about the pyro_noise.h vex file is that it also contains functions that return the statistical norm and min and max ranges for all the default vex noise functions. The results are also embedded in pyro_noise.h for you if you wish. This is the table built for you. Returns the noise name, min value, max value, median value and a bit to say if it is not celular 1 or celular 0 (I think...). Then followed by a probability variance of these values. Note all the function variations are included in the file for your reference: //------------------------------------------------------------------------------- // The constants used in this module were generated with the call: // // nstats(0.005, 10,20, 1000, (int)5e6, 0); // // which produces the following output: #define ns_fperlin1 \ nsdata ( "perlin" , 0.248834 , 0.767147 , 0.488376 , 1 ) // +/- 0.0024 #define ns_vperlin1 \ nsdata ( "perlin" , 0.229499 , 0.761877 , 0.509742 , 1 ) // +/- 0.0024 #define ns_fperlin2 \ nsdata ( "perlin" , 0.136616 , 0.864593 , 0.499529 , 1 ) // +/- 0.0024 #define ns_vperlin2 \ nsdata ( "perlin" , 0.033912 , 0.946057 , 0.511009 , 1 ) // +/- 0.0025 #define ns_fperlin3 \ nsdata ( "perlin" , 0.0832587 , 0.920337 , 0.497705 , 1 ) // +/- 0.0024 #define ns_vperlin3 \ nsdata ( "perlin" , 0.0013614 , 0.996832 , 0.335704 , 1 ) // +/- 0.0032 #define ns_fpperlin1 \ nsdata ( "pperlin" , 0.272539 , 0.732348 , 0.493888 , 1 ) // +/- 0.0024 #define ns_vpperlin1 \ nsdata ( "pperlin" , 0.24574 , 0.7608 , 0.493501 , 1 ) // +/- 0.0024 #define ns_fpperlin2 \ nsdata ( "pperlin" , 0.128858 , 0.839149 , 0.521924 , 1 ) // +/- 0.0024 #define ns_vpperlin2 \ nsdata ( "pperlin" , 0.0974457 , 0.914321 , 0.492854 , 1 ) // +/- 0.0024 #define ns_fpperlin3 \ nsdata ( "pperlin" , 0.0777629 , 0.911734 , 0.50605 , 1 ) // +/- 0.0024 #define ns_vpperlin3 \ nsdata ( "pperlin" , 0.0191109 , 0.982488 , 0.402437 , 1 ) // +/- 0.0025 #define ns_fsimplex1 \ nsdata ( "simplex" , 0.0135945 , 0.980643 , 0.503308 , 1 ) // +/- 0.0024 #define ns_vsimplex1 \ nsdata ( "simplex" , 0.00470505 , 0.979253 , 0.508709 , 1 ) // +/- 0.0024 #define ns_fsimplex2 \ nsdata ( "simplex" , 0.100222 , 0.909426 , 0.494677 , 1 ) // +/- 0.0024 #define ns_vsimplex2 \ nsdata ( "simplex" , 0.0576417 , 0.958953 , 0.491143 , 1 ) // +/- 0.0024 #define ns_fsimplex3 \ nsdata ( "simplex" , 0.15302 , 0.850784 , 0.497038 , 1 ) // +/- 0.0024 #define ns_vsimplex3 \ nsdata ( "simplex" , 0.0434933 , 0.970121 , 0.315176 , 1 ) // +/- 0.0076 #define ns_fsparse1 \ nsdata ( "sparse" , -1.05121 , 1.41258 , 0.437552 , 1 ) // +/- 0.0024 #define ns_vsparse1 \ nsdata ( "sparse" , -1.84633 , 1.41258 , 0.563931 , 1 ) // +/- 0.0025 #define ns_fsparse2 \ nsdata ( "sparse" , -1.85569 , 1.8013 , 0.514998 , 1 ) // +/- 0.0027 #define ns_vsparse2 \ nsdata ( "sparse" , -2.28436 , 2.08765 , 0.520132 , 1 ) // +/- 0.0025 #define ns_fsparse3 \ nsdata ( "sparse" , -2.34351 , 2.43843 , 0.49609 , 1 ) // +/- 0.0174 #define ns_vsparse3 \ nsdata ( "sparse" , -2.71525 , 2.64793 , 0.504632 , 1 ) // +/- 0.0256 #define ns_fflow1 \ nsdata ( "flow" , 0.191786 , 0.838335 , 0.476434 , 1 ) // +/- 0.0024 #define ns_vflow1 \ nsdata ( "flow" , 0.156953 , 0.847188 , 0.498596 , 1 ) // +/- 0.0024 #define ns_fflow2 \ nsdata ( "flow" , 0.110068 , 0.907473 , 0.489255 , 1 ) // +/- 0.0024 #define ns_vflow2 \ nsdata ( "flow" , 0.019407 , 0.977013 , 0.330133 , 1 ) // +/- 0.0032 #define ns_fflow3 \ nsdata ( "flow" , 0.0972697 , 0.879663 , 0.514725 , 1 ) // +/- 0.0024 #define ns_vflow3 \ nsdata ( "flow" , 0.0789278 , 0.909136 , 0.506907 , 1 ) // +/- 0.0024 #define ns_fpflow1 \ nsdata ( "pflow" , 0.192796 , 0.835272 , 0.483768 , 1 ) // +/- 0.0024 #define ns_vpflow1 \ nsdata ( "pflow" , 0.192727 , 0.834885 , 0.481012 , 1 ) // +/- 0.0024 #define ns_fpflow2 \ nsdata ( "pflow" , 0.0875699 , 0.872108 , 0.526021 , 1 ) // +/- 0.0025 #define ns_vpflow2 \ nsdata ( "pflow" , 0.0681927 , 0.928206 , 0.502054 , 1 ) // +/- 0.0025 #define ns_fpflow3 \ nsdata ( "pflow" , 0.0931273 , 0.896028 , 0.506575 , 1 ) // +/- 0.0024 #define ns_vpflow3 \ nsdata ( "pflow" , 0.0427369 , 0.940558 , 0.509313 , 1 ) // +/- 0.0024 #define ns_fworleyFA1 \ nsdata ( "worley" , 0 , 0.742495 , 0.0740117 , 0 ) // +/- 0.0024 #define ns_vworleyFA1 \ nsdata ( "worley" , 0 , 0.742495 , 0.0740117 , 0 ) // +/- 0.0024 #define ns_fworleyFA2 \ nsdata ( "worley" , 0 , 1.15271 , 0.108373 , 0 ) // +/- 0.0256 #define ns_vworleyFA2 \ nsdata ( "worley" , 0 , 1.15271 , 0.108373 , 0 ) // +/- 0.0256 #define ns_fworleyFA3 \ nsdata ( "worley" , 0 , 1.18895 , 0.159684 , 0 ) // +/- 0.0256 #define ns_vworleyFA3 \ nsdata ( "worley" , 0 , 1.18895 , 0.159684 , 0 ) // +/- 0.0256 #define ns_fworleyFB1 \ nsdata ( "worley" , 0 , 0.902963 , 0.118548 , 0 ) // +/- 0.0025 #define ns_vworleyFB1 \ nsdata ( "worley" , 0 , 0.902963 , 0.118548 , 0 ) // +/- 0.0025 #define ns_fworleyFB2 \ nsdata ( "worley" , 0 , 1.24931 , 0.108399 , 0 ) // +/- 0.0256 #define ns_vworleyFB2 \ nsdata ( "worley" , 0 , 1.24931 , 0.108399 , 0 ) // +/- 0.0256 #define ns_fworleyFB3 \ nsdata ( "worley" , 0 , 1.1101 , 0.118099 , 0 ) // +/- 0.0181 #define ns_vworleyFB3 \ nsdata ( "worley" , 0 , 1.1101 , 0.118099 , 0 ) // +/- 0.0181 #define ns_fmworleyFA1 \ nsdata( "mworley" , 0 , 0.587001 , 0.0971886 , 0 ) // +/- 0.0025 #define ns_vmworleyFA1 \ nsdata( "mworley" , 0 , 0.587001 , 0.0971886 , 0 ) // +/- 0.0025 #define ns_fmworleyFA2 \ nsdata( "mworley" , 0 , 1.29428 , 0.314845 , 0 ) // +/- 0.0059487 #define ns_vmworleyFA2 \ nsdata( "mworley" , 0 , 1.29428 , 0.314845 , 0 ) // +/- 0.0059487 #define ns_fmworleyFA3 \ nsdata( "mworley" , 0 , 1.56603 ,0.398481 , 0 ) // +/- 0.0124397 #define ns_vmworleyFA3 \ nsdata( "mworley" , 0 , 1.56603 ,0.398481 , 0 ) // +/- 0.0124397 #define ns_fmworleyFB1 \ nsdata( "mworley" , 0 , 0.618887 , 0.178215 , 0 ) // +/- 0.00249998 #define ns_vmworleyFB1 \ nsdata( "mworley" , 0 , 0.618887 , 0.178215 , 0 ) // +/- 0.00249998 #define ns_fmworleyFB2 \ nsdata( "mworley" , 0 , 1.25947 , 0.183175 , 0 ) // +/- 0.0153326 #define ns_vmworleyFB2 \ nsdata( "mworley" , 0 , 1.25947 , 0.183175 , 0 ) // +/- 0.0153326 #define ns_fmworleyFB3 \ nsdata( "mworley" , 0 , 1.45466 , 0.161667 , 0 ) // +/- 0.0213142 #define ns_vmworleyFB3 \ nsdata( "mworley" , 0 , 1.45466 , 0.161667 , 0 ) // +/- 0.0213142 #define ns_fcworleyFA1 \ nsdata( "cworley" , 0 , 0.587747 , 0.0978262, 0 ) // +/- 0.0025 #define ns_vcworleyFA1 \ nsdata( "cworley" , 0 , 0.587747 , 0.0978262, 0 ) // +/- 0.0025 #define ns_fcworleyFA2 \ nsdata( "cworley" , 0 , 0.901443 , 0.320862 , 0 ) // +/- 0.00593521 #define ns_vcworleyFA2 \ nsdata( "cworley" , 0 , 0.901443 , 0.320862 , 0 ) // +/- 0.00593521 #define ns_fcworleyFA3 \ nsdata( "cworley" , 0 , 0.843453 , 0.406956, 0 ) // +/- 0.00592824 #define ns_vcworleyFA3 \ nsdata( "cworley" , 0 , 0.843453 , 0.406956, 0 ) // +/- 0.00592824 #define ns_fcworleyFB1 \ nsdata( "cworley" , 0 , 0.619793 , 0.178844, 0 ) // +/- 0.0025 #define ns_vcworleyFB1 \ nsdata( "cworley" , 0 , 0.619793 , 0.178844, 0 ) // +/- 0.0025 #define ns_fcworleyFB2 \ nsdata( "cworley" , 0 , 0.849381 , 0.185333, 0 ) // +/- 0.00514269 #define ns_vcworleyFB2 \ nsdata( "cworley" , 0 , 0.849381 , 0.185333, 0 ) // +/- 0.00514269 #define ns_fcworleyFB3 \ nsdata( "cworley" , -0.0114286 , 0.776565 , 0.165661, 0 ) // +/- 0.0114286 #define ns_vcworleyFB3 \ nsdata( "cworley" , -0.0114286 , 0.776565 , 0.165661, 0 ) // +/- 0.0114286 #define ns_falligator1 \ nsdata ( "alligator" , 0 , 0.897279 , 0.13911 , 0 ) // +/- 0.0024 #define ns_valligator1 \ nsdata ( "alligator" , 0 , 0.931199 , 0.132454 , 0 ) // +/- 0.0024 #define ns_falligator2 \ nsdata ( "alligator" , 0 , 0.981734 , 0.117792 , 0 ) // +/- 0.0025 #define ns_valligator2 \ nsdata ( "alligator" , 0 , 0.980294 , 0.126717 , 0 ) // +/- 0.0024 #define ns_falligator3 \ nsdata ( "alligator" , 0 , 0.993732 , 0.117951 , 0 ) // +/- 0.0032 #define ns_valligator3 \ nsdata ( "alligator" , 0 , 0.992102 , 0.128566 , 0 ) // +/- 0.0025 #define ns_fperlin4 \ nsdata ( "perlin" , 0.0168713 , 0.998413 , 0.507642 , 1 ) // +/- 0.0073 #define ns_vperlin4 \ nsdata ( "perlin" , 0.00576016 , 1.025 , 0.518260 , 1 ) // +/- 0.0037 #define ns_fpperlin4 \ nsdata ( "pperlin" , 0.154528 , 0.828153 , 0.511577 , 1 ) // +/- 0.0024 #define ns_vpperlin4 \ nsdata ( "pperlin" , 0.149949 , 0.853128 , 0.49744 , 1 ) // +/- 0.0024 #define ns_fsimplex4 \ nsdata ( "simplex" , 0.0943673 , 0.912882 , 0.503625 , 1 ) // +/- 0.0064 #define ns_vsimplex4 \ nsdata ( "simplex" , 0.13602 , 0.848679 , 0.510355 , 1 ) // +/- 0.0025 #define ns_fsparse4 \ nsdata ( "sparse" , -2.18691 , 2.46426 , 0.476393 , 1 ) // +/- 0.0064 #define ns_vsparse4 \ nsdata ( "sparse" , -2.59173 , 2.50891 , 0.506553 , 1 ) // +/- 0.0145 #define ns_fflow4 \ nsdata ( "flow" , 0.0541632 , 0.942907 , 0.501736 , 1 ) // +/- 0.0025 #define ns_vflow4 \ nsdata ( "flow" , 0.0834745 , 0.893131 , 0.514653 , 1 ) // +/- 0.0024 #define ns_fpflow4 \ nsdata ( "pflow" , 0.144938 , 0.852499 , 0.501408 , 1 ) // +/- 0.0024 #define ns_vpflow4 \ nsdata ( "pflow" , 0.155242 , 0.840548 , 0.5022 , 1 ) // +/- 0.0024 #define ns_fworleyFA4 \ nsdata ( "worley" , 0 , 1.19425 , 0.314428 , 0 ) // +/- 0.0024 #define ns_vworleyFA4 \ nsdata ( "worley" , 0 , 1.19425 , 0.314428 , 0 ) // +/- 0.0024 #define ns_fworleyFB4 \ nsdata ( "worley" , 0 , 1.53913 , 0.1402 , 0 ) // +/- 0.0512 #define ns_vworleyFB4 \ nsdata ( "worley" , 0 , 1.53913 , 0.1402 , 0 ) // +/- 0.0512 #define ns_fmworleyFA4 \ nsdata ( "mworley" , 0.00495732 , 1.7116 , 0.482286 , 0 ) // +/- 0.0068835 #define ns_vmworleyFA4 \ nsdata ( "mworley" , 0.00495732 , 1.7116 , 0.482286 , 0 ) // +/- 0.0068835 #define ns_fmworleyFB4 \ nsdata ( "mworley" ,-0.0163645 , 1.42481 , 0.159796 , 0 ) // +/- 0.0163645 #define ns_vmworleyFB4 \ nsdata ( "mworley" ,-0.0163645 , 1.42481 , 0.159796 , 0 ) // +/- 0.0163645 #define ns_fcworleyFA4 \ nsdata ( "cworley" , 0.0274073 , 0.690122 , 0.521913 , 0 ) // +/- 0.00249996 #define ns_vcworleyFA4 \ nsdata ( "cworley" , 0.0274073 , 0.690122 , 0.521913 , 0 ) // +/- 0.00249996 #define ns_fcworleyFB4 \ nsdata ( "cworley" , 0 , 0.647968 , 0.156623 , 0 ) // +/- 0.00587861 #define ns_vcworleyFB4 \ nsdata ( "cworley" , 0 , 0.647968 , 0.156623 , 0 ) // +/- 0.00587861 #define ns_falligator4 \ nsdata ( "alligator" , 0 , 0.994222 , 0.117762 , 0 ) // +/- 0.0032 #define ns_valligator4 \ nsdata ( "alligator" , 0 , 0.991346 , 0.125998 , 0 ) // +/- 0.0025 #define ns_fsine1 \ nsdata ( "sine" , 0 , 1 , 0.5 , 1 ) // +/- 0 #define ns_fsine2 \ nsdata ( "sine" , 0 , 1 , 0.5 , 1 ) // +/- 0 #define ns_fsine3 \ nsdata ( "sine" , 0 , 1 , 0.5 , 1 ) // +/- 0 #define ns_fsine4 \ nsdata ( "sine" , 0 , 1 , 0.5 , 1 ) // +/- 0 #define ns_vsine1 \ nsdata ( "sine" , 0 , 1 , 0.5 , 1 ) // +/- 0 #define ns_vsine2 \ nsdata ( "sine" , 0 , 1 , 0.5 , 1 ) // +/- 0 #define ns_vsine3 \ nsdata ( "sine" , 0 , 1 , 0.5 , 1 ) // +/- 0 #define ns_vsine4 \ nsdata ( "sine" , 0 , 1 , 0.5 , 1 ) // +/- 0

Next step is to make sure that you animate your boat such that the boat object itself is +Z forward. You scene was +X as forward. Built a simple animation rig around your boat object using two nulls. Made sure there was no animation on the boat object itself but putting animation on a null above the boat. Used the same network with the CHOPs to add dynamic motion to boat. This also sets things up to build a bearing angle by inspecting the parent object orientation compared to the world root orientation. boat_on_waves_rig.hip

The logic is a bit flawed. The Bounding Box with the Oriented option enabled does orient a box around your input but because it is a deforming flat pancake, you may get a bounding box that is rotated in non-predictable ways. This means your Blast SOP removing primitive 5 for the most part is the top polygon of the bounding box but in some deformed states this is one of the front or sides of the box causing everything to fail. By removing all of those three SOPs and just fusing all the ray points to get the average P and N, you are good. As well since the animation is at the object level, you don't need to supply UP as the forward Z direction which you tried to calculate by subtracting two known points from Primitive 5, which again fails when the box spins due to the deforming input. I then took your logic but worked it up a bit differently using CHOPs. With CHOPs you can add lag for weight in both the P and N. I had to smooth the N out a bit. Have a look at the scene file. boat_on_waves_jw.hip

A real tough condition for procedural tools to fill those holes. I used a curve SOP then mirrored a couple times to fill in the holes. And those four holes will create a polygon that is concave. Not a very good primitive to render with many engines, or to pass on to a game engine as triangulating that face may cause overlaps. Polyfill sees the input as degenerate which means there are one or more cases where things are ambiguous. Consider that there are six open conditions that it considers to fill. The four holes, the perimeter of the frame and the perimeter of the exuded oval. Instead I reworked your file to be more procedural. Where the original grid and circle are properly configured, skinned and then three methods to create the extrusion: your existing polyextrude SOPs (fussy approach), using a single poly extrude and it's ramp lookup for the extrusion, sweep SOP to sweep a profile curve to create the profile. You can change the window outline, the padding of the circle to the perimeter and anything else you want to drive procedurally. What's also nice is that the topology is rock solid and you can create an infinite number of variations. Begging to be turned in to an HDA. manifold_geo_window_frame.hip

pop* will bring in any DOP objects that begin with pop. The default name for a particle system built from the POP SOP is popobject. So pop* will fetch that object along with any other simulation objects that begin with pop. ---- DOP Import SOP imports simulation objects. More specifically any geometry sub-data bound to that simulation object. If you open up a Spreadsheet on any DOP, you will see a listing of all the simulation objects. Open up any Simulation object will show you the list of subdata of which Geometry is one. Geometry contains all the points, polygons, any geometry for that object. The DOP Import SOP has two slots actually. One is for the name of the simulation object(s) to bring in. A second field, usually blank is used to import any subdata. Blank always defaults to Geometry. You could use this to bring in any named fields/volumes by name on that simulation object as well. Any sub-data on the simulation object that is of type geometry can be imported back in to SOPs.

As a Houdini presenter having used MacBook Pros for the last 10 years it has everything to do about video support, ruggedness and thin/light weight and direct access to key tools such as keynote from the very first MacBook Pro released. All of this up until now made up for les than ideal viewport experience with Houdini. Since I love to use Houdini live in many presentations and with Apple moving to Metal and the Houdini viewport experience not keeping up with windows and Linux, well things have now changed for me personally. I am switching back to PC laptops and windows 10 because higher end PCs have come a very long way and most have thunderbolt and DVI out for easy setup to presentation monitors and projectors. Windows 10 is what it is but is far more manageable. I use Cygwin for shells so no issue there. Plus I want to run other tools for games support on the road. Unreal, Unity. Substance, redshift, etc. Unfortunately MS still believes that MS Office still has value beyond the cost of the OS so you do have to pay and it is subscription now. Why MS? Why in this day and age? PowerPoint is not keynote but it too has come a long way. Houdini performance is better and supports all viewport features with a decent Nvidia card and with the Mac you have little choice here. —— Why do some Houdini presenters put down a geo Object, dive in, blast the file sop and start working, I don’t know. I call this the seven deadly clicks and is the main reason we added shelf tools. Familiarity I guess. I use shelf tools to add Primitives then dive in when presenting myself as I try to avoid needless complexity in Presentations. On my own, it’s a toss as to what I do, —— i do not have a moustache. Nor do I see myself growing one in the near future but nothing wrong with that. Had a moustache all through High School and never once was I carded, if that means anything.

This is H16. To add Displacements you have to build this in to the Core shaders. Core shaders only do surface shading. If you want to add a texture displacement, use displacetyexture VOP. To build a single non-mixing shader, you add two output VOPs one of type surface and one of type displacement after the skinshadercore and displacetyexture. Add a Collect VOP and wire in the two outputs. You also have to add a Properties VOP. RMB (RightMouseButton) on the properties and choose Edit Render Properties. In the dialog that pops up, in the render property list, in the bottom search field type displace. Then find the Mantra > Render and choose all the render properties as in the snapshot image. See the attached Houdini scene file for a working skinshadercore with displacements in /mat. skinshader_with_displace.hiplc

Wait a couple weeks... H16 will have an answer for you that still blows me away every day I use it. In the meantime, yes Cookie needs a lot of love to get results in some cases. Always try jitter parameter first. Cookie also has issues when the geometry is too small (less than 0.01) or large (greater than 100) so scale in to the sweet spot of 1 to 10 overall units. It also doesn't like co-incident surfaces hence jitter. Always put the more complicated geometry in to the left first input. Really try not to slice up a manifold left input geometry with an open grid plane and instead use a box to cut the geometry using only one of the faces of the box as the cutter. Always make sure primitive (not point normals as they simply do not matter but check the primitive normals) are always facing outward or else use a Reverse SOP to make sure they are facing outward. We gave up on Cookie when doing the shatter tool as it was unpredictable. Shatter Tool uses recursive Clip SOPs to cut up the geometry reliably.

If you are eroding a surface VDB, you can use the VDB Activate SDF to activate a wider band of voxels to do the erosion in to. You can also use the more involved VDB Activate SOP with far more options to activate regions of the VDB grid to do your work including second input geometry to act as a mask for active regions. VDB's are efficient due to the thin band of data that exists around the limit surface in SDFs and volumes around the data that is varying between constant values (density usually 0 to 1). Generally the thin band is defaulting to 3 voxels either way of the 0 value for SDF and around the 0-1 varying band in Density VDB volumes: Exterior Band voxels and Interior Band voxels. These two parameters are exposed on the VDB from Polygons SOP. Please use the VDB Visualize SOP to see the active band. IMHO you simply can not sculpt VDB's without using this SOP somewhere in the chain to avoid this issue. Use the Active Voxels toggle parameter and set to points to see where the active voxels are. You can't push data in to a region of the VDB grid that has inactive voxels. You will get no result which is what you are experiencing.

No need to hack the shader and remove displacement links. Leave the displacement and normal wires in place. Just add the Mantra Property: True Displacements < vm_truedisplace > to your Properties VOP inside your shader using the Edit Parameter Interface Edit Rendering Parameters. This adds the toggle True Displacements. Just turn it off and the geometry will not be diced and displaced. Only surface normals calculated. There is another interesting property as well that you may want to look in to: Add Bump To Ray Traced Displacements which will do both displacements and bump when the threshold is met. This is a critical one when reworking large scenes as archives using Material Style Sheets. You can control this render property right at the end of the pipeline without adding to your shader when using material style sheets and targets with property overrides. Could even put a wrangle in the stylesheet that sets this property based on distance from camera.

Depends on what you want to do. If you need to work with the faces in SOPs, then yes Unpack SOP is what you need to do. Only unpack what you need. There is "one way" to select faces on deferred primitive types (packed prims, alembic archives) and that is to use the Style Sheet Data Tree interface. You can use the style target option Selection from Viewport to select faces buried deep in any archive to do shader/material and Mantra property overrides. Viewport selections can be any group or @attribute group type selection. All selection options are available within the Style Sheet selection target tool.

The number 1 reason to work with shells is that each shell represents it's own environment. Each environment can be set up to a separate project, shot, scene, WIP test of an HDA asset, different versions of Houdini per shell, whatever. Most users in production need concern themselves with a single task. This means that launching Houdini with a single environment. GUI works as well as a whole host of other tools such as python GUI launchers, launching through a Production Management software, double clicking on a .hip file. As you get more and more things on the go shells start to make a lot of sense. Each shell can be configured with different environment variables to point at any build of Houdini with any project environment. Another reason to look at shells as a power user is that all the launch scripts for Houdini are either a csh or bash script, no matter how you launch Houdini. These shell scripts are used to configure the Houdini environment. Convenience is a huge factor here. Using shells isn't for everyone. Actually 99% of users in production don't need shells to do what they want. So many other ways to work. But if you aspire to be a full on Houdini user in a demanding production environment and desire complete control, there is no equivalent to using shells. It's truly liberating for power users. It's easy to get in to shells with Houdini. Houdini ships with it's own shell wrapper that you can double click in Windows/MacOS. This installs the Houdini environment. Then you need to concern yourself with a handful of commands: ls (directory listing), cd (change directory), cp (copy), mv (move), houdini, mplay. Shells are available in all OS'es. Linux and Mac have Unix underpinning where shells are how you interface with the OS. Windows has it's own shells which are getting better or you can install CYGWIN, a 3rd party Open Source shell environment for Windows. It's also interesting to see that Microsoft after all these years seems to be tipping it's hand to more Unix/Linux tools and collaborations. There is even rumour of a proper shell running tcsh and bash in the next release but we'll see... As for what type of shell to use, there are quite a few with the two most common in the CG industry being csh / tcsh (SGI roots showing) or bash which is the Linux default shell. There are those old school users that still cling to csh or tcsh but I made the switch over to bash shells way back when Houdini was ported to linux. I believe most Houdini users have moved over to bash as well. New shell adopters gravitate toward bash. Why fight the default. Hope this helps.