Leaderboard

Last week a guy asked in the brazilian houdini group, in facebook, how to simulate colored smoke. I believe there are lots of hip files with this kind of effect, but while thinking about it, it came to my mind the possibility of using CMYK instead of RGB, since cmyk is more suitable for mixing colored things other than light. I couldn´t spend more time testing it or improving the file, but it seems to work, so here´s the hip file. colored_smoke_V002.hip

Now Im guessing you can post this. All the presentations from Siggraph are available! https://vimeo.com/goprocedural and talking about H17

I have been exploring how constraints work and I have put together a basic RBD car rig. The vehicle/car rig supports front and rear wheel drive, a spring suspension, motor speed, adjustable wheel size with front and rear axle offsets and a switchable front/back engine block mass. Dive inside and look for the node named Controls to play with the various settings. I have a 1st draft attempt at steering, but it does not really work yet. If anyone has any ideas on how to link steering to the constraints I'd love to see them. Thanks to Richard Lord and Julian Johnson for posting their constraint systems and Matt Estela's CGWiki . Dissecting their work helped me build this rig. ap_basic_vehicle_090318.hiplc

Hey You could create a lens shader (http://mattebb.com/blog/weblog/houdini-fisheye-camera/) or then model your custom lens as an object. Here's a scene showing a sphere with a refracting material and soft edges acting as a mysterious ray bender. distortion_field.hip

Hi, Quick setup attached to illustrate the idea. Give it a go. fastGas.hipnc Cheers!

During the last 3 weeks, a did some Rnd and published my results on vimeo . Some people asked me to share my files here, so here we are i hope it will help!

I have had this issue before when working with flip and collisions. I find this often happens when your collision is animated. So a potential work around that has worked for me before, would be to freeze your collision geometry, and bring it in as a static object in your sim, and then add the transform data back onto the static collider with a motion node in your sim referencing the translate and rotation data from your animated geo in sops. This way you should be able to avoid substeps.

It would be great if I could select nodes with lasso selection

no loops necessary and you should try to avoid them if you can also first point of the primitive doesn't guarantee that it's at the start or at the end or even that the primitive has any start or end if it's closed, so you are better off using points belonging to first or last vertex and either checking if the prim is closed or using the neighbourcount() test so to detect all you can combine first test with test whether point belongs to the first or the last vertex of the primitive int pts[] = primpoints(0, @primnum); int isend = neighbourcount(0, @ptnum) == 1; int isfirst = @ptnum == pts[0]; int islast = @ptnum == pts[-1]; i@group_ends = isend; i@group_start = isend && isfirst; i@group_end = isend && islast; OR mentioned open/closed poly test int pts[] = primpoints(0, @primnum); int isopen = !primintrinsic(0, "closed", @primnum); int isfirst = @ptnum == pts[0]; int islast = @ptnum == pts[-1]; i@group_ends = isopen && (isfirst || islast); i@group_start = isopen && isfirst; i@group_end = isopen && islast;

A setup that finds the maximum pscale points can have, so the resulting spheres don't intersect. Scene at: https://jmp.sh/hEctEky

yes please! C4D has a similar system but this looks even better!

Hi Folks ! For Houdini optimization nerds I'd like to share "Houdini easy compile blocks". It's a simple script which creates for you the compile blocks + update the expressions to use spare inputs ( if needed ) around a for loop or a selection of nodes. Compiling a for-loop is now one click away Available for free here: http://cgtoolbox.com/houdini-easy-compile-block/. If you have issues with a loop compilation, feel free to send a small hip file if possible, to support@cgtoolbox.com, with the nodes you're trying to compile and I'll have a look ! https://vimeo.com/287152763

Not sure what is the workflow you are after. Cache files are there to avoid computation on heavy graphs. As hip scene files are tiny usually compared to the size of cached data it's not a problem to save unique (locked) source scene file for each cache version in the case of need to return to the previous version. I tried to create a quick prototype that computes a checksum from the input graph and save it in the data block and then compares it against the current graph. It's done on Windows (10) but it has an issue with the way how Houdini evaluates nodes. pz_input_hash.hip

A while ago .idx were ascii so you could do a lot of stuff with them, and then they made them binary... since then, the way as you describe is the only real method to copy. You can make some fancy python to wrap it up that method if you have a large library, but you still have very little control. This is certainly something SideFX needs to work on. I think they know about it, but certainly send them and RFE to of this as an example. They certainly need more poking on the subject.

I've encountered this as well. Turns out, there is a HIDDEN mantra parameter, that controls resolution of environment maps! Why hide such important parameter is beyond my understanding.

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

In a pointwrangle or a group expression SOP: neighbourcount(0, @ptnum) < 2

Because neighbours function return array. Henry just forgot type square brackets after n variable.

The worst thing is shortcuts, navigation and stuff like that. Yeah, I know you can basically redo it completely after spending an hour or two in settings, but damn the original settings are beyond idiotic and they are loosing a lot of newbies because of it. You open the program and the LM button sets weird 3D cursor what is not like any other 3D soft, the selection is on RM button (I know no one who isn't switching it back in Blender) and so on and so on. Blender is AMAZING, but it's biggest problem I'd say in default settings.

It's coming... https://www.eventbrite.com/e/houdini-17-launch-event-tickets-49857673644

Woop I just made a matcap GLSL shader for the Houdini viewport! Will be sharing the shader with some info & explanations soon when I have time.

Woop I just made a matcap GLSL shader for the Houdini viewport! Will be sharing the shader with some info & explanations soon when I have time.

As people above have mentioned the tasks involved in making a shot like this to work, is a team work , fx, lighting, comp and grading to get something like this done , but do not get discouraged, you can always try making something similar if time and resources are a constraint, so quickly put together a hip file , so you can play around with and modify to your needs , and there is a post related this topic in the effects forum, lava flow, so you can refer to that as well , clothsetup.hiplc

Check breakdown of this element without comp. And don't waste time trying recreate this, repeat just similar and simpler, this fx was done by high level team with dozents iterations not newbie. of

Hi guys! I would like to share here my latest personal project. Everything done in Houdini and Mantra Hope you like it. Youtube Version: Shark_Youtube.mp4

Hi Atom, nice car rig. As for steering, you can use orient attribute for constraint. I attached simple example how it works. constraint_steering.hipnc

I think this may do what you need: 1. Template the reference geometry (in your case, the line) 2. Select the Transform SOP and display the handle 3. Enter Pivot Mode [Ins] 4. Start Orientation Picking [;] 5. RMB on the Viewport > "Use Extended Mode" 6. Determine which two points (P, Q) on the reference geo will define the Z axis of the pivot (the pivot will be placed on P) 7. Shift-LMB on the Q point, then LMB on the P point 8. Exit Pivot Mode [Ins]

Hello Joseph, Sorry for the inconvenience, We have had various issue with our tutorial delivery system combined with various member of our team being on vacation which caused the delayed reply. As you said we have sent you the tutorial link and I personally issued you a 100% refund, please accept this as an apology for the hassle caused . Regards Saber

You can do this in a two-step process. Use one simulation to collect impact points so that they exist throughout all of time. Then use another simulation to generate the fracture from those supplied points. The fracture is glued together. Activate the fracture by breaking glue bonds based upon proximity to collisions. This video shows a way to set this up.

Hi Alvaro! This might be interesting in some way? https://www.youtube.com/watch?v=H-2GOIDQgnA

Check out this link. Also...

All the above posts are correct , made a few changes to your file , hope this helps Fluid_sim_Test9_solver_mod.hiplc

Ok, now we are having fun!

Hey Tony, What if you zero out the velocity of the collider?

Well, I couldn't just leave it there so I did do a few further tests but started getting different results between 16.5.496 and 16.5.536 (the sim would explode in .496 but stay stable in .536) so these further tests are in 16.5.536. I noticed that with the conetwist setup in the original the 'freedom' to roll downhill was reduced as though there were some stiffness to the twist in the conetwist constraint so I remade those particular constraints with hard constraints set to position only. Again, the stiffness of the rotation was quite strong. You can see that test in suspension11.hipnc. I then converted those new hard constraints to position and rotation but used condof/condir to allow rotation around the wheel rotation axis (but unfortunately that also permits position changes (sliding) along that axis). However, that did allow the whole assembly to travel freely downhill but you can see the wheels sliding a little along their axes. I put the conetwist test in the same scene to see just how great the difference was: suspension12.hipnc. Had to give the conetwists a slight position CFM value to prevent craziness. You can see the conetwist chassis on the right is still very slow to roll. Finally, as you do, I did attach a motor to all wheels for some torque! suspension13.hipnc. Don't have time at the moment to explore further. Not sure what combination of parameters is driving the stiffness or would loosen it: Position CFM, Position ERP, Bias, Relaxation or the physical properties like Friction, Bounce, Mass. Constraint iterations and solver iterations would also play a part. Very hard to work out the exact contributions of each of those parameters or how they affect the sim and the manual is very 'dry'. suspension11.hipnc suspension12.hipnc suspension13.hipnc

You really need waayyyy more voxels than that to do a FLIP sim. Overall your setup is good, I tweaked the Collision generation a bit and the shifting geometry should not be a problem. I time stretched the Alembic and delayed the initial change while adding a trail to compute the velocity. This way each time the geometry shifts, you get a little kick out of the flip. Just disable the node if you don't want that. Inside the DOP I added an additional hi-res FLIPObject that you can plug in for a more realistic simulation. It is set to 68 million voxels, compared to the mere 79 thousand found in your uploaded file. The preview FLIPObject is set to 1/2 million which gives reasonable response on most video cards. Hi-res will take a lot longer but your surfacing should look better. I also enabled Reseeding and turned up the Surface Oversampling to help smooth out the surface. ap_Fluid_sim_Test7.hiplc

I am working on a way to use one object to dent or impact another object, with a ripple effect around the impact area. The color red is available to create a group out of the impact area. Here is what I have so far. There is a small jump in the result which I have not figured out how to solve yet. ap_matte_vdb_dent_with_ripple.hiplc

In a typical wrangle in SOPs there's no difference. However in CVEX, there's no real "inputs" that you can count on, so you may have to use geoself() in order to reference the geometry you're working on if it's not directly reading a file on disk.

Hello Odforce! I recently put this Fern Generator Asset together, and I wanted to share for any interested. Also if anyone is interested in giving me any critiques or pointers I'd really appreciate it! Thank you everyone! Hope someone can get some use out of it! Link to example video and download

Realised I'd attached the springs to the upper wishbone instead of the main chassis!. Updated gif and hipnc attached@: suspension10.hipnc

Hello @AntoineSfx That's Softimage Closest Location: Closest Smoothed Surface in ICE. Very useful for cage deform. I think I nailed this one, by stop focusing on trying to compute the correct direction from on xyzdist/primuv resulting normal. I'm sure there's a way and I wish I could do it for simplicity but the math it's just not coming to me... So what I did was to loop for each point, select only the candidate prims from the reference mesh that could be the closest primitive, "extrude" them along their point normals until they are coplanar with the point. Then check which prim is the point inside of. If you already know the right prim, maybe the problem can be resumed by finding the ray direction from the primitive's point normals. What I did is on the right, extruded to make it coplanar, xyzdist() on the extruded prim, and applied the returned prim and uvw with primuv() on the original primitive. It's like I'm dividing the 3D space into extrusions of the reference mesh and see inside of which extrusion the point is in. The only advantage with this is that in the process of finding the correct prim, I also right away get the corresponding uvw, hence a complete "location". On the other hand a bunch of SOPS and Loop block are required. As for the initial shape it looks, like so: I added all this info to the RFE. Hopefully in the future we will just need to type a function in VEX. Would be cool since what I came up with is inherently slow for heave geo Scene file here: https://jmp.sh/bELWJdX Cheers

Few tips and tricks to manipulate gas simulation. 1. Independent resolution grid. E.g. Overriding vel grid size independent to a density grid. 2. Creating additional utilities. E.g. gradient, speed, vorticity and etc which can be used to manipulate forces. 3. Forces via VEX and some example snippets. smokesolver_v1.hipnc P.S. Some of this technique are not Open CL friendly though.

Ok. here is the updated version on fields.. previously it wasn't working. in gas field vop, distance and speed ramp(promoted outside) controls how particles stick to the surface. spheredripping01.hip

To me that looks a lot like the existing Ocean tools. Check out the master class on Oceans.

for shrinking, modifying your rest geo is the way to go ts_shrink_cloth.hip

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...