moebelhaus

Just found the solution: TOP node "Geometry Import" allows for fetching SOP geometry, which will then be temporarily stored on disk. The work item will have the proper @pdg_output attrib and can then be used in the HDA processor.

Hey Ron, just ran into the same issue right now and found your post here. Did you receive any feedback in the meantime (or solve the problem?) Cheers! -Patrick

Hey Everyone on this beautiful sunday! So, as I am touching pyro for the first time, of course I am using the "Gas Resize Fluid Dynamic" node (from here on out called the "resize node") in my DOP-net to auto adjust the grid size. However, I a getting this slight flicker in the simulation, as long as the container size is being modified by the resize node. As soon as the container has reached its maximum size, and no resizing is going on anymore, flickering stops. Turning off the resizing and letting the container have static dimensions, also eliminates the flicker of course. Anyone out there familiar with this? I tried messing around with the resize-node's "Subtract Threshold" parameter, since it seemed to me (from the help) this might be connected to the problem somehow? But no luck so far.... Thanks for having a look people. resizing active, flickering results before the gridsize comes to rest resize_flikr.avi resizing disabled, no flickering noresize_noflikr.avi --------------------------------

interestingly, after going through everything again, I found the cause for the f*cked *p geo-pieces.... which makes it work with packed prims also (praise the lord). when i am initially fracturing my building still in SOPs, in the "Voronoi Fracture" Node I had checked 'Keep Internal Attributes' checked in the 'Attributes'-tab. Which messed it all up, once it started dynamically fracturing the geo in DOPs. UNchecking this makes it work smoothly again. Since I am new to Houdini, this doesnt immediately make sense to me, but I guess since DOPs is pulling in the source SOP recursively at every timestep and new geo is being created in DOPs, the source attributes from the original SOP-Voronoi-Fracture might overwrite the attributes of the new pieces being created. Hence the disconnected geometries that don't belong to any proper piece anymore...? Does this sound right? I am just trying to wrap my head around the whole "SOP>DOP>and back" transfer process here.... hm hm hm hip is below: odforce_egyptianTemple_cgfx_destruction_v005.bad_voronoi_2.hipnc

hey wateryfield, thanks so much for your quick reply! and the .hip of course. That actually solves the problem, which is awesome. And yet, it seems so expensive when it comes to sim-times, now that we are not dealing with packed geo anymore. Interestingly, a super-simple torus situation actually gives really nice results with dynamic fracturing using packed primitives. So somehow, it does seem to work..... just not with my egyptian temple scenario :/ check this out... super simple scene. odforce_voronoi_dynamic_packed.hipnc

Hey guys, this is my very first post, about one of my very first tries in houdini... So I am overlooking something OR (and that's much more probable) I dont get it: I am trying to destroy a building, prefractured via "voronoi fracture", packed into packed primitives via "assemble", brought into DOPs via "RBD Packed Object", pieces glued together via "Constraint Network". Everything works quite fine BUT I am also using Voronoi Fracturing within DOPs to dynamically break the geo further apart once it is being hit by the impacting sphere. Now the problem is that the dynamically broken fragments generated inside DOPs are completely messed up. In the screenshot below you can see that the newly created inside faces (grey)are immediately detached from the new chunks (teal/blue). And I cant figure out why. For kicks I tried the whole thing not using "RBD Packed Object" but rather "RBD Fractured Object", which was infinitely slower, but at least worked. I would reeeealllly love to use packed primitives though, and with a simple Torus, that workflow does actually work. hm. So the questions in my head right now are: Is it the way I treat (or not treat) the incoming OBJ? Is it the scale of things? Is it the crazy impulse forces? Is it the fracture pointcloud scale? ODFORCE is the place to ask for help, too many smart people out there!!! Thanks in advance to everyone having a look at this. Thanks guys!! odforce_voronoi_bad_geo.zip

Guys, this node is worth its weight in gold! I've been using it in 12.5 and 13 so far, thanks to all those compiled versions you are throwing in here BUT::: Would someone be able to compile it for 13.0.310, pleeeaze?? Thanks so much!