Jump to content

underscoreus

Members
  • Content count

    111
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by underscoreus

  1. Hellium balloon colission, wind, etc help

    You are right that you could try to stiffen up the pressure constraints to tr to minimize the squishing of the balloons. However, I think my implementation of using gravity as the main driving force for the motion of the ballons was too heavy-handed. If gravity is always pushing on the balloon you might need to make the pressure constraints very hard to be able to resist it and prevent the balloon from squishing. If you want them to float down the hallway then you might want to consider using a wind force instead, maybe if you dive into the vellum solver and place a "pop wind" node and then set the direction you might have some better luck.
  2. Hellium balloon colission, wind, etc help

    Heyo, I've had a look at your file. I guess I'll go over the solutions in a list for easier readability. Making the balloons float - To do this I simply did it quick and dirty by changing the gravity from -9.8 which is propper earth gravity to something like 1. The higher you put this the faster they fly up. Of course this is not a very elegant way of doing it but I'm unsure if there is a way to set a vellum object to have a weight lighter than air so that it will float away even if the gravity is set to its default value. Adding wind - To add the wind I simply used the "pop wind" node inside the simulation. Quickest and best way I know of to make some nice wind with some added noise. Collision - To make your balloons collide with stuff in a dopnet you'll need to use the "static object" node plugged into a merge node somewhere in your tree (note that this has to be plugged in "to the left" of the sim geometry or you'll need to change the collision relationship of the merge node to "mutual"). This brings the geometry into your sim and allows stuff to collide with it. However, for your case this is slightly different. Whenever you import alembics into Houdini they come in as "Packed alembic primitives", when you want to use geometry as a collider it is often the best to have it as plain geometry, so for this, you'd need to place down an "unpack" node and then possibly a "convert" node since when you unpack alembics they come out as "polysoups" instead of normal meshes. But, one thing I noticed is that your geometry does not seem like it would work very well as collision geometry. After unpacking and converting your alembic I can see that multiple of your faces are "z fighting", aka they are on top of each other. This is a big no no when the geometry is going to be used in any kind of simulation, whether for collision or the actual sim geometry. It all has to be squeaky clean and watertight or you'll run into issues. My solution here was to just make a simple box for the ceiling and each wall. Faster sim time - To improve the sim time I've simply reduced the number of polygons in your balloons which means there is less data for the sim to worry about. Often times in cloth sims you can get away with simming pretty low res stuff and then subdivide the geometry afterwards, there is a handy option to do this in the "vellum post-process" node. On another note, I've gone from using your autodopnet to using the sop version of the vellum solver just based purely on my own preference. I find it just easier and quicker to use the sop version of this solver when it comes to plugging in colliders and constraints rather than write out all of the paths etc. The last thing I'll say is that I'd always recommend trying to make things to scale when doing physics simulations. 1 unit in Houdini is 1 meter in real-world units and I've noticed that your balloons and building seem somewhat small for that. The scale is not a super important thing but it is a thing to keep in mind to make your sims go as smoothly as possible and give you the best result with the least amount of tweaking. Hope some of that info can be useful! Do note that I changed the scene in a non-commercial version so you might want to look at the scene and try to replicate it in or copy the node to a limited commercial scene so it does not limit you in any way. setup_v01t02.hipnc
  3. Installing Octane

    Haven't tried installing Octane and I'm kind of new to the whole .json way of doing it, but I'll include my layout for Arnold. One thing I'd be particularly mindful of is your last line: "path": "C:\Octane_2020.2.3.0_Houdini_18.5.532_demo_Win64" To me, this just looks like it is trying to explicitly set the whole path variable to be just the path to your octane demo. Maybe it could help to change around the "\" to "/". I've often found that most programs prefer the "/" to the "\" since "\" is often used as an escape character. My layout: { "env" : [ {"HOUDINI_PATH":"C:/solidangle/htoadeploy/htoa-5.5.0.1_r45f2926_houdini-18.5.351"}, {"PATH":"C:/solidangle/htoadeploy/htoa-5.5.0.1_r45f2926_houdini-18.5.351/scripts/bin"} ] }
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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?
  9. 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
  10. 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.
  11. 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.
  12. Simple Way to Disconnect Edge?

    Polycut sop set to "cut" strategy maybe?
  13. 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.
  14. 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.
  15. 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.
  16. 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.
  17. 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.
  18. 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
  19. Crashing

    @Renderhouse Nice, I can have a look at the hipfile, however, do you think you could either include the building fbx file or just check the "lock geometry" button on the file node reading in the building geometry (Snowflake icon button when hovering over a node. If you save the scene after checking this button it will save the fbx into the hipfile itself)?
  20. Crashing

    It's going to be a bit tricky to pinpoint the exact cause of your crash without an error message or the hipfile itself so I'll just be going over some general things below. System resources: Like I said I can't know for sure what the issue is but 16GB of RAM is not a lot. For an RBD sim it should probably be enough but when you could do is to open a system monitor like "task manager" on windows, "Activity Monitor" on mac or "htop" on Linux and check it while your sim is running. The main thing to look at would be the RAM usage. If the RAM usage climbs to the maximum amount then Houdini is prone to crashing since the sim tries to store all the data inside RAM and then write it to disk and if it can't fit it in the RAM it will try to store some of it in a temporary location on your main drive, however when it does this Houdini is very prone to crashing since this is a lot slower than just storing stuff in RAM. When it comes to reading your cache back make sure you have the "Load from disk" option checked. Again since I don't have the hipfile I don't know if you are using a "file cache" node or something else like a "dopIO" node. But it should be called the same on any node that supports it. If you are using a straight-up "file" node it should not be an issue since a "file" node can only read from disk. If that is the case just make sure that the "file" node has the display flag on it.
  21. analytical voxel displacement

    Heyo, I'm not sure I've completely understood what you want to do, but I've managed to make a "voxelized" sphere using this little vex snippet: v@P = lerp(v@P, floor(v@P), chf('Lerp')); Adding the lerp since I assumed based on the gifs that you wanted to animate the transformation over time. You could also change out the "floor" function for the "rint" function if you'd like the positions to snap to the nearest whole value instead of always rounding down. However, the advanced math you are doing in your VEX code is making me doubt whether or not I've understood what you actually want to do, haha. Hope it can help!
  22. importing abc files

    @Renderhouse Try using the "alembic" node when importing alembic's instead of the file node. Inside the alembic node you should have the options that DaJuice mentioned and it should solve your issue. After you've made sure the alembics are not imported as packed alembic primitives, make sure that your viewport selection is set to primitives and you could also try to toggle the lock icon on the left side of your viewport under the arrow icon as this sometimes limits selection options.
  23. Hey Haya, Here is a hipfile with those modifications. To change these kinds of orientations you'll need to fiddle around with either the normal attribute or the up attribute. In this case, it was the up attribute. I made this work by rotating the up vector 90 degrees if the line was going up or down. I rotated the up vector by using a matrix and the rotate function which might be very heavy-handed and overcomplicated here so if anyone else has a better, simpler solution that might be easier to implement/understand. To be able to figure out which pieces of the path goes up or down I simply added a polyframe node that outputs a tangentu attribute. This is basically just a vector pointing from one point to the next point on the path. So if the y component of that vector is too far from 0, meaning its horizontal, it's pointing up or down, hence meaning that that points up vector should be rotated 90 degrees. Good luck! Underscoreus / Martin pipe_02_electric_boogaloo_mnb.hipnc
  24. Attribute Wrangle Variable Return

    The more you know! I rarely ever deal with quaternions because my mind breaks whenever I try to understand them so whenever possible I try to avoid actually dealing with them. I don't know for sure, but this might be an area where you'll have to look at the point function like I mentioned in my original comment to get the attribute value. Not all parameters like fetching point attributes by just using the "@attribname" method because this essentially means you are doing this for each point in your geometry and not all nodes/node parameters are made to work like that. In the point function, you end specifying a specific point to fetch the value from so this is often more stable than just "@attribname". Also do note that is the thing you are putting this expression into usually takes text, like a group field, you might need to add a ` to the beginning to make Houdini understand that it is an expression and not just normal text.
  25. Attribute Wrangle Variable Return

    It's a simple syntax issue. Whatever you put in front of the "@" symbol when assigning an attribute determines its datatype and I don't think there is a datatype abbreviated with the letter "p", at least not one I am familiar with. You have "f" for float, "i" for integers, "s" for strings, "v" for vectors, "m" for matrices etc. I haven't been able to find an overview of them all but I'm sure one is out there. These are the most commonly used ones. This video, and series, from Sidefx, explain more about the basics of using VEX in Houdini and talks about the assigning of attributes.
×