Jump to content

ChazS

Members
  • Content count

    43
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About ChazS

  • Rank
    Peon

Personal Information

  • Name
    Chaz Sutherland
  • Location
    California
  1. TY! I'll dive into this ASAP and report back.
  2. This problem only occurs when outputting from TOPs. Why would it write to my user directory and not to where it's specified to go (a different hard drive drive altogether)? The paths in Edit >Aliases and Variables >Variables are correct, as are the paths in the file caching node. Is there another place to look?
  3. [SOLVED] In/Active Constraints

    Thank you, that was the issue. I simply created a new constraintnetwork node with fresh params and it now works. I'll switch the cannonball to rbd as well, but being rather new to Houdini, I'm curious as to why this is necessary? addendum :: I made the ball an rbd and have fed it into the rbd solver but no matter how much velocity and density it has, it won't smash through the walls. However, the castle does collapse. I'll mess with the glue constraints, but would like to know if there are any other parameters I should be paying attention to as well?
  4. [SOLVED] In/Active Constraints

    I'm trying to shoot a cannonball through a small castle. The cannonball animates and blasts through the walls, but the constraints look like they're being ignored (or they aren't hooked up properly), so the entire structure collapses the moment the sim begins. The clusters are being ignored as well, but I can't figure out why. Many thanks for you even reading this. v17.5 rookDestruction_chazS.hipnc
  5. Planting points

    Thank you davpe. Despite finding another way to make this work, I'm going to give this method a try too. Never hurts to learn all the ways to skin a cat
  6. I have a lightning bolt with a start and end point, where the end point snaps to a ground point, triggers, plays out and disappears. I'd like to procedurally add an effect to where the lightning contacts the ground. My thinking is that when the end point of the lightning snaps to the ground point, to somehow spawn a new point or capture the ptnum of said ground point. From there a new effect triggers... ?? Problem is that I don't have a clue how to capture a single ptnum or reassign it somehow to begin the last effect. Is my logic flawed? If there's a simpler way... or even a more difficult way, I'm all ears either way. I have a sneaking suspicion this is probably an elementary thing to do, but haven't figured it out. My apologies if that is the case.
  7. [SOLVED] Normals point away

    Ahhh... I see now... I just wasn't considering distance as the value in question (which flcc was referring to earlier, d'oh!) since my brain was thinking of angles, not distance. Somehow I was thinking there was some intrinsic angle to P I wasn't seeing/understanding (spreadsheet would say otherwise though... ugh, *shame*). It didn't occur to me these values can commingle. My background in game vfx using proprietary tools which always had points carrying basic transformation parameters (position, angle and sometimes color), but this isn't how Houdini works. Old dog and all... So what's happening is that the distance vector of P was being added to the normal value of 'a' causing the seen behavior. This is another example that data is just data despite whatever name or expectation I place on it. I will take your advice and begin to look at the geo sheet more carefully. I have been trying to use it, but I'm not sure what I'm looking for at times, but this helps immensely. No excuses though, I hadn't looked at it in this case, but will do so from now on. Anyway, humbly and delightfully educated and corrected, so thank you both for dispelling this for me.
  8. [SOLVED] Normals point away

    Obviously I'm missing something here (so you have my sincerest apologies for the bother) but yes, the fact that the value of P increases as it moves away from the center doesn't make sense to me. Reason being, I'd expect values to decrease the further they are away they get from its origin. What does make sense—and I'm not claiming this is what's happening, but please bear with me—is that the value of P is a constant value and that a.y loses its mojo the further away from the point it gets. This then allows the influence of P to become more noticeable as a.y decreases...?? Anyway, that's just what's clicking with me, although I'm not married to the idea, so hopefully your explanation will click into place at some point.
  9. [SOLVED] Normals point away

    Okay, the distance thing I get, but what doesn't make sense is that the values grow over the distance (away from the center)... shouldn't the reverse be true and the stronger values be toward the center?
  10. [SOLVED] Normals point away

    I hadn't realized that P had a distance falloff. What's still a little confusing is that P.y having less effect toward the outside since it has no value. For some reason, my brain wants to reverse that logic. Gonna need to chew on that info for a bit. Hopefully it'll make sense sooner than later. Thank you flcc.
  11. This is a simple network consisting of a circle with a scatter node that's followed by an attribute wrangle to create (and orientate) some normals upward. It's working but I'm curious as to why all the normals lay down as they get further away from the center of the circle. Here's what's in the Att Wrangle :: vector a = set(0,1,0); @N = normalize(a+@P); Increasing the Y parameter affects the normals' direction (e.g. a value of 1000 forces them straight up without a noticeable difference in their relative angles, where a value of 1 has the noticeable falloff like influence). I'm wondering why it has a stronger influence toward the center of the circle?
  12. Path following disparity

    It's obvious now that I was really overthinking it. Splitting after a dopio hadn't occurred to me to even try. That is what you mean, correct? I only ask since this is still new to me and I don't want to make any assumptions. I split the forces in the dopnet (which is where the disparity happened) but your solution was to kill one of those streams and split it after the dopio node. Your solution is so simple and elegant.
  13. Path following disparity

    What a simple and embarrassingly obvious fix *face palm*. It's so good that (despite my curiosity about my posted issue) I'm going to call it done for now and move on. Thanks Jesper.
  14. Path following disparity

    I hope a particles issue qualifies as an effect, so you have my apologies if this is the wrong sub-forum. However, if I'm in the right place my dilemma is as follows... ...In the attached file is a simple double helix curve and a dopnetwork pulling the particles upward on it. What's curious is why the particles move up the curves at different speeds. Especially considering that the two curves are using the same POP Curve Force & popstream nodes... how is this possible?? I've tried multiple things, like switching the poplocation inputs that feed its appropriate helix and turning off the gravity to no avail. The best result was adjusting the Pop Curve Force node >> Global Forces tab >> FORCE ALONG PATH ramp. This adjustment brings them close but still not quite right. Anyway, thanks in advance. followPath.hipnc
  15. The latest version of the source volume dop has a new name (sourcevolume >> volumesource) but more so, tabs have been consolidated into one... I think?? At least it looks that way since the volume operation and mask components seem to reside in this new, single volume tab. Anyhow, here's a snip of both versions and my attempt to translate from version 16 to 17. Am I doing this right?
×