Texture UVs computed incorrectly

[GoogleCodeExporter]

I took the collada duck and converted it to OBJ, then ran objcompress on it to 
get a UTF8 file. I loaded it in three.js and here is the result:
http://jterrace.github.com/webgl-utf8/

The mesh looks good, but the texture is wrong. I thought at first that it might 
just be the texture flipped in the y-axis, but I tried various combinations of 
flipping the texture and couldnt get it to line up correctly.

Is something going wrong here with the encoding? Or perhaps the three.js loader 
is out of date? This is using r50.

Original issue reported on code.google.com by jterr...@gmail.com on 5 Dec 2011 at 7:42

[GoogleCodeExporter]

Original comment by wonchun on 5 Dec 2011 at 8:31

• Changed title: Texture UVs computed incorrectly
• Changed state: Accepted
• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Note to self: some bounds computations were not properly initialized, which 
might be causing this problem.

Original comment by wonchun on 20 Dec 2011 at 7:53

• Changed state: Started

[GoogleCodeExporter]

Hi, have just started using utf8 for threejs. It is quite excellent. However I 
have been testing a few models, and it seems that repeat UV's are not really 
supported? It seems to be doing a check for normalized UV coordinates - is this 
expected?

Original comment by dlanna...@gmail.com on 19 Apr 2014 at 3:37

[GoogleCodeExporter]

Yeah...unfortunately a known bug. I could try to add a flag to support it, but 
I'm actually in the midst of reimplementing lots of this stuff.

Original comment by wonchun on 19 Apr 2014 at 8:47

[GoogleCodeExporter]

Thats ok. I can have a look at making a patch for it if thats ok? I assume this 
might break the format? To explain - Im making a loader of "blocks" of road 
pieces and road and paths tend to need texture repeats to make the best use of 
the texture. I'll have a look and if I can make a suitable patch I'll post 
here. Thanks for the quick response, and if there's anything I can help out 
with let me know - Im quite interested in this format. 

Original comment by dlanna...@gmail.com on 20 Apr 2014 at 2:26

[GoogleCodeExporter]

Hi again. I have changed the UV compression/quantisation to work in the same 
manner as the position attributes - this seems to be a fairly decent solution. 
The size difference was small, and the general results were great. I now have a 
40MB road network with textures in the size of around 5 MB. Im going to start 
looking at skeletal animation, and see if I can get something useful working. 
Id like to thankyou for the work done on this format (after trying numerous 
others - CTM, glTF, OBJZipped etc). Have attached a screenshot of the scene now 
working online.

Original comment by dlanna...@gmail.com on 21 Apr 2014 at 5:31

Attachments:

• Screenshot001_TrackSim.png

[GoogleCodeExporter]

Back again. Just to let people know there is a fairly simple way to improve 
textures and support repeats as well. 
First: In bounds.h change the texcoord bounds to have a minimum -2.0 and a 
scale of 4.0
       choose whatever maximum values you want to use, I used position (16383) but it can be reduced without too much problems (depending on how big your repeat textures are).
Second: Change the UV value setting in the ParseTexCoord function - in mesh.h
       Test the uv - if its >1.0 or <1.0 it is a repeat UV. So do something like this: newuv = 1/olduv + 1.0f;  This will make the uv 1.xxxx and the xxx represents the repeats. Do this for both +ve and -ve UVs.
Third: In the loader you need to restore the UVs to their original glory (or 
close to it). Like so: if(u < -1.0)    uu = 1.0/(u + 1.0); So it the reverse 
operation of the compression routine.
I have attach code snippets you can use to patch your own code. Its simple, and 
the result is quite decent (better than the pic above :) ).. And my test is 
available here to play with: http://cloudsim.gagagames.com
If you need help please contact me at gmail account. dlannan68. 
Good luck..

Original comment by dlanna...@gmail.com on 30 Apr 2014 at 1:53

Attachments:

• utf8loader_patches.txt

[GoogleCodeExporter]

Oh. Minor note too - dont worry about the poly data loss in the demo. Im taking 
a 2km x 2km scene in Unity and converting it to UTF8 .. so the scale is too big 
to show small details. I intend to 'sub object' export the scene so that each 
section has only 10-20m of data in it for good poly detail.  

Original comment by dlanna...@gmail.com on 30 Apr 2014 at 1:58

[GoogleCodeExporter]

@dianna68

Hey, I'm going to have time to take a look at this tomorrow. So, wouldn't there 
be a texture filtering seam where those repeats occur?

BTW, I really appreciate the kudos!

Original comment by wonchun on 13 May 2014 at 3:04