New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shape (OBJ) import texture data is 0.0 #3156

Closed
aml25 opened this Issue Mar 17, 2015 · 7 comments

Comments

Projects
None yet
5 participants
@aml25

aml25 commented Mar 17, 2015

There appears to be a bug in the PShape myShape = loadShape("xxx.obj") where myShape.getTextureU(i) and myShape.getTextureV(i) always returns 0.0 regardless of the .obj file I load.

The source of my obj file clearly includes vt (texture) data, in the correct format according to http://en.wikipedia.org/wiki/Wavefront_.obj_file#Face_definitions

v -23.37775039672852 0 15.94831371307373
v -19.77339744567871 0 5.378586292266846
v -16.8441162109375 0 -3.211503267288208
v -14.04735279083252 8.653888702392578 -11.41298007965088
v -10.39787006378174 0 -22.11504936218262
v 17.75258827209473 0 22.24656867980957
v 18.87799835205078 -8.668776512145996 12.74141693115234
v 19.79262542724609 0 5.01651668548584
v 20.6658763885498 0 -2.358911991119385
v 21.80537796020508 0 -11.98307514190674
vt 0 0
vt 0 0.25
vt 0 0.5
vt 0 0.75
vt 0 1
vt 1 0
vt 1 0.25
vt 1 0.5
vt 1 0.75
vt 1 1
vt 0 0.25
vt 1 0.5
vt 0 0.5
vt 1 0.75
f 9/7 4/11 5/1 10/6
f 8/12 3/13 4/2 9/7
f 7/14 2/4 3/3 8/8
f 6/10 1/5 2/4 7/9
@tewelltech

This comment has been minimized.

Show comment
Hide comment
@tewelltech

tewelltech Apr 6, 2016

Just checking to see if any progress had been made on this issue. I too am running into this with properly formatted .OBJ files... Thanks!

tewelltech commented Apr 6, 2016

Just checking to see if any progress had been made on this issue. I too am running into this with properly formatted .OBJ files... Thanks!

@codeanticode codeanticode added the opengl label Apr 6, 2016

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Apr 6, 2016

Member

Thanks for bringing back to my attention will look into it.

Member

codeanticode commented Apr 6, 2016

Thanks for bringing back to my attention will look into it.

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode Apr 7, 2016

Member

I think this is not an bug, but a result of how the PShape object is constructed from the OBJ data: the the faces of the OBJ are stored inside a base group shape that does not contain any vertices. Try the following modified version of the built-in LoadDisplayOBJ example:

public void settings() {
  size(640, 360, P3D);
}

PShape rocket;

float ry;

void setup() {
  size(640, 360, P3D);

  rocket = loadShape("rocket.obj");
}

void draw() {
  background(0);
  lights();

  translate(width/2, height/2 + 100, -200);
  rotateZ(PI);
  rotateY(ry);
  shape(rocket);

  println("Number of vertices in base shape: " + rocket.getVertexCount());
  for (int i = 0; i < rocket.getChildCount(); i++) {
    PShape child = rocket.getChild(i);
    println("Number of vertices in child shape " + i +": " + child.getVertexCount());
    for (int j = 0; j < child.getVertexCount(); j++) {
      println(  "vertex " + j +" U: " + child.getTextureU(j));
      println(  "vertex " + j +" U: " + child.getTextureV(j));
    }
  }

  ry += 0.02;
  noLoop();
}

You should get the corresponding UV values printed to the console for each one of the child shapes. Let me know if you have another OBJ file for which this approach does not work.

Member

codeanticode commented Apr 7, 2016

I think this is not an bug, but a result of how the PShape object is constructed from the OBJ data: the the faces of the OBJ are stored inside a base group shape that does not contain any vertices. Try the following modified version of the built-in LoadDisplayOBJ example:

public void settings() {
  size(640, 360, P3D);
}

PShape rocket;

float ry;

void setup() {
  size(640, 360, P3D);

  rocket = loadShape("rocket.obj");
}

void draw() {
  background(0);
  lights();

  translate(width/2, height/2 + 100, -200);
  rotateZ(PI);
  rotateY(ry);
  shape(rocket);

  println("Number of vertices in base shape: " + rocket.getVertexCount());
  for (int i = 0; i < rocket.getChildCount(); i++) {
    PShape child = rocket.getChild(i);
    println("Number of vertices in child shape " + i +": " + child.getVertexCount());
    for (int j = 0; j < child.getVertexCount(); j++) {
      println(  "vertex " + j +" U: " + child.getTextureU(j));
      println(  "vertex " + j +" U: " + child.getTextureV(j));
    }
  }

  ry += 0.02;
  noLoop();
}

