Leaderboard

Hello all Due to an unfortunate series of events we were forced to upgrade the forum software prematurely. Mostly that means that the template is different to what came before. But honestly it might be fine. The database seems to have made it through unscathed, so everything should work outside of that. If you find you're missing something, let me know and we'll do our utmost to restore it. Thanks! Marc

A simple mycelium growth simulation that works in 2D and 3D: It constantly adds points to the outer edge of point clouds (1) and favours doing so towards food (2). 1: Direction away from surrounding points: float radius = chf('radius'); int pts_max = chi('max_points'); int handle = pcopen(0, 'P', v@P, radius, pts_max); vector pos_avg = pcfilter(handle, 'P'); vector dir_avg = v@P - pos_avg; v@N = dir_avg; 2: Weighting probabilities and adding points: int pt_near = nearpoint(1, v@P); vector pos_near = point(1, 'P', pt_near); float prox = distance(v@P, pos_near); float weight_prox = fit(prox, prox_min, prox_max, 0.0, 1.0); float weight_rim = fit(length(v@N), rim_min, rim_max, 1.0, 0.0); float weight = dens * (weight_rim + weight_prox); if(nrandom('mersenne') > weight){ vector pos_add = v@P + normalize(v@N) * offset; int pt_add = addpoint(0, pos_add); addprim(0, 'polyline', i@ptnum, pt_add); } mycelium.hiplc

All done in Houdini except for the rigging/animation, although we're going to see about changing that up for the next one. He's going to have his own YouTube channel at some point. Bear vlogging is where it's at these days.

Haven't posted here in a while, but I've written a few posts since! Thought I'd do myself some promotion, so listing some here: Houdini, venv, OpenCV and cats VEX treats positions and vectors as row vectors You can modify environment variables in Generic Generator TOP Using VSCode with Houdini 19 and Python 3 A better way to batch-convert textures from Houdini The TD's Guide to Laziness Happy reading, feedback appreciated.

we are all "Newbies" now

Missing modules on the right side (reply Topic's and New Topic's). I need those for better Way on Helping other user's and navigation.

Regardless of the constrain to closest point setting, stitch to geometry still requires a source set of points (geometry) and target set of points (target geometry). It still needs to know which set of points you want to stitch to what. So you're going to have to find a way to tell Houdini which is which. The hip file below isn't ideal, but it illustrates the point. To be honest my first thought is to build the constraints in vex. What you really want is for each edge point (that is not an outside edge) in the orig_pt group created by the fracture to stitch itself to the corresponding point in the new_pt group. Use an enumerate SOP to create an index for each point before the fracture. Then after the cloth configure node, split out the constraints and add a point wrangle. For each "orig_edge point" find the corresponding "new_edge point" and create a new poly line between those two points. Then add all the necessary vellum attributes to each polyline. It's a little more than I have time for this morning, but there's a few good tutorials on using vex to build constraints. Including this one. If I have time later in the weekend I'll try to build a simple setup. And someone else might have a way of ordering the constraints without VEX. I just can't think of a way off the top of my head. stitch.hipnc

measure SOP: perimeter, and delete by perimeter attrib, for example a blast SOP with: @perimeter>10

Hello peeps! This is a fun project created using Houdini, so hopefully it ain't against the rules! Vancouver had a snowmageddon last week, and I thought it was the time to make snow ducks! I whipped up this simple mould inside Houdini, got it 3d printed and BAM! Ice ducks! There's some improvements to be made - the joint that aligns both halves of the mold fills up with snow really easily, and they need to be kept clear in order for both halves to form a perfect seal. I think instead of using a half ball with its matching negative space, a cylinder matches with a through hole would allow the snow to pass through, and the cylinder would resist the moulds sliding out sideways. The head was also difficult to form - the ice kept sticking to the mould. Perhaps a coating of polyurethane or even just sanding the insides would help with that. The ducks themselves are a rubber duck model I got off thingiverse, converted to vdb then back to a mesh, sculpted that mesh in sops to remove undercuts, and finally I used the boolean sop to create the empty areas. The final snow duck is about 12cm tall, and the moulds themselves are printed with abs filament. It took about 12 hours for this print using a 0.4mm nozzle. I hope you found this interesting!

Should be attribute i[]@ then index [] f@element2 = i[]@arr[1]; Also, you can always find useful tips here: https://www.tokeru.com/cgwiki/index.php?title=HoudiniVex

