teodor staicu

yes

looking at the nodes inside maps baker it seems they are normalized even if they are not "clamped" by the filetype. there's also a convert node in cops for all maps that converts to 16 bit for some reason. i guess it makes sense for games that 32 bit textures are overkill, but what if you want to bake out something more precise like position or normals...

i need to evaluate if i really need the HDR values or if i can accept the loss of precision, else i need to "gut" the baker or make my own.

make sure the texture compression is HDR, no srgb, nearest filtering, etc.

on the mesh, enable high precision UVs and that the generate lightmap uvs is not overriding the uvs used by the VAT

best way to do this would be with soft body deformation VAT.

in unreal try to use the debug material functions in order to see the resulting values.

another thing is that houdini and ue have different unit systems (meters vs cm) and the axes are switched (y and z). by default the labs VAT system should account for that but you can always check to see what happens if you swizzle the axes a bit.

hi, i have a VAT-like system where i need to bake out position data kinda like vector displacement.
i'm using labs maps baker and tried a custom attribute bake, but the EXR data is clamped (at least the negative values are).
i tried using the vertex color (Cd) option but same results.
from what i understand, just by using a HDR format like Exr is sufficient for the baker to output correct data (i.e: 32 bit float).
when opened in PS the file is indeed 32 bit but the negative values are not there.

looking at the data in houdini spreadsheet i see that it is correct both in terms of type of data and the values (negative values and above 1).

does anyone have any idea why this is happening? am i missing something?

there is a merge node that throws a warning something about attributes not being initialized properly but checking the data before and after the merge node i see no difference...