Trigger movements aren't part of the physics calculations, they are pre-defined animations.

We would like to have some sort of UI during gameplay that:

1. Displays interesting stats
2. Allows interaction with the game

It should be possible to exclude this from production builds to avoid unnecessary overhead, so it's probably best to have this shipped as a separated Unity package. @ravarcade is already working on a ImgGUI implementation.

For point 1), the debug UI package needs to plug itself into somewhere in order to receive the necessary data for the stats. For point 2), it has the entire VPE API at its disposal and doesn't need any plugging.

When running the game in Unity, we should have an overlay that allows creating and draining balls, and probably some more stuff.

VPX shows in which direction a gate is oriented.

One way:

Two way:

This would be useful to see in the Unity's Scene View as well.

Forgot about that, those are completely ignored for now. Tags M3AY and M3AX. A table containing those is AC-DC_Premium-1.4.

Need to read more into vertex animation and how this is done in Unity.

Looks like we need to resize the structured storage when saving. Probably unrelated, I'm still clueless what's going on.

Looking at VPX's code, this happens when the Visible attribute of a rubber is changed during gameplay.

Looks like there's an issue when writing the SLMA attribute.

Surfaces, rubbers and walls are based on drag points, which are control points of a Catmull-Rom spline. The goal is to visually move the drag points, similar to the Visual Pinball editor:

Unity allows customizing the scene view. The first step is to display the drag points as handles, and then make them movable in the editor. On each movement, the drag point data should be updated, and the mesh regenerated (see RebuildMeshes()), so users see the final mesh while dragging the control points.

There is a short tutorial here, API reference is here.

If you actually want to draw the spline like in the tutorial (which would be awesome), here is a snippet that converts Catmull parameters into Bézier, so you can directly use DrawBezier(). Or you can draw them as lines.

Lastly, the drag point parameters should editable in the inspector panel as well. This is somewhat necessary, because a drag point has not only a position, but a few other parameters, such as IsSlingshot and IsSmooth. I'd say the best UI would be to not render any drag point data in the inspector at all if no drag point is selected, and only the selected drag point if selected.

Just movement physics, no collision yet.

Just movement physics, no collision yet.

Many playfield elements use generic colliders. These are:

• Plane
• LineZ
• LineSeg
• Triangle
• 3DPoly
• Circle
• Point

Just movement physics, no collision yet.

Just movement physics, no collision yet.

This issue is to track reaching parity with the VPX editor.
Remaining issues:

