John VanSickle wrote:
> In my bone system, I have a set of two transforms for each bone,
> one for the start and one for the end.

Mee too.

All the details about how the transforms are generated and the various joint
types are not important to me, since my system will take care of generating
the transforms in its own way. The only thing that matters is that the end
result is compatible. And the end result is for both of our systems two
transforms for each bone, one for the start and one for the end.

> The vertices that are attached to each bone are local to either the
> start or the end of the bone.

The "local" part here I'm not sure I understand. Surely all vertices in the
model are modeled in a global coordinate space? I presume by local you only
mean that the vertices are "attached" to either the start or the end of the
bone?

> #declare Part3_te=transform {
>     rotate z*Part3_az
>     translate z*Part3_sl
>     transform Part3_tb
> }
>
> You can base the objects on these transforms:
>
> cylinder { 0,Part3_sl,rRadius transform Part3_tb }

Shouldn't that be z*Part3_sl there?

> My modeler works in conjuction with my subdivision surface
> macros.  If the original mesh has some vertices based on one
> bone, and other vertices based on another bone, the faces
> that span the two bones will show stretching when the bones
> are moved relative to each other.

Yes. Your format and the game-related formats I was looking at seem to have
in common that each vertex is attached to one bone only, not multiple bones,
each with a weight of influence. This restricts the format to being useful
for low-detail models only. I know that subdivision takes care of creating
additional triangles, but a smooth subdivided mesh will still be as
low-*detail* as the model it is derived from even though it is
high-*polygon*. This doesn't mean that such formats aren't useful, it just
mean that there are certain restrictions to how detailed models one can work
with.

I tried out your LionSnake modeler, but I must admit I failed to create
something as simple as a regular box. But then, I have no experience with
other modelers either. I'd be curious to see what more talented modelers
could create with your modeler. The sample object that comes with the
program (which resembles a sheet of paper) is not a very good indication of
what the program can be used for I think.

Anyway, the things I need to know if I am to support this format is not so
much the joint types, but rather what the format itself looks like, i.e. how
is the information stored in the file?

Rune
-- 
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message