Ptex Writer problem with texture exporting

32 views
Skip to first unread message

Colin Chargy

unread,
May 14, 2014, 12:26:38 PM5/14/14
to pt...@googlegroups.com
Hi guys,
I'm trying to write an ptex export module and I'm having few issues while exporting textures.
I try to isolate the problem. Here is the thing : if I put 0 in every red channel of an image and 255 in every blue one, I don't get these values while reading the output file.
Enclosed, you can find the sample cpp I use to test it.

Can you see where I'm wrong or what am I missing ?

Thanks for your help,
Best regards,
Colin Chargy
TestPtex.cpp

Brent Burley

unread,
May 14, 2014, 12:37:43 PM5/14/14
to pt...@googlegroups.com
When I run your test (on Linux) it passes and prints "no error found".  Btw, I had to add includes for stdio.h and math.h and also fix the syntax of the FaceData ptr initialization (PtexPtr doesn't support operator=).  What values are you seeing in your getPixel result?


--

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

Colin Chargy

unread,
May 15, 2014, 4:10:29 AM5/15/14
to pt...@googlegroups.com
Hi guys, Hi Brent,
Thank you for your time.

I've patched as you said and I've reduce the test to a simple 4x4 writing/reading data. When compiling and executing it on Linux and Windows (Visual Studio 2010), I have the same result : the read data is not what I've been written. I have enclosed the cpp file and the result I have on both system. Have you the same problem ?

Thank you,
Best regards,
Colin Chargy
ResultTestPtex_Linux.txt
ResultTestPtex_WinVS2010.txt
TestPtex.cpp

Brent Burley

unread,
May 15, 2014, 10:36:49 AM5/15/14
to pt...@googlegroups.com
Your revised test compiles without error and runs successfully for me.  It would be useful to see if it is a problem reading or writing.  You can look at the data in the generated ptex file with ptxinfo.  Here's what I get with your file:

> ptxinfo -d test2.ptx 
meshType: quad
dataType: uint8
numChannels: 3
alphaChannel: (none)
uBorderMode: clamp
vBorderMode: clamp
numFaces: 1
hasEdits: no
hasMipMaps: no
numMetaKeys: 0
face 0:  res: 1 1 (2 x 2)  adjface: -1 -1 -1 -1  adjedge: 0 0 0 0  flags: (none)
  data (2 x 2):
    (0, 0):  0.000 0.000 1.000
    (1, 0):  0.000 0.004 1.000
    (0, 1):  0.000 0.008 1.000
    (1, 1):  0.000 0.012 1.000
texels: 4

Note that ptxinfo shows integer data scaled to a normalized range (1.0 = 255)

You might try calling PtexWriter::close explicitly and check the return value and error string.  You might also try reading and writing from separate test programs.

Colin Chargy

unread,
May 15, 2014, 12:00:42 PM5/15/14
to pt...@googlegroups.com
Hi Brent,
Thanks again.
As you suggested, I used the close function, I checked its error return (empty) and I split the code in two differents files. Still the same. I've run the ptxinfo program on the result of my test program. I get the enclosed file (still wrong). Could you try your ptxinfo on my file and send me the result ? Also, can I have your resulting .ptx (in order to test it with my ptxinfo) ? This way, I should be sure of what's wrong : my reading, writing or both.

What could make this issue happen ? Zlib or cmake version (I'm using cmake on windows) ? I've get the file as a zip from github (ptex-master), not by checkouting them with git (I don't have internet access in the dev computers). Does it matters ? I'm looking for every thing that could cause these differences ...

Thank you,
Best regards,
Colin Chargy

ResultPtxInfoLinux.txt
test2.ptx

Brent Burley

unread,
May 15, 2014, 12:11:22 PM5/15/14
to pt...@googlegroups.com
I get the same output as you, so it looks like a problem writing.  I've attached my test2.ptx.
test2.ptx

Brent Burley

unread,
May 16, 2014, 11:00:32 AM5/16/14
to pt...@googlegroups.com
Thanks Colin for debugging this.  It was a regression from a recent commit.  I've just pushed a fix.

Reply all
Reply to author
Forward
0 new messages