Jump to content

jimeng20

Members
  • Posts

    38
  • Joined

  • Last visited

Contact Methods

  • Website URL
    https://www.jiemengfx.com/

Personal Information

  • Name
    Jie Meng Snek
  • Location
    Los Angeles

Recent Profile Visitors

1,183 profile views

jimeng20's Achievements

Newbie

Newbie (1/14)

  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

8

Reputation

  1. Hi there, First of all, your N attribute need to be on point class instead of vertex. So in your normal sop adjust construct to add normal on points. Second, if you are using pack sop to get the center point make sure you transfer N to the points. Cause the pack won't transfer attributes automatically. Cheers,
  2. Hi there, In the RBD sim, I will recommend to use rbd packed object workflow rather than the rbd fracture object. In rbd packed object, you can overwrite an attrribute called "active", which allow you turn your RBD sim from inactive to active based on this attribute. Or if you are using bullet solver sop it's in bullet object tab. So the idea is fracturing your geometry first and then pack them in the assemble sop. Then transfer your "infected" attribute to the points and use it as active attribute. You can use pcfind like you did in the solver or just a simple attribute transfer sop. You can then have something like when the infected is > 0, active = 1. If you have overwrite active turn on, chunks will start to fall when it detects your active attribute is 1. Unfortunately I can't upload the file since I'm at work, but here is some information I found to explain the packed workflow better. http://www.tokeru.com/cgwiki/index.php?title=HoudiniDops#Rigid_Body_Dynamics
  3. Looks like a sdf cut, do you have any collision field in your set up by any chance? For smoke all you need is density and vel. What's your initial lowres value and upres value ? - sometimes if you upres too much the voxel will be shattered and has artifact then looks all weird. And I know the upres technique is a way to approach for high quality volume, but, to be honest I try not to rely on it. I will just use standard smoke solver and tweak the division size instead of cache out lowres and use upres solver. Hope this would help.
  4. I would trail the collision geo and convert into sdf in the sop, cache out and you can either use it as a proxy volume in the static object or, you can create colliison and collisionvel and use in the dop as collision fields. If you are going to try the collision/collisionvel, make sure you wire the volume source to your THIRD INPUT of the flipsolver instead of the forth. Basically, only rely on the substep in the solver is very expensive, the dop is trying to figuring out the sub-frame information during the sim, and apparently, you can prepare the sub-frame info in the sop, cache out, and dop just need to read it in. It will be much faster if you have trailed your collision animation 1/5 increment and put substep 2 in solver than try to calculate sub-frame while siming with 10 substeps. Hope this would help.
  5. Hi there, Just curious what do you mean the Solver has access to the sub-frame collision geometry? Have you tried to use a trail sop to trail your animation yet? If not, I would try to create all the sub-frame animation as much as possible before completely relying on solver's substep. Based on the speed, put down a timeblend and then set something like Trail Length 10, Trail Increment 0.1, then convert it to sdf. Hope this would help.
  6. Hi there, If you are using static object WITHOUT proxy volume, the solver will create sdf every frame if your object is animated or deformed. But if you create the sdf outside of the dopnet, the dop will just read in whatever sdf from sop level and calculate it i.e. gasenforceboundary microsolver, or using proxy volumes in static object. You can cache out your collision sdf so the dop will just read in the disk file. Also here is some information about collision from sidefx: Hope this would help.
  7. Also volume is not like points or prims, you can not just directly use spreadsheet to check the information in spread sheet. If you really need to check the P information, I would suggest create a vector field name it Position, then store the P into Position and I would scatter the points to sample the Position field by using volumesamplev.
  8. Hi there, I would do a frame record in the solver, basically set up a trigger attribute initializes from 0, and in certain condition turn to 1(in your case let's say if(@P.y>5)). And also record which frame it trigger, and name it something like trigger_frame. And no matter you are using rbd or pop, you can manipulate your force/vel/pos when @Frame >= trigger_frame. You can do this separate in another solver sop or you can directly record in the current dopnet. This is normally how I would do something like character walking then shattering, basically if @Frame >= trigger_frame, the pieces will falling or exploding etc, if not then copy the intrinsic from the animation. Here are some info about how to setup trigger attribute and record the trigger_frame. Maybe there is a better way to do it, but I hope this would help.
  9. Hi there, I don't know how you prepare your collision geo, I would also try create collision sdf and collisionvel then bring into dop instead of using the static object. I would trail the collision geo to fill the gap between the frames, compute velocity , convert to sdf and create velocity field to use as a collisionvel. Then use source volume to bring it in and wire into flipsolver THE THIRD INPUT(if you wire into the fourth input as usual source volume, you will get no affect) The good thing about collision field and collisionvel is that you can modify the scale of your collision velocity to affect the flip, also you can prepare your own sdf in the sop level(if you don't use proxy volume, the static object will create sdf every frame). Hope this would help.
  10. Hi there, Have you try fuse sop? Also are those two individual geometry?
  11. Hi there, Also I think there are some info that I found can help you to better understand quaternions/orient and matrices. http://www.tokeru.com/cgwiki/index.php?title=JoyOfVex17 Hope this would help.
  12. Hi there, I'm sure there are a lot of different ways to do that, I will probably use point cloud to found out the how many points in the searching area. For example int pts[] = pcfind(0, "P", @P, 0.1, 10); if(len(pts) < 10){ removepoint(0,@ptnum); } So if there are less 10 points find in 0.1 meter area, blast the particles. Then you can mesh the remaining. Hope this would help.
  13. Hi there, First, instead of doing a parameter for prim_number, connect the global primnum into both primitive_intrinsic vop "prim" parameter. Because you want to grab the individual primitive number for both packed geo at the same time. Second, in you setattrib, you need to connect the global primnum into i1, again, you need to define which primitive number to set the intrinsic, so it knows to set intrinsic to the corespondent packed geo. I tested and also added another packed geo and it should work, but unfortunately I can't upload the file since my work place doesn't allow to. Hope this will help.
  14. Hi there, I would use the intersect vex function, so create a wrangle and wire the tube in second input, and you can write something like: vector pos; vector uvw; int prim = intersect(1, @P, @N, pos, uvw); f@length = distance(@P, pos); @P = lerp(pos, @P, chf("mix")); So the original position is first input, and intersect vex function will take that position and emit ray to your target tube, and of cause the ray direction is the normal, and it will create the hit position and hit uv. So the hit position, which is "pos" in the code is the target intersected P that based on your normal direction. So compute the distance of @P and pos is the length you want. Also you can mix the original P and intersect P to see the blending movement. Hope this would help.
  15. Hi there, First you don't need to connect the primnum to your volumegradientfile vop, that is for which primitive volume you wanna sample, let's say you have two volumes named density and heat, 0 will be density and 1 will be the heat. Second, you should connect your volume to your second input, cause you want to sample the gradient from the volume right? You can't sample the gradient from the points. Third, you can't just bind in the density in a point/prim/vertex/detail vop, you need to do that in a volumevop or you can sample the density from the second input volume using volumesample vop. Volume doesn't work like points and primitive, we can't directly grab the density/gradient/surface or any other fields we created in volume and assume it's gonna work, so we need to use the volumesample to sample the density, surface etc and use volumegradient to sample the gradient from a volume. I know it's a bit hard to understand so I found more information here: Also cgwiki has a great topic for understanding volumes, how to modify and sample, how to create field etc. http://www.tokeru.com/cgwiki/index.php?title=HoudiniVolumes Hope this would help.
×
×
  • Create New...