I am trying to make a baker which is selfconatined so it can become a OTL.
Running into alot of different issues, but it sorta does Diffuse, AO and Normal now.

Some of the issues:
- The diffuse gets a nasty seam where the Hi-Res intersect the Lo-Res.
- My Normal baking math skills are limited
- Normal bake seems to be in the wrong color space not sure how to fix.
- Doesnt seem like I can make the “UV Render Object” in the ROP to be a realtive value.

But anyway, I will tinker on and if someone wants to play with it and solve things I also attach a .hip file. Which is a Indie .hip file so not sure apprentice people can open it but there you go.

Trying to figure out why this happends…because in my mind it shouldnt

Issues update:
- The diffuse gets a nasty seam where the Hi-Res intersect the Lo-Res.
- My Normal baking math skills are limited

Fixed:
- Normal bake seems to be in the wrong color space not sure how to fix.
- Doesnt seem like I can make the “UV Render Object” in the ROP to be a realtive value.

But I would love if someone has any input on whats happening on the above screen where the normals are strange. This can however be solved by subdivding the lo-res to a silly amount..but I would rather like not to do that.

Updated version with my fixes and a ‘ugly’ subdivide' lo-res for better result work around.

Here is a procedurally generated “stone” I made both Hi and Lo poly in Houdini, baked it with the baker, exported Lo-poly mesh to .obj and saved out the AO and Normal. And renderd it in Modo just well..because.

Hey Magnus, great to see you doing this work hope you get an awesome asset you can submit to orbolt!

I perhaps can be of assistance as I have done this for my studio already.

which VOP node are you using to transfer the information from the hi res to the gameres? those issues you get when the intersections happen do not manifest themselves when using the gather loop VOP, but can show up with the ray VOPs. Do make sure you are doing also a bi-directional trace so that you can catch changes on the surface whether they go into or out of the geo (i.e. two gather loops with opposite normal directions, with a check to see which one hit. I generally bias the forward facing direction, and if fails, use the backwards direction). You can also calculate your max distance procedurally in SOPs as an attribute generated by the ray SOP and feed it to the gather loop directly ( a nice perk over many other applications)

for the geneation of your tangent space normal map, how are you generating your tangents and binormals? just using a polyframe may not be enough if you need to take in account areas of the geometry where primitives may have attributes which cause your tangent and binormal calculation to split. For example, on a UV seam you may have a problem if you are using UVs to generate your tangent space. You will have to do some massaging in vex to resolve those seams

you should be able to use relative paths on a mantra ROP if using the opfullpath(“../relPath”) syntax (but I recall seeing another post where this was giving you issues?)

also, if you use the gather loop to transfer the albedo information (which comes already from a texture) I recommend to render at the source resolution, then scale to target resolution as a post process in COPs using sinc filtering. That will yield the best results

grayOlorin, thanks for your feedback. I am using both gather loops and ray hit, I was thinking of trying to just use gather loops.

You should download the hip file and tell me what I did wrong since u already have done one I think that will be easier than me trying to answer your questions.

I posted it here in the hopes that it might be like a community thing that people contribute to it since I feel that I might not be the best person for normal map math

Hey Magnus, so got a chance to look at your setup. The issue you show above appears to be due to the tangents and binormals being wound differently at that location of the geometry. you can see it even a little bit after you subdivide the geo, but its a lot smaller as the polygons are smaller.

Making the UVs a point attribute via a vertexSplit (which splits the geo at the verts, then promotes the attribute) seems to make that go away (as I suspect the import of UVs into shader context is probably having an issue). However, for some reason when I did this, my render to UV seem to be rendering incorrectly (almost as if the UVs were focused on a smaller area of the map). Did not look too much into that, but perhaps that may be a useful lead for you? Another thing to try is, instead of computing your tangents twice (which may be calculating different at that particular point), try doing your ray hit direction switch BEFORE you calculate tangents, then calculate the tangents on the output of the switch.

Another thing I noticed could be improved is that you shoot a ray, see if it misses, then calculate the inverse ray hit. What if both hit but the inverse is shorter than the regular? who should win? in my case, I test both, and pick the shortest that hits, and if both hit, I bias towards forward facing. This may help some too

What I did on my tool, is to generate my own tangents and binormals in the SOP context, pass those directly to my shader, and convert from world to tangent that way. But I think you are in the right track to be honest (heck I think I want to use the compute tangent VOPs now on my side just to compare notes).

if all that fails, have you emailed support about this or submitted a bug on the computeTangent vop?

hope this helps! Looking good man