• Light importer not parenting unity light objects to VP item
• Need to implement light inspector and behavior edit support
• All Items: Visibility toggles
• All Items: Object type drop downs, changing meshes etc
• All Items with children: Visibility toggles for each child (e.g. bumper skirt)
• Bumper needs rotation gizmo
• Drag point support - this would cover ramps, rubbers, surfaces (#75)
• 3d rotation gizmo doesn't appear to be working on the correct axis in all cases
• -"Toolbox" window for creating new items in the table (own ticket, #76)-

We'll need:

• Unit tests executed on push
• Coverage reports
• Automatic build artifacts
• Deps refreshed weekly with Renovate

Gates have their own hit objects.

Shouldn't be too much work, but nearly every game object has an event proxy object it uses to trigger events in the physics loop.

Collections need an API, need to be iterable, and they must be properly handled during event propagation (when EventData.GroupEvent is set).

VPE can write .vpx files, but currently there is no way from the editor to actually do that.

A .vpx file consist of:

• Table Info (pre-defined and custom key/values)
• Table Data
• Other game items
• Collections
• Images
• Sounds
• Fonts
• Some meta, like hash and file format version

If we want to read and write data in a consistent way, we need Unity to serialize it so what we want to write is also available runtime and doesn't get lost during reloads.

That means our data classes need to be all [Serializable]. Before writing, we would create a new Table object based on the serialized data, and then use its API to write the .vpx. So what needs to be done:

• Store table info somewhere on a GameObject
• Create a component per game item (see flippers and table, where it's somewhat implemented)
• Store invisible components (like timers) somewhere
• Somehow store collections
• Find a way to pull the texture assets back as VPX textures
• Deal with sounds
• Deal with fonts (add read and write support already)

To be clear, this means that we create a new .vpx from scratch every time we export (as opposed to taking an existing file and only patching the differences).

These elements just use a bunch of generic colliders, so they should be relatively quick to set up:

• Hit target
• Primitive
• Ramp
• Rubber
• Surface
• Table
• Trigger
• Kicker

I hope to eliminate timers as much as possible and replace them with events and animations that are easier to use and more performant.

However, this will happen incrementally, so we need to handle them like VPX does first. The APIs already have a time event, so we need to hook it into a system that triggers them correctly.

Currently prints a warning.

While this repository ships with VPX physics, we would like to have a way of replacing the physics engine at runtime. The main idea that we can a) easily test new engines without having to branch the code all the time and b) finally even deliver multiple engines for the table authors to choose from.

@ravarcade already started on a Bullet Physics implementation, so this has become somewhat relevant now.

Other physics engines aren't necessarily part of the same repo, but can be added as a Unity package and will be discovered by VPE when installed. Ideally, this would work like that:

1. A new Unity package containing a physics engine is added to the Unity project
2. The editor somehow allows to select the desired engine (preferably on per-table basis, somewhere in the table inspector)
3. If the (default) VPX engine is chosen, the other engine(s) should be invisible (not called at all in the game loop)
4. If another engine is chosen, the VPX engine should be completely disabled (no systems active)
5. Each engine can be configured somehow, by the table (i.e. at runtime)
6. The overhead should be minimal

Architecture will follow.
See ravarcade#3.

We have a stack overflow error when testing with large files. Haven't yet tested in Unity, only with the test runner. No stacktrace.

It's a bit unclear to me how we'll handle materials, so the main goal of this issue is to open the discussion.

A material in VPX basically defines which shader to use and how to use it. Textures aren't part of the material, they are assigned to the object individually, however, there are physics properties as well.

Now, in order to fully benefit from Unity's renderer, we need to use Unity's shaders, which are obviously a very different beast.

So the first question would be: If authors use Unity just for authoring with the goal of using the VPX player, do we provide a way to deal with materials? There is no way of providing an accurate visualization, so what we could do is the following:

• When a Unity material is created or edited, create or update a VPX material as well. There are a bunch of parameters such as colors or shininess than can be converted in order achieve a similar look.
• Provide a VPX materials editor clone where an author can fine-tune the VPX materials. Knowing those won't affect Unity's shaders.
• The VPX materials should be "lockable", i.e. they then won't be updated when corresponding Unity material updates.

In short, authors should be able to apply Unity materials to their meshes without any restrictions, but since we still want to be able to play the produced .vpx file in VPX, they should be converted and editable.

How we internally handle all that, which of Unity's render pipelines we support, how we write the Unity materials to the .vpx file etc will be part of another issue.

Thoughts?

Right now, the editor can load and save VPX files, but new elements will be ignored. So instead of looping through the imported data structure, we should loop through the game objects and pull the data from authoring components (the Behaviors which I'll rename to Authoring soon).

This has a few consequences:

• We should make sure only objects under the corresponding TableBehavior are exported, and if possible refuse to add those components outside of that tree.
• The idea is that the author adds empty GameObjects and then adds the relevant authoring component on it - or maybe we can create an editor toolbox that does those steps at once.
• When an authoring component is added, the relevant meshes should be created as well. It's desirable that children of a component cannot be moved around (e.g. the rubber and base children of a flipper)

Collections are read and written, but we can't edit them.

Basically we'd need a UI to manage them, context menus to add/remove elements to them, etc etc.

Right now we have two versions of the table importer, which is highly confusing and not maintainable. Let's refactor this to have only one.

That would be bad.

We currently can't instantiate blob pointers with an arbitrary size. I've created a thread here. Until this is solved, Poly3DCollider don't work.

There are a few material attributes that are incorrectly written, mainly due to multiple attributes being packed into a byte:

Original:

Written:

There's a bunch of metadata we can write to a VPX file:

I'm sure we can do a nice UI for that.

Also, a default Transform handle is shown in SceneView and you can freely move any items, even locked.

Gizmos enabled :

Gizmos disabled :

They have patterns and stuff :)

Probably also depend on #115.

This is VP's UI:

Balls gets spawned in-game, but we still need to setup the data layer for them. All in all, the physics-related tasks are:

• Create data layer
• Create main object
• Create a mesh generator
• Implement rigid body physics
• Implement hit object

Flippers have their own hit objects.

Spinners have their own hit objects (actually, they have a few, two circles for the bracket and a special one for the plate).

Patch file detection

Currently the patch file is determined by meta tags. This isn't fine granular enough, e. g. the Tom & Jerry table has the wrong meta tags:

[MetaMatch(TableName = "Beach Bums (HH Mod - Gottlieb 1986)", AuthorName = "Retro Bash")]

However the table's name is TomandJerry which can in addition to the MetaMatch be used to get the proper patch file.

Access to Primitive data

There needs to be a re-parenting of gameobjects. In order for that to work, one also needs to apply the transform of the Primitive. That data isn't available in the patcher, it should be handed over in addition to the gameobject.

Patching children

The Tom & Jerry table has a gameobject Ramp20 which has children LeftWall, RightWall, etc. The way it is now one has to set NameMatch to Ramp20 and the code in the patching methoc would be applied to all the children, not just a selected one.

This should be made finer granular, e. g. Ramp20/LeftWall. Of course only optionally. Ramp20 should still select all children.

Disable patching during Import

I added a parameter applyPatch to the importer, but it's unclear where to put that if-code in order to not apply a patch. For one because at certain places the importer uses local methods, for the other it uses static methods.

Graphics Pipeline

Depending on the graphics pipeline one has to set different shader properties. Should we distinguish by creating a dedicated file for the graphics pipeline? Or a common interface which allows to set e. g. a material to be double sided. In HDRP this might look like this:

[NameMatch("Primitive66")] // jerry at plunger
public void SetDoubleSided(GameObject gameObject)
{
	var unityMat = gameObject.GetComponent<Renderer>().sharedMaterial;

	unityMat.EnableKeyword("_DOUBLESIDED_ON");
	unityMat.EnableKeyword("_NORMALMAP_TANGENT_SPACE");

	unityMat.SetInt("_DoubleSidedEnable", 1);
	unityMat.SetInt("_DoubleSidedNormalMode", 1);

	unityMat.SetInt("_CullMode", 0);
	unityMat.SetInt("_CullModeForward", 0);
}

Which is way too much code to be duplicated per patch file and hence a common HDRP class with SetDoubleSided(...) might be the better solution.

We should decide in advance, this will have far reaching consequences.

A bare-minimum physics loop that doesn't do anything.

This includes the quad/octree implementation, the mover and hitobject interfaces, and probably a lot more.

It also includes making Unity execute it at 1000fps when running the game.

I have just downloaded Unity 2020.1.of1 and attempted to add Package.json with Unities Package manager.
Script Error Report
! Cannot perform upm operation. One or more dependencies could not be added to the local file.
! Error adding package. UnityEditor.EditorApplication_CallupdateFunctions()

Bumper movements aren't part of the physics calculations, they are pre-defined animations.

Drop target movements aren't part of the physics calculations, they are pre-defined animations.

Currently the playfield's material is cut-out, meaning that if there's no texture, it's opaque. This results in the kickers being virtually invisible. Here's a textureless playfield in Visual Pinball:

...which renders like that in Unity:

In most cases this shouldn't matter, since playfields are textured, and the kicker will be transparent.

A possible solution to implement the same behavior as Visual Pinball is to cut out the geometry of the playfield with a library like triangle.net.

Plungers have their own hit objects.

We have a ton of importer classes (VpxImportEngine, VpxImportWizard, VpxMenuImporter, VpxImporter), each doing something which isn't entirely clear to me. It probably needs refactoring, otherwise I'll close this issue.

VPX has 11 layers where elements can be rapidly hidden and shown in order to keep the view port in order. VPX 10.7 comes with an arbitrary number of layers, which can also be named, and displays a tree structure of all elements.

The tree structure we already have in the hierarchy, but handling layers in Unity would be nice too. AFAIK there isn't such a thing, so we could implement our own with a custom editor.

Example_Table.zip

From a freshly opened project, with VPE package installed. This table is imported, and immediately exported.

Most game items emit events during gameplay. Those should be handled on the main thread using C# events.

Currently, the balls roll off the playfield if there are no walls or other colliders keeping in on it.