Indeed! I do think it makes sense to have a sound together with the animation in this case, just saying that an effect is so much more than just that. 
Canât track the source, so Iâve decided to try another approach. If I canât make a door out of a chest, Iâll try to make a chest out of a door.
Came right to replacing models and anims with my custom ones. This attempt is not in the repo yet, so anyone willing to try with the previous one is welcome!
Update:
Yay! Success. It seems Iâve narrowed the list of culprits greatly.
The animation does work: apply my custom animation to the original door model (renaming skeleton bones in the animation to fit the model)
The animation doesnât work: apply my custom animation to the changed door model (the only change Iâve made was rename the matrices in VoxelShop to fit the animation).
So far I have two theories:
- VoxelShop somehow corrupts QB model format crippling its functionality in SH
- I choose bad names for renaming
Even more updates:
Itâs alive. ITâS ALIVE!!!
âŚ
Anyway, it seems Iâve tracked the reason for animation not working. Second theory is viable. Stonehearth does not process matrices with underscore ( _ ) in the name. Donât use it.
Obviously itâs not yet working pefectly - I need to modify the coordinates, and the axes are messed up. But itâs polishing now. The concept works.
Thanks everyone!
Right now Iâm going to polish the animation, cut the unnecessary door functions and attempt to make a âframeworkâ for adding more animated containers, including those from other users 
Repo updated.
Another idea I have in mind is modifying door locking function (as soon as it gets implemented). I see locking as an object action triggered by the player. This way we can inherit it and make user-triggered animations (like opening windows and drawbridges). Maybe someone will do it
1 Like
Ah, thatâs exactly what i expected!(the animation)
Thatâs why the matrix size has to be equal(i guess position didnât matter that much)
Equal? I donât understand.
Remember my reply?
Your chest has two matrixes, but the size of the box(the matrix area) isnât same from one another
The bottom half has it a little short and the top part has it floating
The size seems to be optimized for the model, which it shouldnât, the matrix box has to be the same size
You lost me 
I do remember your reply, but I donât understand what the âsize of the boxâ is.
In my understanding, Iâve messed up the axes (namely, X axis, as we see the lid is rotating around the chestâs lock, not the hinges) and offsets.
Are you talking about the âfloatingâ lid? Itâs my first attempt at working with multiple matrices, so Iâm kinda blank slate here.
The red is the model, blue is the current matrix and green is the additions you beed to make
Does this help explain it?
1 Like
Was going to say ânoâ at first, then I began to grasp it. I think.
So there is a âbounding boxâ for the matrix (letâs call it that way). This âbounding boxâ defines the place where the matrix (model part) should be in relation to the whole model.
If I need the parts to fit together, I need to set the âbounding boxâ of every matrix to the size of the entire model.
Did I get it right?
Itâs unintuitive since in VoxelShop matrices have no visible borders.
It sounds like the same thing to me!
Try making it so and try animating and applying it to your test mod
Okay, the âfloating lidâ problem was due to incorrect scaling (I knew it would break something, didnât I?). Repo updated.
ToDo:
- Fix wrong X-axis direction
- Fix origin/boundary/collision (see screen)
- Fix matricesâ boundaries
I still donât know how to do the last one. Canât find how is it made in VoxelShop. There is an option âUse bounding box as matrixâ. Using it generates a bigger file, but the problem with incorrect rotation center persists.
@8BitCrab Youâve told you used VoxelShop with multiple matrix models. Did you stumble upon this problem as well?
âŚGotta get some sleepâŚ
well not this exact probelm⌠but in this case you need to have the matrixes the same size, but you also need to have the model in the correct orientation, which as far as i know isnât really possible with voxelshop⌠
1 Like
Okay, Iâm confused.
Here you can see 5 files:
chest_test.zip (6.0 KB)
- chest_voxelshop - a chest saved in Voxelshop with enabled option âUse bounding box as matrixâ. What this option does is sets the boundaries of every matrix to the boundary box of the whole model. I.e. what (as I understand it from Hyruleâs words) fixes the problem.
The same file in Qubicle Demo:
Fixed? You wish. - chest_qb_left_alpha - left-handed z axis, enabled visibility encoding
- chest_qb_left_noalpha - left-handed z axis, disabled visibility encoding
- chest_qb_right_alpha - right-handed z axis, enabled visibility encoding
- chest_qb_right_alpha - right-handed z axis, disabled visibility encoding
Strange things:
- None of these files are identical to the first one! Their hashes differ.
- None of these files actually fix the problem.
From what I see, visibility encoding makes no difference. Left-handed Z-axis makes the chest open from the lock size, not the hinges (already better).
But the center or rotation for the lid is still messed up and is situated⌠somewhere, but definitely not at the hinges as the skeleton dictates.
Unfortunately Qubicle trial is limited by 10 days, so my timeframe for experiments is limited.
I remember Hyrule saying about the model being centered on zero coordinate (while SH expects it not to be like this). Itâs what Iâm going to try next.
Youâll need to make a new skeleton and animation for it if you want to test if it works, if you already made one and itâs still the same i have no real fix
the model position shouldnât matter that much for what i understand, but i can always be wrong
1 Like
Now weâre talking.
Iâm being torn between despair and happiness.
Despair - because this one clearly showed another problem - Blender being Z-up while⌠somewhat⌠being Y-up.
Happiness - because (re)animation clearly fixed the issue with the wrong rotation point (if you rotate every chest part counter-clockwise 90 degrees, the animation becomes correct.
Workflow:
- Export from VoxelSHop with matrix bounding box option ON
- Export to obj with Qubicle
- Animate via Blender
Iâm going to try and fix the axes, while also trying to remove Qubicle from the equation.
It seems Iâve found the problem. Still canât understand how to solve it, but at least itâs something.
My workflow from second attempt:
- Export from VoxelShop with matrix bounding box option ON
- Export matrices to separate dae with VoxelShop
- Animate via Blender
And the problem with the wrong rotation point was reproduced.
While working in Blender I create helper bones (root) and re-set origins for the parts of the chest. However when I export to dae from VoxelShop, it asks me where to set the origin.
I donât know why, but when I import obj into Blender and edit origins, Blenderâs settings override the inherent obj ones.
However when I import dae into Blender and edit origins, resulting exported animation is still based on the old origins from dae, completely ignoring Blenderâs settings.
It may be some Blender-specific behavior, or it may be something in VoxelPirateâs export script, I donât know. I assumed the format of the import does not matter, as the model is still re-saved in Blenderâs own blend format later. Apparently, this is not the case.
Discourse points out that Iâm a very bad user. I donât let anyone else post in the thread.
Anyway.
This.
My new theory is this is the problem.
Blender uses Cartesian Z-up setting which cannot be changed. Qubicle, Maya, 3ds etc (and, I suppose, Stonehearth as well) use Y-up setting that, while not traditional geometry-wise, is traditional to modelling software (Magica being the exception - it also uses Z-up).
Some google research shows that in this case all the âtransitionalâ work should ideally be done by the export script. I guess I should let VoxelPirate know⌠as soon as I confirm my suspicions.
Additional tech mumbo-jumbo. Both Qubicle and Blender use Cartesian (right-hand) coordinate system (thatâs a relief). The only difference is the direction of Y-axis. In Blender X-Y plane is horisontal while Z is up. In Qubicle X-Z is horisontal while Y is up.
Assumption: while we see the basises in Qubicle and Blender differ, X axis is pointed at the same direction in both. That means, if we rotate around X axis, the basis matters not. If only we had the origin in (0,0,0), we would not even notice the difference.
But. Since my origin points are shifted from zero, the animation in SH âbreaksâ.
Time to put my theory to the test 
How about i directly teach you how the animating works?
I donât know if you ever animated creatures before, but iâm seeing that youâre at-least not so use to it
As far as I can tell, your models are correct in most ways, and blender shouldnât have any problems using and exporting it correctly
Maybe contact be via PM if you want me to help you directly
This Hearthling is very happy. Really. Trust me, Iâm an Psychologist Engineer.
How I made it.
- Solid model in Magica. Save it as qb.
- Save model parts for animation into obj from Magica (this is important!)
- Load qb from Magica into VoxelShop. Separate into layers (matrices). Save it again.
Important: do NOT export from VoxelShop for animation. - Load obj files into Blender. Set origins. Export skeleton.
- Note that every model part youâve just loaded is rotated 90 degrees around X axis. Rotate it back to 0. Yup, your model is a mess now. Didnât know FOSS comes with a bit of sacrifice? Now I do.
- Animate as usual and export animations.
Note that the skeleton can be exported at any time after setting origins since rotations are not saved. Animation, however, must be made and saved after model parts have been rotated to 0 degrees.
And now about the reasons why.
Rotation stuff, I suppose, takes root in Z-up right-hand basis in Blender. Both Qubicle and SH (I assume) use Y-up right-hand basis.
As for NOT being able to import to Blender from VoxelShop⌠Bad news. According to the graphics inside the program VoxelShop uses left-hand basis system. While we can get Y-up from Z-up with a simple rotation 90 degrees, getting a right-hand basis from a left-hand basis is not that easy. So my conclusion is VoxelShop currently should not be used in anything aside from light model edits (and especially not in animation).
Axes are still haunting me - I had no 3D exercises in years, so I hope pro animators will forgive me if Iâm talking gibberish. That being said,
1 Like
Some more little details.
- Head helper bone in construction/furniture models serves no purpose. It can be safely removed (or not added if youâre working from scratch).
Iâve suspected this, but now I can confirm it. While it is present in vanilla door animation, itâs useless. Root helper bone is (supposedly) still required, as itâs akin to the âmainâ bone of the whole model. - Iâve shifted rotation point to the border of the bounding box, 10 voxels from zero coordinate. This way it can be reused more easily. If youâre using bounding box 20x20x20, your model should be placed to the back of the bounding box in VoxelShop. You can center it afterwards properly with model_origin in your model_ghost.json. Animation coordinates shift with the model origin, so (hopefully) nothing will break.
- A nice trick in Blender: you can save all of your animations in a single *.blend file, one after another. All you need to do is set âstartâ and âendâ frames properly before exporting into *.json. My *.blend file holds three keyframes, from which Iâve made three animations (open 1>2; close 2>3; looped closed 1).
Essentially youâll need:
- Blender
- MagicaVoxel
- VoxelShop for working with layers
Qubicle saves you a lot of time and is very handy, but not necessary in a strict sense.
ToDo list:
- Change to custom lua (had troubles with this, will try again later). Strip it of all door functions we donât need.
- Polish the animation. I want it to be more fancy.
- Make model prettier.
- âŚ
- Profit!
PS. I suppose Iâll create a separate topic for containers as soon as I get it working as intended.
1 Like