freezy / visualpinball.engine Goto Github PK
View Code? Open in Web Editor NEW:video_game: Visual Pinball Engine for Unity
Home Page: https://docs.visualpinball.org
License: GNU General Public License v3.0
:video_game: Visual Pinball Engine for Unity
Home Page: https://docs.visualpinball.org
License: GNU General Public License v3.0
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.
Drop target movements aren't part of the physics calculations, they are pre-defined animations.
We'll need:
We have a stack overflow error when testing with large files. Haven't yet tested in Unity, only with the test runner. No stacktrace.
Just movement physics, no collision yet.
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.
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.
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.
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.
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.
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.
Spinners have their own hit objects (actually, they have a few, two circles for the bracket and a special one for the plate).
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:
Architecture will follow.
See ravarcade#3.
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.
They have patterns and stuff :)
Probably also depend on #115.
These elements just use a bunch of generic colliders, so they should be relatively quick to set up:
Bumper movements aren't part of the physics calculations, they are pre-defined animations.
That would be bad.
Many playfield elements use generic colliders. These are:
Just movement physics, no collision yet.
Plungers have their own hit objects.
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 Behavior
s which I'll rename to Authoring
soon).
This has a few consequences:
TableBehavior
are exported, and if possible refuse to add those components outside of that tree.GameObjects
and then adds the relevant authoring component on it - or maybe we can create an editor toolbox that does those steps at once.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.
This issue is to track reaching parity with the VPX editor.
Remaining issues:
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.
Trigger movements aren't part of the physics calculations, they are pre-defined animations.
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()
Just movement physics, no collision yet.
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.
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.
Looks like we need to resize the structured storage when saving. Probably unrelated, I'm still clueless what's going on.
Currently, the balls roll off the playfield if there are no walls or other colliders keeping in on it.
When running the game in Unity, we should have an overlay that allows creating and draining balls, and probably some more stuff.
Just movement physics, no collision yet.
We would like to have some sort of UI during gameplay that:
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.
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.
Flippers have their own hit objects.
Currently prints a warning.
VPE can write .vpx
files, but currently there is no way from the editor to actually do that.
A .vpx
file consist of:
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:
GameObject
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).
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:
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?
Gates have their own hit objects.
Collections need an API, need to be iterable, and they must be properly handled during event propagation (when EventData.GroupEvent
is set).
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.
From a freshly opened project, with VPE package installed. This table is imported, and immediately exported.
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.
Balls gets spawned in-game, but we still need to setup the data layer for them. All in all, the physics-related tasks are:
Most game items emit events during gameplay. Those should be handled on the main thread using C# events.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.