Radagast.

It reminds me of one of our planned features that is not yet in our list. Thanks! (units will need resources, so the more units, the more difficult to feed, though the administrative and management idea sounds promising too - we have this for fields already where more units start hindering/decreasing gather rates)

Interesting. The saddle reminds of those we use for camels sometimes ... I wonder why they tied it across the length of the horse and not like nowadays. Probably there were reasons ..

Why not put it in the share repository: install git.Get the share repo:git clone https://github.com/0ADCoM/share.git path/to/local/target/dir/Drop your file into: path/to/local/target/Rightclick on the folder --> commit. (or: git commit -a -m "my files I want to share with you") You can create and edit your files directly in the repository folder. Before you want to push the changes onto the server, just run: git add *git push Not difficult, but very useful, as it keeps order and you win time.

Essentially: The local coordinates that are imported for bones are completely different than their (the bones') object coordinates! (see screenshots) This could be the alternative reason for the old animations being screwed up. (the other theory is the vertex index inconsistency in COLLADA format)

For the head, see above, y-up and z-up is mixed up. In blender it's looking fine, but somehow the imported data is still in y-up while the prop points seem to get out into the COLLADA in z-up. The engine ignores it completely I was told. Interesting .. that could explain it. Have to try it. Ha, you know I compared it? When I looked at it I saw a lot of metadata in the dae from 3DSMax. Also the 3DSMax files contained an array/list of the prop points whereas in blender-dae files they have only two occurences of prop-head, once in the id of a node and once in target or name of the same node (so just one node in the bone-structure as it is parented to it and that's all). Also in the 3DSMax files there were a lot of other objects around. Still both only had one material. Hm... have to take another look. what did you realise when you compared them? Edit 2: thanks for the files!!

Enrique, Wijtmaker, Look at this: (z-up vs y-up, this could be what screws the old animations, have to tell blender to feel like y-up) @Enrique: You are right. I just mixed up the terms, lost the overview as there are many threads about COLLADA problems, once have import, the other export problems, the next don't get it into the engine. So I thought I should try it myself instead of only talking (what I definitely already do enough). I didn't want to attack your pipeline in any way. Just help out ... Thanks for the animal animations. I like the animals in 0A.D., they are just like the real thing.

I will try to be more specific. Used the dude_4.blend and exported it. It did not work. Then I added a blender specific skeleton for the biped (.xml) (see tar.gz above or my github link). There I mapped the hierarchy and the names with the help of all the experiments of you artists in this and other threads. Then I replaced the cuves with empties. I used the daily build. In blender I select the Armature, the Prop points (empties) and the main mesh. Then I export and use these settings though this may be forgiving: I created the files as being told by our masters. Loaded the animations in ActorViewer in Atlas, but only the one from the same .dae file worked. The .psa animation (all our old ones) are screwed. perhaps we can try old .dae where the .psa were derived from instead?

I'm lucky he had issues, because having the possibility to give each entity a bit a different scale in each direction (x,y,z) in the local object frame would be brilliant. Just imaging, we could have units that are taller, a monk that is a bit wider, a really thin and tall guy that'd better become archer than melee. This would also be nice to look at in action. Currently it's hard to know which unit you lost, but with the variation in scale, you could immediately tell .. oh no, my tallest archer's wounded. Also later we could include the scale, hence the final height into the calculations to calculate when an archer misses the target. Also big guys could walk quicker (in a formation deactivated). What I like best about it, is that we could make units grow ... imagine we could influence the scale (within the simulation depending on time, saturated of course). Even a tree would finally grow slower, would it? Even without growing, a variation of a tree's height and width (within one species) would be really fantastic. Can't believe you are working on it ... brilliant. Wow, that's fitting our purposes perfectly. Finally we can make campaigns happen then. And draw red lines .. when an AI might get really get angry once you settled on this land (as an example). A trigger could also be hidden in a tree, making a unit suddenly appear, once the tree is cut. We could also use it to make legends, dragons, whales, .. appear over lakes, bringing messages, changing the world effents, i.e. adding new triggers (we reached the next phase). Also a trigger could add new civilizations, e.g. "The Spartans arrived on your coast". The whale then could finally be used as a ship to bring you to a cave, especially with the HybridAI, where citizens may split from a civlization, then being hunted for by many enemies at a time this opens up dozens of possibilities. No matter how it turns out. It will definitely create a new depth and atmosphere. Those two changes will be felt. Especially as Mythos already wanted this variation and this would make 0A.D. much more natural. Hardly can await seeing it.