You should get the corresponding UV values printed to the console for each one of the child shapes. Let me know if you have another OBJ file for which this approach does not work.

@tewelltech

This comment has been minimized.

Show comment
Hide comment
@tewelltech

tewelltech Apr 7, 2016

Thanks for the code example although I am still getting zeroes for u and
v. Attached is a picture of the output and I have attached the .obj that I
am using.
The problem I am having is with the "stock" version of Processing
downloaded today - version 3.0.2
I am pulling a Git clone of the source and plan to build Processing from
source tomorrow and see what happens...

Thanks!

On Wed, Apr 6, 2016 at 8:43 PM, codeanticode notifications@github.com
wrote:

I think this is not an bug, but a result of how the PShape object is
constructed from the OBJ data: the the faces of the OBJ are stored inside a
base group shape that does not contain any vertices. Try the following
modified version of the built-in LoadDisplayOBJ example:

public void settings() {
size(640, 360, P3D);
}
PShape rocket;
float ry;
void setup() {
size(640, 360, P3D);

rocket = loadShape("rocket.obj");
}
void draw() {
background(0);
lights();

translate(width/2, height/2 + 100, -200);
rotateZ(PI);
rotateY(ry);
shape(rocket);

println("Number of vertices in base shape: " + rocket.getVertexCount());
for (int i = 0; i < rocket.getChildCount(); i++) {
PShape child = rocket.getChild(i);
println("Number of vertices in child shape " + i +": " + child.getVertexCount());
for (int j = 0; j < child.getVertexCount(); j++) {
println( "vertex " + j +" U: " + child.getTextureU(j));
println( "vertex " + j +" U: " + child.getTextureV(j));
}
}

ry += 0.02;
noLoop();
}

I'm getting the corresponding UV values printed to the console for each
one of the child shapes.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#3156 (comment)

tewelltech commented Apr 7, 2016

Thanks for the code example although I am still getting zeroes for u and
v. Attached is a picture of the output and I have attached the .obj that I
am using.
The problem I am having is with the "stock" version of Processing
downloaded today - version 3.0.2
I am pulling a Git clone of the source and plan to build Processing from
source tomorrow and see what happens...

Thanks!

On Wed, Apr 6, 2016 at 8:43 PM, codeanticode notifications@github.com
wrote:

I think this is not an bug, but a result of how the PShape object is
constructed from the OBJ data: the the faces of the OBJ are stored inside a
base group shape that does not contain any vertices. Try the following
modified version of the built-in LoadDisplayOBJ example:

public void settings() {
size(640, 360, P3D);
}
PShape rocket;
float ry;
void setup() {
size(640, 360, P3D);

rocket = loadShape("rocket.obj");
}
void draw() {
background(0);
lights();

translate(width/2, height/2 + 100, -200);
rotateZ(PI);
rotateY(ry);
shape(rocket);

println("Number of vertices in base shape: " + rocket.getVertexCount());
for (int i = 0; i < rocket.getChildCount(); i++) {
PShape child = rocket.getChild(i);
println("Number of vertices in child shape " + i +": " + child.getVertexCount());
for (int j = 0; j < child.getVertexCount(); j++) {
println( "vertex " + j +" U: " + child.getTextureU(j));
println( "vertex " + j +" U: " + child.getTextureV(j));
}
}

ry += 0.02;
noLoop();
}

I'm getting the corresponding UV values printed to the console for each
one of the child shapes.


You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#3156 (comment)

@tewelltech

This comment has been minimized.

Show comment
Hide comment
@tewelltech

tewelltech Apr 7, 2016

So - I got it working - but it took some digging. BTW -_ I pulled the source and was able to build Processing and this allowed me to look into this with a lot more clarity._

The Processing .OBJ reader requires that you have a corresponding .MTL file that specifies the texture image. Even though the texture coordinates might be in the .OBJ file (the "vt" entries) the obj parser / reader ignores these coordinates unless there is a specifically designated .MTL file. Just FYI - you don't have to have a .MTL file in order to have texture coordinates in an .OBJ. I have a lot of .OBJ files that don't reference a .MTL - even though they have vt coordinates and a corresponding texture map.

