Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About 9of9

  • Rank

Personal Information

  • Name
  • Location

Recent Profile Visitors

1,210 profile views
  1. Thank you very much yglemarec, that's pretty comprehensive - sorry it's taken a while to reply, I've been playing around with the grain solver all week and trying to get a handle on it The sea cucumber test scene works really well for me with both approaches at this point, but I wonder if I'm doing something fundamentally wrong with the way I'm setting up collision. Ultimately both with tets and with the grain solver, I seem to end up with the same fundamental problem - some grains or tets keep getting stuck on the wrong side of the collision geometry: In this case, you can see a few grains on the left of the image, but also a whole bunch on the right that are also apparently stuck on the interior of the collision mesh. Some likely get pinned by the forces acting on them, but the majority genuinely do just seem to clip through with very little provocation. Is there any good way of avoiding this behaviour? Many thanks again for the help!
  2. I can, for example, constraint a 'backbone' of points throughout the centre of the object, and that mostly eliminates the catching of tets around the edges, but still doesn't seem to be quite ideal. PenetrationTest_FEM.hip The rest of the mesh droops off quite noticeably from this central line - I could increase stiffness of course, but that would change the overall material response, too. I've tried adding a lower-strength constraint to the rest of the point, but even a very subtle one does lead to artefacting. And of course, even the 'backbone' of constrained points causes visual issues if it ever passes through collision that it doesn't have a path around will get stuck a little bit. Is there a better way to drive deformation from animation? The FEM constraint seems like a coarse solution.
  3. Thanks! I mean, that's my starting point It's good advice - I'm using fairly similar settings, but the main thing I'm doing differently is I'm using a target deformation to drive the animation, and that seems like it's the main reason for the sticky tets. The target deformation, in order to push the mesh up through the opening, has to be strong enough to overcome the stiffness of the solid, but that means when the tets press up against a barrier, the force is stronger than the elasticity pulling them to the side and ends up pinning them to the surface, which I guess is part of what makes them stick and, eventually, clip through the collision volume. That does make things a little awkward though. I can get it to, for example, pass down through the opening under its own gravity, but what's the best way to drive the animation in this case? If I increase the target deformation strength, it ends up sticking to the collision, but if I lower the target deformation strength, its left without a strong enough force to get through the opening at all.
  4. I'm trying to simulate some relatively complex interactions between a squidgy, soft-body tentacle kind of asset and some arbitrary, sort-of-complex geometry. FEM seems like the best way to go about this - I've tried cloth simulation, but but there's little else that easily gives me the really nice volume-preserving properties I get out of the soft-body solver. Overall though I'm still kind of a noob at this, so I'd appreciate completely different suggestions on how to do this My main problem is that no matter what I do, I seem to very easily get tets being stuck on concave geometry. I'm attaching a scene that I've been using as a technical test to try and resolve the issue - it's pretty representative of the issues I get on more complicated scenes, but with faster iteration times. The objective is to get this sea cucumber to pass through a narrow, concave space in an organic, slippery, squishy way. Mostly it behaves correctly, but the problem is that eventually: Some of the tets will get weirdly stuck on the geometry The unfortunate thing is that increasing substeps and collision passes only seems to make this worse - with more collision passes, more tets seem to get stuck, and it becomes harder for them to get unstuck! I don't have any friction on either object, and ideally I'd want them to pass through each other really smoothly. Is there a good way of achieving that? Or anything substantially different I could be doing, to get the same effect? Would love any advice people might have! The scene itself: PenetrationTest_FEM.hip
  5. File SOP - automating FBX export for games

    Thanks, it's just the kind of thing I was looking for. Unfortunately, I don't think I know enough about rop networks to make this work - using a single fbx node to export over a frame range just writes out all the objects I'm after into a single fbx with a vertex cache, which isn't quite what I was hoping for. Trying a more laborious set up of having a separate fbx node for every frame and setting it to render across a specific frame range (of one specific frame per node) kind of works if I trigger them individually, but where I would expect to be able to wire them up to a Merge node and have them all render at once, they do, but they all only render the final frame for some reason.
  6. I've found myself using the File SOP a lot to export series of meshes for import into a game engine - in this case mostly Unreal Engine 4. It tends to be really useful to have a File sop at the end of your network, so Houdini updates a series of assets every time you change something in your SOP network and cook it out again, especially as game engines tend to automatically pick up on the changes and reimport those assets. However, while this tends to work okay with .obj files it's a lot more awkward with .fbx ones. Unreal tends to be quite picky about the .fbx formats it will read and if I go through the File > Export > Filmbox FBX route then I get a dialogue that allows me to specify the .fbx export settings and set it up to be a format compatible with Unreal. That works fine! But if I want to automate mass exporting within my sop network using File sops, then there doesn't seem to be any way of actually configuring the FBX export options. I thought perhaps they defaults you set up in the FBX export dialog would be used, but they're not. So I can either laboriously go through and export every FBX file by hand, or I can get fbx files spat out by the sop network automatically, but they are not readable by Unreal. There's got to be a way around this, surely?
  7. Still fairly new to Houdini and can't quite escape the feeling I might be going about this completely the wrong way, so I'm curious what ideas the good people of odForce might recommend. Strangely, I've not found much in the way of discussion of this sort of problem for Houdini - though perhaps I have not been looking for the right terms? What I'm attempting to do is shrink-wrap a generic mesh (e.g. a high-density geosphere) onto a mesh of arbitrary shape under it, while retaining the geosphere's original topology, preserving as much detail of the source mesh as I can, maintaining as even a distribution of points as possible, and - preferably - doing it fairly quickly. The arch reason for doing it this way (rather than, say, doing a polyReduce on the source mesh or something) is that ultimately feeding in several different source meshes should produce different shapes with the same topology, which can then be smoothly interpolated between. For instance, several frames of a Pyro sim could be meshed, shrink-wrapped and then turned into a vertex animation to create a sort of a 'smoke-in-a-bag' effect. Primarily for real-time rendering purposes where importing a separate mesh per frame would not be a practical solution. The best I've come up with myself is the method I've attached below along with this post. Using a ray sop by itself tends to produce very messy results, so I use the ray sop to cast to minimum distance, then lerp back to 15% of a blend between the original position and the ray sop, relax the points on the result in order to even out the topology and then use a smooth sop to even out the jitters introduced by the relax sop. Iterating this around 20-50 times (depending on the mesh), getting a little closer to the source mesh every time, tends to result in a cautious and slow shrink-wrap that accommodates most meshes without too much artefacting and keeps the geosphere quite nicely and evenly stretched out across the whole mesh. However, it's proven to be very, very slow to run the iteration and I feel like surface detail could be better preserved. As such, would quite like to hear if anyone can suggest other approaches to this problem! iterativeShrinkWrap.hip