Jump to content

julian johnson

Members
  • Content count

    40
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    7

julian johnson last won the day on October 18

julian johnson had the most liked content!

Community Reputation

45 Excellent

1 Follower

About julian johnson

  • Rank
    Peon

Personal Information

  • Name
    julian
  • Location
    london

Recent Profile Visitors

779 profile views
  1. Updating RBD constraints from deforming geometry

    Just a small followup to the constraint orientations thing. It looks like the orientations of both points of the polyline are co-dependent(!). You rotate one and it rotates the other so any tricks involving animating the constraint orientation can only really work if you only rotate one of the points otherwise they just 'fight'. That said, the attached scene shows rotating only a single point per constraint working for rotations about Y and Z but it looks like X rotations are possibly bugged (there was a similar bug a year or so ago) where the rotation is doubled up on the non-animated point.... anchors_orientation_bug.hipnc
  2. Updating RBD constraints from deforming geometry

    Hi Henry, been wondering the same thing. Can't really help you with your scene but I do have a testbed scene where I've been trying (and failing) to understand the relationship of the orientations of the constraint points. Without any documentation it empirically looks like the world anchor and the position anchor have a pseudo 'child/parent' relationship but with the weird twist that the 'child' seems to have its orientation inverted relative to the 'parent'. I don't think I can explain this very well and I may well be barking up the wrong tree but the attached scene gives a few examples of how the two constraints might be related. (At least in terms of orientations but perhaps only for world to point pins). Needs a lot more testing. Feels like the Y axis of each constraint point's orientation is pointed towards the alternate constraint point along the tangent of the polyline. I'm sure it would be a different scenario with non-world space anchors as well. anchors and orientations.hipnc
  3. bullet_add_impact attribute

    Not sure that you have to use a seperate bullet_add_impact attribute as you can just turn it on using the Bullet tab on the geometry in the dopnet. With it on, you can then try using the same mechanism the DOP SOP Solver uses to grab the Impact records from the bullet sim i.e. DOP Import Records. Not sure if that's what you wanted but it does seem to work.. Impact_recording_Packed_Obj_amended.hipnc
  4. How could I select edges between selected points in VEX?

    if (i@group_PointsGroup) { int ph = pointhedge(0,@ptnum); while (ph != -1) { if (hedge_equivcount(0, ph) < 2) { int src = hedge_srcpoint(0, ph); int dst = hedge_dstpoint(0, ph); setedgegroup(0, "edges", src, dst, 1); break; } ph = pointhedgenext(0, ph); } } Just tried this in H17 and seemed to work OK in a point wrangle..
  5. @Atom - that looks great! Next thing I'd be looking at would be the spring strength, restlength multiplier and damping to control the body oscillations...just as you would tune a normal car suspension system. You're right the constraints have to be positioned correctly. I did it all manually because it was a quick hack to demonstrate the principles. I've hacked the original hack (!) so that you can now scale the chassis without any manual intervention on the constraint positions: But I think that whole system needs to be built more elegantly from scratch in a more procedural way possibly using a name attribute on the chassis points to generate the appropriate constraints. At the moment it's a kludge. suspension14.hipnc
  6. Well, I couldn't just leave it there so I did do a few further tests but started getting different results between 16.5.496 and 16.5.536 (the sim would explode in .496 but stay stable in .536) so these further tests are in 16.5.536. I noticed that with the conetwist setup in the original the 'freedom' to roll downhill was reduced as though there were some stiffness to the twist in the conetwist constraint so I remade those particular constraints with hard constraints set to position only. Again, the stiffness of the rotation was quite strong. You can see that test in suspension11.hipnc. I then converted those new hard constraints to position and rotation but used condof/condir to allow rotation around the wheel rotation axis (but unfortunately that also permits position changes (sliding) along that axis). However, that did allow the whole assembly to travel freely downhill but you can see the wheels sliding a little along their axes. I put the conetwist test in the same scene to see just how great the difference was: suspension12.hipnc. Had to give the conetwists a slight position CFM value to prevent craziness. You can see the conetwist chassis on the right is still very slow to roll. Finally, as you do, I did attach a motor to all wheels for some torque! suspension13.hipnc. Don't have time at the moment to explore further. Not sure what combination of parameters is driving the stiffness or would loosen it: Position CFM, Position ERP, Bias, Relaxation or the physical properties like Friction, Bounce, Mass. Constraint iterations and solver iterations would also play a part. Very hard to work out the exact contributions of each of those parameters or how they affect the sim and the manual is very 'dry'. suspension11.hipnc suspension12.hipnc suspension13.hipnc
  7. Realised I'd attached the springs to the upper wishbone instead of the main chassis!. Updated gif and hipnc attached@: suspension10.hipnc
  8. @vicvvsh - very nice and elegant! Here's a different approach using a simple double wishbone setup using cone twist constraints (primarily). No idea how accurate or robust it is but it seems to be a starting point for some fun: Inspired by this: https://www.youtube.com/watch?v=GW__Gzkk4G0 (4.53 is where this setup is described) suspension9.hipnc
  9. Random pop bounce direction

    I thought I'd try looking inside the Pop Solver itself to see where it constructs the collision normal. Couldn't find any method to modify it on the fly. In doing that I started messing around with the mass of nodes in there to see if I could bypass the whole collision response built into the Gas Integrator in the Pop Solver and do a simple one myself. Turns out you can do that but it is probably the opposite of a 'cleaner way' to do the original challenge. Matt's is by far the cleanest/most explicit way I could find. Anyway, scene attached is my attempt. It is only a single Pop Wrangle inside the Pop Solver and seems to work OK. Was interesting to see how granular you could go with the built in nodes and how many you could throw away(!). pop_rand_bounce_simple4.hipnc
  10. Point/SOP level parent-constraint

    http://www.sidefx.com/docs/houdini/vex/lang.html If you look under the heading 'Dot Operator' there's an explanation of the matrix dot syntax.
  11. Point/SOP level parent-constraint

    Not sure if this is what you need but it illustrates a simple way of doing a very rudimentary parent/child hierarchy in vex. The parent can have any number of children (including 1). (Done in 16.5.473). parent.hip
  12. Define a function in point wrangle

    // // VEX Code Generated by Houdini 16.5.268 // Date: Sun Jan 28 16:23:25 2018 // File: C:/Users/johnson/untitled // Node: /obj/geo1/attribwrangle2/attribvop1 // #ifndef VOP_OP #define VOP_OP #endif #ifndef VOP_CVEX #define VOP_CVEX #endif #pragma opname attribvop1 #pragma oplabel "Local Vop Code" #pragma opmininputs 1 #pragma opmaxinputs 1 #include <math.h> void _obj_geo1_attribwrangle2_attribvop1_snippet1(int _bound_test[]) { function int[] test() { int result[] = {1,2,3}; return result; }; _bound_test = test(); } cvex obj_geo1_attribwrangle2_attribvop1(export int test[] = {}) { // Code produced by: snippet1 _obj_geo1_attribwrangle2_attribvop1_snippet1(test); } Looks like a nested function when you expand the inner VOP node to VEX...
  13. Define a function in point wrangle

    I found this in the documentation: http://www.sidefx.com/docs/houdini/vex/arrays.html Not sure what a BNR is :-)
  14. Define a function in point wrangle

    function int[] test() { int result[] = {1,2,3}; return result; }; i[]@test = test(); I get syntax errors using the 'normal' array syntax in the documentation i.e. a simple int[] test(){}; but if you disambiguate using the 'function' syntax it seems to work..
  15. get UV on curve by arclen in VEX

    I think using primuvconvert() now that it has been fixed in 16.5.323 you can go one better in that primarclen() only worked on nurbs and bezier curves. Using primuvconvert() you can get an arclength from u for all curve types including polygonal curves AND you can use it to go in the other direction i.e. get a U value for a given arclength: //get arclength from u f@lenC = primuvconvert(@OpInput1, 1, 0, 8)[0]; //get U on curve using arclength f@u = primuvconvert(@OpInput1, @lenC, 0, 10)[0];
×