dont know actually, never exported a collada model myself. might be that, or he might be using multiple skeletons, or sth else

well, the error is descriptive I suppose there are multiple skeletons. maybe you are exporting multiple models with separate skeletons?

you can have multiple models and all should be attached to a single skeleton

you compare it with what?

yes, possibly missing library_controllers is the reason

what is facial landmarks?

Bones only support skeleton animation in Collada files (yet dont know if other type of animation exist in Collada files, anyway) for sure you need a skeleton rigged to your model for that.

facial animations are generally pose animations (although not a strict rule), Bones only support it via Ogre3D not via Collada. have a look at FacialAnimationSample for that

Quote
you means that i can covert .obj to .bone format too?

nope, you cannot. unless you write an importer for that

Quote
How can i tell .bone where my texture are?

texture names are not imported. you need to set texture after Animated3D is constructed, check the samples. and for sure this also means same Animated3D cannot have multiple textures. unless you modify textures of polygons "manually"

Quote
i am wondering why bones need the animations compulsorily? it is because there is a case that we animate the model programatically instread of playing a predefined animation.

because typically exporters do not export skeleton without animation. no skeleton -> no programatic animation

yes, Bones' binary format should be faster and more important it has no runtime dependency other then Bones and jPCT. remember when loading Collada or Ogre3D format, Ardor3D's or jME's loader / parser is used, then converted to Bones format.

this has nothing to do with .obj format. just a binary representation of Bones animation model.

you can use the scripts in the /scripts folder to convert to Bones' binary format. they should provide help with -help switch

most possibly if there is no animation, skeleton data is not exported. just try to put a dummy animation

hey!

nope, not possible with current state of api. you can change the code or use reflection to add a joint to skeleton. however I'm not sure math will follow what you intend to do.

I will suggest attaching your movable object to skeleton at blender and export the male body and object as a group, separate objects but both are linked to same skeleton. at run time you can show/hide your object. (not sure if possible with blender exporter, but anyway)

see the ninja demo, it's exported as a group and ninja holds a sword at his hand which can be shown/hidden but follows ninja's animation.

as you intend to write the importer part too, it doesnt actually matter.

but Bones' internal logic requires joints in a skeleton are ordered such that a joint's parent joint always comes before the joint itself. this should be handled either at exporter or importer.

Quote from: AGP on January 04, 2017, 08:03:12 PM
I'd still need the very first one, for the model itself, right?

sorry?

Quote from: AGP on January 04, 2017, 08:03:12 PM
We're still talking about my JSON-serialized format, you see.

in that case you shouldnt care about vertex count or unique vertex count in jPCT. your exporter from 3dsMax and importer to jPCT should agree on that.

we are talking about Bones' SkinData class, right?

when you import any skeletal animation into Bones, SkinData is automatically generated for you. you can access it via Animated3D.getSkinData()

I'm not sure I understand what you are trying to do.

Quote from: AGP on January 04, 2017, 05:24:18 PM
No, the bones are also defined in the file.

then why are you creating a SkinData "manually"?

what e

Quote from: iguatemi on January 03, 2017, 08:53:29 PM
We have for the same model, two very different vertex counts (triple the number of triangles in jpct versus the unique vertex count which is typically less than the number of triangles in any given model), while retaining the same number of triangles, between jpct and 3ds max. But when we create our SkinData, we use only the number of unique vertices. Now we're thinking that we should be using the number of vertices in jpct. Did that make sense to you and do you agree?

what exactly is your pipeline?

if you are creating your skeletal data from scratch in code, and loading your model from 3ds format or similar, yes, you possibly need to use number of vertices instead of unique vertex count.

Quote from: AGP on December 25, 2016, 06:46:07 PM
And is it possible that other engines, like Unity, have some kind of logic to redistribute the weights for models that use more than four? Yet another question: is it trivial to increase the number of joints per vertices, or would that be a massive undertaking?

assuming exporter supports it, it should be modified in loader code (jME, ardor3d). but again I dont see any good benefit for that

Quote from: iguatemi on December 23, 2016, 08:49:54 PM
hey, raft. in some models, some vertices have more than 4 joints associated to them. do you have any input on how to handle these cases?

need to check loader (jME, ardor3d) code but most possibly they are simply ignored. I cant see any good reason to support more than 4 joints. to me 4 joints are almost more than good enough