# Help needed with collision region definition

Guys, I need some help!

I’m trying to add some collision region to the boat model I’m using for the lakeside city.

Before all, yes I read the very good thread about references by @Tuhalu but I must have some mental deficiencies because after many, many, many tries, I’m unable to get a single collision shape in correct shape and position and I sometimes get some really unexpected results…

So I need some help to get at least one of the needed regions but please I need some precise explanations.

First here is the model in game with no collision region at all. The reference is what I get from export from MagicaVoxel:

You can see the boast is floating in the air, that’s normal (it’s to get the boat at water level).

Now, in theory I need several regions to get a pretty correct collision shape, something like this:

But let’s focus on one, let’s sat the blue one. Let’s say it is at 2 from the ground and is 9x3x1 and let’s say all the definitions (`region_origin` and `model_origin`) are `{ "x": 0, "y": 0, "z": 0 }`.

What would be the definition for this region?

Subsidiary question, in the ghost.json, `region_origin` and `model_origin` are enclosed into “mob”. What is this “mob”?

1 Like

I think you’ll have problems down the line if your model origin is not near the centre of the boat.

That aside, I’m going to have to guess the distance from the origin to the nearest corner of the boat. I think it’s -1 in x, 1 in y, -2 in z in world coordinate space. Given that, it looks like the blue area would be defined as:

``````   "region": [
{
"min" : { "x" : -4, "y" : 1, "z" : -11 },
"max" : { "x" : -1, "y" : 2, "z" : -2 }
}
]
``````

Does that help?

Hmmm you mean the origin we can see on pict 1, right? How can I change that? `model_origin`?

Well… nope but at least I have one of this odd result! Adding your region make the boat to touch the ground. Cannot imagine why… On the right without your region, on the left with your region:

I fear I will end in and asylum…

I’m guessing the reason the item fell is because its collision region is not in contact with the ground, so its falling until the collision region hits the ground. Since you actually want it floating in the water, it’s probably not a big deal.

It’s best if you can set the origin of your object in your modelling program. I just played around a bit with MagicaVoxel and it looks like it has no way to do that, which is a problem! I also tried exporting from MagicaVoxel to a qb file and opening it up in Qubicle. It looks like there are some artifacts that shouldn’t be there, the entire object is rotated and the model origin is off from where you’d expect it to be.

Maybe have a look at StoneVox? It’s still possible to get Qubicle 1.6 Stonehearth Edition (one of the questions at bottom of page has a link) too.

See, that’s the kind of logic I cannot understand. Why the model without collision would stay as expected and why the other would fall?? Is the collision bypassing the matrix of the model? I would expected these things were independent…

I have installed StoneVox but need to dig because last time I opened it, I was unable to select/move anything!
And Quibicle is a no go for me (for many reasons) unless there is really no other solution…

Anyway I even cannot imagine why changing the model origin would miraculously make the whole process crystal clear… I just don’t get it… My last neurone is probably dead…

That said, tx a bunch for the time, I’ll try again on my side, need to understand this mess!!

Ok, really I’m limited! I had to think in 2D else no way… BUT this way, finally I have the correct region:

1 Like

I assume you meant on the right with my region added (since that’s the one that’s fallen to the ground in the image)?

As far as why you want the model origin to be in the center of the model (or as near as possible)… If the origin is outside the model, when the player rotates the model the entire model will rotate AND the centre of the object will move too. The following (rough) diagram illustrates this for a rectangle in position A that is rotated and winds up in position B (the arrow shows the movement of one corner).

If the model_origin is set to the middle of the object, then when you rotate it, the centre of the model will not move.

The model_origin tag in your ghost.json file is meant to be an offset for very small tweaks in the position though (half a voxel usually, so that items with odd-widths centre on a tile correctly). It’s safe for now to use larger numbers to move your model origin to the correct place, but at some point in the future, that may no longer be true.

Yes sorry, on the right… (that’s what happens when I get nervous! )

Concerning the rotation, I saw the collision region do not rotate as expected with the model. I will have to investigate this too. But first, what I really wonder about is why there is a difference of behavior (boat sunk or not) between the following change in the collision region definition. SO two boats, boat A on the left and boat B on the right. Boat A float (“normally”) while boat B is down.

Code for boat A:

``````{
"mixins" : "file(boat_ghost.json)",
"components": {
"stonehearth:entity_forms" : {
"iconic_form" : "file(boat_iconic.json)",
"ghost_form" : "file(boat_ghost.json)",
"placeable_on_walls" : true
},

"render_info" : {
"scale" : 0.16
},

"region_collision_shape": {
"region": [
{
"min" : { "x" : -4, "y" : 1, "z" : 11 },
"max" : { "x" : -0.5, "y" : 1.9, "z" : 0 }
}
]
}
}
}
``````

