Jump to content

Atom

Members
  • Content count

    3,323
  • Donations

    0.00 CAD 
  • Joined

  • Last visited

  • Days Won

    110

Posts posted by Atom


  1. You could call the more extended version of curl noise directly. There is a periodic version that might help with the tiling. You need to include the voplib.h to access these extended functions, which are basically what VOPs wraps.

    vector freq = chv("Frequency");
    vector off = chv("Offset");
    
    #include <voplib.h>
    vector noise = vop_curlNoiseVP(@P, freq, off, { 0, 0, 0 }, "pnoise", "", 3, 0, 1, 0.5, 1, 1, 1, 0.0001);
    
    // Laydown along an axis.
    v@N = cross(noise,{0,0,1});

     


  2. You might want to try something like this but use a Timeshift node instead of Retime. Shift time so the second input to the skeletonblend will be the final pose that you want to loop upon. You can even drop down a RigPose node to tweak the final pose for best blending. Animate the skeleton blend bias at the right time to take on the final pose.

    Untitled-1.jpg


  3. The use case that I am pursuing is using the Labs toolset to export the VDB points (not volume data) as a hbjson file. This is readable using the Labs Niagara plugin for Unreal. It's a way to export points from Houdini pyro, and use them in a particle system point source inside of Unreal.

    Check out Simon's tutorial on the topic.
    https://www.sidefx.com/tutorials/realtime-fx-with-niagara-ue4/
     

    You can download the project files and review his HIP setups.


  4. I don't know of any direct pipeline for Unreal to render volumes from Houdini. The Unreal Niagara particle system can accept a Houdini generated point cache to drive the Unreal volumetrics.

    You may want to search for tutorials on Houdini to Niagara.

    I'm in the process of trying this pipeline, myself, so I don't have a solution yet.

    Houdini fractures and Unreal Alembic imports don't like each other. This is because Houdini will generate n-gons. Unreal can only import triangles and quadrilaterals. I use this setup to detect and convert n-gons into triangles.

    The bad candidates are detect inside an attributeVop running over primitives.

    i@group_candidates = 0;
    int num = primvertexcount(0, @primnum);
    if(num > 4) {
        // Not acceptable by Unreal.
        i@group_candidates = 1;
    }

     

    Untitled-1.jpg

    ap_rbd_fixup_for_unreal_alembic.hiplc

    • Like 1

  5. I agree, that is a candidate for bug report. Go ahead and unlock the HDA and move to the bottom of the network. You'll discover that your attribute is copied to the guide geometry, but not the Output node.

    To continue your work, try using an attribute transfer after the trailsource to forward your attributes along.

    Or give this a try...

    trailsource_fix.gif

    • Like 1

  6. When Unreal hangs with no progress, it means the Alembic file is not usable by Unreal, even if other software can read it. One thing to try immediately is to export a short frame rage to keep the file size small until you figure out the attributes. Unreal can't handle a 4million polygon object, it is only a game engine.

    Get rid of Cd, move uv to points, polyreduce and try again with a limited frame count. I have been able to export 360-480 frame Alembic to Unreal.

    Don't use Skeletal or Static mesh, use the experimental geometry cache.

    Untitled-1.jpg


  7. That's completely normal. With certain setups I am constantly clicking on the Reset Simulation button. It's annoying to have to jump up a level to do that. DOPs can't tell if a parameter that feeds the network has changed. So if you change, for instance, @pscale on the points that you supply to the network, that will not alter the generated cache, at least not until you issue a "rewind". In your case you have started the DOP simulation on frame #3. Try changing your start frame on the playbar to 3, instead of 1. Then a rewind might work for you. Or, change your start frame to #1 and time shift the final to frame #3 after you have locked in the simulation.


  8. I'm certainly no expert on this topic, but I have been trying the same thing. I want to get my Houdini animated deforming mesh inside of Unreal for rendering.

    As far as FBX goes, you need to supply a bone system with the deformed mesh. This is basically for characters or machines that you have pre-rigged. I don't really export anything from Houdini using this format.

    This basically leaves only the experimental alembic cache as the animated option for Houdini->Unreal.

    The Alembic support for Unreal is fragile. It can not accept any polygons that are not triangles or quads. You need to prepare your geometry output with that in mind. I use this simple wrangle to subdivide any primitives that are over the vertex count.
     

    Untitled-1.thumb.jpg.de592154cddb7df9ac9ba7aeea2d8a98.jpg

    Another thing that will hang up the Alembic import on Unreal 4.25.3 is the presence of excessive attributes or groups. You don't need normals, and that seemed to hang up my import until I figured that out. You only need @P and @uv, both on points. Make sure to check "Recompute Normals" on the Unreal import dialog box. If you do wish to keep your normals, use an attributePromote to migrate them to points instead of vertex, which is typical for FBX. This does add weight to the final file size, however, and you can recompute them on import.

    NOTE: if you do supply groups, they show up as material inputs inside of Unreal. For fracture sources I recommend keeping inside and outside groups.

    Untitled-1.thumb.jpg.2abd2dcf01d3550fc8a0f86452e221c2.jpg

     

    Both the dragon and the fracture were exported as mesh based, non-instanced, Alembic caches from Houdini. The dragon is a 480 frame cache that is about 210 MB in size. The wall is 480 frame cache that is 643Mb in size.

    alembic_cache.gif.a61a25420b2b4af0bbf05cd94dd595b4.gif

     

     

     

×