Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won


Darric last won the day on October 17 2012

Darric had the most liked content!

Community Reputation

3 Neutral

About Darric

  • Rank
  • Birthday 01/04/1986

Contact Methods

  • Website URL

Personal Information

  • Name
  • Location
    Naughty Dog, Santa Monica
  • Interests
    Games, Films, Books
  1. FX in games, where to get started?

    I can't speak for DICE, and I haven't researched that Battlefield building collapse at all, but it's almost certainly entirely pre-simulated. You wouldn't risk having something as drastic as that in a multiplayer map utilizing any realtime simulation, except for small debris. Not when you need to maintain a consistent framerate and sync over a network. Like others have said, presimulated animations are used extensively in games, even in singleplayer. Realtime simulation still has a long way to go, (DMM is impressive, but limited in realtime). Any time you want to art direct a collapse to behave in a very specific way, it just doesn't make sense to leave it to the whims of a realtime solution. The same is true of (sometimes), cloth and fluid simulation. Good cheap realtime cloth exists, and it's used extensively for characters, but sometimes for specific fidelity or looks, presimulated is the way to go. Generally, if there's any risk of a realtime solution producing an unfavourable result, you bake it - it's more optimized that way, anyway. Believe it or not, Alembic *is* used in some engines. I forget other examples right now, but Crytek's Ryse used realtime Alembic loading extensively. For our part at Naughty Dog, every animation (cloth/rigid body/fluid) that isn't done in realtime gets baked down into a joint animation, and is handled virtually identically to any other animated object/character. For destruction, that means large scale structure or building collapses (we still rely heavily on realtime physics for anything the character can interact with). On the other hand, cloth is almost entirely realtime in Uncharted 4 (using a vertex shader technique that integrates with our wind system), except for a handful of instances where we specifically needed more interesting looks, fidelity, or character interaction - this certainly wasn't true for The Last of Us, where almost all the environment cloth animations were prebaked. Our fluids are also almost entirely realtime now - but we typically don't have anything with the fidelity of a FLIP or SPH solve in-game, except for some closeups in cutscenes.
  2. Random link of interest

    Yours is much better!
  3. Random link of interest

  4. As one of a handful of Houdini artists in a Maya studio ... This. Is. Incredible. My only question is how does Houdini Engine interact with licensing? Is there a separate pricing model? Will it be prohibitively expensive to get, say, 5 or 6 people running Houdini Engine in Maya while I have the sole Houdini license for development?
  5. What I normally do is use VOPs to go Quaternion to Matrix, followed by an Extract Transform VOP to get you the Euler rotations. Edit: Whoops, that's exactly what's in Marc's link. ><
  6. stretching using timewarp on cache

    If you use a timeshift (I much prefer this to using timewarp, I normally just create a curve for my Frame parameter) make sure you uncheck "Integer Frames".
  7. It takes a little bit more than in his post, but it works. Nice idea, Edward. sum.hip
  8. Procedural rolling wheels

    Yay, calculus!
  9. I'm surprised this isn't an available option on the Wireframe SOP actually.
  10. This is sort of crude, but here's something hacked together using the Wireframe SOP as a starting point: wireframe.hip
  11. Problem with Boolean in Houdini

    I'm much more intrigued by this engine that doesn't like tris!
  12. Calculating acceleration

    There are a few problems here ... First, the derivation in your image is incorrect, in the last step you're multiplying both sides by -1, but "vt-d" incorrectly becomes "-vt-d" instead of "-vt+d", or simpler, "d-vt". The correct form of the equation is: a = (d-vt)/(0.5 * t^2) But even that is a little unwieldy, if you shuffle the terms a little bit you end up with: a = 2 * ((d-vt) / (t^2)) Your expression was: ( (-1) * ch("./viewVel") ) - ch("./timeToDest") / ( (1/2) * ( ch("./timeToDest") * ch("./timeToDest") ) ) ... which doesn't even match your derivation, it's missing distance on the left and is bracketed badly (BODMAS!), so in all you're not getting nearly the result you want. Worse yet, your acceleration node isn't even hooked up to your accelerationAccess channel (it's looking for "null1" instead of "null_controls"). A correct expression based on my earlier derivation is: 2 * ( ch("./measureDistance") - ( ch("./viewVel") * ch("./timeToDest") ) ) / ( ( ch("./timeToDest") * ch("./timeToDest") ) ) I gave it a few tests, and it seems to work fine for different time values ... ... except this probably isn't going to work how you expect it to for some velocities. The mechanics equation doesn't account for the fact that you (probably) want zero velocity as the particles approach the goal, so what ends up happening for high enough initial velocity (try putting your initial velocity to 10) is that the particle overshoots the goal at first, and then decelerates to return back to it at the time mark. Here's a modified version of your scene with the corrections: acceleration_test.hipnc
  13. Problem with Boolean in Houdini

    I spent a little bit of time thinking about this yesterday. Ideally one wants to delete all those newly created edges after the Cookie node. It's a pity Houdini has no means of creating Edge groups/attributes, then it'd be easy. It might be worth investigating a means to "retopologize" geometry that's been triangulated. It's a pretty tricky problem to get right in the general case though. Hmmm ...
  14. Problem with Boolean in Houdini

    Sure, here you go: That's with the AttribTransfer working in one direction only (because the problem geo is only the grid) - you might want to set up a custom Cookie OTL with the option to do it to either/both inputs. predividecookie.hip
  15. Problem with Boolean in Houdini

    Incidentally, the only improvement I can offer you is to implement your own pre-divide that's localized to the intersection region. It's far from perfect, but I've done this in the past with a AttribTransfer with some success.