Help needed with collision region definition

Modding
21

as you’ve already discovered, collision boxes are a big headache and aren’t exactly the easiest thing to wrap your head around, and @Albert (i think its Albert…) doesn’t exactly love doing it either if you know what i mean…

22

I can’t speak to the floating issue or non-standard scaling, since I haven’t tried either yet. One thing I discovered after my questions prompted the thread linked at the top of this one is that the “model origin in center of model” recommendation is not particularly needed. What works for me is placing the object in Qubicle relative to the origin such that the object is correctly oriented as if the origin were the center of a world square. That way I don’t need to specify the model origin in the json file and stonehearth will supply the default of 0,0,0. I then always use region origin of 0.5, 0, 0.5 and work from there.

As Tuhalu stated above the issue of getting region origin on a world grid corner is key. There are many model origin / region origin / region collision shape combos that will look OK in game when using F11 to look at the region, but if region origin isn’t on a corner items that look like they should fit snugly next to one another just won’t. The approach I described above forces this, but the way I verify my regions in game is to click F11, then click on a stockpile so the object, origin, and shape are shown along with the world grid.

1 Like
23

Even though this may not be of help for you; I might as well add this.

There is a rather easy way of defining a model’s collision shape; by using region_from_model, like so:

      "region_collision_shape":
      {
         "region_from_model":
         {
            "model" : "MODEL_FILEPATH"
         }
      }

But(!), there is one caveat: the model must be of scale 1; otherwise the collision shape will be either too big or too small.

3 Likes
24

@Drotten, interesting! Quite useful for any 1:1 model, tx for the trick!

2 Likes
25

Still no comment from someone @Radiant? At least it would be nice to know if the issues spotted here would be investigated soon or if they belong to the very low level of priority list.

26

i guess i’ll page @sdee @yshan @Albert for you then.

[quote=“Beatrice, post:25, topic:15777”]
At least it would be nice to know if the issues spotted here would be investigated soon or if they belong to the very low level of priority list.
[/quote]TR knows about this problem, though i’m not sure how high of a priority it is, but it definitely has been present for quite awhile now.

2 Likes
27

Depending on whether you’re doing any post-processing with the collision shape, you can use this code that I came up with:

local rcs = entity:get_component('region_collision_shape')
local region = rcs:get_region():get()
local location = radiant.entities.get_world_grid_location(entity)
local facing = math.floor(radiant.entities.get_facing(entity) + 0.5)
region = region:translated(Point3(-0.5,0,-0.5))
region = region:rotated(facing)
region = region:translated(Point3(0.5,0,0.5))
region = region:translated(location)

I use this (and other code removed for clarity) when calculating possible connections between machines. However, if you need the collision shape to “just work” you can either make your models symmetric or at a 1:1 scale and use what @Drotten mentioned above.

28

Ok, a few notes that might help:

  1. Objects will fall until their collision region (or their origin if no region_collision_shape component is defined) intersects something solid.

  2. You can turn off gravity for an object by calling:

    item:add_component(‘mob’):set_ignore_gravity(false)

  3. The collision shape for the door won’t show accurately when it’s not mounted. There is a (-0.5, 0, -0.5) offset for terrain aligned items like buildings and boulders. For example, a hearthling placed at (0, 0, 0) has her origin at (0, 0, 0) as expected. A small boulder placed at (0, 0, 0) has world bounds (-0.5, 0, -0.5) - (0.5, 1, 0.5). The collision region for mounted items may also have other adjustments too, that we shouldn’t get into here.

  4. Collision regions can be defined to quarter (0.25) voxel resolution in the x and z dimensions. Defining less than unit (1) voxel resolution in the y dimension probably won’t have an effect.

  5. Collision regions should rotate correctly for placed items. Note the difference between the collision regions for a dining table and large crate. Both are solid 2x2 objects, but the large crate is terrain aligned and rotates differently. Collision regions on moving objects might not be well defined yet.

  6. We will build tools to help out with this stuff. It’s a pain in the ass, especially with asymmetric mounted items on rotated templates.

Hope this helps!

4 Likes
29

indeed it does (even though i didnt ask the question). thanks for the response @Albert :smile:

30

@chessmaster42, tx for the tips even if this is much more advanced than what I have done so far. I guess I will have to dig quite a lot to understand and test at such level!

@Albert, many tx for these details.

  1. make sense now (even if I saw once (pict above) an oddity with “levitating” boat with collision defined),
  2. could be useful but now I’m wondering how you place the item on the vertical axis,
  3. will have a closer look
  4. good to know
  5. Need to dig this with your table/crate example because for now the boat is a mess!
  6. Oh yeah, would be reaaally cool!
31

To place an item above the ground, try this:

item:add_component('mob'):set_ignore_gravity(false)
radiant.terrain.place_entity_at_exact_location(item, location)
3 Likes