Jump to content


  • Content count

  • Donations

    0.00 CAD 
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mottosso

  • Rank

Personal Information

  • Name
    Marcus Ottosson
  1. Just saw this, that's an interesting approach!. I'll give this a try on the real geometry and see what pops up. And yes, the groupexpand node in 18 also seems to do the trick. I'm still on 17.5 though so the VEX will come in handy. Thanks!
  2. Interactive Wedge

    Thanks, I'll experiment with this and see what comes up.
  3. Interactive Wedge

    Oh, and I just realised, there isn't a For-Each construct in DOPs. Maybe that's not what you meant, @anim?
  4. Interactive Wedge

    I hadn't considered that, I will experiment with that, but it sounds problematic. At frame 0.. Simulate 10 frames ahead, adding a value of e.g. 0.1 to `max_impulse` Simulate 10 frames ahead again (ideally in parallel), this time with a value of 0.2 ..then a value of 0.3 ..and so forth Then determine which of the variations got closer to some goal, of e.g. having the lower body reach a given angle, say 45 degrees Whichever was closest, continue from that value, e.g. 0.2 At frame 1.. Repeat For that, I think I need individual DOP networks such that when I get for frame 5000 I could continue from that frame, rather than resimulate it. But you're right, it's not clear what I want, I don't know yet myself. :S It is, you're right! A "Wedge TOP" along with a "ROP Fetch TOP" is exactly what I'm looking to do, except in SOP/DOP. The hurdle with TOPs is the launch of Hython (adding 5-10 seconds to each work item) and roundtrip to disk (adding 200-500 ms to each frame). I need this to run quicker, as each iteration of my Bullet simulation runs at ~30 ms per frame and I need hundreds of variations for every frame of my animation to determine the next frame.
  5. Interactive Wedge

    Hi all, I've explored the various options for wedging, but they all come down to writing results to disk, and I'd like to avoid that if I can as I'd like to run hundreds to thousands of iterations per timestep. The Wedge ROP for example writes multiple versions to disk. Wedge TOP does the same, but in parallel, from a Hython instance each nonetheless. Useful in their own right, but what I'd really like is this. Where I can vary some parameter of my simulation per wedge interactively, without writing anything out. I've got something which "almost" works, like this. But I can't tell whether it's anywhere near success. What ends up happening makes sense I think, but isn't what I want. That dopnet is singular and I suspect the loop tries increment it multiple times per time step which confuses its internal state somehow. I was hoping I could manually step the simulation, such that I could step it relative the current iteration. But I bet there needs to be unique instances of a DOP network per iteration, such that each can carry its own state. But here I'm at a loss. :S It's a bit of an XY problem, what I've really like to do is run a number of frames - say 10 - per iteration, measure the result and use it to determine what to change for the next iteration. To make a PD controller, somewhat like you do for machine learning and genetic algorithms, like this one. Hip file attached if it helps. Any ideas? procedural_wedge.hipnc
  6. @konstantin magnus Sure, I mocked up some examples of clothing that represents what we're dealing with. Two of them are from the "DemoSoldier" ZBrush project, and the other two are modified from the Houdini "Test Geometry: Tommy" keep_outer_side_examples.hipnc
  7. Thanks @konstantin magnus, I've been meaning to come back here once I've taken the approach as far as I can and I think that's where I am now. In a nutshell, it works well for simple cases where the differences in angles between seam and surface are distinct. I managed to find a way to help increase that distinction for geometry that had sharp angles not part of seams, like t-shirt arms or general wrinkling in the model, by prepending a Smooth SOP. It had this nice effect of making uneven surface angles smoother, whilst making seams *sharper*, and works quite well for a few kinds of clothing. I was also able to build on this technique to automatically move the resulting surface to the center of its thickness, even in cases of irregular thickness across the surface. An ideal case for cloth simulation. The issue I found however was that my clothing is rarely evenly extruded. Part of the interior is often removed; partly for optimisation (as it would never be visible) but likely for ease of editing the clothing after the extrusion. And when the thickness ends shortly after the seam, this smoothing trick doesn't cut it anymore.
  8. VEX and normals from @ptnum

    Thanks @animatrix
  9. VEX and normals from @ptnum

    That's it, thanks. I figured it must have been something obvious like that. But that begs the question; what attributes are generated on the fly like this? More importantly, how do I generate attributes on the fly for anything other than geometry 0?
  10. VEX and normals from @ptnum

    Hi all, I'm new to VEX and am facing an odd issue. With an Attribute Wrangle iterating over points, connected with any polygonal mesh (in this case a Sphere). // Why does this not work.. vector broken_normal = point(0, "N", @ptnum); // Why this does? vector working_normal = @N; // And this as well? vector working_position = point(0, "P", @ptnum); if (@ptnum == 0) { printf("%s\n", broken_normal); printf("%s\n", working_normal); } // {0,0,0} // {-6.31725e-09,7.5807e-08,-1} As you can see, the "broken_normal" yields a value of { 0, 0, 0 } when I would have expected a value identical to the "working_normal". I'm running this on Houdini 18. vex_and_normals.hipnc
  11. That's a really good idea, could potentially sculpt something more fitting than a sphere for complex cases like a long-sleeve shirt. I wasn't able to manuever the feature, it didn't seem to respond to changes to the sphere and didn't seem to respond to any changes to the geometry at all. :S Will need to experiment more, but the idea is sound!
  12. Thanks for chiming in @konstantin magnus, that sounds reasonable. Would it be possible to illustrate? I also considered converting to a volume, and generating a new single-sided mesh from it. Since the mesh is remeshed before use in a simulation, preservation of the topology isn't necessary. It would need to fit somewhat tightly though, and would need to account for folds and nearby parts of itself.
  13. Hi all, There likely does not exist a perfect solution here, instead I'm looking to brainstorm and find the most automatic method by which to detect and remove one of two sides from a double-sided polygonal mesh. The end goal is preparing meshes for simulation with Vellum, of e.g. a t-shirt or pants, that has been modelled with two sides (to represent thickness during render). The simple solution would be to provide a separate one-sided mesh for simulation in addition to the renderable mesh, but when that is not possible the current workflow are as follows. Recieve double-sided render mesh (of potentially too-high polygonal count and needless edgeloops unsuitable for simulation) Manually select interior (via e.g. edgeloops and growing of primitive selections) to remove it Remesh to achieve a uniformly distributed triangular mesh Profit The manual step (2) is what's preventing my setup from being applied procedurally to the tens of characters with tens of double-sided geometries each. I'm attaching an example of one such mesh for clarity. Given that thickness is most commonly - but not always - achieved by extruding a single-sided mesh, there are some assumptions we can make about the extruded side; primarily that each exterior primitive will have exactly one associated interior primitive, and that their normals are facing away from each other. So what I've got in mind is somehow iterating over primitives, finding their closest neigbours and checking whether any of them are (1) unconnected, (2) within a certain distance and (3) faces the opposite way. That's about as far as I've gotten at this point, and wanted to enquire with the community about whether anyone has tackled a similar issue, or whether there are any ideas along the same lines? Thanks, Marcus