Fix units when importing

[freezy]

Units seem to be a pain point with Visual Pinball. We assumed that a VP unit corresponds to one millimeter, but that's not the case. In VP, 50 units correspond to the ball diameter. A ball being 1 1/16 inch, we get the following relations:

• 50 VP unit = 1.0625"
• 1 VP unit = 0.02125" = 0.53975mm

or

• 1" = 47.05882352941176 VP units
• 1mm = 1.852709587772117 VP units

The main issue with VP having a fantasy unit is that imported meshes from other modeling software with correct dimensions end up with incorrect dimensions.

There are two ways of approaching this:

1. We decide a real-world unit for meshes in VPE and scale generated meshes to that unit
2. We keep the VP unit in VPE and scale imported meshes

I don't see 1. as feasible. It basically means converting everything back and fourth all the time. When creating new meshes, when updating existing meshes, when importing the .vpx, when exporting the .vpx, when launching a game in order to create the colliders, etc etc.

I'm not sure if 2. is possible in an automated way. I haven't played around with import from external programs, and there needs to be additional logic as well, e.g. authoring components must be conserved when reloading, game items must be removed from the structure when removed from an updated mesh, etc. So once we dig into this, we should choose an approach.

Glossary

Generated Mesh - a mesh that gets generated by VPE based on the game item's properties. All meshes but primitives are generated. Imported Mesh - a mesh imported from a third-party modeling software. In VPX, they are all primitives, but in VPE you can replace any generated mesh by an imported mesh.

[ecurtz]

Option 1 makes much more sense to me. VPX is the thing with a totally non-standard unit so importing / exporting VPX data is where the conversion should happen. Real-world issues about the effort involved might mean it isn't worth doing it that way, but it's certainly the "correct" solution IMO. Aren't the VPE positions already being transformed because the axes are different?

[freezy]

We currently leave everything and translate the parent.

The problem with doing it the "right" way is that we need to modify the physics behavior, which currently set to VPX's scale.

[borgdog]

I'm with ecurtz on moving to real world units, and have everything in VPE be in inches since that's how most real pinball has been made would make the most sense to me. personally, and I think I have expressed this in the past, there should be no need to export to VPX. that really only leaves when importing from vpx as a translate time. i'm guessing if you didn't have to worry about making it backwards compatible, or having the ability to export backwards, there would be different choices and a lot less work to do, but you are likely way beyond that point.

I see your point on the physics however, and I don't know that the physics is easily scalable (go ahead and call me jon snow, or sgt. schultz). how are things like nfozzy and roth's drop targets and such going to be incorporated? I thought at one time the idea was to go to unity physics?

[Roland09]

1 Unity unit is 1 meter. Unity doesn't use inches.

[borgdog]

If unity is native in meters, I'm fine with that, I can work equally fine in metric. Anything but VP units.

[a-bord]

I'm with borgdog and ecurtz. Doesn't matter imperial or metric (although an import in imperial/convert to metric option would be welcome), but VP units are garbage. I think keeping VP units just because old tables use them is too backward looking. Why handicap this project right out of the gate?

[freezy]

We ended up at everything visible to the user in world units. Also, the asset lib will provide assets in world units, and the shipped meshes are in world units as well. During runtime, the colliders are scaled to VPX units and the physics engine still runs in VPX units. This keeps the heuristics intact but allows the users modeling everything in real world units.