Jump to content

curv.u

Members
  • Content count

    10
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About curv.u

  • Rank
    Peon

Personal Information

  • Name
    curveu
  • Location
    Italy
  1. Vellum Random colors

    Plus, make sure to apply color on points. Patchname is a point attribute, so color must go on points. I see you're applying it to detail, if you want to do that you should promote the attribute first.
  2. Vellum Random colors

    oh yes, of course you should make patchname as unique identifier, so in vellumsource node add $OS_$F for example. The result will be "node_name"_"frame_number" ( = vellumsource_1 if you're on first frame). Check on the Spreadsheet to see the newly created names: your goal should be to have a different name for each frame a ball is emitted, that gives you the dissimilarity useful for the random function.
  3. Vellum Random colors

    Hi, you can use "Vellum Patch Name" attribute in vellumsource node to identify each iteration, then out of the dopnet (after vellumpostprocess) use a color SOP set to Random From Attribute: patchname. Patchname is a point attribute. Is that the result you wanted?
  4. Hello, i come to you after several sleepless nights due to a matter i can't find a solution. Hopefully some of you may provide help. In my project i have one geo, replicated and simulated in vellum with "Instance on points" method: every 4 frames a new geo is created and the simulation starts. Now i have trouble point deforming the proxy simulated geo with the original geo, because Hi-res and Rest geos should appear exactly when a new proxy is created. I thought it would suffice a ForEach and something like a Birthid attribute to isolate every guy, but it seems i'm not able to make it work. Below the hipfile attached: i simplified it and replaced my original geo with a Rubbertoy; so don't mind too much attention to the shape of the proxy geo... now it's strange, but in my case it did the work. I really hope in some clarifications with the script, i'm stuck there. Thank you very much! pointdeform.hipnc
  5. Thank you @ziconic, super straight explanation! To see now it was the very obvious thing to do, but i actually didn't thought about it earlier ... I'll mark as [SOLVED], many thanks to all you mates!
  6. ok wow! thank you @Noobini, it does work now indeed! i somehow missed how important the bias was: testing it with the spheres really make the difference! Anyway i still have big problems when i swicth those spheres with any other geometry (my original geo, as well as pighead or roberto): they go straight ahead! AND i noticed one thing: if i pack the geometry, now any velocity node works like a charm. Right now meanwhile writing to you came an idea (better to say a workaround): if i pack the geo, then assign v, then unpack geo and pass v attribute NOW it works! I really would like to understand why they work only this way tho. Can someone kindly explain me WHY? i really have a struggle to understand. Has this maybe something to do with points? (position, quantity, disposal)?
  7. hi @Noobini, thank you for your reply. I carefully dug into your Tommy file (poor guy ^^) and i made some tests with pointVelocity, but i think it can't resolve the problem. PointVelocity and AttributeRandomize both can create a velocity within a cone angle, and that's ok, but neither of them seem to work when fed into a vellum dopnet. Note that they work perfectly when put in a rigidbody dopnet. Below some screenshots to better explain: Studying your file gave me ideas: a target to orient direction or an initial rotation at starting point can make the trick, but tbh they're a workaround and really don't end where i wanted to, so i don't quite feel like to use them... Seems very strange to me that super fancy sop nodes (point vel and attr rand) can't work there. Am i missing something obvious? Please give a look at the file i've updated, maybe it can provide some hint (?) emitting_multiple_vellumobj.hipnc
  8. Hi everyone, recently i had a look into vellum and tried to make an emitter of soft objects colliding each other as they go. I know it does exist the setting "Emission type: continuous" which generates a copy of your geo and constraints periodically, and it works like a charm when you basically just want them to fall one over another. But this system seems not to be affected by external velocity, as for example do does a simple setup of multiple rbd objects. I was particularly interested in this because i want my objects to move with a random velocity, in a certain direction, within a cone angle; and i set all these properties in an AttributeRandomize at sop level. So, is there a way to feed this external velocity into dopnet, like you do with inherit velocity in rigid bodies? Plus, i know there are several methods to emit multiple rigid objects, using Packedobj and PopSource or the SopSolver and Rigidbodysolver combined with Multisolver. They seem clear and simple as hell, isn't there a way to make a similar process into a vellum driven dop? Attached below the hip file, with two examples of multiple rigid body emitters, which i can't replicate with vellum. Hope it helps. Oh, and i suddenly thought about vellum, but if there is another smarter method to do this (ie FEM...?) please let me know! Many thanks emitting_multiple_vellumobj.hipnc
  9. GLTF animation import

    yeah, that works. Eventually i did this way: pit stop to Blender, and exported three different Alembic files, one per animation. I did really hope there was a smarter workflow tho. Thank you for you reply
  10. Hi everyone, I have a gltf scene which contains a mesh of a rigged character and three different animated poses. I can import the whole scene, but cannot manage to make the character move. Where can i actually find those animations?
×