-
Notifications
You must be signed in to change notification settings - Fork 84
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
Is there a EmbededTexture property from which I can get the texture image reference ? #50
Comments
I am currently running into this issue as well since .GLB's embed the textures im having a hard time understanding how to associate a texture to a mesh material. The meshIndex will be 0 or 1 and all the file names are *0 *1 its very confusing. Edit: So i have been looking at this for a bit over the last few days. It appears though mind you im working thru this at the moment myself that asterick filename *0 ect actually represents or points to the Textures[0] indexs. Using the method on the material equates to the same index. I have been running tests to verify behavior. I will post pics as well later on for clarity further down.
This particular model has one mesh and here you can see the output for the model itself on the mesh. The console output separately displays the material for that mesh and what textures have non null maps (actually loaded to the model) and how they correspond to the previously outputed indexs loaded and shown. Particularly note the loaded maps for this mesh material.
Conclusions from this test appear to show that there is some ambiguity in what is happening here. More then one diffuse texture is typically listed for a material loaded. Also the texture index *1 is also loaded twice and placed into two separate textures. The emissive map appears to just be a bump or normal map.
One other note this is a .glb file and even ones that say they are pbr never seem to denote the pbr property bool true in the material at least i haven't found one yet. |
This issue is fixed in the 5.0 version of assimp, where a FilePath property does exist on EmbeddedTextures and TextureSlots always contain the filepath instead of a *-path. Still, for those using this version, has there been a workaround for this? |
have an issue when I tried to read texture image information using AssimpNet.
The fbx file that I tried to read has 10 embedded textures and has no external textures: texture screenshot
according to the information from assimp, the embedded textures are referenced from materials using strings like "*0", "*1" as the texture paths.
However, among the 12 materials in my fbx file, some them have texture paths like "..\buildings.fbm\6M4P000O.JPG" which corresponds to the image file name
As for the first scenario which has strings like "*0", "*1", I can find corresponding texture by using the number as the reference to Textures, but for the second scenario, I could not find the corresponding file name from Textures because in AssimpNet, the EmbeddedTexture has no such property
But according to assimp, which is the base of assimpnet, from its texture.h file, I found that it has a property called mFilename and from this property we could get the texture's image file name; assimp texture.h
I am wondering if AssimpNet should include filename into EmbededTexture properties so that we could find the correct reference if the filepath contains the filename rather than number.
The text was updated successfully, but these errors were encountered: