Is this ok that LWO importer doesn't read multi UV texture cordinates?
Always read only first set. Or do I need to do special care before saving LWO file?
I was also tested X file with multitexture cordinates and also doesn'n working. I think that importer can't
do proper FVF data section reading as D3DX (DXSDK) importer. For example Max Panda exporter working ok and write texture cordinates to FVF data section.
For what format Assimp can import multi UV (needed for lightmapping)? Maybe ASE?
AFAIK, ASE is loading properly vertex colors but I'm not shure for multi UV.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the LWO importer should import multiple UV texture coordinates as long as they're used by at least one texture. If it doesn't, it's definitely a bug and I'd greatly appreciate if you could send me the file over.
ASE should work. Again, multiple UV channels haven't been tested extensively.
Oh, and IRRMESH supports two UVs too but there are almost no exporters available.
>> I was also tested X file with multitexture cordinates and also doesn'n working.
Hm .. I don't think the x loader supports multiple UVs yet.
- Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh, I forgot: the viewer won't display multiple UVs correctly. If Assimp still doesn't work for you, you could try building assimp_cmd and let it generate xml dumps of the imported data.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is not a problem because I have own file format and viewer. My format supports multi UV and multi color channels. I'm using assimp as importer and then I'm write data to my format and everything works ok.
We just need to get proper settings for LWO so that scene->mMeshes[i]->HasTextureCoords(1) return true :)
We will try to assing some texture to second texture cordinate set and then try to convert it.
LWO importer support single or multi color channels?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did some major modifications to the LWO loader to make it easier to use.
The old implementation rejected VMAPs (UVs, Vertex colors) if they weren't referenced by a material. This had the advantage that the visual result was absolutely identical to LightWave's own rendering, but the disadvantage that it's you had to insert dummy textures, import of multiple vertex color wasn't possible.
Gone now. New strategy is to import as many channels as possible (up to the limit of 4), where explicitly referenced VMAPs are imported with higher priority and placed in the first UV/Color channel. Condition that a channel is imported for a particular submesh is that at least one point of the mesh defines a non-default value for the channel (e.g. an all-black vertex color set won't be imported).
A little warning, though. I just implemented this and checked it in but I didn't test exhaustively. Would be great if you and all other LWO fans reading these forums could give it a try and give feedback whether it works as intended :-)
Alex
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Bad. MODO materials are not imported at all due to the lack of proper documentation (rest of LXO is identical to LWO). If you have a proper source, let me know.
I'm always scared of getting into legal trouble for reverse engineering of undocumented stuff, that's why I didn't invest any further work :-)
PS: Modo should be able to export to proper LWO (surely, it's the same dev team).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PPS:
With yesterday's changes multiple UVs and colors should indeed be imported, but no materials. Modo is the only of the hude modelers to which I don't have access to so I can't test it except with some free files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that this version is much better. For now converts LWO without error.
In last version in few cases importer didn't calculate tangents and bitangens.
Now everything is detected properly and I don't need to set texture to import second texture cordinates.
Great work ;)
But, what order is now of multi UV, by name or by order of creation?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Output order is currently by appearance in the file, so I guess it's also order of creation in LW. UVs referenced by a surface are equally ordered but always in front of not referenced UVs.
Problem is that Assimp doesn't know the concept of named UV channels. Lexical ordering by name would be a possible solution to overcome this issue. Would you prefer it this way? I don't care.
Alex
PS: I'll start a wiki/extra doc to document all these details soon.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that this version is much better. For now converts LWO without error.
In last version in few cases importer didn't calculate tangents and bitangens.
Now everything is detected properly and I don't need to set texture to import second texture cordinates.
Great work ;)
But, what order is now of multi UV, by name or by order of creation?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more question. Why on some of the models UV gets mess up, but in lightwave look ok. When I export to X and render in my engine everything is ok,
but when I export to my format I get that error. Your viewer also display same error as my viewer and mesh format.
I get strange very repeating seams at some polygon edges.
These are falgs that I'm using:
aiProcess_Triangulate
aiProcess_ValidateDataStructure
aiProcess_ImproveCacheLocality
aiProcess_RemoveRedundantMaterials
aiProcess_SortByPType
aiProcess_FindDegenerates
aiProcess_FindInvalidData
aiProcess_TransformUVCoords
aiProcess_MakeLeftHanded
aiProcess_GenSmoothNormals
aiProcess_JoinIdenticalVertices (maybe this is a problem because importer weld some vertices that are not 100% same)
aiProcess_CalcTangentSpace
aiProcess_SplitLargeMeshes
aiProcess_GenUVCoords
aiProcess_FlipUVs
aiProcess_FlipWindingOrder
For multi UV, order is important because, if necessary, We need ability to change UV order in LightWave.
But if this is a order of creation this can be a problem.
Lightwave can only change name of UV but not order. If I change name in LW I get different order but not
different order in export.
If I have channels like this
UV01
UV02
(AFAIK) they will be exported as
UV01 and
UV02
but if I rename UV01 to UV02 and 02 to 01
order in lw will be
UV01 (old 02)
UV02 (old 01)
but again they will be exported as
UV01 (old 01)
UV02 (old 02)
and I can switch that index and everything will work ok but it's hard to do that every time.
To me, it's same that UV is order by name or some other value but it's important that artis can change order directly in LW so that
new order reflect in importer.
If this is not possible I will think of something in my converter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, different order is tested now. UV can be swaped in Lightwave. Just need to change names and LW will sort them in new order by names and
then importer will recognize that so you don't need to do anything with that issue.
But still, I have a problem with corrupted UVs. Sometimes is corrupted first Diffuse or second lightmap UV.
It depends to order of UVs. But always is one wrong.
A hope that invert of UV isn't a problem (aiProcess_FlipUVs)? I need it for DX engine and maybe you invert just one (e.g. first channel) and second one not.
So always one has an error and wrong representation.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It looks like that second UV map (second in lightwave list) will have error. Did you forget to do something with second UV :)?
If you (Alexander) like, I can send you one of the meshes that gets wrong import.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok, check your e-mail now. I sent you mesh, lightmap, textures, screenshots of error and mesh in my XML format.
If you open it in LWO you will see that everything is ok but after my import/export or in assimp view I get strange UV patterns.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is this ok that LWO importer doesn't read multi UV texture cordinates?
Always read only first set. Or do I need to do special care before saving LWO file?
I was also tested X file with multitexture cordinates and also doesn'n working. I think that importer can't
do proper FVF data section reading as D3DX (DXSDK) importer. For example Max Panda exporter working ok and write texture cordinates to FVF data section.
For what format Assimp can import multi UV (needed for lightmapping)? Maybe ASE?
AFAIK, ASE is loading properly vertex colors but I'm not shure for multi UV.
Hi,
the LWO importer should import multiple UV texture coordinates as long as they're used by at least one texture. If it doesn't, it's definitely a bug and I'd greatly appreciate if you could send me the file over.
ASE should work. Again, multiple UV channels haven't been tested extensively.
Oh, and IRRMESH supports two UVs too but there are almost no exporters available.
>> I was also tested X file with multitexture cordinates and also doesn'n working.
Hm .. I don't think the x loader supports multiple UVs yet.
- Alex
Oh, I forgot: the viewer won't display multiple UVs correctly. If Assimp still doesn't work for you, you could try building assimp_cmd and let it generate xml dumps of the imported data.
This is not a problem because I have own file format and viewer. My format supports multi UV and multi color channels. I'm using assimp as importer and then I'm write data to my format and everything works ok.
We just need to get proper settings for LWO so that scene->mMeshes[i]->HasTextureCoords(1) return true :)
We will try to assing some texture to second texture cordinate set and then try to convert it.
LWO importer support single or multi color channels?
Ok multi UV with LWO file is tested now and works great. Some texture need to be assigned.
Hi,
I did some major modifications to the LWO loader to make it easier to use.
The old implementation rejected VMAPs (UVs, Vertex colors) if they weren't referenced by a material. This had the advantage that the visual result was absolutely identical to LightWave's own rendering, but the disadvantage that it's you had to insert dummy textures, import of multiple vertex color wasn't possible.
Gone now. New strategy is to import as many channels as possible (up to the limit of 4), where explicitly referenced VMAPs are imported with higher priority and placed in the first UV/Color channel. Condition that a channel is imported for a particular submesh is that at least one point of the mesh defines a non-default value for the channel (e.g. an all-black vertex color set won't be imported).
A little warning, though. I just implemented this and checked it in but I didn't test exhaustively. Would be great if you and all other LWO fans reading these forums could give it a try and give feedback whether it works as intended :-)
Alex
Ok I will update to latest version and give exporter to my artist to make the test.
What is situation with MODO model ( *.lxo ) regarding multi UV and color?
Bad. MODO materials are not imported at all due to the lack of proper documentation (rest of LXO is identical to LWO). If you have a proper source, let me know.
I'm always scared of getting into legal trouble for reverse engineering of undocumented stuff, that's why I didn't invest any further work :-)
PS: Modo should be able to export to proper LWO (surely, it's the same dev team).
PPS:
With yesterday's changes multiple UVs and colors should indeed be imported, but no materials. Modo is the only of the hude modelers to which I don't have access to so I can't test it except with some free files.
I think that this version is much better. For now converts LWO without error.
In last version in few cases importer didn't calculate tangents and bitangens.
Now everything is detected properly and I don't need to set texture to import second texture cordinates.
Great work ;)
But, what order is now of multi UV, by name or by order of creation?
Output order is currently by appearance in the file, so I guess it's also order of creation in LW. UVs referenced by a surface are equally ordered but always in front of not referenced UVs.
Problem is that Assimp doesn't know the concept of named UV channels. Lexical ordering by name would be a possible solution to overcome this issue. Would you prefer it this way? I don't care.
Alex
PS: I'll start a wiki/extra doc to document all these details soon.
I think that this version is much better. For now converts LWO without error.
In last version in few cases importer didn't calculate tangents and bitangens.
Now everything is detected properly and I don't need to set texture to import second texture cordinates.
Great work ;)
But, what order is now of multi UV, by name or by order of creation?
One more question. Why on some of the models UV gets mess up, but in lightwave look ok. When I export to X and render in my engine everything is ok,
but when I export to my format I get that error. Your viewer also display same error as my viewer and mesh format.
I get strange very repeating seams at some polygon edges.
These are falgs that I'm using:
aiProcess_Triangulate
aiProcess_ValidateDataStructure
aiProcess_ImproveCacheLocality
aiProcess_RemoveRedundantMaterials
aiProcess_SortByPType
aiProcess_FindDegenerates
aiProcess_FindInvalidData
aiProcess_TransformUVCoords
aiProcess_MakeLeftHanded
aiProcess_GenSmoothNormals
aiProcess_JoinIdenticalVertices (maybe this is a problem because importer weld some vertices that are not 100% same)
aiProcess_CalcTangentSpace
aiProcess_SplitLargeMeshes
aiProcess_GenUVCoords
aiProcess_FlipUVs
aiProcess_FlipWindingOrder
For multi UV, order is important because, if necessary, We need ability to change UV order in LightWave.
But if this is a order of creation this can be a problem.
Lightwave can only change name of UV but not order. If I change name in LW I get different order but not
different order in export.
If I have channels like this
UV01
UV02
(AFAIK) they will be exported as
UV01 and
UV02
but if I rename UV01 to UV02 and 02 to 01
order in lw will be
UV01 (old 02)
UV02 (old 01)
but again they will be exported as
UV01 (old 01)
UV02 (old 02)
Is that true? My test shows me that.
My format looks like this:
<texturecoords index="0" type="uv">...</texturecoords>
<texturecoords index="1" type="uv">...</texturecoords>
and I can switch that index and everything will work ok but it's hard to do that every time.
To me, it's same that UV is order by name or some other value but it's important that artis can change order directly in LW so that
new order reflect in importer.
If this is not possible I will think of something in my converter.
Ok, different order is tested now. UV can be swaped in Lightwave. Just need to change names and LW will sort them in new order by names and
then importer will recognize that so you don't need to do anything with that issue.
But still, I have a problem with corrupted UVs. Sometimes is corrupted first Diffuse or second lightmap UV.
It depends to order of UVs. But always is one wrong.
A hope that invert of UV isn't a problem (aiProcess_FlipUVs)? I need it for DX engine and maybe you invert just one (e.g. first channel) and second one not.
So always one has an error and wrong representation.
It looks like that second UV map (second in lightwave list) will have error. Did you forget to do something with second UV :)?
If you (Alexander) like, I can send you one of the meshes that gets wrong import.
>> If you (Alexander) like, I can send you one of the meshes that gets wrong import.
Yes, i'd greatly appreciate that :-) In my tests all UV sets were converted correctly.
Ok, check your e-mail now. I sent you mesh, lightmap, textures, screenshots of error and mesh in my XML format.
If you open it in LWO you will see that everything is ok but after my import/export or in assimp view I get strange UV patterns.
Ah wrong spelled mail :)
OK, now check your gmx.net mail.
Ok, I got your mail now, I'll take a look this evening.
Alex
No news with multi UV and LW?
Sorry for being late, I was kept busy the last few days.
I think the UV seams are evaluated correctly now, although I'm not *absolutely* sure. Fontain.lwo looks like this: http://assimp.sourceforge.net/tmp/beautifulback.png.
Bye,
Alex
Ok, this seems fine. I will check now latest assimp version with my exporter.
Now importer and my exporter works fine.
Good work ;)
Thanks