Jump to content


  • Posts

  • Joined

  • Last visited

  • Days Won


Everything posted by DennisSchmidt

  1. There is a great explanation about packed primitives on the SideFX help doc: http://www.sidefx.com/docs/houdini/model/packed In your case, I don't think it makes much a difference. If you use packed primitive you are not compressing anything. It's just keeping it in memory and just using a small amount of ram for referencing it. But if you are planning to copy it multiple times it makes sense to use packed primitives. Since then it will refer to the geometry already stored in memory and also drawing it in the viewport will be much quicker since it uses the data already stored and just adds a different transform to draw it. If it's just for rendering I would recommend using packed disk primitive in the file load. Since that creates a reference to the file on disk rather than having it in memory. This is also very efficient for viewport display and rendering. As well as for copying(same as before with packed primitives, only you have to unpack to do any changes other than transforms). For very big scenes this comes in handy as it creates a reference to the file on disk and especially for IFD's the size won't grow as much.
  2. As always there are many solutions to this. If you are familiar with CHOP's that would be the easiest. Just right-click on the channel and go to motionfx and add noise. You also mentioned the mountain SOP. What you could do is create a single point and modify that with a noise(mountain) and then reference it to your translate/rotate/scale of your locator channel with the centroid expression for example. centroid("../geo1/OUT_noise/", D_X) for the X channel of your moving point. D_Y and D_Z give's you the other values. This is just one of many possible options.
  3. Ah, I get it so it was the padding as mentioned in my previous post(there is also an option to visualize it which makes it easier to adjust). And what exactly did you do? Did you increase it to something higher than 0.02? I am wondering why you would want such a high value since it's not representing the geo and when the scatter sphere is scaled the boxes are not touching and wouldn't need to explode unless you add more of them. Sounds interesting what you are doing though, just curious : )
  4. Can you elaborate a bit more what you mean by "not working" and maybe what you are trying to achieve? Since for me, everything is fine. The only difference is that you get an "explosion" due to touching polys and as soon as you scale the scatter-sphere they no longer touch and don't explode. The reason why they still move once visibly separated is due to the collision padding. Check the Bullet Data tab on the rbdpackedobject to visualize the guide geo as well as the padding.
  5. The best way to check your collision geometry is to visualize it in the object itself. So in your example, if you go to your static object and in the Bullet collisions tab tick on the visualization you can see that the problem is, as you guessed right, the convex representation of your object. So either change it to concave (which will be pretty heavy depending on the resolution of the incoming geometry) or as Olly suggested, fracture your Object into smaller pieces that aren't concave. Bring them in as packed and set the "active" value to 0.
  6. Did you get it to work yet? Would you mind setting up an example scene or describe more in depth of what you are doing? Would be interesting to see. The script works fine for me. Dennis
  7. As usual, there are many ways of doing this. One would be setting the collisionignore with a wrangle. The collisionignore is a string attribute and works the same way most of Houdinis include/exclude with "*", "* ^except", "only". So for your example, just group the objects you want to ignore the collision and assign the collisionignore attribute with the desired value(for example "*" for ignoring all collisions). If you want to only exlude specific objects you have to use the DOP objects name. Quick example: if (@group_nocollide == 1) { s@collisionignore = "*"; } Take a look at the attached file. There is a simple setup showing what I mean. Hope that helps. Dennis collisionignore_setup_v01.hiplc
  8. "Teamwork" is the best node ever Yeah, I absolutely agree with you. Maybe there is a better solution. What is actually happening is that modeling is done in ZBrush and rigging is supposed to be done in Houdini. Therefore I think that this is the most efficient solution. And I love to learn new things too so I got a win-win situation here Oh, and by the way, I sorted it out with your method. Really great. Thanks a lot for that. What I did is just add a name attribute to the points and the geo and then use a transform pieces node. Works perfect. The only thing I had to add was a center point for calculating the UP vector. I highlighted the added nodes in red. Thanks again for your help! Dennis rotate_objects_local_v03.hiplc
  9. Thanks F1 and Michel for the reply and your time looking into my setup. Good to know that I was just missing a normalize node. But makes sense and thanks for the link for further explanation. Now just to take it a bit further, is there a possibility of doing the rotation somewhere else in space(not the origin)? As you can see at the moment I am moving each piece to the origin, doing the rotation and then moving it back to where it was. So rotating around a given point would be a nice addition. I have been trying but so far no luck. Your approach Michel is kind of what I was thinking of. Very nice way of doing the transform on the points. And a very nice solution in the wrangle node. Almost better to read than in VOPS The thing that I am trying now with your solution is to use each individual piece from the spiral. The reason is because the geometry that I will be applying the effect to will come from another application and every piece is unique. Any idea? Thanks both of you for your help and solutions! Really great.
  10. Just tried it and it worked for me. All the second parameters get a number added. How I did it was by opening the parameter interface editor first. Create the folders and then dive in the VOP network. Then just created the input parameters for the first noise. They immediately appeared in the parameter interface editor and I dropped them into the first folder. Then the process was repeated for the second noise. No problems, errors or corrupt parameters. I am on Houdini 15.5.565.
  11. Hi there, I have been trying to figure this out but probably don't know enough about transform/rotate matrices and how they work. What I got is a circle of flat boxes all orientated in Z. The flat side is always faced to the center of the circle. See attached image for better understanding. Now what I want is a rotation around the local X axis of each box. Attached is an example file to see what should happen and also what I have come up so far. To better illustrate what the end result should be there is the same setup built with a copy SOP and a transform node before to do the rotation. Now the solution I came up with kind of works. The main problem is that there seems to be some sort of scaling. You can see this when viewing the solution made in Houdini in template mode. Maybe someone can point me in the right direction. Also, my setup is not very elegant so if there are other or better solutions I would love to hear them. Thanks in advance! Dennis rotate_objects_local_v01.hiplc
  12. As Chris said, you use it to bind your SOP source to the fields. Or remap them. So you could use your density as temperature field or add a second Source Volume and add density to the divergence field for example. The Volume Operation describes how your source is added every timestep. You could easily check if you turn your Source Volume to copy instead of add and notice that your volume gets replaced every frame. This could be useful for example if you don't want your incoming velocity to add up each frame (but be aware that all your velocity will be replaced when using copy).
  13. As far as I know you can't edit standard parameters of nodes like transform. You could create a new parameter, reference it to the old one and make the old parameter invisible.
  14. Just use your life attribute instead of the frame. Take a look at the transform node inside the foreach: fit($F, 1, 25, 1, 0) For example, just change it to: fit(@age, 1, 25, 1, 0) Take a look at the attached file if necessary. Don't get confused about the wrangle before the foreach. It's just there to create an age attribute to demonstrate it better. Feel free to ask if you get stuck. scaleOverTime_v02.hipnc
  15. If you could share your file, would be interesting. As always there are a ton of ways to do this. It all depends on the needs and how procedural it should be. Attached you can find a quick and "dirty" approach. The changed or added nodes are colored yellow. Maybe later i will find some time to build a more elegant version. constraint_visualize_v03.hipnc
  16. As Dominik suggested, just exclude the object in your popnet node under the "Object merge" Tab. The asterisk exports all your inputs. You could either only export your "popobject" or exclude your collision geometry. For the single export replace the asterisk with "popobject". For the exclude keep the asterisk and add your collision object with a "^"(example: * ^staticobject1).
  17. Your constraint setup is not complete. The constraint needs two names so it knows what to connect. At the moment you only have the name of the boxes. What you are missing is the name for the second point of each constraint which in your case is "box0". One possible solution would be to initialize the name with "box0" and override the second point of each constraint with the corresponding box. And since the constraint attaches the boxes to the moving object you shouldn't be adding the same movement of the Ball to the constraints before importing to DOP's. Maybe the image in this post will help understand how constraints are typically set up: Hope it helps. Feel free to ask any further questions Dennis
  18. Nice. So I guess that the names were mixed up and therefore the constraints would try to hold the wrong pieces together...maybe
  19. Weird. But I kinda like the motion Are you using any forces? Looks like some kind of wind/turbulence. Any chances uploading the file? Would be interesting to see what's causing this awesome effect.
  20. As you described, glue constraints will hold together until deleted or collision. A force breaking on glue constraints does not work. If you want to use forces you would have to use the cone twist or similar constraints. So your file looks fine to me. Setting the active value also looks correct. I found a file from an older post I made where the conetwist and the active value was used. Check it out to better understand and see one way of how to set it up. Hope it helps. Dennis active_with_constraint_v01.hipnc
  21. Just made a simple sand/grain setup and it works fine for me. And Open CL even works with the checkpoints. I think its something specific to your scenario. Are your files that small after you try to continue the sim? Be sure to have a trail of at least 2 or 3 since the last checkpoint is not complete when the sim crashes(to be sure just delete it, normally the frame is smaller than the others). Another important part is continuing from the correct frame. Note that the checkpoints frame count starts at 1. So if your sim starts on let's say frame 1000 and crashes on frame 1020 the last checkpoint would be 21. Now you would continue caching from frame 10019 since the last checkpoint(21) should not be used. I think the workflow is clear and it's something specific to your setup. But just in case i attached the sample file. Is it possible to upload your scene? sand_simtest_v01.hipnc
  22. Strange. I only used checkpoints with pyro but I think it should work for other solvers as well. I will give it a try later. Oh and Open CL with pyro works fine. Are those files your caches or the checkpoints? Have you tried recreating a simple setup? If it's still happening maybe you could post the hipfile.
  23. Yep, you have to use checkpoints. Be sure to set a trail length. Those files will be picked up and used for continuing the sim after it failed or was stopped manually. When setting a different output directory for the checkpoint files make sure you create those intermediate directories otherwise the files won't be saved. Check the attached file if you get stuck. Dennis DOP_continue_cache_v01.hipnc
  24. To simplify the process of setting up the network itself you could have them merged and loop over each object creating the wanted network. One solution would be by grouping the objects with a unique prefix before merging them together and then looping over that group prefix. For example "obj_box", "obj_sphere" and looping through the group mask of "obj_*". Then create the constraint name and type. Now you can proceed as Andrii described. Check the attached hipfile if you get stuck. Hope it helps, Dennis multiple_glue_setup_v01.hipnc
  25. It works for me. I just changed the copy of the boxes from 3 to 4(did you do the same?) and the copy of the lines also to 4. That was it. I think you forgot to add to the number of line copies. So there is no constraint created. A good way to check is looking at your geo spreadsheet. There you would see if there is a point connected to box3. If you select the OUT_ROT1 and look in the spreadsheet of the attached file you can see that point 5 is connected to box3. The second point belonging to that primitive is point 4 and it is connected to box2. Therefore, it should hold box2 and 3 together. Hope that clears it up a bit. constraint_visualize_v02.hipnc
  • Create New...