We have the pipeline but we have not saved the old animations so far. Unfortuenately the result is semi-okay. The animations plays well, all movements correct, but the mesh is distorted. The head prop is rotated by 90 degree. Do you think the weights of the vertex groups have to be rotated by 90 degree. Strange though that the walking is perfect, still the mesh looks like each bone was rotated along the axis that points towards as when the model looks at us and along the z-axis for the head ... have to find the issue.

Good news everyone! We have it! Prop points working. Objects are treated differently than empties for blender, not even helps to delete all vertices. 3DSMax prop tools must have done some post-processing, so for blender we have to take empties, as Enrique and others already stated before. Only problem so far, that though I parented the empty to the head and called it prop-head ... still the head appears at a different location. Btw, have you noted, the above file was a tiny gif animation, for those that want to see how it looks in Atlas Actor view. Together we strive ... we had never made it that far without all the year-long desperate efforts to make it. My thanks to our team. Also GaiaClary needs to be honoured for the vast improvement of COLLADA export and import. If we get animations to work in blender with the COLLADA importer, then we have made it. To prepend the "prop-" or "prop_" to the empties that have the armature (more specific: a bone of it) as parent, we can create a blender script or addon. Still can't believe that there is a head now attached ... okay its rotation and position ... well ... have to check how to fix it in blender, surely parented the wrong way. Btw. some bad news too, I'm afraid, the other animations don't seem to play nice with it. Only the one that was embedded in dude.dae. https://github.com/0ADCoM/share/blob/master/blender/dude--actor-xml_dae_and_blend.zip Note that this all is made to work with ForeArm instead of Forearm. I have to change it .. Edit: Updated link and marked ForeArm instead of Forearm problem as resolved.