But wait! That's not all. Not ONLY do you have to have a .MTL file if you want to use a texture map - but it has to have some entries in it OTHER than the "map_Kd test.jpg" entry specifying the texture image or the .MTL parser will hiccup, cough and sputter badly - in essence - just not work. The format for the .MTL file I had to end up using looked like this:

newmtl material0
Ka 1.000000 1.000000 1.000000
Kd 1.000000 1.000000 1.000000
Ks 0.000000 0.000000 0.000000
Tr 1.000000
illum 1
Ns 0.000000
map_Kd test.jpg

Again - I don't use materials for many of my .OBJ files with textures - so while I don't mind terribly about requiring a materials file - I DO mind having to have bogus entries in it - even though I don't use them - other than the "map_Kd" entry.

So the FIRST line of my .OBJ file had to be:
mtllib test.mtl
that referenced my relatively empty .MTL file.

I am going to look into changing the .OBJ reader to eliminate the .MTL file requirements for .OBJ files that use texture maps but not materials.

Rick

tewelltech commented Apr 7, 2016

So - I got it working - but it took some digging. BTW -_ I pulled the source and was able to build Processing and this allowed me to look into this with a lot more clarity._

The Processing .OBJ reader requires that you have a corresponding .MTL file that specifies the texture image. Even though the texture coordinates might be in the .OBJ file (the "vt" entries) the obj parser / reader ignores these coordinates unless there is a specifically designated .MTL file. Just FYI - you don't have to have a .MTL file in order to have texture coordinates in an .OBJ. I have a lot of .OBJ files that don't reference a .MTL - even though they have vt coordinates and a corresponding texture map.

But wait! That's not all. Not ONLY do you have to have a .MTL file if you want to use a texture map - but it has to have some entries in it OTHER than the "map_Kd test.jpg" entry specifying the texture image or the .MTL parser will hiccup, cough and sputter badly - in essence - just not work. The format for the .MTL file I had to end up using looked like this:

newmtl material0
Ka 1.000000 1.000000 1.000000
Kd 1.000000 1.000000 1.000000
Ks 0.000000 0.000000 0.000000
Tr 1.000000
illum 1
Ns 0.000000
map_Kd test.jpg

Again - I don't use materials for many of my .OBJ files with textures - so while I don't mind terribly about requiring a materials file - I DO mind having to have bogus entries in it - even though I don't use them - other than the "map_Kd" entry.

So the FIRST line of my .OBJ file had to be:
mtllib test.mtl
that referenced my relatively empty .MTL file.

I am going to look into changing the .OBJ reader to eliminate the .MTL file requirements for .OBJ files that use texture maps but not materials.

Rick

@lucid-kyle

This comment has been minimized.

Show comment
Hide comment
@lucid-kyle

lucid-kyle Apr 18, 2016

Rick - You're my hero.

I ran into this a couple months back and had gone so far as to start writing my own loader. I totally see how someone who only uses OBJs in conjunction with an MTL file would see this as a logical way to approach the problem, but I'm right there with you in terms of having OBJs on their own.

Let me know how the process goes with changing the loader, and in a couple weeks I might be able to pitch in, once my bandwidth opens up a bit.

Kyle

lucid-kyle commented Apr 18, 2016

Rick - You're my hero.

I ran into this a couple months back and had gone so far as to start writing my own loader. I totally see how someone who only uses OBJs in conjunction with an MTL file would see this as a logical way to approach the problem, but I'm right there with you in terms of having OBJs on their own.

Let me know how the process goes with changing the loader, and in a couple weeks I might be able to pitch in, once my bandwidth opens up a bit.

Kyle

@codeanticode

This comment has been minimized.

Show comment
Hide comment
@codeanticode

codeanticode May 11, 2016

Member

Should be fixed now, tested on a couple of OBJs and seems fine (tex coords will be loaded even if no texture map is specified, and the MTL file can contain only the map_Kd field), but give it a try in the next release and let me know if you see any problems.

Member

codeanticode commented May 11, 2016

Should be fixed now, tested on a couple of OBJs and seems fine (tex coords will be loaded even if no texture map is specified, and the MTL file can contain only the map_Kd field), but give it a try in the next release and let me know if you see any problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment