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?
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
- 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…
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
- 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
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.
- 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.
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
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,
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:
- VoxelShop for working with layers
Qubicle saves you a lot of time and is very handy, but not necessary in a strict sense.
- 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.
PS. I suppose I’ll create a separate topic for containers as soon as I get it working as intended.
Hey guys, sorry for the late reply. Not a lot of time on my hands.
Can someone summarize the issue(s) described here relevant to VoxelShop and how we could improve the program?
If you have specific issues or improvements please post here:
VoxelShop is now open source and I’m trying to handle everything through github now.
Thanks for the reply! Also, congratulations for opensourcing your project! I can see now it’s made in Idea If only I had enough time…
[quote=“MelOzone, post:59, topic:21672”]
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).[/quote]
I may be wrong as my theoretical knowledge about models is minimal… But I believe this is the culprit. In a few worlds, I believe what happens is this: because of the difference in basises the coordinates of the origin points for matrices are messed up (wrong axes). This leads to animation breaking, as the origin points made in Blender for the model exported from VoxelShop are also located incorrectly when viewing from Stonehearth.
I assume the option to convert the basis (and choose Y-up or Z-up setting) when exporting can fix the issue.
And if we’re talking about overall improvement, adding export to obj with each layer saved as a separate object inside the same file would be great
Could you let me know if that works? I’d be very interested in helping to resolve any issues with this, but I would need more insight into the pipeline!
Done and released. Let me know how that works for ya!
Still have no idea about that, haven’t tried animating from dae. But I don’t need the trick I mentioned earlier any more:
“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.”
Since I changed nothing in my pipeline but VoxelShop (installed the last version), I suppose something changed in exporting.