Hi did you ever get this to work?
I'm having the same problem and can't get a baked blueprint to generate with a specific name

Hi did you ever get the "unreal_level_path" attribute to work?
I'm having the same issue now..

darkimage
im facing a normal seam issue when using the tile split node do you guys know how to fix this type of issue
in houdini (visible seams) -> https://i.imgur.com/jR6t01p.png [i.imgur.com]
in unreal (even more pronunced visible seams, wold normals are incorrect at the edges of the tiles) -> https://i.imgur.com/xtXBDJz.jpg [i.imgur.com]
the setup is identical to the one used by hektor (using a pdg network to drive the tile number of the tile split)

Hi darkimage,
Sorry to bring up and old thread, but I am also getting normal issues at the seams between my heightfields in Unreal, I was wondering if you found a fix?

Basically I am using a Houdini Engine HDA in Unreal to import a landscape I have split into 4033x4033 resolution tiles in Houdini.
The edges of the landscapes align perfectly without overlap, but there is an ugly dark line in the lighting at every seam, so it seems like a lighting/normal issue on the Unreal side.

In this case I can't just make one huge landscape but have to divide it up into multiple landscape actors, each with multiple landscape streaming proxies.

If anyone has any ideas on how to make the seam between 2 landscape actors "seamless", that would be great to know.

Thanks Sebi,

I did end up using Houdini Engine to import a .bgeo file and by using the detail attributes naming convention in the Houdini Engine docs, was able to get fine grained control over proceduraly creating sockets in SOPs context.
This way it also gives me good control over the name of the .uasset it creates, and allows to overwrite the previous one so it's more or less the same functionality as right clicking on a static mesh that was imported from a .fbx and selecting re-import from file.

Cheers for the great suggestion!

Hi eusebijucgla,

I actually just tried this today, by using the `Build hierarchy from Path attribute` option on the FBX ROP node, but no matter what I did I could not get the sockets to work.
One issue is that the path attribute needs to be on a primitive, but for the socket what would that primitive be?
All I want for that is a transform.
I tried using an empty packed primitive but it caused a fatal error when trying to export the FBX.
I also tried using simple box geometry, but unreal just imports the boxes in as separate meshes instead of sockets, even when using the naming convnetion of SOCKET_## from their own docs.
The only way I cuould get sockets out of Houdini in an FBX file and into Unreal, is to do it at the Object context, and use Nulls for the sockets.. which is tedious and doesn't lend itself to being procedural, especially with many sockets.

Any advise (or a sample file) would be great!
Cheers

Hi Rob, sorry but this particular example is for a commercial project and under NDA so I can't share it, but when I get some free time I'll try and put together a simple generic test that reproduces it.
Cheers!

Hi there,
I am trying to render a simple VDB sequence in LOPs/Karma, using the Render All Frames With a Single Process option on the USD Render ROP.
The reason I'm using that option is because with it switched off, the Husk process time per frame is about 10x longer than the frame itself takes to render.. so with it switched off the sequence takes ~10hrs to render, with it switched on takes about 1hr.

This technique has worked on other VDB sequences, but for some reason with this particular one I'm having problems, namely that the VDB sequence will get "stuck" at random frames and not progress to the current frame's cache, or suddenly move in world space to a random location and then back again.
If I disable Render All Frames With a Single Process I don't have these problems, but the Husk processing times are a dealbreaker.

I have tried using a VDB sequence on disk and reading it in using a Volume LOP, I have also tried bringing the volume in through a SOP Import LOP, both have the same problem.
The nodes are definitely Time Dependent.

I'm sure I'm missing something simple that has to do with USD time authoring of samples maybe.. any ideas on what I can try to get this to work?

Thanks!

Has anyone managed to get Landscape Streaming Proxies to import properly in a World Partition level?
Each one of my landscape tiles comes in as a streaming proxy each with it's own Landscape actor, instead of all sharing one Landscape actor.

I have set unreal_landscape_tile_actor_type and unreal_landscape_shared_actor_name attributes correctly, but they still each come in as an independent landscape

Hi there,
I'm building an HDA that uses PDG to reference multiple other HDAs on disk, write geometry files to disk, and then generate geometry in Unreal Editor.

Since $HIP and $JOB aren't useful inside Unreal Editor, my question is how to go about using relative paths to read the HDAs and read/write the geometry files on disk?
This setup will need to be shared on Perforce so that multiple users can use the top level PDG HDA without issue.

Are there any variables available to get the location of the Unreal project from inside Houdini Engine?
I think then at least some relative paths could be constructed.
I saw another post that recommended using a custom Houdini environment file, that can be loaded by Houdini Engine in the project settings, but even then wouldn't a path like $HSITE or another custom variable still have to be set to an absolute path to begin with?

Ultimately I would like someone to be able to download the Perforce depot into a workspace at any location on their drive, and then the HDAs and intermediate geometry file be able to be saved into a path relative to that location.

Lastly, what would be considered best practices for including non-Unreal project specific files (such as the .hda files) in the Perforce depot?
Would you do something like put a folder called Assets at the top level (next to Content, Plugins etc), and have subfolders in there for hda (for the HDAs), geo (for intermediate generated geometry) etc?

Cheers for any advice!

I think I tried everything I could and then gave up to be honest.. if you find a way to do it, let me know!

