Jump to content


Popular Content

Showing most liked content since 06/19/2018 in all areas

  1. 7 points
    Since there's been a lot of talk around the web about graphics APIs this past week with Apple's decision to deprecate OpenGL in MacOS Mojave, I thought I'd take this opportunity to discuss the various graphics APIs and address some misconceptions. I'm doing this as someone who's used all versions of OpenGL from 1.0 to 4.4, and not with my SideFX hat on. So I won't be discussing future plans for Houdini, but instead will be focusing on the APIs themselves. OpenGL OpenGL has a very long history dating back to the 90s. There have been many versions of it, but the most notable ones are 1.0, 2.1, 3.2, and 4.x. Because of this, it gets a reputation for being old and inefficient, which is somewhat true but not the entire story. Certainly GL1.0 - 2.1 is old and inefficient, and doesn't map well to modern GPUs. But then in the development of 3.0, a major shift occurred that nearly broken the GL ARB (architecture review board) apart. There was a major move to deprecate much of the "legacy" GL features, and replace it with modern GL features - and out of that kerfuffle the OpenGL core and compatibility profiles emerged. The compatibility profile added these new features alongside the one ones, while the core profile completely removed them. The API in the core profile is what people are referring to when they talk about "Modern GL". Houdini adopted modern GL in v12.0 in the 3D Viewport, and more strict core-profile only support in v14.0 (the remaining UI and other viewers). Modern GL implies a lot of different things, but the key ones are: geometry data and shader data must be backed by VRAM buffers, Shaders are required, and all fixed function lighting, transformation, and shading is gone. This is good in a lot of ways. Geometry isn't being streamed to the GPU in tiny bits anymore and instead kept on the GPU, the GL "big black box" state machine is greatly reduced, and there's a lot more flexibility in the display of geometry from shaders. You can light, transform, and shade the model however you'd like. For example, all the various shading modes in Houdini, primitive picking, visualizers, and markers are all drawn using the same underlying geometry - only the shader changes. OpenGL on Windows was actually deprecated decades ago. Microsoft's implementation still ships with Windows, but it's an ancient OpenGL 1.1 version that no one should use. Instead, Nvidia, AMD and Intel all install their own OpenGL implementations with their drivers (and this extends to CL as well). Bottlenecks As GPUs began getting faster, what game developers in particular started running into was a CPU bottleneck, particularly as the number of draw calls increased. OpenGL draw calls are fast (more so that DirectX), but eventually you get to a point where the driver code prepping the draw started to become significant. More detailed worlds meant not only bigger models and textures, but more of them. So the GPU started to become idle waiting on draws from the CPUs, and that draw load began taking away from useful CPU work, like AI. The first big attempt to address this was in the form of direct state access and bindless textures. All resources in OpenGL are given an ID - an integer which you can use to identify a resource for modifying it and binding it to the pipeline. To use a texture, you bind this ID to slot, and the shader refers to this slot through a sampler. As more textures we used and switched within a frame, mapping the ID to its data structure became a more significant load on the driver. Bindless does away with the ID and replaces it with a raw pointer. The second was to move more work to the GPU entirely, and GLSL Compute shaders (GL4.4) were added, along with Indirect draw calls. This allows the GPU to do culling (frustum, distance based, LOD, etc) with an OpenCL-like compute shader and populate some buffers with draw data. The indirect draw calls reference this data, and no data is exchanged between GPU and CPU. Finally, developers started batching as much up as possible to reduce the number of draw calls to make up for these limitations. Driver developers kept adding more optimizations to their API implementations, sometimes on a per-application basis. But it became more obvious that for realtime display of heavy scenes, and with VR emerging where a much higher frame rate and resolution is required, current APIs (GL and DX11) were reaching their limit. Mantle, Vulkan, and DX12 AMD recognized some of these bottlenecks and the bottleneck that the driver itself was posing to GPU rendering, and produced a new graphics API called Mantle. It did away with the notion of a "fat driver" that optimized things for the developer. Instead, it was thin and light - and passed off all the optimization work to the game developer. The theory behind this is that the developer knows exactly what they're trying to do, whereas the driver can only guess. Mantle was eventually passed to Khronos, who develops the OpenGL and CL standards, and from that starting point Vulkan emerged. (DirectX 12 is very similar in theory, so for brevity’s sake I'll lump them together here - but note that there are differences). Vulkan requires that the developer be a lot more up-front and hands on with everything. From allocating large chunks of VRAM and divvying it up among buffers and textures, saying exactly how a resource will be used at creation time, and describing the rendering pipeline in detail, Vulkan places a lot of responsibility on the developer. Error checking and validation can be entirely removed in shipping products. Even draw calls are completely reworked - no more global state and swapping textures and shaders willy-nilly. Shaders must be wrapped in an object which also contains all its resources for a given draw per framebuffer configuration (blending, AA, framebuffer depths, etc), and command buffers built ahead of time in order to dispatch state changes and draws. Setup becomes a lot more complicated, but also is more efficient to thread (though the dev is also completely responsible for synchronization of everything from object creation and deletion to worker and render threads). Vulkan also requires all shaders be precompiled to a binary format, which is better for detecting shader errors before the app gets out the door, but also makes generating them on the fly more challenging. In short, it's a handful and can be rather overwhelming. Finally, it's worth noting that Vulkan is not intended as a replacement for OpenGL; Khronos has stated that from its release. Vulkan is designed to handle applications where OpenGL falls short. A very large portion of graphics applications out there don't actually need this level of optimization. My intent here isn't to discourage people from using Vulkan, just to say that it's not always needed, and it is not a magic bullet that solves all your performance problems. Apple and OpenGL When OSX was released, Apple adopted OpenGL as its graphics API. OpenGL was behind most of its core foundation libraries, and as such they maintained more control over OpenGL than Windows or Linux. Because of this, graphics developers did not install their own OpenGL implementations as they did for Windows or Linux. Apple created the OpenGL frontend, and driver developers created the back end. This was around the time of the release of Windows Vista and its huge number of driver-related graphics crashes, so in retrospect the decision makes a lot of sense, though that situation has been largely fixed in the years since. Initially Apple had support for OpenGL 2.1. This had some of the features of Modern GL, such as shaders and buffers, but it also lacked other features like uniform buffers and geometry shaders. While Windows and Linux users enjoyed OpenGL 3.x and eventually 4.0, Mac developers were stuck with a not-quite-there-yet version of OpenGL. Around 2012 they addressed this situation and released their OpenGL 3.2 implementation ...but with a bit of a twist. Nvidia and AMD's OpenGL implementations on Windows and Linux supported the Compatibility profile. When Apple released their GL3.2 implementation it was Core profile only, and that put some developers in a tricky situation - completely purge all deprecated features and adopt GL3.2, or remain with GL2.1. The problem being that some deprecated features were actually still useful in the CAD/DCC universe, such as polygons, wide lines, and stippled lines/faces. So instead of the gradual upgrading devs could do on the other platforms, it became an all-or-nothing affair, and this likely slowed adoption of the GL3.2 profile (pure conjecture on my part). This may have also contributed to the general stability issues with GL3.2 (again, pure conjecture). Performance was another issue. Perhaps because of the division of responsibility between the driver developer of the GPU maker and the OpenGL devs at Apple, or perhaps because the driver developers added specific optimizations for their products, OpenGL performance on MacOS was never quite as good as other platforms. Whatever the reason, it became a bit of a sore point over the years, with a few games developers abandoning the platform altogether. These problems likely prompted them to look at at alternate solution - Metal. Eventually Apple added more GL features up to the core GL4.1 level, and that is where it has sat until their announcement of GL deprecation this week. This is unfortunate for a variety of reasons - versions of OpenGL about 4.1 have quite a few features which address performance for modern GPUs and portability, and it's currently the only cross platform API since Apple has not adopted Vulkan (though a third party MoltenVK library exists that layers Vulkan on Metal, it is currently a subset of Vulkan). Enter Metal Metal emerged around the time of Mantle, and before Khronos had begun work on Vulkan. It falls somewhere in between OpenGL and Vulkan - more suitable for current GPUs, but without the extremely low-level API. It has compute capability and most of the features that GL does, with some of the philosophy of Vulkan. Its major issues for developers are similar to those of DirectX - it's platform specific, and it has its own shading language. If you're working entirely within the Apple ecosystem, you're probably good to go - convert your GL-ES or GL app, and then continue on. If you're cross platform, you've got a bit of a dilemma. You can continue on business as usual with OpenGL, fully expecting that it will remain as-is and might be removed at some point in the future, possibly waiting until a GL-on-top-of-Metal API comes along or Apple allows driver developers to install their own OpenGL like Microsoft does. You can implement a Metal interface specific to MacOS, port all your shaders to Metal SL and maintain them both indefinitely (Houdini has about 1200). Or, you can drop the platform entirely. None of those seem like very satisfactory solutions. I can't say the deprecation comes as much of a surprise, with Metal development ongoing and GL development stalling on the Mac. It seems like GL was deprecated years ago and this is just the formal announcement. One thing missing from the announcement was a timeframe for when OpenGL support would end (or if it will end). It does seem like Apple is herding everyone toward Metal, though how long that might take is anyone's guess. And there you have it, the state of Graphics APIs in 2018 - from a near convergence of DX11 and GL4 a few short years ago, to a small explosion of APIs. Never a dull moment in the graphics world
  2. 5 points
    Here is another slight variation. Instead of generating a fixed length line segment that moves through time, generate the full path over the entire time range. Then add a primitive attribute @path_pos to each line primitive. Drive the offset along path value, of the path deformer, with this attribute. Then you can have some geometry leading others as they each flow along their own path. float frame_end = 200.0; // deform_path node expects input in the range of 0-1. f@path_pos = fit01(@Frame,0,frame_end); // Now offset each path based upon it's index. float delta = 0.05; // per-line delay time can be set here. f@path_pos -= (delta * @prim); ap_ps_Cardume_Odforce_v3.04.hiplc
  3. 5 points
  4. 4 points
    We've made a few incremental upgrades to MOPs, but the next big feature addition (uploaded just now) is support for instancing sequences. Currently you can load either Alembics or bgeo files as packed disk sequences, and there's full support for frame cycling and individually addressable frame selection via expressions or point attributes. Details are in the Instancer documentation.
  5. 4 points
    I'm working on something related to art direct the swirly motion of gases; Its an implementation of a custom buoyancy model that let you art direct very easily the general swirly motion of gases without using masks, vorticles, temperature sourcing to have more swirly motion in specific zones, etc. Also it gets rid of the "Mushroom effect" for free with a basic turbulence setup. Here are some example previews. Some with normal motion, others with extreme parameters values to stress the pipeline. For the details is just a simple turbulence + a bit of disturbance in the vel field, nothing complex, because of this the sims are very fast (for constant sources: average voxel count 1.8 billions, vxl size 0.015, sim time 1h:40min (160 frames), for burst sources, vxl size 0.015, sim time 0h:28min). I'm working on a vimeo video to explain more this new buoyancy model that I'm working on. I hope you like it! Cheers, Alejandro constantSource_v004.mp4 constantSource_v002.mp4 burstSource_v004.mp4 constantSource_v001.mp4 burstSource_v002.mp4 burstSource_v003.mp4 burstSource_v001.mp4 constantSource_v003.mp4
  6. 4 points
    Hey guys! I have been busy with roads, lots of roads. I mainly found the intersections very interesting and hard to solve. Here is some of my progress, the blue roads are straight pieces and the red ones are the interesections. I mainly focused on creating clean geometry with working UVs. I hope you guys like it! Solving osm data.mp4
  7. 4 points
    Hey Stephen, This is probably not the best approach but I think it's a starting point. You can make all the caches on the OUT context (using the merge node) Tea.Flip.Pyro_v1.01.hiplc
  8. 4 points
    One little bug that's been bothering me recently is when you copy a parameter and 'paste relative reference' into a wrangle. If you have an empty wrangle then it's fine, but if you already had code there, it replaces it all with the channel expression, rather than just pasting it into the code. Just a small thing really, but it would be cool to see it fixed
  9. 4 points
    Probably because the case study ends up derailing the actual work.
  10. 3 points
    Bumping with the recordings : EPC2018 - Innes McKendrick - Working With Change (Hello Games: No Man’s Sky) EPC2018 - Anastasia Opara - Proceduralism and Deep Learning (EA: SEED) EPC2018 - Oskar Stalberg - Wave Function Collapse in Bad North EPC2018 - Twan de Graaf and Pierre Villette - Procedural Content Generation at Ubisoft Paris
  11. 3 points
    Here is most of the data sets converted to .rs Proxy files.
  12. 3 points
    set the point attribute i@found_overlap=1 on your packed RBDs before the simulation and they will resolve overlaps at the beginning of the simulation. you can then apply other forces if necessary to push them back together.
  13. 3 points
    ver 2: added Use Overlap option. Previously, the Repel represents how much to move away each iteration, in absolute terms. Now if Use Overlap is enabled, the Repel is a portion of the actual overlap amount. So if 2 spheres overlap by 3 units...and Repel is 0.5, then the 'move away' amount is 1.5 With Use Overlap enabled (and say Repel is 1), it gets to the desired positions much quicker...but not as 'nice' and relaxing as when Repel is lowish... vu_SimplePacking2.hipnc
  14. 3 points
    there is a "control field" on the gas disturb node. You can get a "speed" field with the gasmatchfield + gasanalysis microsolvers disturb_on_speed.hipnc or you can build disturbance directly is a gaswrangle node: vector4 hvec; vector _div = (v@P + rand(f@Frame+chf("seed")) * chf("divscale"))/chf("divscale"); hvec = _div; setcomp(hvec, f@Frame, 3); vector disturbance = vector(random(hvec))*2-1; v@vel += disturbance * length(v@vel) * chf("disturbance_amount");
  15. 3 points
    Houdini tip | Assets versioning workflow
  16. 3 points
    Houdini getting easier, more accessible is a matter of time, so those that feel the need to protect their jobs I would suggest to look at both ends of the spectrum, either you bring some truly serious maths and engineering skills to the party or you bring some serious good flair and taste. Don't fight gravity... you will loose.
  17. 3 points
    I think the rbd is the way to go on this one. Heres a simple setup to get you starting. chips.hiplc
  18. 3 points
    Heres the latest rbd experiment I did. It's some motors being driven by a sine wave at the same pace as a piece of music. The music and images line up pretty nice I think. I was surprised!
  19. 3 points
    You're losing sight of the bigger picture here, which is to create art. FX TD's are by definition going to be on the technical side of things, but their goal is to facilitate the creation of art. The final image is what matters, 99% of the time. People with engineering mindsets sometimes like to get caught up in the "elegance" or "physical correctness" of their solutions, but that stuff rarely (if ever) matters in this field. Rotating an object is conceptually a simple thing, but it turns out that there's quite a bit of math involved. Is it really insulting one's intelligence to not assume that every artist is willing to study linear algebra to rotate a cube on its local axis? I do know how to do this, and I still don't want to have to write that code out every single time. It's a pain in the ass! Creating a transform matrix, converting to a quaternion, slerping between the two quaternions, remembering the order of multiplication... remembering and executing these steps every time gets in the way of exploration and play. Besides, all of that is only possible because SESI wrote a library of functions to handle this. Should we be expected to also write our own C++ libraries to interpolate quaternions? Should we be using Houdini at all, instead of writing our own visual effects software? Who engineered the processor that you're using to compute all this? This is a rabbit hole you'll never escape from. Anyways, Entagma and MOPs are not officially affiliated at all, so Entagma's core mission of reading white papers so that you don't have to is unlikely to change.
  20. 3 points
    "The Tree" Another R&D image from the above VR project: The idea for the VR-experience was triggered by a TV-show on how trees communicate with each other in a forest through their roots, through the air and with the help of fungi in the soil, how they actually "feed" their young and sometimes their elderly brethren, how they warn each other of bugs and other adversaries (for instance acacia trees warn each other of giraffes and then produce stuff giraffes don't like in their leaves...) and how they are actually able to do things like produce substances that attract animals that feed on the bugs that irritate them. They even seem to "scream" when they are thirsty... (I strongly recommend this (german) book: https://www.amazon.de/Das-geheime-Leben-Bäume-kommunizieren/dp/3453280679/ref=sr_1_1?ie=UTF8&qid=1529064057&sr=8-1&keywords=wie+bäume+kommunizieren ) It's really unbelievable how little we know about these beings. So we were looking to create a forest in an abstract style (pseudo-real game-engine stuff somehow doesn't really cut it IMO) that was reminiscent of something like a three dimensional painting through which you could walk. In the centre of the room, there was a real tree trunk that you were able to touch. This trunk was also scanned in and formed the basis of the central tree in the VR forest. Originally the idea was, that you would touch the tree (hands were tracked with a Leap Motion controller) and this would "load up" the touched area and the tree would start to become transparent and alive and you would be able to look inside and see the veins that transport all that information and distribute the minerals, sugar and water the plant needs. From there the energy and information would flow out to the other trees in the forest, "activate" them too and show how the "Wood Wide Web" connected everything. Also, your hands touching the tree would get loaded up as well and you would be able to send that energy through the air (like the pheromones the trees use) and "activate" the trees it touched. For this, I created trees and roots etc. in a style like the above picture where all the "strokes" were lines. This worked really great as an NPR style since the strokes were there in space and not just painted on top of some 3D geometry. Since Unity does not really import lines, Sascha from Invisible Room created a Json exporter for Houdini and a Json Importer for unity to get the lines and their attributes across. In Unity, he then created the polyline geometry on the fly by extrusion, using the Houdini generated attributes for colour, thickness etc. To keep the point count down, I developed an optimiser in Houdini that would reduce the geometry as much as possible, remove very short lines etc. In Unity, one important thing was, to find a way to antialias the lines which initially flickered like crazy - Sascha did a great job there and the image became really calm and stable. I also created plants, hands, rocks etc. in a fitting style. The team at Invisible Room took over from there and did the Unity part. The final result was shown with a Vive Pro with attached Leap Motion Controller fed by a backpack-computer. I was rather adverse to VR before this project, but I now think that it actually is possible to create very calm, beautiful and intimate experiences with it that have the power to really touch people on a personal level. Interesting times :-) Cheers, Tom
  21. 2 points
    Hi Stephen Are your particles going thru your mesh or just your fluid surface. If it's only the fluid surface look to how you're building that, maybe dilation is too much? Or the resolution of your surfacing mesh is too high - not detailed enough to catch the detailed shape of the fluid as it pours out of the carton? Oh and check the positioning and definition of your collision volume in relation to the geometry of your milk carton. The inside surface of the collision volume will need to match perfectly with the inside surface of the milk carton, or at least where it's pouring from. cheers Nigel.
  22. 2 points
    Pixelkram / Moritz S. (of Entagma) and I are proud to announce MOPs: an open-source toolkit for creating motion graphics in Houdini! MOPs is both a suite of ready-to-use tools for solving typical motion graphics problems, and a framework for building your own custom operators easily. More information is available from our website: http://www.motionoperators.com Enjoy!
  23. 2 points
    The Moana .obj files are textured using .ptex, which means there are no UVs on any of the provided geometry elements. I am playing around with adding UVs to some of the larger scene elements so image based textures can be applied.
  24. 2 points
    They don't connect to anything because they are generators, kind of like a BOX node does not have an input, it generates all the points that make a box. The python file does "connect" to the .JSON file which contains the data that the script reads to generate points. You need the data and to point the hard coded file path in the python node to the Moana data before you can see anything generated in the scene. Yeah, it took me 3 days to get all the data downloaded. Just an FYI too. You don't really need the animated data. All that is in that data set is a .obj sequence of the ocean which barely moves. The basepackage contains a single still of the ocean which is enough to get going.
  25. 2 points
    Here are the python based instance point generators for the isBeach portion of the data set. The set shown below is made up of 1,688,000 points. Adjust the data_path in each object to point to the location your downloaded data set. Shown here are data sets for...xgFibers, xgHibiscus, xgPalmDebrisd, xgPebbles, xgSeaweed, xgShells, xgShellsSmall and xgStones. ap_moana_stones_070918.hiplc
  26. 2 points
    well if the underlying surface is just a sphere...then that 'conform' step is actually the easiest step to do... Here....now the hard part is to workout the underlying template points pattern to get you the desired pattern. (note: if you observe the model in the link...it's not 'uniform' throughout.....rotate it in 3D and you'll see it's actually symmetrical, ie. 2 hemispheres) vu_RingOrb.hipnc
  27. 2 points
    I think I would try using flocking particles that leave a trail. Connect the trail as a line then deform the person/mesh along the line. Kind of like the pile of worms file.
  28. 2 points
    A setup that finds the maximum pscale points can have, so the resulting spheres don't intersect. Scene at: https://jmp.sh/hEctEky
  29. 2 points
    Hi, Here is the hip setup for the vimeo video about the icecream sim with uvs; Its a very old setup (5+ years). Nothing over-complicated here, not always you have to do Black Magic to solve complex things! I hope it helps! Cheers! Alejandro icecream_vimeo_v001_to_share.hip
  30. 2 points
    At this point i only wish for H17.0 an accelerated GPU FEM solver. With all functionality and stable. Or at least, an much faster CPU FEM using fully the multi-thread capabilities of AMD Threadripper processor. all the other things can wait, already good enough. But SESI never stops, and all improvements are very welcomed. there are a multitude of research on this since 2011 (http://www.web.uwa.edu.au/__data/assets/pdf_file/0005/1524848/Finite-Element-Method.pdf) anyway, finger crossed! PS: i really do not like to fake things with PBD/Grains only for speed, where FEM is much more precise/realistic ...
  31. 2 points
    I think it's done? I'm getting https on all my links anyway. Let me know if it's all good on your end. M
  32. 2 points
  33. 2 points
    Available: August 1st The past year I have been working remotely, mainly focusing on Feature Film work, but also doing some FX Design type work, like below. Looking for remote work primarily, but able to be on location for up to 2 weeks if needed. Let me know if you think I might be a good fit for an upcoming project. www.RyCoFX.com I also offer a discounted rate the first time I book with a new vendor, when invoicing through my LLC.
  34. 2 points
    Maybe the problem is that you need to grab the opinput()? It will trigger an infinite recursion otherwise. Although, it does that outside of a for each loop as well.
  35. 2 points
    matrix3 m = ident(); vector axis = set(0,1,0); float angle = radians(rand(i@class)*360); rotate(m,angle,axis); @P *= m; Write that in a pointwrangle after a connectivity node set to points.
  36. 2 points
    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!
  37. 2 points
    Okay, I think all of those group masking bugs are fixed. There's a few other fixes and features added as well; details are in our updates thread.
  38. 2 points
    Wait a second, I was just about to say, if you want Vex course work, you can pay exclusively for that on the Entagma Patreon - but, it sounds like you are not currently subscribed to the Entagma Patreon, but are simply consuming their "free" content!? Now, MOPs is some additional "free" content from the likes of Entagma, and your argument is that, "Hey, no, dont waste time creating free things I wont use, please only create free things that I want"? I cant believe you have the selfishness to even type such a comment - let alone try and defend it.
  39. 2 points
    Which is mildly ironic since the people who's tutorials you want so much are themselves designers. MOPs and Entagma are amazing to see and more knowledge/tools should not be discouraged. Even if all you do every day are pyro sims, learning some design skills will help your sims look better, guaranteed. M
  40. 2 points
  41. 2 points
    There are so many nice example files on this website that I am often searching for. I wanted to use this page as a link page to other posts that I find useful, hopefully you will too. Displaced UV Mapped Tubes Particles Break Fracture Glue Bonds Render Colorized Smoke With OpenGL Rop Moon DEM Data Creates Model Python Script Make A Belly Bounce Helicopter Dust Effect Conform Design To Surface Benjamin Button Intro Sequence UV Style Mapping UV Box and Multiple Projection Styles Ping Pong Frame Expression Instance vs. Copy (Instance Is Faster) Particle Bug Swarm Over Vertical and Horizontal Geometry Rolling Cube Rounded Plexus Style Effect Pyro Smoke UpRes Smoke Trails From Debris Align Object Along Path Fading Trail From Moving Point Swiss Cheese VDB To Polygons Get Rid Of Mushroom Shape In Pyro Sim A Tornado Ball Of Yarn Particles Erode Surface Unroll Paper Burrow Under Brick Road Non Overlapping Copies Build Wall Brick-By-Brick FLIP Fluid Thin Sheets Smoke Colored Like Image Volumetric Spotlight Moving Geometry Using VEX Matt's Galaxy Diego's Vortex Cloud Loopable Flag In Wind Eetu's Lab <--Must See! Wolverine's Claws (Fracture By Impact) Houdini To Clarisse OBJ Exporter Skrinkwrap One Mesh Over Another Differential Growth Over Surface Rolling Clouds Ramen Noodles Basic Fracture Extrude Match Primitive Number To Point Number Grains Activate In Chunks Fracture Wooden Planks Merge Two Geometry Via Modulus Fill Font With Fluid DNA Over Model Surface VDB Morph From One Shape To Another Bend Font Along Curve Ripple Obstacle Across 3D Surface Arnold Style Light Blocker Sphere Dripping Water (cool) Exploded View Via Name Attribute VEX Get Obj Matrix Parts eetu's inflate cloth Ice Grows Over Fire Flying Bird As Particles DEM Image To Modeled Terrain Pyro Temperature Ignition Extrude Like Blender's Bevel Profile Particles Flock To And Around Obstacles BVH Carnegie Mellon Mocap Tweaker (python script) Rolling FLIP Cube Crowd Agents Follow Paths Keep Particles On Deforming Surface Particle Beam Effect Bendy Mograph Text Font Flay Technique Curly Abstract Geometry Melt Based Upon Temperature Large Ship FLIP Wake (geo driven velocity pumps) Create Holes In Geo At Point Locations Cloth Blown Apart By Wind Cloth Based Paper Confetti Denim Stitching For Fonts Model A Raspberry Crumple Piece Of Paper Instanced Forest Floor Scene FLIP pushes FEM Object Animated Crack Colorize Maya nParticles inside an Alembic Path Grows Inside Shape Steam Train Smoke From Chimney Using Buoyancy Field On RBDs In FLIP Fluid Fracture Along A Path COP Based Comet Trail eetu's Raidal FLIP Pump Drip Down Sides A Simple Tornado Point Cloud Dual Colored Smoke Grenades Particles Generate Pyro Fuel Stick RBDs To Transforming Object Convert Noise To Lines Cloth Weighs Down Wire (with snap back) Create Up Vector For Twisting Curve (i.e. loop-d-loop) VDB Gowth Effect Space Colonization Zombie L-System Vine Growth Over Trunk FLIP Fluid Erosion Of GEO Surface Vein Growth And Space Colonization Force Only Affects Particle Inside Masked Area Water Ball External Velocity Field Changes POP particle direction Bullet-Help Small Pieces Come To A Stop Lightning Around Object Effect Lightning Lies Upon Surface Of Object Fracture Reveals Object Inside Nike Triangle Shoe Effect Smoke Upres Example Julien's 2011 Volcano Rolling Pyroclastic FLIP Fluid Shape Morph (with overshoot) Object Moves Through Snow Or Mud Scene As Python Code Ramp Scale Over Time Tiggered By Effector Lattice Deforms Volume Continuous Geometric Trail Gas Enforce Boundary Mantra 2D And 3D Velocity Pass Monte Carlo Scatter Fill A Shape Crowd Seek Goal Then Stop A Bunch Of Worms Potential Field Lines Around Postive and Negative Charges Earthquake Wall Fracture Instance Animated Geometry (multiple techniques) Flip Fluid Attracted To Geometry Shape Wrap Geo Like Wrap3 Polywire or Curve Taper Number Of Points From Second Input (VEX) Bullet Custom Deformable Metal Constraint Torn Paper Edge Deflate Cube Rotate, Orient and Alignment Examples 3D Lines From 2D Image (designy) Make Curves In VEX Avalanche Smoke Effect Instant Meshes (Auto-Retopo) Duplicate Objects With VEX Polywire Lightning VEX Rotate Instances Along Curved Geometry Dual Wind RBD Leaf Blowing Automatic UV Cubic Projection (works on most shapes) RBD Scatter Over Deforming Person Mesh FLIP Through Outer Barrier To Inner Collider (collision weights) [REDSHIFT] Ground Cover Instancing Setup [REDSHIFT] Volumetric Image Based Spotlight [REDSHIFT] VEX/VOP Noise Attribute Planet [REDSHIFT] Blood Cell Blood Vessel Blood Stream [REDSHIFT] Light Volume By Material Emission Only [REDSHIFT] Python Script Images As Planes (works for Mantra Too!) [REDSHIFT] MTL To Redshift Material [REDSHIFT] Access CHOPs In Volume Material [REDSHIFT] Mesh Light Inherits Color Dragon Smashes Complex Fractured House (wood, bricks, plaster) Controlling Animated Instances Road Through Height Field Based Terrain Tire Tread Creator For Wheels Make A Cloth Card/Sheet Follow A NULL Eye Veins Material Matt Explains Orientation Along A Curve Mesh Based Maelstrom Vortex Spiral Emit Multiple FEM Objects Over Time Pushing FEM With Pyro Spiral Motion For Wrangle Emit Dynamic Strands Pop Grains Slope, Peak and Flat Groups For Terrains Install Carnegie Mellon University BVH Mocap Into MocapBiped1 Ramp Based Taper Line Fast Velocity Smoke Emitter Flip Fill Cup Ice Cubes Float [PYTHON]Export Houdini Particles To Blender .bphys Cache Format Collision Deform Without Solver or Simulation Mograph Lines Around Geometry Waffle Cornetto Ice Cream Cone Ice Cream Cone Top Unroll Road Or Carpet Burning Fuse Ignites Fuel or Painted Fuel Ignition Painted Fuel Combustion Small Dent Impact Deformation Particle Impact Erosion or Denting Of A Surface Helicopter Landing Smoke And Particles Radial Fracture Pieces Explode Outwards Along Normal Tangent Based Rocket Launch Rolling Smoke Field Tear/Rip FLIP (H12 still works in H16) Rain Flows Over Surface Smoke Solver Tips & Tricks Folding Smoke Sim VEX Generated Curve For Curling Hair Copy and Align One Shape Or Object To The Primitives Of Another Object (cool setup) A Better Pop Follow Curve Setup FEM Sea Cucumber Moves Through Barrier Fracture Cloth Smoke Confinement Setup Merge multiple .OBJ directly Into A Python Node Blood In Water Smoke Dissipates When Near Collision Object Whirlpool Mesh Surface Simple Bacteria Single Point Falling Dust Stream Flames Flow Outside Windows Gas Blend Density Example Localized Pyro Drag (smoke comes to a stop) Granular Sheet Ripping Post Process An Export (Post Write ROP Event) Corridor Ice Spread or Growth Set Velocity On Pieces When Glue Bonds Break Water Drops Along Surface Condensation Bottle Grains Snow or Wet Sand Starter Scene A Nice Little Dissolver Turn An Image Into Smoke Fading Ripples Grid Example Stranger Things Wall Effect Face Through Rubber Wall [PYTHON]Create Nurbs Hull Shelf Tool [PYTHON] Ramp Parameter Select Outside Points Of Mesh, Honor Interior Holes Sparks Along Fuse With Smoke Umbrella Rig Melt FLIP UVs Tire Burn Out Smoke Sim Flip or Pyro Voxel Estimate Expression Motorcycle or Dirt Bike Kicks Up Sand Particles Push Points Out Of A Volume [PYTHON]Cellular Automata Cave Generator Punch Dent Impact Ripple Wrinkle VEX Rotate Packed Primitive Via Intrinsic Kohuei Nakama's Effect FLIP Fluid Inside Moving Container Particles Avoid Metaball Forces Use Google To Discover Attached HIP Files Useful Websites: Tokeru Houdini Houdini Vex Houdini Python FX Thinking iHoudini Qiita Ryoji Video Tutorials: Peter Quint Rohan Dalvi Ben Watts Design Yancy Lindquist Contained Liquids Moving Fem Thing Dent By Rigid Bodies Animating Font Profiles Guillaume Fradin's Mocap Crowd Series(no longer available) Swirly Trails Over Surface http://forums.odforce.net/topic/24861-atoms-video-tutorials/ http://forums.odforce.net/topic/17105-short-and-sweet-op-centric-lessons/page-5#entry127846 Entagma SideFX Go Procedural
  42. 2 points
    one possibilty would be to transform the geometry to uv-space, clip it there and than bring it back. or you just use the polycut-sop... hth. petz clip_uv.hipnc
  43. 1 point
    Quick tip about converting dense SDF volumes to VDB SDF volumes.
  44. 1 point
    Hi Ezequiel, Here is a simple mod that I did to your file for you to see a method to transfer color to the flip sim that is using the boundary layers option, just go inside the flip solver! I hope this helps! Alejandro flip_issue_aeb.hip
  45. 1 point
    Check out my latest project - creating an open library full of learning resources about various areas of VFX. It has many houdini-related presentations and theses. library: https://github.com/jtomori/vfx_good_night_reading blog post: https://jurajtomori.wordpress.com/2018/06/11/learning-resources-about-vfx-and-cg/
  46. 1 point
    Choose a better motherboard. That one maxes out at 32GB which means when you out-grow that memory limit you will be forced to build another computer. Think ahead now and grab a motherboard that supports at least 64gb maximum. When you buy ram, buy in 16Gb single chips, not 8Gb.
  47. 1 point
    The StaticObject is not the actual surface used in FLIP collision. FLIP contains its own collision surface which you can view (in purple) by activating the Guide on the FLIPObject. The FLIP surface object resolution is derived from the Particle Separation by default. So lower that value to increase FLIP collision resolution. You can decouple FLIP collision resolution from FLIP particle separation by enabling Override Particle Separation. Then just lower that value on it's own. Can you post a screen shot of that submarine model converted to a collision object? (i.e. the VDB representation). My guess is it might not be water tight.
  48. 1 point
    the LookAt parameter has been deprecated in favor of the new CHOP based constraints. (it IS still there if you Edit Parameter Interface and show hidden - but use the constrains instead)
  49. 1 point
    Hi all. I made something a few weeks ago that I thought might be useful, so I somewhat tutorialised it here: http://www.pixelninja.design/manhattan-voronoi-approximation/ Basically it's a method of achieving something close to a Manhattan-distance voronoi diagram. I hope someone out there finds this useful If anyone knows of a better method, or a method of achieving an actual Manhattan voronoi I'd love to hear it! ManhattanApproximation_01.hiplc
  50. 1 point