Balazs Gyurics

Did you took a look, as what non desirable attributed had been smuggled into the SOP net? It could happen accidently by a miss click in the SOP network. After you dropped an attribute delete, try to regenerate the geo's normal attribute. Also take a blink on a normal render VAR path - what it shows on the problematic field. I know these are simple suggestions, but I'm sure that the geo has something not wanted. The mentioned version worked well on my side with old projects.

I'm in the same boat.

It would be cool to know how we would be able to render out an animation sequence that was stylized in cop net.

So far it seems that the official description is lacking somewhere, since I could not render out my results true ROP out, just true COP image out, but well, in that case its not just the lack of sequence but also quality - I can not manipulate the settings true Karma render settings.

The opportunities that it would be able to offer are fantastic! I hope we will receive a solution.

Photogrammetry and 3D scans in general are more and more popular in regards of building an asset pack for a shot.

Generally speaking not a single tool can handle texture baking processes due to these not rarely close to a billion polygon meshes.
(The one and only tools that can handle such process are the integrated bakers inside PG software as Reality Capture or Zephyr as two examples. They handle the baking process that is restricted to normal and displacement by exploiting the fact that all these mega meshes before export are aligned and meshed to parts, so several parts are baked separately not the whole mesh)

We are (in general) working with such large UDIM counts nowadays, that it is a pure waste of captured details to decimate these meshes before handling the baking process.

I would love to see a Karma driven new baker (quite same HDA as Lab's baker) built up by a node graph that would handle the mesh separation and UDIM split.
I would love to see it as a pure GPU baker: texture resolution and geo detail goes hand by hand due to photogrammetry, so basically what should be handled by one go is a 4K 1:1 UDIM segment + the underlying mesh (take in account that optimal texel density due to photogrammetry is already requires as many UDIMS, that if we would use the UDIM field as a converted attribute that separates the mesh to parts, it would always generate a part that can fit even to a middle range GPU Vram (12-16) and never would run out IF optimal texel density is used based on the photogrammetry data.

Valid question: why don't I set up a HDA as that?
Maybe I will have to, but I'm sure, that since Karma's ray projection plays with a bunch of random values, I would not be able to write it in a way to dodge visible seams between the parts. Also, my version would be 10× slower and would hide a bunch of issues VS a HDA that is written the SideFX team.

I hope we will be able to see something as described above in the near future.

(please correct me if it exists, I did not found it - and no, its not the simple baker and it is not the existing Lab's baker)