Welcome to od|forum

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

sekow

Members
  • Content count

    132
  • Joined

  • Last visited

  • Days Won

    2

Community Reputation

36 Excellent

About sekow

  • Rank
    Initiate

Contact Methods

  • Website URL http://www.sekow.com

Personal Information

  • Name Sebastian
  • Location Germany
  1. break it down. like every problem is better to disect it into smaller problems. start with to one you most comfy with. build up from there. identify whats important and whats not. what comes first? (thats maybe the hardest part) most times the next step is pretty obvious, and I bet you will have a good picture of progression pretty soon sketch out in your mind. thats why houdini is great at that kind of work. your effect can contain on bigass setup or, which is way better, is coming to live thru individiual blocks/modules.
  2. please do and let support know!
  3. I cant really observe that here. dual 12 core xeons. with a usage of around 50 % (of all 24). I think the slow down comes from that vdb loading out of sops. Did you observe ram peaks? 64 should be enough, but Houdini on windows aint that good with flushing ram, so its does accumulate in time. and if your is full windows starts to swap, and that will result in just a core working.
  4. thinking of that a second more, one could hack the grain constraints to achieve a better result and even attach that to something... interesting task indeed
  5. had to try that out myself, here is my attempt: snot.hip
  6. while we are at it. Ive never understood that proxy thing. When we volume sample vdbs from sops, isnt that redundant? In the end dops transfer the sdf into a dop object out of houdini volumes.
  7. cant really help without the alembic file. but I assume that dops does not know the center of gravity. you could fill out the pivot parameter in the initial state tab with the centroid() expression. centroid(opinputpath("/obj/sphere_object1/dopimport1", 0),D_X), centroid(opinputpath("/obj/sphere_object1/dopimport1", 0),D_Y), centroid(opinputpath("/obj/sphere_object1/dopimport1", 0),D_Z), good luck
  8. what you need to check is how rbds work in dops. when you import your animated geo into dops, dops assume the first simulation frame as inital state of the geo and wont refresh the geo. In your case you want you should do some reading in the docs. In a nutshell: RBDs are set to active by default, so the solver know that object needs to be solved. But you have the possibility to set it to deactive (i@active == 0). And when using bullet your are able to set an attribute "@animated" to 1 to make dops aware that it should refresh the animated geo. Check the file for a crude example animated_rbd.hip
  9. after you copied your box in sops, plug in a connectivity sop set it to primitive. get a primitive wrangle and type in: @group_frag = (random(i@class)<0.5); now you have approx half of your boxes set in a group called frag. blast sop all not inside that group and feed that into your loop. (btw you dont need to loop over them, you can fracture them all at once, just make sure that @class attribute is copied over to new fragments). merge that result to the bevor blasted prims.
  10. hey you have been on the right path. look at the hipfile. ive changed the collision methond in the solver to particle and used the static solver. in my experience this works better than than just pump in collision fields into the sim. now the collision is a seperate dop object. dialed down the substeps to 1 and let the solver decide when its needed. could be that you need more later when the fluid starts to splash. didi not sim that long. but at least you dont have any loss at the beginning good luck! b2.hip edit: you could do the volume sample method in the static solver and use vdbs.
  11. in your static object switch to "use volume based collision"
  12. https://www.sidefx.com/docs/houdini15.5/nodes/vop/bind
  13. said that, I believe that a bind just does the trick too
  14. check out the render state node, you have access to pack attributes via packed:attribute syntax
  15. all valid ideas, but thats all outside of houdini. What Im doing right now is a combination of opengl rop and that video output rop from orbolt (https://www.orbolt.com/asset/SideFX::videoout) The video rop is using ffmpeg, and gives out errors, but writes out mp4 directly out of houdini.