3D snapping methods and fixedjoints, uses and performance comparisons

Unity Engine
, , , , , ,
1

Working on a project where I need to snap some cubes (and partial cubes of the same size that are part of other models) together, and lock them into a fixed position that they cannot escape by any means save for destruction. I need them to not slide around, so no extra physics calculations during runtime, and said destruction needs to chain onto whichever sub-parts of the parent object are no longer connected to the main mass/remaining HP of the parent. I also need to have HP values of adjacent blocks able to be affected in a radius of the first block, but only if connected directly to a face, and a way to control how much of the total damage value gets applied where.

I am still in pre-prototyping due to just focusing on research and not really knowing how everything works (scripting-wise) just yet. have some rough models to test but the full testing environment isn’t set up yet.

2

You told us what you need, but is there any question you wanted to ask? :wink:

Then you can’t use physics. For both reasons. The fixed joint will still allow objects to move relative to each other, more so the greater the forces that act upon either or both. And yes, this will be calculated at runtime.

What you’re looking for is a grid system.

1 Like
3

That is a massive stack of very precise requirements.

You almost certainly won’t get what you want using physics.

As CodeSmile posted, you want some kind of grid system.

Beyond that, you will build this up in layers, not all at once. Here’s some great steps to try, in this order:

  • get a cube dragging under finger control
  • make that cube align to your grid of positions as you drag it
  • make that cube instantly snap to adjacent cubes that it comes in contact with, and now moving any of them moves all of them.
  • refine any rules that allow / deny the snap-to-block to happen, giving game feedback

This are dependent steps. Do not move onto any step until the previous step is perfect.

Each part may have a large number of sub-parts but you will need to do them to decide if they apply to your game design.

Hare is how iterative game development works:

Imphenzia: How Did I Learn To Make Games:

1 Like
4

I’m coding this for desktop, how does this “finger control” thing work (does it work with mouse inputs)?

5

There are various implicit and explicit mappings between mouse vs touch but they come in through completely different sources in the old Input manager. See the docs for the latest promises.

I did not want to write dual parallel code to deal with touch and mouse so I wrote my own wrapper class called Microtouch that wraps the mouse AND the touches and treats them all as the same source of touches.

Obviously on desktop you can only have one finger, the mouse.

Microtouch is available in my Proximity Buttons package. It’s used everywhere in there if you need examples. It seamlessly works on desktop or phone or tablet.

proximity_buttons is presently hosted at these locations:

https://bitbucket.org/kurtdekker/proximity_buttons