Jump to content


Popular Content

Showing most liked content since 02/18/2018 in all areas

  1. 20 points
  2. 9 points
    A small summary from the Houdini -Carbon Workflow for the german Movie Project "Die kleine Hexe". Hope You like it
  3. 7 points
    I put together a simple script to read the .mtl file, typically associated with a .obj, and create a Redshift material for each entry it finds in the .mtl with a map_Kd token. A Redshift material is created and a texture map is linked to the diffuse color with the filename for the map populated with what is found in the .mtl entry. This is useful when importing architectural .obj files that typically have a large number of materials associated with them. Expected .mtl format of supported tokens. #newmtl _4_2_ <- Material name. #Ns 96.078431 <- Specular intensity #Kd 0.640000 0.640000 0.640000 <- Diffuse color. #Ks 0.500000 0.500000 0.500000 <- Specular color. #Ni 1.000000 <- Index of refraction. #d 1.000000 <- Opacity. #map_Kd 21_budova/_4_2_.jpg <- Map name. The result of one-click texture mapping. Here is the Colosseum auto texture mapped. The path to the .mtl file and texture path is hard coded. Place the code in a shelf tool button and adjust the path to point to your .mtl file. mtl_to_redshift_022418.zip
  4. 6 points
    Hello, most of the .hip from my video #7 are here. enjoy note : thank you particuleskull, your hip (from november in this thread) helps me a lot for my grain rnd ! elephant grain.hiplc grain for each voronoi pieces-v3.hiplc grain-tree.hiplc paint brush-v2+.hiplc sticky projection.hiplc
  5. 5 points
    Hey all We've noticed an increase of people posting HDA's and other general tools in random forums around the site. To help everyone we thought it would be beneficial to open a forum dedicated to the sharing of these so they can live in one place and be browesable: http://forums.odforce.net/forum/71-tools-hdas-etc/ Let us know what you think. There is also the option of opening up a commercial tool repository where you can sell HDA's, tutorials etc. Let us know if this is something that you'd like to see. Thanks Marc
  6. 5 points
    Here is some method: fit_circles_to_curves.v4.hipnc
  7. 4 points
    New Houdini tip: Using HOU module in Visual Studio Code. https://jurajtomori.wordpress.com/2018/02/20/houdini-tip-using-hou-module-in-visual-studio-code
  8. 3 points
    I know this is a bit late, but I missed this thread and felt like I should comment. Firstly, this topic amuses me since I think I could count on two hands (maybe some toes) the amount of times we've had to lock threads in the 20 years this site has been running. So the assertion that we're trigger happy thread lockers is a bit of a stretch. Now it may be that some of the very small number of locked threads belonged to some people in this thread, and if that's true then I would suggest taking a look at your online etiquette and perhaps adjusting a few things. You should note that we have very few rules governing each forum, where most other forums on the internet have a laundry list of do's and don'ts for posting. The reason for that is that we have an amazing community of professionals who actually like to help each other produce great work. Healthy debates are certainly welcome, but personal attacks are not. tl;dr: If the topic descends to the equivalent of "no, you!", "heck you!" etc, then it is looked at as a lockable entity. Don't want that to happen? Don't behave that way. M
  9. 3 points
    Hi Matt, thanks very much, I haven't seen your answer, sorry, it was months ago haha, at the end I used a different approach, something that wikipedia calls harmonic damped oscillation, or something like that, basically is F = -KX -CV, I used that formula to drive the position of the rbds to the goal position. Also used a modified version of that formula to make an orientation follow, the result of that research are this two videos. Thanks very much for your answer by the way.
  10. 3 points
    Hi It's already far from my first attempt to simulate wind and realistic movement in Houdini. Since it's f addictive and so hard to stop playing with tons of variations, noises, mixes and stuff. Just wanted to share with you guys where I'm going to make some point, and get your honest opinion. Still a wip tho.
  11. 2 points
  12. 2 points
    Ok, what about something like this... Place this code in the Pre-Frame Script field of the rop_geometry1 node. Remember to switch code processing from the default of Hscript to Python. It basically scans the input folder on every frame change and uses the frame number as an index into the retrieved list. It re-writes the file1 input path and the rop_geometry1 output path to match the current file being processed. The results are stored in a folder named results, so you will have to manually create that. Quite a bit of hard coding, but it does seem to work. Just don't rename nodes and populate the input and output paths to match your folders. USAGE: Click Render on the rop_geometry1 node. # Process a series of .OBJ files. import os input_path = r"F:\Keep\Models\Rocks" output_path = r"F:\Keep\Models\Rocks\result" def returnFilesLike(passedFolderName, passedFileExtension = ".obj"): result = [] for file in os.listdir(passedFolderName): if file.endswith(passedFileExtension): result.append(os.path.join(passedFolderName,file)) return result lst_files = returnFilesLike(input_path, ".obj") l = len(lst_files) if (l>0): frame = hou.intFrame() if frame <= l: # Frame is within range of object count in this folder. file_source = os.path.split(lst_files[frame])[1] file_node = hou.node("/obj/geo1/file1") file_node.parm("file").set(lst_files[frame]) file_dest = os.path.join(output_path,file_source) rop_node = hou.node("/obj/geo1/rop_geometry1") rop_node.parm("sopoutput").set(file_dest) ap_re_process_folder_of_OBJs.hiplc
  13. 2 points
    how about this: -resample the curves to have equal amount of points. - measure the distance between the points with the same point number, this will give you the diameter for each circle. - you can now place a point using the radius and instance a circle onto this point.
  14. 2 points
    Like this? rot_constraint.hipnc
  15. 2 points
    Vertex colors will work in Maya from Houdini if: the attribute is vector3 RGB (it's possible this could work with vector4, haven't tried it) it's a vertex attribute it has the attribute type "color" (use the VEX command setattribtypeinfo() to set the type to "color" if it isn't already) Here's a sample file, this displays with vertex colors in Maya as expected: meshed_pyro_vtx_color.hip
  16. 2 points
    10+ HOURS HOUDINI TUTORIAL IS DONE LINK COMING SOON It is a paid Tutorial, and I will put the link once its all ready to download 10+ Years of Industry Experience 18+ Years of DCC Apllication Experience Currently Employed as a Lead FX at a VFX Company https://www.timucinozger.com/
  17. 2 points
    Probably have a look at the modulo and sprintf functions/vops modulo is useful for looping time like: $F % 3 give you 1, 2, 3, 1, 2, 3, 1, 2, 3.... instead of the straight count. So in vex just do @Frame%3 or in vop there is a modulo node. sprintf allows for string formatting kind of C style: sprintf('%04d', @Frame) is like padzero(4, $F) expression. In vop there's the print node that allows similar string formatting.
  18. 2 points
    In the Operator Type Properties → Scripts tab select "On Created" event handler, change "Edit as" to Python. Here is basic code: node = kwargs['node'] node.setName('some_special_name') For default operators you need to make a shelf tool and create node and change it's name manually in the tool script. Custom assets also use tool script. In Operator Type Properties → Tools tab and the tool script looking like this: import soptoolutils soptoolutils.genericTool(kwargs, '$HDA_NAME') The function call at the last line returns fully created node instance. After On Created event was executed. You can use it too: import soptoolutils node = soptoolutils.genericTool(kwargs, '$HDA_NAME') node.setName('some_special_name') It's more logical to use On Created, but sometimes it doesn't work. For example, if I remember correctly, you can't set node position in it, it will be overridden.
  19. 2 points
    Maybe Pyro_smoke_localised_drag_v01.hip
  20. 2 points
    So now I've wrapped this up into a subnetwork. Sharing it here as well as my random group expand, in case anyone cares. GroupMod_mk_v001.hipnc
  21. 2 points
    I can't see any benefit to the Houdini community at large in allowing slapfights between users to continue unmoderated. On-topic disagreements are one thing, but when people start getting heated and making things personal it doesn't do anyone any favors. This is a Houdini user's forum, not Facebook.
  22. 2 points
    Basic smoke solver built within SOP solver, utilising openVDB nodes. Happy exploring & expanding =) P.S. DOP’s smoke solver still solves quicker in many cases though. vdbsmokesolver_v1.hipnc
  23. 2 points
    Methods to Stir Up the Leading Velocity Pressure Front We need to disturb that leading velocity pressure front to start the swirls and eddies prior to the fireball. That and have a noisy interesting emitter. Interesting Emitters and Environments I don't think that a perfect sphere exploding in to a perfect vacuum with no wind or other disturbance exists, except in software. Some things to try are to pump in some wind like swirls in to the container to add some large forces to shape the sim later on as it rises. The source by default already has noise on it by design. This does help break down the effect but the Explosion and fireball presets have so much divergence that very quickly it turns in to a glowing smooth ball. But it doesn't hurt. It certainly does control the direction of the explosion. Directly Affecting the Pressure Front - Add Colliders with Particles One clever way is to surround the exploding object with colliders. Points set large enough to force the leading velocity field to wind through and cause the nice swirls. There are several clever ways to proceduralize this. The easiest way is with the Fluid Source SOP and manipulate the Edge Location and Out Feather Length and then scatter points in there then run the Collide With tool on the points. Using colliders to cut up the velocity over the first few frames can work quite well. This will try to kick the leading pressure velocity wave about and hopefully cause nice swirling and eddies as the explosion blows through the colliders. I've seen presentations where smoke dust walls flowing along the ground through invisible tube colliders just to encourage the swirling of the smoke. You can also advect points through the leading velocity field and use these as vorticles to swirl the velocity about. The one nice thing about using geometry to shape and control the look, as you increase the resolution of the sim, it has a tendency to keep it's look in tact, at least the bulk motion. As an aside, you could add the collision field to the resize container list (density and vel) to make sure the colliders are always there if it makes sense to do so. Colliders work well when you have vortex confinement enabled. You can use this but confinement has a tendency to shred the sim as it progresses. You can keyframe confinement and boost it over the first few frames to try and get some swirls and eddies to form. Pile On The Turbulence Another attempt to add a lot of character to that initial velocity front is to add heaping loads of turbulence to counter the effect of the disturbance field. You can add as many Gas Turbulence DOPs to the velocity shaping input of the Pyro Solver to do the job. Usually the built-in turbulence is set up to give you nice behaviour as the fireball progresses. Add another net new one and set it up to only affect the velocity for those first few frames. Manufacturing the turbulence in this case. In essence no different than using collision geometry except that it doesn't have the regulating effect that geometry has in controlling the look of the explosion, fireball or flames, or smoke. As with the shredding, turbulence has it's own visualization field so you can see where it is being applied. Again the problem is that you need a control field or the resize container will go to full size but if it works, great. Or use both colliders and turbulence pumped in for the first few frames and resize on the colliders. Up to you. But you could provide some initial geometry in /obj and resize on that object if you need to. Hope this helps...
  24. 2 points
    Temperature Field and Divergence Field and what to do about it Combed straight velocities lead to mushroom puffs. Large directional forces lead to combed straight velocities. The pressure wave leading the divergence field leads to combed straight velocities. So what to do? Looking at Temperature first, it is directly used with Gas Buoyancy to drive the intensity whereby the upward direction is multiplied by temperature and then added to vel. Temperature is also used to burn fuel at an ever increasing rate with higher temperatures which then ultimately affects the divergence field. Temperature is also used by some of the shaping tools to inject noise or trigger confinement within the simulation, amongst other fields. Temperature and Gas Buoyancy DOP High temperature values fed in to the Gas Buoyancy DOP will affect the velocity field quite effectively, in a singular direction no less, the buoyancy direction. This inherently leads to nicely combed velocity with higher temperature values and large amounts of buoyancy as the simulation evolves which leads to nice mushrooms leading the way. Just like in real explosions and initial bursts of hot smoke/steam. But the director always wants more "character". That's fine and manageable in most cases as the velocities aren't that large, especially in smoke simulations where the temperature is driven by the sources. In the case of explosions, the burning of fuel can create very high temperatures and cause large upward velocities. Working Temperature with Disturbance By default the Disturbance field affects temperature. It is also cited as one way to break up or diminish the mushrooms. But how and why? And does it work? Using disturbance is designed to add noise to the temperature field around the simulation. This is one way to try to kick or disturb the rising velocity field, in an indirect way though. For Pyro, temperature is used to ultimately affect vel in two ways: Buoyancy and Combustion (which inevitably drives the divergence field). What is Divergence? Well it's randomly generated noise. It's not time coherent turbulence. Yep. If you dive down in to the Gas Disturbance DOP, in to the disturb_field Gas Field VOP you will find a lowly random VOP that is fed a vector 4 (vector P and an animated offset) and generates random incoherent noise per substep. If this sounds desperate, well it kinda is. But it works very well in some cases to etch the leading edge of the velocity to cause eddies that then form ripples and swirls. Think volcano smoke. Disturbance can be applied to temperature and it will eventually have an effect, or you can have it work directly on the velocity for a brute force immediate effect to try to etch away at that leading velocity front generated by the rapidly expanding divergence field. if it is strong enough and if it is localized to just around the evolving sim so that our container doesn't resize to maximum and take too much memory and take too long to simulate, it can work very well. Perhaps this is why the shelf tools only allows for a small value relative to the velocities that are present in an explosion or fireball: it doesn't really work for these types of sims at it's defaults. We have all of the necessary tools to implement this well enough. The Gas Disturbance DOP built in to the Pyro Solver and exposed as the Disturbance parameters can do this. It has support for a control field and even a ramp with min and max threshold values to really dial this in, if you have a field to use that is... For Smoke and combustion fire type simulations (no explosions), you can gleefully use the density field as both your Threshold Field to control the cut-off threshold for the disturbance and as the field to control the amount of disturbance you want. Or use temperature as the Control Field as with rising smoke, the temperature tends to lead the density. For fast rising smoke, you can set the Control Field to temperature and then use the Control Range to say 0 and 0.1 to try to etch the velocity field prior to it being run over by the advancing wave. For Explosions, there is feint hope. Unless you envelop the entire container with shredded velocity, there is no other field at your disposal to use to control where the disturbance should be applied. Yes you can create an additional field containing an expanded divergence field to try this, but there's better ways to coax swirls in the initial part of the explosion. In the end, as with all the other shaping tools, it comes down to magnitude. If the magnitude of the previous frame's velocity is much larger than the velocity shaping amplitude, knowing that velocities are for the most part added or subtracted in most simulation engines, you aren't going to see much effect, especially after the Non-Divergent step gets rid of most of this random pressure hash anyway. When you are dialling in a sim, you have to have the vel on for display and adjust the Visualization Range (working the leading red envelope) to get an idea as to where the velocity is fastest and what those values are (in Houdini units per second). If you have a velocity of 10 in the leading velocity pressure front and you set disturbance amplitude to 0.5, you know it won't have much of an effect. One thing that will have an effect is to apply Disturbance directly to vel for explosions and apply it within the divergence, burn, temperature or any other field that's playing a role in the fireball itself. But not to the surrounding area unless again you bypass the resizing of the container. Heck you don't even need to bypass the resize container DOP. If you are resizing on density and vel, the container will max out after the second or third frame anyway. And you can live with completely incoherent noise that for the most part is wiped out by the Non-Divergent counter pressure field. Divergence and Burning Fuel The divergence field in explosions and fireballs is the main contributor to mushroom caps over the first second or so. It will comb the velocity vectors perfectly straight in the leading pressure wave advancing in front of the density, temperature, fuel, whatever. We know why. It's the Non-Divergent step trying to remove any pressure across the timestep outside of the divergence field. It makes perfect sense then that when carefully inspecting the velocity around the leading edge of the divergence, you will find the greatest velocities. Divergence pushing outward creating a large pressure front causing the Non-Divergent step to add a very large counter pressure field that gives you that front of straight combed velocity. Large amounts of burning fuel (fuel + temperature = burn, divergence (gas expansion) then uses burn and fuel to drive the expansion of the sim) leads to a strong divergence field. Gas Buoyancy affects vel very effectively and divergence allows for rapid expansion. How do the explosion and fireball shelf tools try to avoid mushrooms? Well we see that the timescale is reduced for both options in an attempt to add enough time to evolve interesting swirls in the simulation as it evolves. But for many cases doesn't give you that nice character over the first few frames of the simulation. We also see Disturbance added but at a meagre 0.75 Shredding is set to 1. Shredding is a very nice tool for adding character to fire. As it's name implies, within the threshold tolerance of the effect, the velocity field is either stretched along a gradient direction or compressed. It is the transition between the two that gives you the real nice licks of fire. Shredding defaults to 1 and it has visualization option to see where this shredding occurs and how strong it is by it's color in relation to the velocity. If you look at the shredding, by default it is being applied along the surface of the temperature field where the Threshold Width is being set. Again this won't work for the first second of the explosion. Same for Turbulence and Confinement. They too work within the fireball and not the leading edge of the explosion. so what to do?
  25. 2 points
    Coarse Sub-Steps If you have an expanding gas field front that from frame 1 to 2 or frame 2 to 3 travels one or two Houdini units and substeps are set to 1, you will get combed straight velocity vectors which means mushroom caps. No matter how much turbulence or confinement you set on your Pyro Solver DOP, there simply isn't enough time to evolve these fields and have an effect on the result. More substeps means smaller velocities to deal with between substeps making things more manageable too. In an attempt to keep substeps at 1, you can manufacture noise and pump that in to vel but in the end two things will happen: The Non-Divergent step will take your noise and negate most of it, or you end up pumping in so much noise because it isn't working with smaller values you tried earlier, that it swamps the entire effect and it looks like a fractal hash and not that nice evolving fireball. Oh and if you really pump in tons of noise in to vel, it too can create many smaller velocity fronts pushing ahead and you end up with smaller mushroom caps! Doh... This is in essence what the Gas Disturbance DOP does. The Pyro Solver has a Gas Disturbance DOP in it's logic and those parameters are promoted up to the top asset interface but we're concerned about substeps right now and allowing enough time for turbulence and confinement to create the nice swirls on the leading edge of the explosion. So it's coming down to sub steps to try and allow for a lot more character around the leading pressure front for fast evolving explosion type simulations. Two ways to go about this: Brute force increase the global substeps for the entire DOP network, or use the Pyro Solver Substeps in the Advanced tab. Brute Force Global Substeps For explosions, the huge almost instantaneous velocities happen at the first 5-10 frames. It would be nice to keyframe animate the Sub Steps parameter, but you can't (DOPs is that way). If you set the global sub-steps to get enough detail in the first few frames you have to carry those sub-steps through the rest of the sim when things are moving a lot slower and those substeps are no longer required. Not that great. No wonder everyone tries to inject their own pumps to affect vel to avoid global substepping. Pyro Solver Substeps The Pyro Solver exposes minimum and maximum substepping logic to control when and how the Pyro Solver will substep. This sounds interesting and could be just what we need. But what is CFL Condition? No it isn't the Canadian Football League even though we know that 3 downs rule and 4 downs are for those that can't deal 3. It's named after a couple guys who in the '20's, that's 1920's, who were trying to figure out the frequency of data samples they required in order to map and predict fluid simulations and pressures/resistance to flow with fast moving collision objects (that be ships). The help note on the actual Gas SubStep DOP explains it quite well: timestep will be reduced if the velocity field will move only 1 voxel in a timestep. A CFL of 2 will allow it to move 2 voxels in a timestep. Or something like that. You can find it on wikipedia. You can set your minimum substeps to 1 and your maximum substeps to a high enough value such that if the CFL Condition is exceeded, more substeps will occur when the simulation has large velocities and less when the velocity is smaller. Hopefully this gives enough time to let the turbulence and other methods to stir up the vel field kick in. Keyframe Timescale There is a third option to controlling sub steps but that is to keyframe animate the Timescale. Yes more than valid to do this to slow down the sim at the start and then speed up when the huge velocities subside. As a matter of fact, the shelf tools set Timescale to 0.65 as an attempt to get a good looking explosion or fireball without having to resort to substeps. But this is not an automatic method. This requires intervention if you want to animate the timescale. This means you have to run the sim and evaluate. Then you keyframe the timescale and you end up with an entirely different simulation. Then you move your keys, run again. Then you increase the resolution of the simulation and everything changes again. In many ways, it's worth to at least give the min and max substeps a go and see if you can dial in the CFL Condition to get a happy balance. As you increase the resolution of the simulation, the CFL condition measured in voxels will allow substeps to run up a bit faster to the max without too much of a change in the final result.
  26. 2 points
    Project Non-Divergent Step and Mushrooms The Project Non-Divergent DOP is responsible for 99.9% of the simulation's behaviour. Yes hundreds of DOPs inside the Pyro Solver all playing a part but all funnelling through that single Non-Divergent step. This means that if you don't like the look of your sim and the mushrooms, it's ultimately because of the Non-Divergent step creating a vel field that doesn't do it for you. If you want to see for yourself, unlock the Pyro Solver, dive in, find the Smoke Solver, unlock that, dive in and find the projectmultigrid DOP and bypass it, then play. Nothing. For most all Pyro sims, this is the Project Non-Divergent Multigrid as it is the fastest of the Non-Divergent micro-solvers. This specific implementation only takes the vel and divergence field and assuming across the timestep that the gas is non-compressible when divergence is 0, will create a counter field called Pressure and then apply that pressure field to the incoming vel to remove any compression or expansion and that gives you your velocity, nice turbulent and swirly, or combed straight out. Just tab-add a Project Non-Divergent Multigrid DOP in any dop network and look at the fields: Velocity Field, Goal Divergence Field and Pressure Field (generated every timestep, used, then removed later on). All the other fields in Pyro are there to affect vel and divergence. Period. Nothing else. At this point I don't care about rendering and the additional fields you can use there. It's about vel and divergence used to advect those fields in to interesting shapes, or mushrooms. If you want to create your own Pyro Solver taking in say previous and new vel, density, temperature, and then in a single Gas Field VOP network, create an interesting vel and divergence field, then pass that straight on to the Project Non-Divergent Multigrid microsolver, then advect density, temperature and divergence afterward, go for it. Knowing that only vel and divergence drive the simulation is very important. All the other fields are there to alter the vel and divergence field. So if you have vel vectors that are combed straight, divergence (combustion model in Pyro) or buoyancy (Gas Buoyancy DOP on temperature driving vel) have a lot to do with it. Or a fast moving object affecting vel...
  27. 2 points
    I've wanted to tackle mushroom caps in pyro sims for a while. Might as well start here... Three things that contribute greatly to the mushroom caps: coarse sub-steps, temperature field and divergence field. All of these together will comb your velocity field pretty much straight out and up. Turning on the velocity visualization trails will show this very clearly. If you see vel combed straight out, you are guaranteed to get mushrooms in that area. If you are visualizing the velocity, best to adjust the visualization range by going forward a couple frames and adjusting the max value until you barely see red. That's your approximate max velocity value. Off the shelf pyro explosion on a hollow fuel source sphere at frame 6 will be about 16 Houdini units per second and the max velocity coincides with the leading edge of the divergence filed (if you turn it on for display, you'll see that). So Divergence is driving the expansion, which in turn pushes the velocity field and forms a pressure front ahead of the explosion because of the Project Non-Divergent step that assumes the gas is incompressible across the timestep, that is where where divergence is 0. I'm going to get the resize field thingy out of the way first as that is minor to the issue but necessary to understand. Resizing Fields Yes, if you have a huge explosion with massive velocities driven by a rapidly expanding divergence field, you could have velocities of 40 Houdini units per second or higher! Turning off the Gas Resize will force the entire container to evaluate which is slow but may be necessary in some rare cases, but I don't buy that. What you can do is, while watching your vel and divergence fields in the viewport, adjust the Padding parameter in the Bounds field high enough to keep ahead of the velocity front as that is where you hope for some nice disturbance, turbulence and confinement to stir around the leading edge of the explosion. or... Use several fields to help drive the resizing of the containers. Repeat: Use multiple fields to control the resizing of your sim containers. Yep, even though it says "Reference Field" and the docs say "Fluid field..", you can list as many fields in this parameter field that you want to help in the resizing. In case you didn't know. Diving in to the Resize Container DOP, there is a SOP Solver that contains the resizing logic that constructs a temporary field called "ResizeField", importing the fields (by expanded string name from the simulation object which is why vector fields work) with a ForEach SOP, each field in turn, then does a volume bound with the Volume Bounds SOP on all the fields together using the Field Cutoff parameter. Yes there is a bit of an overhead in evaluating these fields for resizing, but it is minor compared to having no resizing at all, at least for the first few frames where all the action and sub-stepping needs to happen. Default is density and why not, it's good for slower moving sims. Try using density and vel: "density vel". You need both as density will ensure that the container will at least bound your sources when they are added. Then vel will very quickly take over the resizing logic as it expands far more rapidly than any other field in the sim. Then use the Field Cutoff parameter to control the extent of the container. The default here is 0.005. This works for density as this field is really a glorified mask: either 0 or 1 and not often above 1. Once you bring the velocity field in to the mix, you need to adjust the Field Cutoff. Now that you have vel defined along side density, this Field Cutoff reads as 0.005 Houdini units per second wrt the vel field. Adjust Field Cutoff to suit. Start out at 0.01 and then go up or down. Larger values give you smaller, tighter containers. Lower values give you larger padding around the action. All depends on your sim, scale and velocities present. Just beware that if you start juicing the ambient shredding velocity with no Control Field (defaults to temperature with it's own threshold parameter so leave there) to values above the Field Cutoff threshold, your container will zip to full size and if you have Max Bounds off, you will promptly fill up your memory and after a few minutes of swapping death, Houdini will run out of memory and terminate. Just one of the things to keep in mind if you use vel as a resizing field. Not that I've personally done that... The Resolution Scale is useful to save on memory for very large simulations, which means you will be adjusting this for large simulations. The Gas Resize Field DOP creates a temporary field called ResizeBounds and the resolution scale sets this containers resolution compared to the reference fields. Remember from above that this parameter is driving the Volume Bound SOP's Bounding Value. Coarser values leads to blurred edges but that is usually a good thing here. Hope that clears things up with the container resizing thing. Try other fields for sims if they make sense but remember there is an overhead to process. For Pyro explosions, density and vel work ok. For combustion sims like fire, try density and temperature where buoyancy contributes a lot to the motion.
  28. 1 point
    hey thanks for update. I picked it up/purchased so I can see how it is done.
  29. 1 point
    I don't think Houdini 16.5 supports multiple GPUs for OpenCL yet. In your houdini.env file you can specify which one to use. HOUDINI_OCL_DEVICENUMBER = 0 {or 1 to default to your 2nd GPU} Use Goggle search instead of this website search for more results on the topic.
  30. 1 point
    That option is new in 16.5 though, he might not be using it.
  31. 1 point
    I would like to see some Mograph type tools. I know Rohan Dalvi created some, still it would be nice to have them native inside Houdini
  32. 1 point
    I just simmed your scene out past 800 frames on my 32Gb machine. Can you put your machine specs in your signature?
  33. 1 point
    I wish the Font object displayed what the actual fonts look like in the drop down list. Or give me some up/down arrow to quickly move through the list. It is such a pain when looking for fonts. I end up using another app just for that task.
  34. 1 point
    You can use the vdb to spheres technique to get around the concave bullet problem. It works quite well. https://i.imgur.com/HBIF1l1.gifv
  35. 1 point
    Yeap haha I did an example. Have a look at the file, it works pretty fine with the convex collision shape RBD Boolean Fracture.hiplc
  36. 1 point
    it was basic, i used a sop solver to import and I used the particles velocity as my vel using a gasparticletofluid
  37. 1 point
    Now to deforming/animated object...pure RBD here... Wiper.hipnc
  38. 1 point
    Houdini Digital Asset to visualize arrays of matrices attributes. https://www.orbolt.com/asset/prb::MatrixDisplay::1.0 Cheers
  39. 1 point
    ver 1.04. This is the JUST WORKS version. Super stable, no fuzzy logic that doesn't work...no flickering...no mangled up connections, even allows to connect every Nth...not just every 2nd block Vu_InterlockMobius_04.hipnc
  40. 1 point
    Thanks... yes hit myself when I discovered my mistake! A little more tricky I cannot figure out how to change the rotation of the scattered objects (within a random range) while still keeping them perpendicular to the surface tile_perpendicular_random_rotation.hiplc
  41. 1 point
    After few test I have enough deformation effect for my project and now have next problem with shader now. You can check in atachment screens of bubbles layer and volume layer + hip file with tests. I would like to achieve this kind of foam like this little monster in this ad: YOUTUBE FOAM Do you have any idea guys how to create this kind of foam? I have geometry on which I'm usuing a little smoke shader + scatter with spheres with glass material but still so far away of this look. foam_09_shade.hipnc
  42. 1 point
    string ftoa(float in){ return sprintf("%g", in); } s@str = ftoa(f@a);
  43. 1 point
    Oh, and I created this thread specifically to try to sort this out once and for all, how particles groups/streams are handled by the solver. Doing a setup like that just can't be that hard, at least if you know how.
  44. 1 point
    Yupp, LOL, because your assumption is one I have made myself and it ended up biting me in the ass - and I'm talking saltwater crocodile biting, not som Pug nibbling. But you know what, just because of this I'm gonna start a specific thread about doing recursive splitting using groups/streams inside a single POP. Time to take this sh!t to the next level. The TP level. As for not being good enough with Houdini, unless you are one of the developers, not sure anyone is - or that it's really possible, even... :D
  45. 1 point
    Hello Odforce! hip attached of the first version of the " VEX sphere slices geo generator " (i am still thinking about the proper fancy name ) Please tell me what you think about it, do you think some important features are missing? To take it a step further i will need some help. QUESTION 0 ORDERED MENU IN VEX I want to be able to switch among different rotation type. float spin_rnd = ...; float spin_trig = ...; float spin_reg = ...; string spin_type = chs("spin_type"); //ordered menu with names corresponding to the different types of rotation float w = amp*spin_type; // this gives me an error : call to undefined binary operator `float = float*string` how do i make him interpret that spin_type string as the float variable? QUESTION 1 RESOLUTION I'd like the resolution of the segments to be proportional/based on their size. When using many rings (say 100) the inner ones don't need the same res of the outers. this would be a nice optimization of the asset when generating a high number of rings. currently the generation of the segments is "angle based", (theta+theta_step) what i am thinking is to convert the logic to "arc based"... i tried this but doesn't work as aspected //proportional resolution if(theta_step*r_max < ch("test_theta_step")){ res_lon -=1; theta_step = (end_theta - start_theta) / (res_lon - 1); } QUESTION 2 the code runs once over detail. why can't I use @Frame? isn't it a global variable? (right now i'm channel referencing to a $FF for animations) QUESTION 2bis is there a way to export attributes even if we run on detail? i think would be cool to have ring_id down the line. createVEX_v02.hip VEXgeo_creation - v001.wmv
  46. 1 point
    There was an error in pop_too_close wrangle. It deleted both intersecting bubbles, not just the smaller one, drastically reducing bubblecount. Normally it should remove only degenerate bubbles almost enclosed by neighbours. It also seems that whole loop can be replaced with a point wrangle. So, it cooks instantly now, retains topology and scales better. Scattering and pscale setup really matters. You need to generate a good foam first, before doing intersections. The current setup should be improved somehow. bubbles2.hipnc
  47. 1 point
    There's a couple of ways of doing this but the basic method is using the fracture parameters node in DOPs, that's what you get set up automagically when you use the "make breakable" shelf tool on a RBD object. Though this is one of the areas in Houdini where I miss Thinking Particles, the methodology built into that workflow is just amazing for doing recursive setups - you basically shuffle stuff between groups and set rules for that group, so something in a group can fracture, then you can shuffle the fragments into another group or have part of it go back into the fracture group, etc. and it's just such a brilliant workflow for doing stuff like refracturing. Here's an example out done by Allan McKay... And here's Allan talking about the shot, setups, lookdev, etc...
  48. 1 point
    Turn on Reap Particles found on Flipsolver > Particle Motion > Behavior tab
  49. 1 point
    quick example of particles being released upon collision ts_particle_release_on_collision.hip
  50. 1 point
    So this is probably too late for the OP, but here a solution I slapped together that doesn't require calling the "bones from curve" tool. Hope it helps someone. #Bones From Multiple Curves Tool - By 90ender ''' Given a node containing more than one curve, the tool loops over each creating a bone chain that matches it's curvature and position. The tool is still in development and currently does not take user input. ''' #create a normal given two points def normalFromPoints(pfrom = hou.Vector3(3,2,1), pto = hou.Vector3(10,5,2)): x = pto[0] - pfrom[0] y = pto[1] - pfrom[1] z = pto[2] - pfrom[2] return hou.Vector3(x,y,z) # convert a normal to a euler rotation def normalToEuler(nto = hou.Vector3(1,1,0), nfrom = hou.Vector3(0,1,0)): a = nto.normalized() b = nfrom.normalized() matrix = b.matrixToRotateTo(a) euler = matrix.extractRotates('srt','xyz',hou.Vector3(0,0,0)) return euler def buildBone(parent = None, pos = hou.Vector3(0,0,0), rot = hou.Vector3(0,0,0), len = 1.0, name = "chain_bone1", container = None): if container == None: container = hou.node("obj") bone = container.createNode("bone", name) bone.parm("length").set(len) bone.parmTuple("t").set(pos) rot[2] = 0.0 bone.parmTuple("r").set(rot) if parent != None: bone.parm("keeppos").set(1) bone.setFirstInput(parent) bone.parm("keeppos").set(0) bone.moveParmTransformIntoPreTransform() return bone def buildRoot(name = "chain_root", container = None, parent = None): if container == None: container = hou.node("obj") root = container.createNode("null", name) root.parm("keeppos").set(1) root.parm("use_dcolor").set(0) root.parm("geoscale").set(0.5) root.parm("controltype").set(1) root.parm("shadedmode").set(1) if parent != None: root.setFirstInput(parent) return root #build chain of n bones along curve #POSSIBLE TO DO: if curve has length attrib then add bones based on length. def bonesFromCurve(curve = None, segments = 5, container = None): #initialize curve position and variables div = 1.0 / segments u = 0 v = 0 apos = curve.positionAtInterior(u,v) boneDir = hou.Vector3(0,0,-1) #get names rootName = "root1" boneName = "curve_bone1" if curve.geometry().findPrimAttrib("name") != None: name = curve.stringAttribValue("name") rootName = name + "_root1" boneName = name + "_bone1" #build root root = buildRoot(rootName, container) chainpos = root.moveToGoodPosition() parent = root bonesLst = [root] for x in range(0, segments): #get bone start and end positions on curve u += div bpos = curve.positionAtInterior(u,v) len = apos.distanceTo(bpos) #Calculate bone rotation along curve from up vector n = normalFromPoints(apos, bpos) rot = normalToEuler(n, boneDir) #create bones here and orient and parent them bone = buildBone(parent, apos, rot, len, boneName, container) bone.moveToGoodPosition() parent = bone bonesLst.append(bone) #set next position apos = bpos #need to return a bone or list of bones return bonesLst #TO DO: Find out how to put parameters into operation controls toolbar #main() selected = hou.selectedNodes() if len(selected) < 1: hou.ui.displayMessage("No Nodes Selected") else: #get curves from node child = selected[0].displayNode() curves = child.geometry().prims() #TO DO: check if geo is curve #TO DO: User input here. Check if zero input = 10 #create subnet container subnet = hou.node("obj").createNode("subnet", "tree_rig1") subnet.moveToGoodPosition() geoInSubnet = [] #iterate over curves for i in curves: bonesLst = bonesFromCurve(i, input, subnet) #we may need another parm for chain parents print "done!\n"