WIP: Visual Pinball in Unity (2021 Edition)

[BrandonLaw]

Internets getting wonky....posted twice.

[BrandonLaw]

Right-click...translate.  Yay google!

 

Takes .16 seconds.  A lot faster than asking someone to 'type in English.'  I also feel that's not nice.

 

Let's be nice.

[fastdraw]

with cinemachine , c'est trop cool unity !!!!!!!!

 

 

[freezy]

12 hours ago, BrandonLaw said:

Right-click...translate.  Yay google!

 

Takes .16 seconds.  A lot faster than asking someone to 'type in English.'  I also feel that's not nice.

 

 

1. You're aware that posts get read more often that written, right? So 100 people having to manually translate shit as opposed to the poster doing it once sounds okay to you?
2. Not everybody is using Google Chrome.

[Fwiler]

Are you done yet?....

 

☺️

 

 

This will be an amazing adventure.  I'm very excited to see this happening.

[freezy]

Small Update.

 

Finally, after over three months of refactoring, I've merged a branch of 8k lines which changes the way a table is loaded into the Unity editor. This part was the first thing I implemented when I had no clue about how Unity works, and it was done in a, uh, sub optimal way. Details are here.

 

The short version is that instead of keeping the original structure of the VPX file intact and serializing it as one giant blob, we now extract all media, meshes, textures, materials etc into separate files so they are part of Unity's asset database. This allows for faster start-up, and you can easily edit your assets. However, importing the table into the editor takes longer, because all the assets are now loaded analyzed by Unity. Re-importing a table whose assets are already on disk is nearly instant though.

 

For those of you who already started playing around with VPE, you'll need to re-import your table again. This will probably happen a few more times until we become stable enough to start thinking about migrations.

 

Another improvement was editor speed. We added some hacks to provide a better editor experience, which turned out to be quite expensive. They are all gone now.

 

You can upgrade by opening the Package Manager, select Visual Pinball (HDRP), and hit "Upgrade". Latest version is v0.0.1-preview.72.

 

Next thing I'll be working on is ditching the Hybrid Renderer, which gives us access to more features and stability, as well as re-organizing and updating documentation.

 

Apologies for not having something more sexy to present, but well, the foundations of the code base are important too, right

[TerryRed]

Never apologize.... it's all sexy.

 

Doing things the more "correct" way at the start, even if it takes longer, or needs a re-do is always worth it in the long run.

 

I have to ask.... does trying to hold on to VPX backwards compatibility (for exporting to VPX) create more roadblocks and compromises at all? I guess I wonder if it would maybe better to have that as a nice "possible extra" down the line.... but not have it limit what can be done, or used in respect to physics, or any other modern engines / methods being used?

 

The import of course is essential (and awesome).... and the better that function works..... the less work it is for everyone down the line, and the quicker turnaround for authors.

 

 

[freezy]

Yeah that's a good question. @BilboX already takes the piss out of me for insisting on VPX export. The idea of VPX export is still to get VPX creators to take it for a spin without having to completely switch engines, i.e. allow a smoother transition. But I see that getting VPX creators onboard might not be such a problem after all.

 

It's not holding anything back though. It's more effort, but it's separated from the rest. If at some point it doesn't make sense anymore to maintain this feature, so be it. It's certainly not hindering innovations or getting new tech into VPE.

[scottacus]

IMHO, if mpf is the means of "script writing" for EM vpe tables then it really doesn't make a lot of sense to include vpx export because vpe will be a completely different beast from vpx for us EM table makers.  If it helps you move the process forward then I'd recommend ditching the export back to vpx from an EM point of view.

 

From a SS  ROM table point of view making vpe tables should be dead easy "lights, switches, coils" action...

[freezy]

The goal of the export is not to convert VPE tables into VPX tables no matter what. It's a convenient way of editing existing VPX tables. You get a nice 3D editor and IMO better tooling to get stuff done. But of course you can't really script anything, or debug table logic, because that's VPX-specific.

[fastdraw]

for shaders and lights and fx effects and of course the animation undoubtedly, 
but certainly not for the 3d (rhino 3d) is very much superior to unity.
same blender for free solutions. (there is a close partnership with).

 

ue5 final will be released in a few months. vpe on ue5 would be good too

Edited July 23, 2021 by fastdraw

[freezy]

Please fastdraw aka fripounet aka granit aka hotdog aka whateverthefuckyoucallyourselftomorrow, can you leave my thread in peace please?

[fastdraw]

