Jump to content

julian johnson

Members
  • Posts

    67
  • Joined

  • Last visited

  • Days Won

    12

julian johnson last won the day on September 21 2022

julian johnson had the most liked content!

2 Followers

Personal Information

  • Name
    julian
  • Location
    london

Recent Profile Visitors

2,340 profile views

julian johnson's Achievements

Newbie

Newbie (1/14)

  • Dedicated Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges

93

Reputation

  1. 001a just turns off your Geometry wrangle and switches the object to animated static which allows the Dopnet to update the geometry orientation and in turn the constraint. 001c adjusts only your Geometry wrangle to also update the orient attribute so that the constraint can 'see' the rotation. Not sure on the ins and outs of why these should 'work' but they seem to do what you want. Maybe? J 001a.hipnc 001c.hipnc
  2. It seems to work in all versions of 18.0.x up until 18.0.499. Up until then, somehow, the Transform Pieces node could apply non-named template attributes from a single point to all four wheel points. In 18.0.499 the points have to be matched by a name attribute for it to work. Possibly SideFX have fixed a long-standing bug or broken a normal piece of functionality. No idea which :-) car_rig_bullet_julian_18.0.499.hip
  3. Have a look in here. All I've changed is the animation along the path, the time start/end in the fetch node in the distance travelled chop and I've had to kludge the constraint on the steering object to work past frame 240 by hard setting the sample rate.... car_rig_bullet_julian_offset.hipnc
  4. Tomas thanks so much. That is exactly what I need :-)
  5. Thanks Tesan, that's definitely food for thought :-). I can definitely 'see' the V plane now....I'll see if I can understand what you're doing with the gamma/colour correct. I need to be able to unpack the image data at the end back into the original velocity values and reconstruct the original velocity field.
  6. Thanks Tesan :-). That's been the scene I've been playing with this afternoon from Jeff Wagner: https://www.sidefx.com/forum/topic/25607/?page=1#post-118620 but I can't figure out how to get the velocity to show. Here's what I've been doing to that scene. Being very thick on this one... cop_volume_slice_attempt.hipnc
  7. I need to create an image sequence representing the slices of a velocity volume as normalized, positive 8bit RGB values in a .raw file. I'm pretty sure it's possible with a cop2network and a vopcop2gen (and I've seen a couple of scenes that do this for a density volume) but I'm totally unclear how to read the velocity into the vopcop2gen and then iterate over the velocity slices and make the appropriate conversions. If anyone has any pointers they would be gratefully received. Documentation seems quite thin. I've tried using V as the image plane in vopcop2gen but just get a blank... Julian
  8. Whilst Tomas's is as elegant/definitive as it gets if you were inclined to use either vex or chops (and, realistically, you probably never would!) here's a scene with rough workings for a vex version and a chops version... vex_and_chops_camtoobjtrack.hipnc
  9. I'm sorry, I hacked apart your scene quite a bit just to see what was going on. Your original scene could be fixed without all those changes. I've attached it below with the minimum of 'fixes' and without the pop emission. Essentially, the mis-alignment of the packed pieces and the constraint geo was down to a few things: 1) the constraint geo needs to be at the rest position of the packed pieces as you saw with the additional wrangle 2) I reset the glue constraint relationship to more or less default with additional strength 3) I ensured all the constraint geo existed on frame 1 with a timeshift and only pulled in the constraint geo on frame 1 to the sim not every frame. All this is based on wonderful responses on this topic by Tomas Slancik: https://forums.odforce.net/topic/25792-emit-packed-rigid-bodies-efficiently/ https://forums.odforce.net/topic/25634-emit-multiple-packed-primitive-with-constraints/ Without these, I'd have no clue. It was Tomas who in the first thread demonstrates that using Pop Source is the most efficient way to emit packed pieces... Constant_Spawn_COnstraints_origfix.hipnc
  10. This might be what you mean/need? Constant_Spawn_COnstraints_v002.hipnc
  11. Hi Eric, I think this page is a great introduction to the wild and wonderful world of constraint geometry: https://www.sidefx.com/docs/houdini/nodes/dop/constraintnetwork.html In the scene above the constraint primitive (a simple two point poly) is manually placed at the centroid of the packed box. One point of the primitive references the name of the packed piece, the second point references nothing. By referencing nothing that point becomes a world space anchor - the other named point is bound positionally to that anchor and becomes the de facto pivot of the packed object. That's all there is really. You can, of course, offset the constraint geometry which effectively offsets the pivot of the packed object. See scene below (the scene also contains an alternate way to handle rotation back to rest via dual constraints rather than manipulating angular velocity). rotate_back_to_rest_rbd_offsetpivot.hipnc
  12. Here's quite a crude way to rotate back by countering the objects orientation with it's inverse and using drag to control the spin... rotate_back_to_rest_rbd.hipnc
  13. Hi K'n'K, glad you liked it. I'm in the middle of a job at the moment so I can only give you brief pointers. You are right, though, I think it can all be done in the distance travelled CHOP. For reverse you need to establish some concept of what constitutes forwards and what constitutes reverse. I think using the tangents of the path curve and bringing them into CHOPs would be the way to do that - then compare the slope vector with the tangent vector. A dot product between the two would give less than 0 for reverse and greater than zero for forwards. Then just multiply the result of the area chop (length) by -1 to negate if you want to reverse (using the dot product to tell you whether you need to). For wheelspin I think a simple animated add to the length chop would do (for a manual spin) or using the acceleration to procedurally increase the length if it goes over a certain threshold. CHOPs are fiddly so it might take a few tries to get it right!
  14. It's been a while (!) but here's an interim development of the original double wishbone chassis concept. Now you can fully adjust chassis to match car - it's all done via names - so you can transform the model in any way you like (just don't change the point numbering as constraint naming is based on point numbers). Effectively bullet is used to make the constraints easy and the only real simulation is on the wishbone springs. Wheels are pre-animated along a path and then adjusted for roll, ackerman steering angle (inner and outer wheels at different angles). Still quite tricky to adjust the sim because mass, spring strength/damping, load transfer and conetwist maximum angles are all interrelated - change one and you need to change all the others! This test Porsche is overly springy to illustrate the basic concepts at work especially the load transfer forward to back. Needs more work on rest to action transition period, too! To change the car simply bring the new car and wheels into the chassis node and swap out, make sure to transform chassis geo to fit. Change path, collision ground as you see fit.... car_rig_bullet_julian.hip
  15. Does this do it with PolyBridge? No for loop required... MOD_Hex_Offset_01_bridge.hipnc
×
×
  • Create New...