Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


underscoreus last won the day on March 30

underscoreus had the most liked content!

Community Reputation

27 Excellent

1 Follower

About underscoreus

  • Rank
  • Birthday 09/02/1996

Contact Methods

  • Website URL

Personal Information

  • Name
    Martin Brattensborg
  • Location

Recent Profile Visitors

321 profile views
  1. I haven't worked with instances in a version newer than 18.0 Redshift and Houdini, however the last time I tried I was under the impression that Mantra and Redshift used different instancing attribute names. One used instancepath and one used instancefile, I think Mantra uses instancepath and Redshift uses instancefile. Could this be of any use? Because I would have thought that the final point count after instancing would matter a lot less if they are all instanced since it just reads the same file from disk. Also just to have asked, are you trying to instance a .rs file or a .bgeo file? Because I believe that Redshift prefers to instance .rs files over .bgeo files.
  2. grouping pts with bounding box vex

    Have a look at this thread: I personally tend to go for the SDF and volumesample() option. Just remember that inside values of an SDF are negative and values outside the mesh are positive.
  3. Yeah, that is the downside to my method. Attributes would have to be transferred back from the original geometry onto the new geometry and you could end up losing some details depending on how many small details are in the original geo and how high res you make the VDB.
  4. Vellum - Different Rest Lengths control in one Cloth

    Heyo, had a look and came up with the setup below. Still some improvements that could be made, like having the shrinking of each constraint happen over the course of a few frames instead of instantly to get a smoother transition etc. One of the key nodes when working with vellum and wanting to really art direct your cloth like this is the "vellum constraint property" node. As long as you have that and either an initial group or use the vexpression tab to fetch attributes or groups from sops then you can do A LOT of stuff with Vellum. The setup below mainly works by creating an animated group in sops to control a rest length multiplier attribute on the vellum constraints. This is done by using a solver sop and merging the current frames group with the previous frames group and then adding to it, causing the group to grow over time. Then setting a rest length multiplier attribute, "rest_mult", based on the animated group. If you are in the group, have a lower rest length multiplier, if not, just be normal and have a value of 1. Then lastly using the vexpression in the "vellum constraint property" node to get this animated attribute from SOPS and bring it into DOPS to have it multiply with our rest length scale. Hope that can be of help! animated_restlength_mnb.hiplc
  5. Debri Source and Alembic

    Heyo, if you want to share your hipfile remember to either include any external files like alembics or lock the import node (in this case the alembic node) so it saves the geometry into the hipfile you share. If not we just end up with an import error when we download and look at the hipfile. As for your issue, there are two things I'd try. 1. Instead of "Edge debris" try using "Surface debris" instead. I've sometimes had it that the edge debris pushes points a little outside where they should be and I also just personally prefer surface debris since it uses the whole inside surface instead of just the edges. 2. You could try to use the group field in the "debris source" node to explicitly tell it what faces/edges to scatter on. By default it is looking for a group called "inside" I believe. Based on just running a normal box through your setup it does not get any faces in the "inside" group, only stuff in the outside group since the "fracture level" was set to 0. Maybe this is your issue? That there is no prims in the "inside" group?
  6. Hey @fell00, Great that you found a solution! I'll attach a hipfile here with the way I would go about something like this. It essentially boils down to not using booleans at all but rather use the "vdb combine" node. Doing boolean-like operations but with VDB's is in my experience WAY more stable, however, it comes at the cost of having to compute the volumes, both converting the geometry to a volume and then back again at the end. But, the times I've needed something like this it has been a preferable alternative to dealing with the booleans unreliable nature. Hope it can help! deforming_boolean_alternative.hiplc
  7. Crashing

    I'd recommend you check the forum if others have asked similar questions to what you'd want to ask before and had them answered, and if not, make new topics for any other questions to keep everything as organized on the forum as possible.
  8. Glue Constraint Guide geometry red lines

    Indeed it does. So after having a look I can't see any of your constraints freaking out like in your screenshot, however, that might be because nothing actually happens in the sim. The dam just sits there. So once again I don't have anything except speculations, but one thing you could try is to remove the expression of the "overwrite with sop" parameter on your "glue_Destroyable_Z_RockCribs" "constraint network" node and set its value to 0. By default this thing runs a python expression, checking the input of your constraints from SOPS and checks if they have been altered, if they have then it will reimport your constraints in the sim with the ones from SOPS. Which is probably not what you want in this case. If you set its value to 0 then it will import the constraints once at the start of your sim and never reimport them, letting them die off during the sim as you please.
  9. Simple Way to Disconnect Edge?

    Polycut sop set to "cut" strategy maybe?
  10. Distributed SOP cooks?

    As far as I know no, there is no built-in solution for general distributed sop cooks. I guess the same can be said for DOPS. No general way there either, always specialized tools. One for FLIP, one for Pyro etc. But for SOPS I think you'd have to make your own little setup if you wanted to distribute it. However, most cooks in SOPS should not be that long anyway so distributing the task might create more work than it removes. Whenever I've encountered these kinds of issues, and it's always been because I ran out of system resources, I've always just split my geometry/volume in two, three, four, or five pieces and ran the task on each part and merged/fused it back together.
  11. Crashing

    Looks good! Glad you've got it working. I mostly only deal with Houdini on the forum here and maybe some on the Houdini artist Facebook group. Leaving discord for casual chat with friends etc.
  12. Glue Constraint Guide geometry red lines

    Heyo, if you post your hipfile (including any external geometry needed for the scene) it would be easier to analyze the issue. But taking a shot in the dark it might be because of what you are connecting with the glue constraints maybe? Is there some geometry out there at the end of the constraints? Also to have asked the question since your viewport grid is turned of, are the constraints going to world 0 on the viewport grid? If so then they most likely could not find the other object they were supposed to connect to.
  13. Crashing

    There are a lot of resources out there, some paid, some free. Most of them are probably listed somewhere here: https://forums.odforce.net/forum/66-education/ However, the tutorial series that I have recommended before is either this one, "Houdini is not scary". Or, the ones in this playlist, however they are somewhat more fast-paced, "SideFX Houdini For Absolute Beginners". Both of these have videos in the same playlist where they start talking about RBD sims, however, it might be a good idea to find tutorials specifically for this topic as they might be better suited for that. Learning Houdini is going to be a step-wise process of encountering a problem or process you haven't done before and looking for a tutorial on how to overcome that problem or a tutorial to learn that process. I don't think there are very many online courses that have it all in one. Though maybe someone with better knowledge on the tutorial landscape out there can correct me on that. As for an explanation of the specifics you are mentioning in the hipfile I sent you; If you want a greater contrast between the smallest and largest pieces you can either turn down the "scale" parameter in the "point replicate" node which should give you pockets of smaller pieces or you could use a good old trusted technique where after you first fracture your pieces with a Voronoi fracture you fracture some of the pieces again inside a for loop. This is going to be a somewhat slower process since for-loops are pretty slow, but if you've got to do it you've got to do it. Either that or have a look at constraints like mentioned in this video by Steven Knipping Yes, you are right, in FX we usually have multiple layers of FX to get the final result, one layer is the RBD sim of the building collapsing and from that, we make debris/grains sims for the small crunchy details as well as another sim for smoke/dust clouds. The "for each begin" and "for each end" are what make up a for-loop (or a for-each loop) in Houdini. To simplify the explanation of what it is it allows you to execute every node that is between the for each begin node and the for each end node x amount of times. Where x is determined by the user, it could be a certain number you choose or in the case of that hipfile I sent you, x is the number of pieces that we get from the Voronoi fracture node. This is a very simplified explanation skipping a lot of the technical stuff but I don't think I can write up a good enough paragraph about it here to cover everything. As for the playback speed that all has to do with what nodes and what settings you set on the nodes as well as in what order you place nodes. It's all about optimizing your node tree so that Houdini has to do the least amount of work possible which means that you get a faster and more responsive scene in return. I don't think I optimized your scene that much, I think the main gain is coming from there not being two buildings that were stuck inside each other inside your rbd sim as well as using points rayed to the surface of your building instead of the mountained spheres you were using before for your Voronoi fracture. My rule of thumb with voronoi is that if it takes more than 10-15 seconds to compute, something is wrong. The voronoi algorithm is very optimized and very fast, so unless you have a crazy high-res geo or you are trying to make hundreds of thousands of pieces it should go very fast to fracture using voronoi. To use the "filecache" nodes simply click the "save to disk" button inside the node and it will cook the sim and save out the result to your disk, and as long as "load from disk" is checked it will read the cache from disk when you playback instead of trying to cook the simulation again. Just note that if you ever make changes to your sim you'll have to "save to disk" again to see the updates when looking at the "filecache" node in the viewport.
  14. Copy to points problem

    Make sure the points you are copying to have the same normals as the surface you want the geometry to follow as well as give the points you are copying to an "up" vector attribute. Try having the vector be 0,1,0 to begin with and maybe change it if it does not work. If you upload your hipfile it'll be easier for people on here to have a look at it so for now the advice above is just speculation on how to solve the issue.
  15. Crashing

    Alright, I had a look at your hipfile and I came up with some examples on how to better utilize the Voronoi fracture node, how to use the file cache node, and preventing there being two of the same building in your RBD sim. I have come up with a solution on how to combine the Voronoi and boolean fractures so they both work on the same building, however, this is not a very good solution as it is very slow and doing boolean operations like this is VERY prone to causing bugs and issues. Boolean fracturing is not a very stable way of doing things, especially when your geometry starts getting complicated. I'd recommend having a look at a tutorial/tutorial series on RBD sims and fracturing to get a more detailed explanation of everything and how it works, but just as a quick rundown of what I did: Instead of using spheres for the Voronoi fracture, I use point clusters that are then rayed to the geometry. The Voronoi fracture node only uses points, not geo like the boolean fracture so my go-to is to use the "point replicate" sop and then if needed use a "ray" with "minimum distance" enabled, then shove that into the Voronoi fracture node. To get the boolean working I add a for loop to run over every piece we get from the voronoi fracture and then only boolean the geometry that is near the piece we are currently iterating over. Blasting the other geometry is simple to save cook time on the boolean fracture node since it is slow and we need to cook that node 2000 times with this method. Like I said above, not a very good method but I'm not really sure of another, better, method. I choose not to hook up this to the RBD sim since it is so unstable and often gives bad geometry, so in the hip I've only connected the voronoi fractured tower. In the dopnet I haven't changed much, just rearranged some of the nodes based on my personal preference and removed one of the two RBDPackedObject nodes since you're only supposed to have one, unless you have multiple buildings etc. After the dopnet I just placed down a dopIO and a filecache node since I could not see any file node in the file for reading in the geometry from the sim. To cache the sim, simply just use the file cache node here at the bottom of the node tree. Hope it helps, good luck! buildbreaking_mnb.hiplc