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?
added on the 2012-03-05 13:22:03 by arm1n arm1n
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
added on the 2012-03-05 22:58:08 by BarZoule BarZoule
Thanks, BarZoule.
Regarding 2) I realized it's actually mentioned in the lwsdk:


"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 :)
BB Image
added on the 2012-03-06 09:40:12 by arm1n arm1n
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.
added on the 2012-03-06 09:45:18 by Bartoshe Bartoshe
Barti: The file format is described on Ernie Wrights (long-time lwsdk maintainer) homepage for example:
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..
added on the 2012-03-06 09:58:58 by arm1n arm1n
my main problem not to code lightwave import file format is that I do not have any of those files.
added on the 2012-03-06 10:12:48 by Bartoshe Bartoshe
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. :)
added on the 2012-03-06 15:53:45 by smash smash
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 :)
added on the 2012-03-06 16:08:54 by arm1n arm1n