Hi there,
I'm using VAT 3.0 in Unreal 5.0.3, I'm using the softbody deformation VAT as well as the rigid VAT.

For the softbody VAT I'm having an issue where many of the vertices on my model are "jittering" around by small but very noticeable amounts frame to frame, and I have confirmed that they are definitely not doing that in Houdini.
I had a feeling it may be some kind of floating point precision error, but the overall scale and world position of my animation is not very large at all (any geometry is maybe max about 20m from the world origin at any time).
I am exporting VAT textures as HDR .exrs, I tried turning on Use Full Precision UVs on the mesh, and I tried changing the Embedded Data Rounding on the material instances, but none of those seems to have any effect on the jittering.
I've tried this on multiple meshes in 2 different project files now, and the same thing happens in all of them..
is it a precision limitation of the VAT workflow?
Or does it sound like something isn't working correctly? ..in which case do you have any suggestions of what I can try next?

Thanks for any help!

Piling on here, having the same issue.
When using session sync I can't undo any new actions in Houdini, making it unusable really

Hi there,

I'm hoping to switch to Karma XPU (from Redshift) for my FX volume rendering needs.
I know that Karma XPU is still in beta, but it's my understanding that Karma CPU is more or less production ready.

My question is whether it is possible in Karma (CPU or XPU) to render point-instanced vdb volumes, with per-instance material attributes that can be driven by attributes on the template points.
For example, to have a Cd attribute on the template points that drives the smoke colour on the volume shader (per instance), or a float attribute on the template points that can drive the smoke density (per instance).
This is possible to do in Redshift (standalone), and would be amazing and very powerful to be able to do in Karma.

I've been able to do this with regular instanced geometry (have template point attributes to drive the colour of the instances in the MaterialX shader), but I can't get it to work with volumes.

If this is possible, then any help would be greatly appreciated.
Or if it is not possible, is it something that might be coming down the track? ..or will it never be possible in Karma.

Cheers!

Oh awesome, thanks twod I'm looking forward to checking it out!

I'm not sure technically what the issue is but from a practical standpoint it's definitely problematic for me because it means I can't trust what I see in the Renderview through the OCIO display transform.. since it looks different than when viewed in other software such as Nuke with the same OCIO display.
As mentioned the dark areas lose a lot of detail in the Mplay and Houdini Renderview

Hey there,
I've tried every combination of advection schemes in DOPs but I can't figure out how to properly advect a Cd (color) vector field without getting very ugly artifacts in the field.
(see screenshot for a slice of the Cd field)

For example I have a Cd field with a subtle color variation over 3D space from a beige to brown color gradient.. but when I advect the Cd field with the vel field in sparse Pyro I start to get very ugly artifacts in the Cd field, lots of little bright green and blue and red spots show up and disappear from frame to frame.
I've tried the different advection schemes and tried injecting a solid Alpha float field with a uniform value of 1.0, but it doesn't seem to help.
I also tried rebuilding the microsolver network to advect the Cd and Alpha fields and do the premultiplying math etc outside of the Pyro HDA.

I can't right now, but at some point I could put together an example test scene, but in the meantime is there a canon recommended method for advecting color fields?

Thanks for any help!

Are there any clever cookies out there that would be able to figure out how to implement a Total Variation Inpainting algorithm in COPs??
I found this paper and source code online: http://www.ipol.im/pub/art/2012/g-tvi/ [www.ipol.im]

There's a node in Nuke compositor called TVI Scale that uprezes an image by a factor of 2, and it gives the best all round uprez results I've seen, and it would be amazing to have a similar fancy uprez method using the TVI algorithm in Houdini COPs.

Ha that's not a bad idea, I might try that..
In the meantime extruding the ground down and using it as a bullet concave object seems to be working suprisingly well, even though I know it's best to avoid using concave collision geos and it's pretty slow.. using a heightfield here would be ideal!

Hey there,

I am trying to collide many hundreds of bullet rbd packed spheres (using spherical collision shape on the bullet object) against an undulating ground plane (think similar to the surface of an ocean or swimming pool).

I want to use the terrain heightfield object to collide the bullets against so I don't have to create some crazy set of convex meshes to represent the animating ground.

If I use a static heighfield to collide against it works great! But as soon as I set the object to deforming, so that it reads in the heightfield at every timestep, all the rbds just dissapear as soon as they collide with it and the P attribute is set to ‘nan’.

Is this a known limitation that bullet packed rbds can't collide against a deforming heightfield??

This will really save my hide if I can get it to work..
Alternatively, what would be the next best thing to collide against an undulating animated wavy ground plane?

Cheers!

Bumping this thread again..

Here's a screenshot of a cropped render linear .exr being displayed in Nuke with the (Aces 1.1) Rec 709 display transform, right next to the same .exr being displayed in Mplay with the Rec 709 display transform:


See how all the detail in the shadow area beneath the car and also along the wall of the tyre are being almost completely crushed to black in the Mplay viewer, which displays the same in the Renderview inside Houdini.

I'm using the Aces 1.1 default OCIO config file.
In that config file, the scene_linear role is set to: ACES - ACEScg
My system $OCIO environment variable is set correctly to point to the config file, and Houdini and Nuke are picking that config file up and are configured correctly as far as I can tell.

I've attached the .exr file in case anyone can take a look at it and please tell me if there's something I'm doing obviously wrong on my end.
Apologies to harp on about this but it's becoming more and more critical to my work to get this right..