Jump to content

LePetitNick

Members
  • Posts

    6
  • Joined

  • Last visited

Personal Information

  • Name
    Nicolas
  • Location
    Wellington

LePetitNick's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

0

Reputation

  1. The modify point instances LOP deals with point instances only - you're creating native instances. Replace the modify point instances LOP with a SOP Modify LOP, dive inside and drop a rbd bullet solver, enable ground plane in the collision section, lower the ground plane, and watch your pieces fall to the ground. Otherwise, change the instancer LOP to output point instances, set the primpath on the modify point instances LOP to "/Rock_Circle_1[*]" (the LOP nodes that deal with point instances take a special syntax to specify which instances to work on - look at the docs for more info) and dive inside, remove all the nodes you've added since the instances are now available from the subnetwork first input, connect that to a rbd bullet solver, and same as previously, enable ground plane, etc... jump out and watch the point instances you have specified tumble.
  2. Dang, that is the right answer, it's my question that is all wrong! I was hoping the getInputIsReference referred to the "is reference" flag you can specify on the otls' type definition inputs/outputs tab - allowing you to turn the connected noodle into a dotted line rather than a solid line, like the second input of the ray SOP for example. setInputReference isn't what I was looking for... how do I get to have dotted lines connected to a specific input of my SOP?
  3. I've been searching for a bit now and can't for the life of me find this... it's not terribly important, but I would like to be able to set my SOP_Node's 2nd and 3rd inputs to be references to indicate to the user that they are indeed reference inputs... Where can I set this? I found the OP_Operator::getInputIsReference, and was hoping to find the setInputIsReference function but sadly it doesn't seem to exist...
  4. Thanks Edward, that's exactly what I was looking for!
  5. I'm writing a SOP node using the HDK for the first time and everything's been pretty cruisy so far, but, I've noticed that when switching collision methods between a volume SDF and a VDB SDF by getting the gradient pushing the points out by the SDF's negative value, the VDB calls are roughly 3-4 times slower than the same calls to a volume. I've optimised the code by forcing a bounds check first which seems to speed things up, (making the assumption that the SDFs are not inverted and only in the edge cases where the SDF bounds only intersect a small portion of the input geo) but still the VDB is substantially slower. Anyone have any trick to speed up these lookups? GU_Detail *sdfInput = new GU_Detail; if (inputGeo(1, context) != NULL) duplicateSource(1, context, sdfInput); ... const GEO_PrimVDB *vdb = NULL; const GEO_PrimVolume *vol = NULL; UT_BoundingBox sdfBBox; sdfBBox.makeInvalid(); if (sdfInput != NULL && doCollision(t)) { for (GA_Iterator it(sdfInput->getPrimitiveRange()); !it.atEnd(); it.advance()) { GEO_Primitive *prim = sdfInput->getGEOPrimitive(it.getOffset()); if(dynamic_cast<const GEO_PrimVDB *>(prim) != NULL) { vdb = dynamic_cast<GEO_PrimVDB *>(prim); vdb->getBBox(&sdfBBox); break; } else if (dynamic_cast<const GEO_PrimVolume *>(prim) != NULL) { vol = dynamic_cast<const GEO_PrimVolume *>(prim); vol->getBBox(&sdfBBox); break; } } } ... UT_Vector3 position; UT_Vector3 gradient; fpreal signDistance; GA_Offset ptOffset; GA_FOR_ALL_PTOFF(gdb, ptOffset) { position = gdb->getPos3(ptOffset); if (!sdfBBox.isInvalid() && sdfBBox.isInside(position)) { if (vdb != NULL) { signDistance = vdb->getValueF(position); if (signDistance < 0) { gradient = vdb->getGradient(position); gdb->setPos3(ptOffset, position - (gradient * signDistance)); } } else if (vol != NULL) { signDistance = vol->getValue(position); if (signDistance < 0) { gradient = vol->getGradient(position); gdb->setPos3(ptOffset, position - (gradient * signDistance)); } } } } If you compile the SOP, plug a vdb sdf into the second input, check the time, then feed the vdb sdf into a vdb convert first and then plug the volume into the 2nd input, you'll notice that the vdb sdf collisions take roughly 3-4 times longer to evaluate than the volume sdf collisions... Ideally I'd like to have the vdb run at least as fast as the volume, and ideally speed up both of them, a lot - as of now a deformer SOP which takes 0.3s to run on 100K points skipping the sdf collisions, takes upwards of 4s with volume collisions enabled, 13s with vdbs...
×
×
  • Create New...