Ah, I forgot ... this might be normal because of the not-fitting animation? We have a pipeline! That means if you remember how brilliantly you got to this .dae ,if we can repeat it for other animations (if we don't bore you of course),And if we get the prop points to exist in the .dae and to work.Or perhaps this is just an illusion?? A dude jumping in Atlas.

no comment.

Good news!! Exchanging the m_pants_tunic.dae with the from blender exported dude_4.dae mesh gave an error, but this is only related to an animation and prop point!! So it looks it could at load it! ERROR: Failed to set idle animation in model "art/meshes/skeletal/m_pants_tunic.dae"ERROR: Failed to find matching prop point called "back" in model "art/meshes/skeletal/m_pants_tunic.dae" for actor "trader_r"ERROR: Failed to find matching prop point called "head" in model "art/meshes/skeletal/m_pants_tunic.dae" for actor "trader_r"ERROR: Failed to set idle animation in model "art/meshes/skeletal/m_pants_tunic.dae"ERROR: Failed to find matching prop point called "back" in model "art/meshes/skeletal/m_pants_tunic.dae" for actor "trader_r"ERROR: Failed to find matching prop point called "head" in model "art/meshes/skeletal/m_pants_tunic.dae" for actor "trader_r"

deleted

Can find the blender specific skeleton mapping in this biped.xml on GitHub. Note, that strangely the ForeArm is written Forearm in blender though UpperArm is not written Upperarm. Might be that that's normal (any native speakers around?). So I've to edit that in the biped.xml. Or you rename the bone in blender via double click onto the bone in the outliner before exporting. Btw. this now looks much better, I tried several options and finally the not recognised skeleton is gone Must have broken something in the biped.xml. Will compare to SVN version now.

For those that wonder, my script is quite useless, as it does not remap the hierarchy. And that's exactly what is done by defining another <skeleton title="blender biped" target="biped">...</skeleton>

I will take this into account. As it's planned, it should be capable of detecting which file should go into which folder, so hopefully it'll not be CoM mod specific. All our mods try to be additive. The capturing is already allowed by our engine (owner changed message/event), so I guess all the rest can be done in JavaScript, making it easy to test if a Mod fulfills all requirements to be adopted as official capturing functionality. Not yet possible to say. The goal is the same, the way to it might be different. That's good news. Naval battles in general will hopefully benefit from mods. That comes unexpected. No matter the outcome, any trials and experiments are highly welcome. Oh, there is a patch for it. Thank you for pointing out. Time will tell which new triggers we should work on. Will have a look on the patch and wait for its inclusion then. (no rush) Thanks for your input.

Okay, if it's autogenerated, then it's cool. Appended the blender specific skeleton-XML to biped.xml. --> GitHub I also have written a blender python script for renaming bones automatically to fit our engine's standard_skeleton: <-- this is useless, see here biped ... for other skeletons this can easily be adapted.Most recent version (GitHub)So I will continue my tests..

Any problem if the DUMMY finger nub is not included as a bone in blender (will file a bug report if so)? I guess it's not because of the DUMMY, but it's better to be safe.

The bone root you mean? I also guess it's the latter: mesh[, armature/bone_root], props Though it could be that the Armature is already exported through the armature modifier that is registered to the mesh in the modifier tab of the properties panel (within blender at the right the wrench). Will try it. Also I realised one problem. In blender, the hierarchy is not completely right. The l_clavicle and the r_clavicle are not children of the head! Nevertheless the animation plays very well (in daily blender build). I will fix the skeleton mapping. (or best use the default names, why didn't we use those? are the bone names generated by the 3D program?)

Okay, I missed a negation !! Faux pas!! Sorry! Edited my post with the anomaly. I will try to find the old skeleton you once prepared. I also try with several COLLADA exporter versions now.

Thanks, that helps. Wait, the prop points were there. It's just that I didn't select them - because i read somewhere they have to be selected too, in the 3DS part of the i think. There we also find blenderspecific: Isn't that a contradiction, select the prop point objects and only 1 object per COLLADA?

Okay, I see we need a custom skeleton model for blender, have to check all bone names ... eventhough the PSA format does not store bone names. strange. I know it has been worked on the blender-skeleton biped.xml. Will look for it or try to make it compatible. I realised it's not possible, because we don't have any prop points in the dude_4, at least we don't export it currently to test the basics only. So if we simply swap it then the engine will try to attach props where there are no prop points ... no good. :/ Or is it not possible to have a model/mesh without any prop points? <-No this can't be the problem.

Okay, will give this a try too. As for now the skeleton can't be recognised, the common case. Looks like it can't find the root skeleton: const Skeleton* skeleton = NULL; const FCDSceneNode* joint = controllerInstance.GetJoint(0); while (joint && (skeleton = Skeleton::FindSkeleton(joint->GetName().c_str())) == NULL) { joint = joint->GetParent(); } REQUIRE(skeleton != NULL, "recognised skeleton structure");This can have many causes, one thing I realized when following the FindSkeleton from the while loop above, is this anomaly:<--it's correct, I missed a negation!! Any help appreciated.

Thanks a lot .. trying to get it ingame starting from blender using dude_4 currently. What I did: put the exported COLLADA .dae into .../meshes/skeletal folder.Modify an existing actor xml file to use this skeletal/dude_4.dae .Trying to figure which animation to assign (must be biped I guess).Or does the .dae go into the animation folder. What's the difference between how the .dae are exported for the two possibilities (mesh & animation). Both the same?