PTex support in osl/oiio?

[Dan Kripac]

Hi there,

I'm just having a look at the impressive Moana dataset kindly donated by Disney research and I thought I'd make sure we could render ptx textures in our OSL plug-in for PRMan.

No mater what I try I can't seem to get the face boundaries to interpolate as expected?

This is with whatever the default swrap and twrap are which in this ptx file is "clamp"

This file is: "textures/isGardeniaA/Color/archivegardenia0009_geo.ptx"

​

If I force the swrap and twrap to "mirror" in the texture() call I get better (but not correct) results.

Also if I force to "clamp" I get a similar (but worse) result to mirror but it looks different to the default (above) which *should* be the same as "clamp"?

​

The stock PxrPTexture PRMan shader does not seem to use the correct u,v patch coords and is totally messed up! But I think this is something to do with the face winding order of Alembic compared to Ptex?

Anyway, after looking at the code for the ptex OIIO plug-in  I wonder if the correct face boundary interpolation is actually even possible?

Does anyone know how to use it or if it works correctly?

The pseudo code for how I'm reading it in our OSL PRMan plug-in is:

// Use the implicit PRMan patch u,v coords as the Ptex coords

// compensate for some-sort of polygon winding differences.

float s = v;

float t = 1-u;

float faceindex = 0;

// this must be generated by a Rif filter in PRMan

getattribute("__faceindex", faceindex);

color res = texture("thefile.ptx", s, t, "subimage", faceindex);

Cheers

Dan

​

[Dan Kripac]

If anyone can validate this, here's a tar ball of the ptx and geometry.

Cheers

Dan

[Larry Gritz]

The OIIO ptex plugin can read the faces but does not currently interpolate across face boundaries. It just treats each face as a separate subimage. The neat thing about ptex is that the file encodes the topological relationship between the faces/subimages, OIIO just doesn't yet examine that in order to know what pixel from what face is on the other side of the boundary. That was one of those "things to do next" tasks, I assume it's not rocket science, but frankly nobody has asked for it so it just hasn't bubbled up to the top of the list. 

Because of that, I must admit that I haven't explored too deeply what, if anything, is missing from the OSL side to make ptex happy. I assumed it was just a matter of passing the face index as "subimage" to the texture call, but if there are other minor details necessary to make it smoother, I'm all ears.

Maybe this Moana data dump is incentive to make it happen. It would be really great to have help on this -- not just as a way for me to shirk responsibility for the coding (though there is that, too), but because it feels like one of those projects that's more likely to be successful if it's done by somebody with a real stake in whether it works well because they need to actually *use* it. My facility doesn't currently use Ptex, so not only does that make it harder for me to justify spending any work time on it, but also I simply have very limited ability to test it, nor anybody close by who will tell me what I've done wrong if I'm not delivering something useful to production.

If anybody is interested in taking this on, I can help with plenty of advice, guidance, and unlimited answering of questions about OIIO internals.

-- lg

On Jul 11, 2018, at 9:29 AM, Dan Kripac <dank...@gmail.com> wrote:

Hi there,

I'm just having a look at the impressive Moana dataset kindly donated by Disney research and I thought I'd make sure we could render ptx textures in our OSL plug-in for PRMan.

No mater what I try I can't seem to get the face boundaries to interpolate as expected?

This is with whatever the default swrap and twrap are which in this ptx file is "clamp"

This file is: "textures/isGardeniaA/Color/archivegardenia0009_geo.ptx"

<disney_moana_leaf_ptx_osl_default.png>

​

If I force the swrap and twrap to "mirror" in the texture() call I get better (but not correct) results.

Also if I force to "clamp" I get a similar (but worse) result to mirror but it looks different to the default (above) which *should* be the same as "clamp"?

<disney_moana_leaf_ptx_osl.png>

​

The stock PxrPTexture PRMan shader does not seem to use the correct u,v patch coords and is totally messed up! But I think this is something to do with the face winding order of Alembic compared to Ptex?

<disney_moana_leaf_ptx_PxrPTexture.png>

Anyway, after looking at the code for the ptex OIIO plug-in  I wonder if the correct face boundary interpolation is actually even possible?

Does anyone know how to use it or if it works correctly?

The pseudo code for how I'm reading it in our OSL PRMan plug-in is:

// Use the implicit PRMan patch u,v coords as the Ptex coords

// compensate for some-sort of polygon winding differences.

float s = v;

float t = 1-u;

float faceindex = 0;

// this must be generated by a Rif filter in PRMan

getattribute("__faceindex", faceindex);

color res = texture("thefile.ptx", s, t, "subimage", faceindex);

Cheers

Dan

​

--
You received this message because you are subscribed to the Google Groups "OSL Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osl-dev+u...@googlegroups.com.
To post to this group, send email to osl...@googlegroups.com.
Visit this group at https://groups.google.com/group/osl-dev.
For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l...@larrygritz.com

[Shane Ambler]

On 13/07/2018 03:11, Larry Gritz wrote:

> If anybody is interested in taking this on, I can help with plenty
> of advice, guidance, and unlimited answering of questions about
> OIIO internals.>
>
> -- lg

Don't know if it will help anyone but opensubdiv includes a ptexviewer
that can display the Moana leaf. Could be an example of reading ptex.

https://github.com/PixarAnimationStudios/OpenSubdiv/tree/master/examples/dxPtexViewer

--
FreeBSD - the place to B...Software Developing

Shane Ambler

[Larry Gritz]

We can read Ptex just fine. The issue is the changes inside our texture system to properly handle the cross-face interpolation.

On Jul 12, 2018, at 8:55 PM, Shane Ambler <Fre...@ShaneWare.Biz> wrote:

On 13/07/2018 03:11, Larry Gritz wrote:

If anybody is interested in taking this on, I can help with plenty
of advice, guidance, and unlimited answering of questions about
OIIO internals.>

-- lg

Don't know if it will help anyone but opensubdiv includes a ptexviewer
that can display the Moana leaf. Could be an example of reading ptex.

https://github.com/PixarAnimationStudios/OpenSubdiv/tree/master/examples/dxPtexViewer

--

Larry Gritz

l...@larrygritz.com

[Dan Kripac]

Thanks for the explanation Larry,

It was becoming apparent that it was at a 'first pass' working state.

Ok well if I get any fooling around time at home (DNeg also doesn't use ptex) I'll have a try.

The other quite major thing I noticed in the code is that it seems like all metadata gets pre-loaded when a plug-in instance calls seek_subimage for the first time regardless of whether you need it or not.

https://github.com/OpenImageIO/oiio/blob/master/src/ptex.imageio/ptexinput.cpp#L220

As far as I can tell (when running ptxinfo -m thefile.ptx - to display metadata, all of the mesh vertices and topology arrays are stored as metadata key-values.

This would potentially mean that for every instance of the ptexinput class per-texture file there would be a full copy of the ptex mesh.

This could really add up when dealing with large mesh data sets. Plus, does OIIO make a separate copy of ptexinput per-file per-thread?

While the metadata pre-load could be changed in this plug-in, it highlights for me one of the major flaws with ptex as a format.

Because you cannot store multiple arbitrary channels per-Ptexture you are forced to have n copies of the mesh on disk and in memory for every texture channel referenced for a material for each mesh.

Perhaps ptex is good at deferred loading only what it needs (I don't know the details)?

Anyway, I can see why UDIMs have mostly won out in the vfx space.

Cheers

Dan