Jump to content

anim

Members
  • Content count

    2,397
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    131

anim last won the day on January 18

anim had the most liked content!

Community Reputation

968 Excellent

About anim

  • Rank
    Grand Master
  • Birthday 02/28/1985

Contact Methods

  • Website URL
    http://tomas.slancik.com

Personal Information

  • Name
    Tomas
  • Location
    New York

Recent Profile Visitors

15,271 profile views
  1. Is there a bug in the Assemble SOP?

    it looks like a bug with Unpack SOP seems like it is always transferring groups from packed to unpacked therefore overriding the original ones so maybe you can also just delete the groups on your packed pieces before unpacking at the end, instead of breaking into RBD Configure to not transfer them
  2. try to provide path to a geometry node (SOP) not just object like this: "op:/obj/oinkster/OUT"
  3. whatever Mark said since you are using 17.5 however technically the new method since H18 is using Piece Attribute to copy variants to points and avoiding for loop altogether
  4. Pop fluid and minpos

    you can start by looking at ParticleFluids/Condensation shelf tool, which will set up popfluid with adhesion force it's based on SDF volume representation of your colider which can be more efficient especially for static colliders and a lot of particles, but can be adapted to minpos() lookup as you can get direction and distance from that too
  5. Particle Radial by velocity Direction

    it's because your popvop1 is constantly recomputing your v direction from incoming v so it's literally flipping directions every timestep to avoid this create Just Born Group on popreplicate3 and execute your popvop1 only on that group
  6. your name attribute is string, not int so instead of Assemble SOP use Connectivity SOP, to create primitive int attribute (by default named class), then bind that class attribute in your shader as int
  7. Delete them after attribinterpolate as before they are not in the correct position relative to the camera anyway Alternatively store unique @id attribute on points before deleting, then after deleting this attribute value will not change so you can use it as a seed for attribute randomize nodes which will then produce stable values per point
  8. you don't have to attribtransfer anything in Attribinterpolate specify only P instead of * if you don't want it to update other attributes from the right input
  9. what I meant is that if you have efficiently instanced packed geo in houdini (many packed primitives point to the same geometry in memory) and you export as .abc preserving instancing (so .abc is pretty lightweight) reading such .abc back into houdini would bring in each individual packed alembic primitive having unique geometry memory reference, losing the notion of referencing the same geo source I'm not sure if this is still the case, but it used to be that way
  10. Your scatter is operating on time dependent geometry so probably producing different results every frame and also making your attribinterpolate sort of useless Make sure to frame hold your geo before scatter If your geo is just deforming, attribinterpolate will make sure points stick to corresponding prims
  11. Last time I checked Houdini wasn't able to import instanced geo from alembics as instances either. Luckily there is .usd now
  12. if you use path attribute to build hierarchy from it will not be saved as an attribute to the geo, it will literally split the geo into separate objects based on the path, most of the applications bring it in as separate objects but the naming should be coming from the path attribute unless you are exporting packed primitives packed primitives may still be forced to separate objects to preserve instancing and if more of them have the same path, then houdini has to make up the names so I'd try unpacking everything, setting up clean path attribs and then the geo should come in into blender segmented only based on path attribute with correct names
  13. Vein pulled out effect using Vellum

    you can increase drag force or post a hip file showing the issue, doesn't have to be your exact scene
  14. then you can store your already computed v that you are happy with into some temporary attrib like v@tmpv using Attribute Swap SOP, method: Move and in DOPs use POP Wrangle: v@force = v@tmpv * chf("weight"); it will use your v@tmpv vector (further scaled by weight parm) as a force since force is added to velocity each timestep it will naturally accelerate, so just adjust weight to control the rate
  15. instead of feeding initial velocity from SOPs, use POP Force DOP or other forces force acts on velocity every timestep, therefore it will keep gradually increasing your particles velocity you can also add some POP Drag or POP Wind to introduce some air resistance to not accelerate forever
×