Refactor Scene Setup#302
Merged
Merged
Conversation
freezy
added
unity
Codecov Report
@@ Coverage Diff @@
## master #302 +/- ##
===========================================
+ Coverage 69.68% 83.62% +13.94%
===========================================
Files 136 136
Lines 6646 7444 +798
Branches 859 0 -859
===========================================
+ Hits 4631 6225 +1594
+ Misses 1785 1219 -566
+ Partials 230 0 -230
Continue to review full report at Codecov.
|
This was referenced Jul 22, 2021
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is still WIP, but I'll write some documentation here so people can validate before I go into too deeply (although the ground work is already done).
Before this PR, importing a VPX file would write the entire table data into the scene. This approach had several issues:
Tableobject, hacks were necessary to update this object when stuff in the scene was added or removed. It actually didn't really work at all.Table Container
To solve the synchronization issue, we've split the
Tableclass, which was the root object of all the data, into two classes:Tablenow only holds the "table data", which are the global parameters of the table, but no game items, textures, or anything else.TableContaineris an abstract class that provides access to the rest of the data, which are textures, materials, sounds, game items, collections, global table props, custom info tags, and mappings.Now, when the table file is read, we get a instance of
FileTableContainer, a subclass ofTableContainer. That's how we get access to all the data in the file. That data is then converted to a scene, where we have aSceneTableContainer(as a field ofTableAuthoring). This container also provides access to all the data, but it pulls it out of the scene. This means we don't need to sync anymore, since the oldFileTableContainerdoesn't exist anymore once import has finished.SceneTableContainerdoesn't contain any state, it just knows where to retrieve the state from. For example, the binary data of a texture would be retrieved from an image in the asset folder (see below), or the metadata of a flipper would be retrieved from the flipper'sFlipperAuthoringcomponent, which still sits in the scene.We currently refresh the references of
SceneTableContaineronEditorApplication.hierarchyChanged, but this might not be necessary, maybe we can lazy-refresh only when we actually need fresh data.Assets
When importing, assets are now written to separate files in the asset folder whenever possible, to keep as little as possible in the scene.
This means that we can now edit textures directly on the disk and Unity will automatically re-import them.
Note that we still store all the original data in the authoring component of the game object. However, we "free" heavy, fields once extracted. For example, after the mesh data of a primitive is saved as an asset, the mesh of the data object is nulled so it doesn't add redundant data to the scene.
Materials
Materials from Visual Pinball are saved for later export, but are ignored otherwise. That means updating them doesn't change anything in the converted Unity material, and changing the converted Unity material doesn't update the original material. If a material is used as physics material, or if it has the physics properties set, the material is saved as asset as a
PhysicsMaterialobject and linked to the collision authoring component. During gameplay, the asset is used instead of the table data.Side Car
The "side car" object was initially used to off-load heavy data into a separate
ScriptableObject. I don't see any use of this anymore. However, we still would like to re-export data we currently don't use in VPE. Thus, this object was renamed toLegacyContainerand contains data that is in the VPX file, but ignored by VPE.TODO
SceneTableContainer.GetMaterial()SceneTableContainer.GetTexture()When creating a new table, ask for a name(Table1 is fine, it can be renamed)Convert the "resources" dependency to prefabs(new issue)When exporting, add an option to automatically include all meshes in the scene as primitives (non-collidable toys), even when no(new issue - maybe)PrimitiveAuthoringcomponent is set.