Code for boat B:

``````{
"mixins" : "file(boat_ghost.json)",
"components": {
"stonehearth:entity_forms" : {
"iconic_form" : "file(boat_iconic.json)",
"ghost_form" : "file(boat_ghost.json)",
"placeable_on_walls" : true
},

"render_info" : {
"scale" : 0.16
},

"region_collision_shape": {
"region": [
{
"min" : { "x" : -4, "y" : 1, "z" : 11 },
"max" : { "x" : -0.5, "y" : 1.9, "z" : 0 }
},
{
"min" : { "x" : -4, "y" : 1.9, "z" : 11 },
"max" : { "x" : -3.5, "y" : 2.9 , "z" : 0 }
},
{
"min" : { "x" : -1, "y" : 1.9, "z" : 11 },
"max" : { "x" : -0.5, "y" : 2.9 , "z" : 0 }
},
{
"min" : { "x" : -1, "y" : 1.9, "z" : 2.05 },
"max" : { "x" : -3.5, "y" : 2.9 , "z" : 0 }
},
{
"min" : { "x" : -1, "y" : 1.9, "z" : 6.05 },
"max" : { "x" : -3.5, "y" : 2.9 , "z" : 4.95 }
},
{
"min" : { "x" : -1, "y" : 1.9, "z" : 8.95 },
"max" : { "x" : -3.5, "y" : 2.9 , "z" : 11 }
}
]
}
}
}
``````

As I haven’t changed anything else, the response should be here but I cannot see it. Any idea?

How did you place each item into the world? If not exactly the same for both, then maybe there is a difference in the method of placement.

Drop tool (item stamper), same method…

And it’s easy, remove the 5 last regions from the code and bingo the boat is floating again… too odd…

That is wierd.

BTW, for the collision region, don’t bother using decimal values. Although the debug_keys outline looks like it makes a difference it actually doesn’t. Any voxel in the world that has any tiny bit of collision region in it cannot be entered by hearthlings, no banners can be placed in it and are considered not placeable if the collision region of an object you wish to place overlaps with it.

Forget, there is a bug somewhere: while I was testing some collision with crates, one boat (the selected one) was dropped correctly…

@sdee, perhaps someone in the team could tell us what’s the problem?

Yep, I just saw with the crates it wasn’t that simple! So in fact, one must think very well his very first sculpting, else it can be a mess. Anyway, what is the minimal useful value? 0.5?

Ideally you shouldn’t use decimal values at all (in your collision region definition). You use the region_origin to place the origin of the collision region on the corner of a tile and then work from that. Then you can be sure your collision region matches up with actual voxels in the world.

Mmhh you mean voxels from the world, not voxels from objects, right? I mean without talking about scaling, the objects’ voxels (hearthlings included) are at 1/10 versus the world’s voxels, so if I use the world voxel as unit, I lose a lot of possibilities like in the present example, dropping a crate inside a boat! Is that what we really want? Grrrr I would say no!

By curiosity I had a look to the door example. I wasn’t expecting this:

How the hell hearthlings do to pass through??? And why is this unique collision region this way???

I don’t know really. The door is a bad example, because it needs to animate and other things. I suspect the positioning of those boxes has something to do with why they don’t always work correctly (fail to open or open too soon).

Well, if that’s what you want, you may have to do some work to make sure your boat matches the world voxels OK.

The collision region doesn’t have to fit your boats exact shape though. Some things are OK to fudge. It won’t matter too much if the crate clips through the boat a tiny bit at the bottom, because nobody can see the bottom of the crate anyway.

Yes of course but meanwhile I’m at understanding what is possible or not, I try to match the idea on how the world should work based on simple observation. Now if underneath mecanisms are trolling me, specially with bugs it’s a bit normal to turn crazy! Anyway, like for the water there is for sure a right way to do it. And I’ll find it! (… or not? )

For now I’m wondering why the collision shape do not turn like the model. I get some weird offsets… Another oddity? Digging right now…

I’m not gonna lie, I spent many hours figuring out a method that kind of works for me most times

1 Like

It’s broken. Has been for a very long time.

Another example is when the goblin camp spawns look at the two identical tents. One of them is rotated and the collision and destination regions are completely wrong on the one that’s rotated.

2 Likes

Omg! Shouldn’t this kind of things been fixed before adding recipes and others eye candy stuff? Else how are we supposed to mod?? @sdee (or any dev btw!) any thoughts?