Assimp Autorotation in 93.1?

[smoth]

the first mech is a s3o, the second is an assimp collada, same for the third. They all run the SAME script. The one on the far right has not rotated 90 degrees because I have the game paused.

first thing the assimp file does after creation is rotate 90 degrees.



wtf

[smoth]

figured out the issue. I needed to bake my rotations for all child objects. However after that, the animation looks really broken for z and y rotations. There is already a mantis for this posting shots in that.

[SpliFF]

I don't think baking the rotations is the correct method because this would make all rotations and offsets based on the model origin (global) and not the parent object. You do have to bake the scale though since spring doesn't support scaling.

Having said that I ran into similar issues in my own testing (including the issue of models starting 90 degrees rotated then snapping into place).

CarRepairer was having similar issues but I think he solved them by making sure the parent/child relationships were correctly defined in Blender (and by "correct" I mean according to Blender's notions of hierarchy and relative offsets).

Blender does have an option to convert child offsets between global and relative but I'll be damned if I remember how.

Once I've refreshed my memory and checked the code itself is not the issue i'll post an end-to-end tutorial on the wiki (which I've shamefully neglected to date).

PS: I quick way to test if this is really an assimp bug would be to export to .obj and try that. OBJ files still use Kloot's implementation, not the assimp codepath.

https://github.com/spring/spring/blob/d ... Parser.cpp

Code: Select all

C3DModelLoader::C3DModelLoader()
{
// file-extension should be lowercase
formats["3do"] = MODELTYPE_3DO;
formats["s3o"] = MODELTYPE_S3O;
formats["obj"] = MODELTYPE_OBJ;

parsers[MODELTYPE_3DO] = new C3DOParser();
parsers[MODELTYPE_S3O] = new CS3OParser();
parsers[MODELTYPE_OBJ] = new COBJParser();
parsers[MODELTYPE_ASS] = new CAssParser();

// FIXME: unify the metadata formats of CAssParser and COBJParser
RegisterAssimpModelFormats(formats);

// dummy first model, model IDs start at 1
models.reserve(32);
models.push_back(NULL);
}

[smoth]

nah baking down the chain fixed my issue. The next issue is z and y being switched for assimp stuff in 93

[SpliFF]

Can you clarify what "baking down the chain" means? What was the process for that?

[smoth]

same thing used to happen in upspring. rotate an object apply transformation. Children get effected. In the case here in blender, it set then next level child as rotated 90.

so what I had to do was walk the hierarchy and apply rotation all the way to the last branch of the hierarchy

[SpliFF]

Slightly off-topic but I just noticed jK has added support for scaled pieces:

https://github.com/spring/spring/commit ... 847477c2d4

I don't think this is the cause of the swapped axis but I just thought I'd correct my previous statement about baking the scale.

EDIT: Maybe not so off-topic. The same commit adds this:

Code: Select all

+  rot        =  piece->rot; 

Not sure how rot used to be set but I suspect there might be a connection. It's highly probable that jK's new code is correct but the original code (my code) was based on the wrong value of rot (probably a default 0,0,0 rotation rather than the true rotation). On the other hand if the piece vertices are rotated inside the node/object then this might cause the "apparent" rotation to be applied twice, ie, the piece is rotated and its contents (mesh/vertices) are also rotated.

If I'm right then this means "baking" in Blender is actually not the correct approach (if "baking" is rotating the mesh and not the object/piece as I suspect it is).

In short, for animation to work as intended the mesh must NOT be rotated inside the node and the node must be rotated relative to parent. Also I believe Spring 93.1 is in fact not broken but fixed and the actual bug is in the model due to the original code and instructions being incorrect (entirely my fault, sorry).

[jK]

I don't think this is the cause of the swapped axis but I just thought I'd correct my previous statement about baking the scale.

No, non-uniform scaling (xyz all scaled by a same different amount) are still unsupported. Still uniform scaling should work (untested).

And yz issue is very complicated, as there are multiple spaces conflicting.

[SpliFF]

No, non-uniform scaling (xyz all scaled by same amount) are still unsupported. Still uniform scaling should work (untested).

There's a typo there:
non-uniform scaling (xyz all scaled by same different amount)

[jK]

brain failed :)

[smoth]

jk requested I post my fixed file.

[SpliFF]

Checked Blender doco and I can confirm my original guess. When you use "Apply Transformation" (CTRL-A) in Blender what you are really doing is re-setting the nodes rotation to (0,0,0) and then transforming the MESH inside the object. That's bad because now your visual "up" and your object "up" are not the same.

A mesh actually has no concept of rotation, it's just a buch of points. That means to fix your model you'll have to manually rotate your meshes (edit object) to the correct alignment. Probably going to be a lot easier for you to go back to a version before you baked the transforms.

[smoth]

I am seriously thinking of not answering another post. The model is fine now and this has gone beyond stupid. I am more concerned the z,y switch which doesn't happen to just my script.

[SpliFF]

Calm down. I'm simply trying to verify whether the orientation of your pieces and meshes match what Spring 93.1 expects. Just because it *looks* ok when the model is loaded does not mean the pieces and meshes are correctly aligned. I know you're a smart guy but for technical reasons (see below) I currently only have your word that the model is "fixed". For all I know your meshes are still "rotated" inside their nodes.

I haven't been able to check due to problems with my blender install (seems to be missing collada plugin). Once I do that I can confirm wether this line of enquiry is "stupid" or not. I *have* looked at the XML source of the dae file and it seems to confirm my suspicion that the meshes are rotated inside their containers and most of the nodes themselves are only rotated at 90 deg. However the visuals you've provided suggest the legs and arms should be at sloped angles so lets not be so hasty when assuming everything is "fine" with the model.

[smoth]

file for jk, ignore this

[Anarchid]

Probably going to be a lot easier for you to go back to a version before you baked the transforms.

This is not entirely correct. Due to x/z conflict and possibly other math nonsense, the local axes for each piece are not aligned properly in 93.1 even if corresponding meshes are.

You end up rotating not around local axis, not aroung global axis, but around something from another dimension.

My test was: a global-aligned Empty piece with attached non-baked object (a stretched cube, basically a stick) at 45 deg, with its (blender) x-axis running along the 'length' of the 'stick' .

The appearance of the root-stick system sans animation was 1:1 match to what i saw in blender, with the stick being placed at proper degree and at proper offset, but:

None of the Spin commands (i tried 6 combinations - x, y, z, and same for root) i gave to that stick ever produced it spinning around that run-along "x" axis. So the axis wasn't just 'misplaced': it wasn't there and something else took its place.

Note that root rotation and stick rotation caused different behaviors, so *some* rotation was applied to the axes, just wrong; the rotation axes for stick was not global.

I think i'll have to dig around this a bit more.

On the other hand - and this is HILARIOUS - my 91.0 mutant jellyfish model not only imports, but also animates perfectly, with no difference.

(bu then, it's baked, so it should not be affected anyway)

Another thing (maybe for a different thread) - Spring assimp seems to fail to import newer blend files. Opening and re-saving my jellyfish to same filename in newer blender caused the model to disappear.

I do realise directly importing .blend is a weird thing to do anyway, but the caveat is worth noting.

[smoth]

Another thing (maybe for a different thread) - Spring assimp seems to fail to import newer blend files. Opening and re-saving my jellyfish to same filename in newer blender caused the model to disappear.

I do realise directly importing .blend is a weird thing to do anyway, but the caveat is worth noting.

same happend for me.

[SpliFF]

For the record I don't think .blend has worked well from day 1, the blend import module should be considered alpha quality at best (that's largely an assimp thing, not Spring-specific).

For those not involved in the chat this afternoon it appears jK has made some progress finding the cause and potential solutions to this issue. If I understand correctly the fault has always been there in my rotation code (causing rotations around the wrong axis) but until 93.0 the rotations weren't being applied so you only got apparent rotation by baking rotations into your meshes. Spring still rotates the nodes to fire etc but the orientations of child pieces were most likely being miscalculated or ignored.

Another complication in all this is scaling. Until recently Spring completely ignored scale transforms. The only way to scale an object was to bake the scale (you know, that process I'm now saying not to do). Unfortunately scaling may still be an issue if X,Y and Z are not the same value (uniform) so it may become necessary to bake ONLY the scale.

If you're wondering why this scale issue didn't affect UpSpring models it's because upspring bakes your scale for you BUT in the process it typically ruins normals. The assimp importer could be modified to do this as well but it would probably also break normals too.

Another bug brought up involves models loaded for cloaking effects or other objects like terrain features not matching an equivalent unit model. The reason for this is parts of the rendering code are currently only applied to units so if you rotate or translate a model it may appear unrotated/untranslated in game. This is something that can and should be fixed but it involves a few big engine changes so it may take some time to fix.

Anyway I'm hoping this can all be fixed fairly quickly but people making assimp models should be aware that any models that "worked" before the recent changes may in fact have incorrect rotations and there probably isn't much point trying to fix/test them until the engine transforms are working and verified.

[Anarchid]

I don't think .blend has worked well from day 1

Some units might disagree:

any models that "worked" before the recent changes

... have no transforms that can be broken, because, due to broken transforms, have all had their rotations baked into meshes.

[SpliFF]

Lucky you. What version of blender is that from?