PDA

View Full Version : Info about 'BONE' polygon tags



pignus
05-07-2010, 04:28 PM
Hello,

I've posted this in the LW General Support forum but got no responses...

I am trying to import bone animation from LightWave object and scene files, since we are preparing a new release for TNGViewer (http://tng3d.com/index.php?page=viewer). However, the 'BONE' polygon tags type is not documented, nor does it appear used in any sample code.

I understand the bone names are contained in the previous 'TAGS' chunk; am I correct in supposing that the contents of the related 'PTAG/BONE' subchunks are simply an index into the tags list...?

If so, I would then have to map the tags to the Bone objects in the related scene file, right...?

I hope some kind soul from NewTek would address these issues.

Thanks,
Dario

Sensei
05-07-2010, 06:23 PM
Bone tags in lwo are probably rather Skeletons.. "Polygons" that should be converted to real bones in Layout.

Lightwolf
05-07-2010, 06:31 PM
If so, I would then have to map the tags to the Bone objects in the related scene file, right...?
As Sensei said, they can be converted to bones in the lws, but not necessarily so.
Basically: Ignore them for your purpose and use the bones from the lws.

If you just wrote an lwo viewer that is supposed to show the embedded Skelegons, then you'd need to use the chunks.

Cheers,
Mike

pignus
05-07-2010, 06:39 PM
Bone tags in lwo are probably rather Skeletons.. "Polygons" that should be converted to real bones in Layout.

Sensei,

Yes, they represent skeletons -- in fact, they represent line segments, which Layout later converts to Bone objects. That is not the information I am after: I am looking for a way to assign a given bone to a specific vertex, in order to apply skinning.

Thanks,
Dario

pignus
05-07-2010, 06:43 PM
As Sensei said, they can be converted to bones in the lws, but not necessarily so.
Basically: Ignore them for your purpose and use the bones from the lws.

If you just wrote an lwo viewer that is supposed to show the embedded Skelegons, then you'd need to use the chunks.

Cheers,
Mike

Mike,

I am not trying to display the actual bones in TNGViewer (http://tng3d.com/index.php?page=viewer) -- I am just trying to import enough skinning information to apply the desired vertex deformations.
Basically, I have a vertex map of type 'WGHT' that provides deformation weights for some points in a layer. What I am trying to access is the information that maps, say, vertex X (whose weight I've read from the vertex map above) to bone Y...
There is no documentation on this issue, so I am not clear how to go on -- the other SDKs we use in TNG 3D (http://tng3d.com) all provide data structures which associate a list of bones to a set of vertices, each with a given weight.

Thanks,
Dario

Sensei
05-07-2010, 06:45 PM
Skeletons are not assigned to any vertex.
So, you need to analyze .lws file, text file, to learn about real bones. Open .lws in text editor and search for "AddBone" or so command. They can be: weight map only (this way you can immediately know which bone has what influence on which vertex), weight map together with distance based vertex assignment, and no weight map pure distance based vertex assignment.
Games usually (always?) use weight map only method. Because it's the fastest.

Sensei
05-07-2010, 06:50 PM
Mike,
There is no documentation on this issue, so I am not clear how to go on -- the other SDKs we use in TNG 3D (http://tng3d.com) all provide data structures which associate a list of bones to a set of vertices, each with a given weight.


Subscribe to Yahoo! Groups lw-plugin mailing list. This was answered probably 1000 times there, each time game maker was writing game engine. Search archive.

Lightwolf
05-07-2010, 06:57 PM
Subscribe to Yahoo! Groups lw-plugin mailing list. This was answered probably 1000 times there, each time game maker was writing game engine. Search archive.
Actually there's only ~650 posts about bones and many open questions.

But this should be a good start:
http://tech.groups.yahoo.com/group/lw-plugin/message/10632

Cheers,
Mike

pignus
05-07-2010, 06:58 PM
Skeletons are not assigned to any vertex.
So, you need to analyze .lws file, text file, to learn about real bones. Open .lws in text editor and search for "AddBone" or so command. They can be: weight map only (this way you can immediately know which bone has what influence on which vertex), weight map together with distance based vertex assignment, and no weight map pure distance based vertex assignment.
Games usually (always?) use weight map only method. Because it's the fastest.

Sensei,

I am trying to learn how bone animation works in LW. Just to be clear, I will explain what other SDKs (e.g. Autodesk FBX, Open Asset Import Library) provide in terms of skinning (or bone animation).

Each mesh that is to be skinned is provided with a list of bones that influence the mesh. An entry in the bone list comprises the bone name (or object), a bone offset matrix and a list of vertex-weight pairs, each containing a vertex index and its corresponding weight. This is roughly what LW calls a weight map, but as you can see from its description, it contains more information than 'VMAP/WGHT' chunks in LW objects: it associates a given vertex with one or more bones. This association is what I'm missing.

I am already importing the correct bone structure from .lws scene files; the problem is that the files I'm using for testing (from the LW 8 Content directory) do not always specify the bone weight map name, therefore they must be using one of the two other methods you mentioned. Unfortunately, those methods are not supported in TNG 3D (http://tng3d.com) -- and without proper documentation it could be somewhat complicated to implement them...

Thanks,
Dario

pignus
05-07-2010, 07:03 PM
Actually there's only ~650 posts about bones and many open questions.

But this should be a good start:
http://tech.groups.yahoo.com/group/lw-plugin/message/10632

Cheers,
Mike

Mike,

I'll sign up for an account and check out that post.

Thanks,
Dario

Lightwolf
05-07-2010, 07:04 PM
This association is what I'm missing.

You don't have that by default. By default all bones affect all vertices, depending on the global falloff (per skeleton).

Weight maps are an optional extra that was added later.

There's also cases like multiple bones sharing a single weight map, or weight mapping being mixed with the falloff method (which never reaches 0 by the way).

Cheers,
Mike

pignus
05-07-2010, 07:14 PM
You don't have that by default. By default all bones affect all vertices, depending on the global falloff (per skeleton).

Weight maps are an optional extra that was added later.

There's also cases like multiple bones sharing a single weight map, or weight mapping being mixed with the falloff method (which never reaches 0 by the way).

Cheers,
Mike

Mike,

Thank you for this information. In order to implement the falloff method, I think I need to access the Yahoo! Groups post you mentioned earlier -- I've set up an account for this purpose but haven't received word from them yet.
I don't think sample code is actually needed: just a general description of how to apply the falloff method... from your description, this seems quite expensive in terms of performance: all bones affecting all vertices by default isn't likely to be particularly fast...

Thanks again,
Dario

Lightwolf
05-07-2010, 07:18 PM
Thank you for this information. In order to implement the falloff method, I think I need to access the Yahoo! Groups post you mentioned earlier -- I've set up an account for this purpose but haven't received word from them yet.
I don't think sample code is actually needed: just a general description of how to apply the falloff method... from your description, this seems quite expensive in terms of performance: all bones affecting all vertices by default isn't likely to be particularly fast...

No, it isn't fast, that's one of the major (known) downsides, even though faster implementations of a similar system exist (as I was reminded yesterday: pmg:messiah uses a similar system but is extremely fast).
The link should help as it contains pseudo-code that explains most of what's going on.
I would venture out and say that the heavy use of pow() is one major reason for slowdown, but I guess you could basically use the information to create temporary vertex maps speeding things up.

Cheers,
Mike

pignus
05-07-2010, 07:20 PM
No, it isn't fast, that's one of the major (known) downsides, even though faster implementations of a similar system exist (as I was reminded yesterday: pmg:messiah uses a similar system but is extremely fast).
The link should help as it contains pseudo-code that explains most of what's going on.
I would venture out and say that the heavy use of pow() is one major reason for slowdown, but I guess you could basically use the information to create temporary vertex maps speeding things up.

Cheers,
Mike

Mike,

This sounds very exciting -- I can't wait to access that post, but Yahoo! has not sent me the confirmation email yet... argh!

Thanks again,
Dario

Lightwolf
05-07-2010, 07:21 PM
Mike,

This sounds very exciting -- I can't wait to access that post, but Yahoo! has not sent me the confirmation email yet... argh!

Thanks again,
Dario
I'd copy and paste, but that post is a collection of links to other posts...

Cheers,
Mike

pignus
05-07-2010, 07:35 PM
I'd copy and paste, but that post is a collection of links to other posts...

Cheers,
Mike

Yes, I understand -- if the links are still part of Yahoo! then there's nothing I can do but wait and hope... otherwise, you could try to print that post to PDF or something like that, but you've already helped a lot as it is.

Thank you,
Dario

Lightwolf
05-07-2010, 07:36 PM
Yes, I understand -- if the links are still part of Yahoo! then there's nothing I can do but wait and hope... otherwise, you could try to print that post to PDF or something like that, but you've already helped a lot as it is.

Patience grasshopper, it's late enough already ;)

If it hasn't show up by tomorrow, ping the thread and I'll collect some stuff for you and post it here.

Cheers,
Mike

Sensei
05-07-2010, 07:51 PM
Or try subscribing from other e-mail. Maybe you provided e-mail that Yahoo doesn't like. I am receiving e-mails from mailing lists in seconds..

pignus
05-08-2010, 06:04 AM
Well...

I have read the relevant posts on Yahoo, and the pseudo-code is pretty clear. However, given that it's part of the lw-plugin group, it is obviously targeted at that environment...

Specifically, I wouldn't know how to apply the algorhythm to .lws files: the bone->omat and bone->rmat matrices are not present in scene files...

Thanks,
Dario

Sensei
05-08-2010, 06:15 AM
You have item position, rotation and scale in lws. Use them to build matrices. Or write LW plug-in which output them to some file.

pignus
05-08-2010, 08:32 AM
You have item position, rotation and scale in lws. Use them to build matrices. Or write LW plug-in which output them to some file.

I am already building a bone matrix from the information in .lws files -- the sample code uses *two* matrices, not one. And, no, I am not interested in writing a plugin: I am interested in importing animated .lws files directly.

Dario

Lightwolf
05-08-2010, 09:14 AM
I am already building a bone matrix from the information in .lws files -- the sample code uses *two* matrices, not one. And, no, I am not interested in writing a plugin: I am interested in importing animated .lws files directly.

Dario
Hm, the other one is the rest position, right? That should be written with the bone information, probably not as a matrix though.

Cheers,
Mike

pignus
05-08-2010, 11:30 AM
Hm, the other one is the rest position, right? That should be written with the bone information, probably not as a matrix though.

Cheers,
Mike

Mike,

I'm building a set of axes from the bone rest position and direction in the .lws file; if I'm not mistaken, this should correspond to bone->rmat in the pseudocode. I guess the other matrix is just the actual bone matrix...

Thanks,
Dario

pignus
05-10-2010, 03:10 PM
No, it isn't fast, that's one of the major (known) downsides, even though faster implementations of a similar system exist (as I was reminded yesterday: pmg:messiah uses a similar system but is extremely fast).
The link should help as it contains pseudo-code that explains most of what's going on.
I would venture out and say that the heavy use of pow() is one major reason for slowdown, but I guess you could basically use the information to create temporary vertex maps speeding things up.

Cheers,
Mike

Mike,

Using pow() is indeed not suitable to real-time rendering, for all practical purposes at least. So we are now trying to create weight maps based on the falloff method, selecting only vertices with non-negligible weights.

However, we would really need some simple test scenes to debug the code, because currently the applied deformations do not match: we've been using the LW 8 Content/Dynamics directory to test, and that's too complicated for efficient debugging.

Do you happen to know where we could find some reasonably simple animated scenes, obviously free...? Ideally, we would need a scene with no WGHT vertex maps, and a scene with at least one such vertex map... and of course the bone animation should not have been generated by any custom plugin.

With similar test files we would have a better shot at understanding what's wrong.

Thanks,
Dario

Lightwolf
05-10-2010, 04:03 PM
Do you happen to know where we could find some reasonably simple animated scenes, obviously free...?
There should be some simple character anims both in the LW 8 and LW 9 content. One I like to use a lot is Zombie.lws (or something close).

Cheers,
Mike

pignus
05-10-2010, 04:54 PM
There should be some simple character anims both in the LW 8 and LW 9 content. One I like to use a lot is Zombie.lws (or something close).

Cheers,
Mike

Mike,

Zombie.lws in the IK_Booster_Rigs/Zombie folder contains weight maps, and it uses a falloff type I don't know about (8, whereas the maximum should be 5). The Zombie_shirt.lws file in the Dynamics folder also uses weight maps. I've found that the ss_lookaround.lws file in the same folder does not specify any weight map, but it isn't particularly simple...

I was thinking more along the lines of something outside of the LW Content directory, some tutorial maybe...

Thanks,
Dario

Lightwolf
05-10-2010, 04:59 PM
I was thinking more along the lines of something outside of the LW Content directory, some tutorial maybe...

I can't think of anything off hand at the moment. and those mixed bones are usually quite common. I.e. only use weight maps if needed to fix something.

You might want to ask for sample content in the forums here...

Cheers,
Mike

pignus
05-13-2010, 08:23 AM
Mike,

We're using the Dynamics/ss_lookaround.lws scene from the LW 8 Content directory for base testing at the moment -- it's the only one we could find that uses no weight maps for the bones, no animation plugins, no bone limits. In fact, its structure is pretty homogeneous, which makes it suitable for testing.

However, we're still facing some issues... currently we are building our own vertex weight maps using the falloff method (because it's impractical to use pow() in real-time). Everything looks correctly in the rest pose. As we start animating bones though, starting from the root bone, we can see degradation in both quality and placement of the deformations.

Since this is clearly an hierarchical problem, we're wondering in what coordinate system bones are actually stored... we understand it's supposed to be "parent coordinates" (something that doesn't commonly exist in real-time environments, where only local and world matter). Based on this assumption, we're building the bone offset matrices (which should represent the rest pose) that are required for our rendering system. Corresponding matrices are used to animate FBX, Collada, DirectX and similar files.

These matrices definitely do not match what is needed to apply the same deformations that LightWave applies -- that's why we suspect a coordinate system issue, although we have no idea *what* issue...

Thanks,
Dario

Lightwolf
05-13-2010, 08:30 AM
we understand it's supposed to be "parent coordinates" (something that doesn't commonly exist in real-time environments, where only local and world matter).
Actually I'm currently working in a scene graph based environment and parent coordinates certainly exist there, but then again they're really nothing else but local coordinates in a hierarchy.


These matrices definitely do not match what is needed to apply the same deformations that LightWave applies -- that's why we suspect a coordinate system issue, although we have no idea *what* issue...

I've no idea to be honest. I never had to deal with this stuff so I can't really help you any further. Posting on the plugin developers ml might get you better answers.

Cheers,
Mike

pignus
05-17-2010, 07:20 AM
Mike,

I've yet to see a realtime scene graph where parent coordinates are very useful... anyways, it turns out we got the coordinate system right the first time.
However, it looks like we have to use falloff exponent - 1 in order to get the same deformations as in LW -- go figure.

Thanks,
Dario