Would it be possible to make the code highlighting integrated in messages like before (in terms of colors) ? The colors are not very well suited for a clear background (the green and orange especially), it is almost impossible to read (see this post for example if someone can read the code : Otherwise the theme looks very nice !! Cheers, and happy new year to everyone !

Hi Robert, yes, you can integrate the minimal surface position with the ray node or minpos(). I've added the pig head to the food input to motivate growth there, as well. mycelium_3d.hipnc

with imagemagick convert -delay 100 -loop 0 *.jpeg animatedGIF.gif

Ohh man, it was as simple as just turning on the Joint Vector, hah! Thanks!

Another reason to place POSTs before TOPICs is that you end up at the top of the thread when you click TOPICs. Personally, I want to see the last reply, which is what POSTs does. When the topic gets long, it's kind of annoying to have to navigate through the pages to get to the end to see the last comment.

Have you tried doing the polywire at a rest frame and point deforming them using "id" as the piece attribute? You can also give the wires an up vector on the rest frame and this will usually prevent this kind of flickering.

This is an incredible setup! I've learned a lot from your file. Sometimes I think of ways to do it like that, but then I have just no idea where to start. Thank you so much for this

You can speed up this solution alot if you get rid of the "foreach" network and dont search for nearby points inside the solver. The iteration-time on your solution will remove any kind of creativity. For_each_primitive_point_infection_system_solution.hip

Alternatively you could store the iteration number from the for-each loop as a point attribute, then use that inside the solver to only infect points with matching iteration number. Hope this helps! For_each_primitive_point_infection_system.hiplc

I see this same issue; it was a problem in earlier versions of Houdini that I thought had finally been resolved for good in H19, but nope, now it's back for me with 19.5.435. I can confirm it's extremely aggravating to be trying to work in a scene and have unselected and undisplayed nodes cooking their networks for no apparent reason. Frankly, it makes me want to just revert back to H19.0

Hmm, I'm not seeing that in H19.5.435. Can you post an example HIP? This HIP generates a high resolution VDB, caches it and then animates the cached frame. I receive no upstream cooks during this process. ap_vdb_verify_upstream_cook.hiplc What if you tried something like this as a workaround. Link a two-state switch to the Load File Cache switch to force everything upstream to essentially be a NULL?

maybe decrease Rest_Angle_Scale down to zero

Take a look at this guide https://www.sidefx.com/docs/houdini/ref/cameralenses.html

Hi @JJ FX, I have a script, which creates .bat and .py script: http://lex.ikoon.cz/render-multiple-opengl-rops-simultaneously/ The .bat contents looks like this: REM This batch file runs multiple .py scripts at once start "Render: OGL" "C:/PROGRA~1/SIDEEF~1/HOUDIN~1.416/bin/hython.exe" "Q:/volby/7 houdini/scripts/OGL.py" The OGL.py looks like this: # This .py script opens a file and renders single rop hou.hipFile.load("Q:/volby/7 houdini/volby - v13.hiplc") node = hou.node("/obj/rop_GL/OGL") node.render(verbose=True,output_progress=True)

They are located in the install directory of houdini, in the /bin sub-directory, you can navigate to it using the cmd like this cd "C:/Program Files/Side Effects Software/Houdini X.Y.Z/bin" hython // or "C:/Program Files/Side Effects Software/Houdini X.Y.Z/bin/hython" Or add the path to your binary directory to the user environment variable PATH and then it will "source" this directory and make the binaries available in any directory from the console. However I do not advise to do this, and instead make a little bat script that launches a console with Houdini binaries (such as hython) available, like this @echo off set PATH="C:/Program Files/Side Effects Software/Houdini X.Y.Z/bin";%PATH% start /d C:/Users/username cmd @echo on And then double click on this script and you're set

Another fun one to play with. If you alter the Gas Calculate to divide the gradient against pressure, the smoke becomes less contained as it becomes more curvy.

You could use the insert function

Just an update - I found a method that seems to work. You can create a vellum constraints node in DOPs, set to create strut constraints on every frame. This will connect scrumpled areas and actively try to maintain their shape. You can then enable plasticity on them to update the rest position when it's deformed. Seems to work pretty well, and prevents the sinking/settling.

Are you a genius? Thank you so much. Perfect.

It's also possible to use ~= for string matching. @group_rock = s@name ~= "*rock*"; in your case should work as well.

@Marc it's Perfect right now . Thank you

I have a group node with unshared edges toggled on. Although, how can I delete not the unshared edges but the rest while keeping the unshared edges ?

We've been running a bunch of pipeline tests recently and it really depends on the type of work you do and what your needs are. I would say that the first question to answer is whether USD and solaris benefits your pipeline. And understanding that these are two different questions. You can use solaris without adopting a full USD pipeline. Keep using your old workflow and just import it into solaris and let solaris hand the USD under the hood so to speak. If you are committing to a full USD workflow it takes a fair amount of care and work to maintain and support. Making a USD pipeline that is friendly to artists (and doesn't allow artists to break it) requires a lot of custom tool building and pipeline TD time. You really have to be sure it will benefit that kind of investment. Solaris, too, has some great features, especially for sequence lighting and working on multiple shots at once time. But it does bring an added step to rendering that takes time and that most artists are not currently very familiar with. Are the benefits worth it for you? For commercial work with quick turn arounds, I don't always like the additional steps of working with solaris. For longform work or commercial work with more time where you are working on multiple shots with similar lighting setups, it can sometimes be worth it. And if you do lots of different types of work, it is generally (at the moment) easier to maintain a non-USD pipeline than a USD one. Then, if you do decide to use solaris in your pipeline, I'll say I'm very excited about where Karma is going. Its speed is on par with Redshift. Karma XPU is behind CPU, but promises a great way to move between quick GPU rendering and farm-based final rendering. And I find it a more pleasing looking renderer than Redshift. Plus you get the benefit of direct Houdini integration with volume shaders, ocean spectra, heighfields, etc. That said, Karma is not 100% production ready. It's close, but make sure to take a look at which features are currently missing before you commit.

