Jump to content


  • Content count

  • Joined

  • Last visited

Community Reputation

14 Good

1 Follower

About DennisSchmidt

  • Rank

Personal Information

  • Name
    Dennis Schmidt
  • Location
    Munich, Germany

Recent Profile Visitors

830 profile views
  1. Pack SOP and optimization

    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. how to give noise per primitive

    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. [novice] Strange collision behavior

    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. [novice] help with Python Script

    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. Bullet collision ignore

    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. Rotate by local axis with VOP / VEX

    "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. Rotate by local axis with VOP / VEX

    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. unified noise parameter mess

    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. Pyro Question

    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. Copying Constraints?

    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