Lightwave file format
category: code [glöplog]
I'm currently writing a LWO2 loader and so far I got the basic stuff incl. VMADs working.
However, I have some further questions, maybe someone here can give some advice:
1) Parsing of VMADs is quite slow, because for each entry you have to lookup the original vertex (searching through the given polygon to find the vertex with the given index), clone it and add the new UVs. Any tips how to speed this up? (I could convert the stuff to a custom format with better layout, but maybe there's another nifty trick i'm missing..)
2) Regarding the PTCH chunk: I guess Lightwave uses the Catmul-Clark subdivision algorithm? But if I don't care about subdivision, can I just interpret the data as additional regular polygons (so I will get the "control cage" mesh)?
3) For bones, do I need to care about the "skelegons"? Or the weight-maps and "AddBone" info from the scene file are enough?
However, I have some further questions, maybe someone here can give some advice:
1) Parsing of VMADs is quite slow, because for each entry you have to lookup the original vertex (searching through the given polygon to find the vertex with the given index), clone it and add the new UVs. Any tips how to speed this up? (I could convert the stuff to a custom format with better layout, but maybe there's another nifty trick i'm missing..)
2) Regarding the PTCH chunk: I guess Lightwave uses the Catmul-Clark subdivision algorithm? But if I don't care about subdivision, can I just interpret the data as additional regular polygons (so I will get the "control cage" mesh)?
3) For bones, do I need to care about the "skelegons"? Or the weight-maps and "AddBone" info from the scene file are enough?
I've never worked with LW files, but in general:
1) converting to one's own format is best for loading speed, but common format is best for work iteration speed (tweak-save-load) So what I did in the past is put in an exporter right in the loader. The first time you load it's the common format, and then it outputs the custom format. Next time you load it, you check for a more recent custom format, and load it quickly.
2) if you're playing with subdivision meshes, just know that generally speaking the cage is much larger than the result (simpler meshes are larger) so you might want to skinnify your mesh by moving the vertex along the normal or something similar
1) converting to one's own format is best for loading speed, but common format is best for work iteration speed (tweak-save-load) So what I did in the past is put in an exporter right in the loader. The first time you load it's the common format, and then it outputs the custom format. Next time you load it, you check for a more recent custom format, and load it quickly.
2) if you're playing with subdivision meshes, just know that generally speaking the cage is much larger than the result (simpler meshes are larger) so you might want to skinnify your mesh by moving the vertex along the normal or something similar
Thanks, BarZoule.
Regarding 2) I realized it's actually mentioned in the lwsdk:
Anyways, here's how things look like so far (props to smash and eetu :)
Regarding 2) I realized it's actually mentioned in the lwsdk:
Quote:
"PTCH - Subdivision patches. The POLS chunk contains the definition of the control cage polygons, and the patch is created by subdividing these polygons. The renderable geometry that results from subdivision is determined interactively by the user through settings within LightWave. The subdivision method is undocumented."
Anyways, here's how things look like so far (props to smash and eetu :)
I'm interested in your loader for my Dead Deer Tool, where did you get the information about file format ?
if you make a correct .lib file I could include it.
for your problem of UV coo. if they are defined by polygons add a map1,map2,map3 uv coo to you polys, and threat the objct in one pass after loading.
if you make a correct .lib file I could include it.
for your problem of UV coo. if they are defined by polygons add a map1,map2,map3 uv coo to you polys, and threat the objct in one pass after loading.
Barti: The file format is described on Ernie Wrights (long-time lwsdk maintainer) homepage for example:
http://home.comcast.net/~erniew/lwsdk/docs/filefmts/lwo2.html
I can send you the code, it's indeed quite stand-alone. But it's a little bit messy, I try to clean it up a bit..
http://home.comcast.net/~erniew/lwsdk/docs/filefmts/lwo2.html
I can send you the code, it's indeed quite stand-alone. But it's a little bit messy, I try to clean it up a bit..
my main problem not to code lightwave import file format is that I do not have any of those files.
1) i have quite a complex list-based structure attached to each vertex to keep the original and all the attached weightmaps, then work out how to split when im building the mesh - i.e. if the verts are really differnet or not. its complicated.. :)
2) yes, and you can switch it to catmuill clark in lw but its something propietary by default.
3) ignore skelegons, its just to see bones in modeller; addbone and weightmaps are sufficient. watch out for bones with falloffs. :)
2) yes, and you can switch it to catmuill clark in lw but its something propietary by default.
3) ignore skelegons, its just to see bones in modeller; addbone and weightmaps are sufficient. watch out for bones with falloffs. :)
smash, thanks.
1) Is this mainly to improve loading speed or to condense the mesh (i.e. removing duplicated vertices etc.)
2) Ok, uff, writing some (catmul clark) subdivision code will take a while i guess, I'll keep that for later
3) Perfect, thanks for clarifying
Ok, next steps are improving the mesh loader to handle multiple vmaps better and actually merging it with the rudimentary LWS scene loader :)
1) Is this mainly to improve loading speed or to condense the mesh (i.e. removing duplicated vertices etc.)
2) Ok, uff, writing some (catmul clark) subdivision code will take a while i guess, I'll keep that for later
3) Perfect, thanks for clarifying
Ok, next steps are improving the mesh loader to handle multiple vmaps better and actually merging it with the rudimentary LWS scene loader :)