KineFX driven Face Peeling FX presentation at Gamescom Asia 2022 (Singapore) is up on SideFX Houdini vimeo channel: There is a sneak peek of Pragmatic VEX: Volume 2 where I showcase the new Poly Carve SOP, one of the major chapters in the upcoming VEX course. I also talk a bit about my own UX design in Houdini based on the inquiry by Fianna Huge thanks to SideFX for letting me present on their platform Hope you find it useful!

@Apesta Search here on Forum and Google Following Marta Feriani 2017 Art-directing procedural vegetation in Houdini using a space colonization algorithm . Ivy Growth . + anything from Vdb Iso deform Displacement you have endless ex on that Topic Plus Files . Images done In Midjourney.

The problem was solved by setting the "Velocity X Grid" tab to just "vel", and leaving all others blank.

clean some parameters(channels) ,that was inside HDA ..or just copy paste(write) and investigate "extrude parameter in Loop to make them 0"- IN new SCENE rebuild .... if that not works Download Fe-ELib for Houdini it has some Examples on that topic using volumes and COPS #define UP {0,0,0.2} vector poses[], uvws[]; int prims[]; int intersect_all = intersect_all(1, @P, UP, poses, prims, uvws, 0.01, -1); #if 0 f@height = intersect_all / 10.0; #else f@height = intersect_all > 1; #endif

What i did eventually was vertex split promote uvs to point transform my world positions to uv space v@wP = @P; //store the points world space positions @P = @uv; //from world space to uv space treat the uvs as a mesh so i could find intersections and use the smooth node. The results where okayish but not great. transform back to world space promote uv to vertex. Any other ideas? because the smoothing part is a bit funky, i keep getting these spikes

Hi everybody! Check out my video about RnD of framework for robust OpenCL development. In this video I describe my old developement: framework for development GPU algorithms like cloth/wire/grains/particle/fluid dynamics. It is implemented as Python code snipped with set of extension functions for control some OpenCL specific tasks. It gives opportunity to develop complex algorithms without compilation, without HDK/C++, without even closing Houdini sessions.

perfect sand refs on this channel https://vimeo.com/atelieramaco

Maybe keep faking like this. vellum_on_fly_v02.hip

'To polar node' ended up being the trick! Thanks for the help guys. Here's what I've got after an hour or so, I think I can do the rest shader level.

Hi all I'm stuck with this. What is the best way to mix two fluids that have different parameters (i.e viscosity)? Both will have different shadings. Any ideas. Attached reference scene. Thank you very much to all Mix_flips_RnD.hipnc

My goal is to make a river, to which I am going to do the shading with an ocean surface and ocean volume. To this river I want to pour a liquid with viscosity. I also want to do an independent shading to this liquid. How far I have come is: I have made the river using a flip solver, and put it inside the flip object as an initial state. I introduce the viscosity liquid in the same dopnet, through a volume source. So I have the perfect collisions between the two liquids. If to both emitters I place a color node at the sop level, in the final cache I will have this information, but I do not want a simple color, I want to be able to do a good shading to each of the liquids. The problem is that I can't separate them to be able to do the shading independently. I have tried removing the viscosity attribute after the flip fluid source in maya, but the result is not good. I would appreciate some help.

Alo @neom315 If you download qLIb : https://github.com/qLab/qLib It has wonderful examples of advecting particles and much more if you combine some vops in particles you can achieve the same effect. Hope it Helps

as promised....I did some more Twisting of your DNA and unraveled it too...you've been sequenced !!! Vu_InterlockMobius_06.hipnc

Here's one way, there's no doubt many ways to achieve this effect. As you say, if you set @v in sops and enable 'inherit from points' in rbd, it only works on the first frame. if you enable 'overwrite attributes from sops' and specify v, then it clashes with the rbd solver which is also trying to set @v, and your pieces fly away. One way around this is to detect the first frame a piece is made active, and only add @v for that frame. Here I use a timeshift to move the geometry back by 1 frame, and I copy active from the shifted geo to the normal geo with a new attib name @active_prev. In dops, I added a wrangle that just tests if @active != @active_prev. The only time they won't be different is on the first frame the piece is made active. As such, I add @v by pulling it directly from sops. The rest of the time, rbd will set @v by itself. chkbox_fix.hipnc

I've attached a hip file. I think I have a slightly faster version of it somewhere else, but basically the thing has to be pretty high res to work well. Also, it's very crashy for me. Something to do with the sop solver and vdb... *shrug*. https://drive.google.com/file/d/0B3ArOtmU3eiLOGZqS3lMaUY2c1k/view?usp=sharing << playblast Found eetu's : http://forums.odforce.net/topic/8471-eetus-lab/?p=120639 http://forums.odforce.net/topic/8471-eetus-lab/?p=120749 They look awesome recursive_growth_if.hip