Problem with texture coordinates in OBJ file

[Zimond]

Afraid i got stuck again -_-

I managed to load an obj file into the Cube demo and put a texture on it.

  LMeshBuffer := MeshBufferInit;
  FModelTags := MeshMetaTagsInit;

  if LMeshBuffer.Initialized then
  try
    if not LMeshBuffer.LoadMeshFromFile(FModelTags, Utf8String('skull.obj'), FModelMinBounds,
          FModelMaxBounds, LDebugString)  then
    begin
          MessageDlg(Format('Could not load mesh file: %s', [string(LDebugString)]), mtError, [mbOK], 0);
          Exit;
        end;

    FModelCube := LMeshBuffer.Model(FDevice, VertexElements);
    if not FModelCube.Initialized then
    begin
      MessageDlg('Could not create 3D cube model.', mtError, [mbOK], 0);
      Application.Terminate;
      Exit;
    end;
  finally
    LMeshBuffer.Free;
  end;

The TextureCoordinates however are ignored. (See pic) I checked the OBJ in Blender and in the Demo Tool from Assimp, both show it correctly so I guess Im loading it wrong.

[lifepower]

Can you please check that "VertexElements" include texture coordinates? Specifically, the entry that says "streamTexCoord"? (like in CubeTextured example)

P.S. You can also omit "FModelTags" parameter during loading, e.g.:

    if not LMeshBuffer.LoadMeshFromFile(Utf8String('Cube.obj'), LMinBounds, LMaxBounds, LDebugString) then
    begin
      MessageDlg(Format('Could not load mesh file: %s', [string(LDebugString)]), mtError, [mbOK], 0);
      Exit;
    end;

[Zimond]

const
  VertexElements: array[0..2] of TVertexElement = (
    (Name: 'streamPosition'; Format: TElementFormat.Float; Count: 3; Channel: 0; Offset: 0),
    (Name: 'streamNormal'; Format: TElementFormat.Float; Count: 3; Channel: 0; Offset: 0),
    (Name: 'streamTexCoord'; Format: TElementFormat.Float; Count: 2; Channel: 0; Offset: 0));

This is how it looks. I tried to research this topic a bit and checked that already. I tried changing the channel for streamTexCoord to 1 just for seeing what happens. Then the whole skull is covered in the first pixel of the texture (i could test it by changing it) I guess that since channel 1 doesnt have any textures coordinates it is simply 0 so first pixel stretched to infinity? Anyway, do I conclude correctly that channel 0 in fact HAS some texture coordinates but not the ones from the OBJ file but rather those of a standard cube?

I know that the Modeltags are not neccessary. I just checked it to understand how to access different parts of a mesh (like making the jaw of the skull, which is a seperate part , open) But thats another topic that is currently not that important since I could work around it by splitting an obj into its parts and load them one after another.

[lifepower]

Can you please attach a problematic OBJ file here so I can try it? I have just tried a simple cube exported from 3dsMax to OBJ file, putting it into CubeTextured example, and it appears to work fine - if you edit texture coordinates, e.g. put "2" instead of "1" in OBJ file, this seems to be reflected at run-time. I have attached the test OBJ file (by the way, it seems that in this file normals were not exported correctly, they have values of -1.570796, so after loading this OBJ to MeshBuffer, please call "CalculateFlatNormals" to re-calculate them).

P.S. I have split the thread as the issue with texture coordinates in OBJ file seems a separate topic, which could be potentially a bug report.

[Zimond]

https://free3d.com/de/3d-model/skull-v3--785914.html

Thats the skull I was testing with.

[lifepower]

Thanks for providing this test case. This can be considered a bug in Afterwarp v1.0.5, where it integrates with Assimp - texture coordinates appear to be loaded flipped, which doesn't cause much problems in case of cubes, but for carefully skinned mesh produces incorrect output. The solution was to apply "aiProcess_FlipUVs" parameter when calling "aiImportFile" from Assimp.

The fix will be included in Afterwarp v1.0.6 update within a week or so. If you need it sooner, please let me know

P.S. You can also attach screenshots and files here in the forum. Do you see "Upload Attachments" options below the text box?

[Zimond]

Great. Im happy I can help to find bugs.

And there is no rush, I can wait and go on with other tasks. I will try to enable shadows on my own as a next step.

Yeah I saw it, probarbly a better solution than using this Gyzo thing. Will use it next time.

[Zimond]

Info : In the current build 2.00 it seems this bug with the wrong texture coordinates reappeared when loading the Mesh with the internal method (non Assimp). With the LoadfromfileEX variant using assimp it works fine. (Tested with the same model as above)

[lifepower]

Afterwarp v2.0 includes native support for OBJ files, so it does not use Assimp for these anymore. It looks like the bug reappeared there. Thanks for the report, the fix will come in next update soon.