must put the lights in a single directory, itself at the root of the table, otherwise we cannot batch edit the multiple lights.
unless we unfold the whole tree and select the lights one by one (it's too bad). ditto for GIs

with better visual control than the light explorer.

 

BAD WORKFLOW

 

 

GOOD WORKFLOW

 

 

 

Edited July 28, 2021 by fastdraw

[Dazz]

On 7/23/2021 at 7:02 AM, fastdraw said:

for shaders and lights and fx effects and of course the animation undoubtedly, 
but certainly not for the 3d (rhino 3d) is very much superior to unity.
same blender for free solutions. (there is a close partnership with).

 

ue5 final will be released in a few months. vpe on ue5 would be good too

@fastdraw Please refrain from spamming other projects in this thread.  This thread s specific for Freezys VPE Unity 2021.  If you want to discuss other projects; please start another thread of your own.

[freezy]

So, we've noticed a few bugs with the last refactoring. It's about prefabs and how they are currently used. I'll be working on that next.

 

Meanwhile I've removed the Hybrid Renderer, meaning VPE will be using the render pipeline's default renderer. This has a few advantages:

• The default renderers are more stable and feature rich (i.e. we can now use DXR again and a few other things we couldn't before, namely skinned meshes).
• Code is simpler overall, since we don't have to deal with DOTS' parenting
• The established debugging tools for the scene work again, so you can pause the game and inspect all items instead of having to rely on the clunky Entities Debugger.

I've also tested Unity's 2021.2 beta and it seems to work well (DOTS is supposed to be incompatible with anything but 2020.3). This is awesome because it provides even more features like DLSS on NVidia cards, many editor improvements, deferred rendering on URP and few more things.

 

Anyway, if you want to take it for a spin, it's v0.0.1-preview.53 for URP and v0.0.1-preview.74 for HDRP. Be aware though, as mentioned above, prefabs are still buggy (you can't currently change props without explicitly editing the prefab).

[pitty]

I just can't beleive how beautiful that jurassic park table looks on github.

 

It's like i'm looking at a pixar image.

[bietekwiet]

Wow, just read through the thread. You guys are geniuses! VPE Looks mighty promising.

[freezy]

First of all, apologies to anyone who was playing around with VPE in the last six weeks, most of the features were utterly broken due to the last refactoring. I've just merged a branch with fixes and further refactoring, and after more extensive testing I'm pretty happy now, mainly because I can move on to more innovative stuff.

 

Here are the changes, apologies for being a bit technical this time.

 

Prefabs

Prefabs in Unity allow you to create re-usable blocks where you can override things and even create variants. So what we're doing now during VPX import is setting up a scene like you would if you were doing it manually:

• Every game item is instantiated from a prefab that we actually ship (we used to create prefabs on the fly before).
• Game items of the same type inherit all from the same prefab (before, we created a new prefab for each game item on the playfield).
• We use prefab variants where it makes sense. For example, the various gate types are all variations of the same prefab.

All in all I think it's an awesome approach. I see prefabs being used in the future all over the place. Think of a library of ready-to-use elements like pegs, flippers from all eras with primitives already set up, etc etc.

 

There's also another aspect, which is performance. When using prefabs, Unity knows which elements on the screen are the same, and can thus reduce draw calls. For example, if we were to provide a screw prefab, you could place as many as you want in the scene without having to manually merge them into a big mesh to gain performance. More flexibility at no cost!

 

Data

This was mainly addressed in the last refactoring, but even more improved in this one. What we did originally was read the entire VPX file into data classes and store them in the scene. This was awfully slow because meshes, textures and sounds were serialized in a format similar to JSON, which was very inefficient. Then, we cleared out the heavy stuff and saved it directly on the file system, but still used the data classes as the "source of truth".

 

Now, there are no data classes in the scene anymore. We copy the relevant fields to the Unity components during import and copy them back during export, but the source of truth are the components now.

 

This opened a whole new world of editor features, since we can now use Unity like we're supposed to. For example, when you put a bumper on a surface, we reference that surface so we can calculate the height of the bumper. Via data objects, this reference was done by surface name, so we needed to maintain a list of surfaces by name to find the right surface, renaming the surface broke the reference, and you couldn't have multiple surfaces with the same name.

 

Now, we just reference the component and that's it. Rename the wall, and it will be updated automatically in the bumper referencing it. Remove it from the scene and it'll be unset, not crashing due to missing references and all the other things you need to deal with when you manually handle references. Also, we can now update everything in real-time now. Check this out:

 

 

Finally, we only copy fields that are relevant for VPE, which makes the code much more clear to read. Everything in the component has a purpose, which is cool.

 

Wiring

As you know, you can visually wire PinMAME inputs and outputs to the playfield items. Until now, these items could either support one switch/coil/light, or act as a "device", with multiple switches/coils/lights. For example, the trough has one or two coils depending on the type, and a switch for each ball.

 

There is also the "Wire Manager" where you can link up outputs (switches) directly to inputs (coils and lamps).

 

Anyway, it doesn't make much sense technically to distinguish between "has one coil" and "has one or more coils". So all game items now always support multiple inputs and outputs. Which simplifies a lot of stuff, actually. If you have a game in MPF that relies on dual-wound coils, just tick "dual wound" in the flipper's inspector and you'll get two coil inputs to link up.

 

It's all much more natural now. Another example are kickers. Some kickers have multiple coils for kicking out the ball at different directions. In VPE, you choose direction, force and inclination in the inspector for each coil, and off you go with multi-coil kickers.

 

Export

So, we're moving a bit away from the VPE-as-VPX-editor approach, meaning while you still can export your table, VPE won't be covering all your VPX editor needs. This is specially true for materials, since materials are very specific to the renderer, which is different from VPX. When importing, VPX materials are converted to the current render pipeline's Unity material, but they aren't converted back.

This PR removed the material editor. You can't visualize VPX materials in VPE anyway, VPX materials are just converted but not referenced in any way once you start tweaking them.

Other Changes

There were a few other things I've tackled on the way:

• In VPX, you can globally scale the entire table along the Z axis (depending on the POV). This was removed, since we should be able to achieve the same results with Unity's camera settings.
• Custom playfield meshes are now fully supported! Just uncheck the playfield's default mesh option and drag your mesh into the mesh field.
• We now distinguish between the "table" and the "playfield". So a few attributes like dimensions and slope angle etc moved from table to the playfield, and the children retrieve these values from their first parent. This should make it less difficult to support multiple playfields in the future.
• Editing drag points for walls, ramps, triggers & co is now always enabled.
• Drop targets and hit targets are two different components now.
• Collider rendering in the scene view has been revamped. It uses proper meshes now, and they are cached, so you can render them all at once if you're debugging where your ball is stuck.
• If you know that an item like a rubber won't ever be used as collider, you can now remove the collider component and it will not be added to the physics world (like a primitive toy), resulting in better performance.
•  The boundaries of the flipper are now more precisely computed, meaning the physics code won't try to collide against the flipper when the ball is still in the lane (look at the pink box in the video).
• Finally, we might have a new logo! Thanks to everybody who commented.
  
   

 

 

 

 

 

 

 

 

 

 

 

 

 

That's it for now

 

   -freezy.

[umpa]

Wow! Thats great changes you have been busy! Thank you all for your time and commitment!

[hitman12]

Really great amount of impressive job.

[pitty]

So awesome, can't wait to get it going in my cab

[fastdraw]

It starts to take shape.
some prefab are not yet operational 100 % (slingshot and kicker)
for those who do not want a pinmame, should take as an example pinball creator , for the creation of missions, multiball and the gamelogic , sort of prefab script, so no coding knowledge of any kind.

the use of dx12 is still tricky.

the light sequencer and rainbow is still not integrated. (except for those mastering C #)
too bad for those who would like to see a nice demonstration of the performance of unity.

when launching a table , no dynamic camera by default, you have to create it yourself.

big improvement in workflow
the lights or gi can be selected in batches (hierarchy), for a global adjustment.
except that it are mixed, the gi should be with the gi and the inserts with the inserts.

like this:

Edited September 18, 2021 by fastdraw

[freezy]

@fastdraw I recently read this article from a guy who does a lot of open source. If you don't want to read it all that's fine, but have a look at the section "Entitlement". I had to think about you when I read it.

 

I get it that things are missing. Some things you're asking for are reasonable, some we'll probably handle differently. None of the things are priority at the moment.

 

If you want to contribute to this project positively, then please open a GitHub issue when you think we should address something urgently. Messages here, specially when you keep editing them, will get lost and probably cause more annoyance than anything else.

[scottacus]

@freezy that is a very well thought out and written essay.  I'm not a dev and it is interesting to get a look into what it is like dealing with bugs and interactions with end users from a devs point of view.

[freezy]

If that's copyrighted code, which I think it is, because pinball creator is commercial, please delete this!

 

cc @Dazz

 

EDIT: @fastdraw thanks for removing, I don't want to get into trouble..