813 replies to this topic

[StevOz]

 

 

 

Tap passes, on the other hand, aren't worth trade-off in terms of latency, in my opinion. They're rarely done, even by the pros. Super dangerous move!

 

 

 

 

I can't speak for everyone else, but I did them as a kid in tournaments all the time.

 

 

I here ya Itchy though comparing an analog to a digital recreation ultimately means some sort of compromises must be made. I might add to feather touch the flipper button to attempt the pass only works on a well maintained machine and even then given two of the same machines side by side that feather touch will be different not to mention left vs right on those same machines.

 

Nothing is impossible though some things are virtually impossible.

Edited by StevOz, 08 March 2020 - 06:40 AM.

[GeorgeH]

Has anyone tried Bforartists?  My understanding it is easier to use than Blender and it imports MilkShape files:

 

https://www.bforartists.de/

[DCrosby]

 BadCats.JPG   156.64KB   17 downloads

 

So this is Unity running HDRP, with Raytracing turned on (Warning it's not easy to do, there's a lot of hoops to jump though)

 

So this is with the following turned on:
GI, with denoising

Recursive Rendering

AO

Contact Shadows

 

I added some AA as well, but that was because the buzzing was pretty bad.

 

All kind of tossed in without regard for performance, as it is an alpha build, so will most likely change performance characteristics anyhow... so no point in tuning it.
It's cool to see what's possible given enough HP

Also Normal Maps crash the lighting, because I tried to add normals to the flashers, and everytime the whole scene goes black. Like I said it's an alpha.

 

Performance is about 30 fps until we get to the back, and then with the ramps becoming full screen and such it gets pretty gnarly... 10-15 fps

 

https://youtu.be/dcTqBKmZvyU

Edited by DCrosby, 08 March 2020 - 04:15 PM.

[Ben Logan]

Wow! That video is really exciting. Looks astoundingly real. 

[rothbauerw]

The reflections, the transparency and distortion through the plastic ramps ...

 

Exciting times!

[DJRobX]

 

I recently did a fairly in depth analysis of flipper behavior and identified a number of areas the current engine either doesn't handle or doesn't handle sufficiently.  I've been able to solve a number of those deficiencies through scripting, although building them into the engine at some point would be ideal.  For example, coil ramp up is linear in VP, while in reality, it should be non-linear.  

 

I tried to convince NFozzy to start looking at these problems at the VPX source, instead of trying to hack around them in table scripts.    If Mukuste were still around I'm sure he would have made short work of fixing it in the engine.        There's a steep learning curve, no doubt, but I've seen enough of your work to know that the two of you are more than capable of working with the C++ code, if you just give yourselves some time to wrap your heads around it.     I think you'd be so much happier with the outcome vs the limited things you can do in table script. 

I sincerely hope you will consider getting involved in the VPE physics at the source level, now that it's being ported to a more friendly C# environment.     Updates probably could even be back-ported back to VPX as fixes are identified.   The kind of analysis you guys are doing is invaluable!  

[rothbauerw]

I recently did a fairly in depth analysis of flipper behavior and identified a number of areas the current engine either doesn't handle or doesn't handle sufficiently.  I've been able to solve a number of those deficiencies through scripting, although building them into the engine at some point would be ideal.  For example, coil ramp up is linear in VP, while in reality, it should be non-linear.

I tried to convince NFozzy to start looking at these problems at the VPX source, instead of trying to hack around them in table scripts.    If Mukuste were still around I'm sure he would have made short work of fixing it in the engine.        There's a steep learning curve, no doubt, but I've seen enough of your work to know that the two of you are more than capable of working with the C++ code, if you just give yourselves some time to wrap your heads around it.     I think you'd be so much happier with the outcome vs the limited things you can do in table script. 

I sincerely hope you will consider getting involved in the VPE physics at the source level, now that it's being ported to a more friendly C# environment.     Updates probably could even be back-ported back to VPX as fixes are identified.   The kind of analysis you guys are doing is invaluable!

I'm involved and will do my best

[bord]

 

 

looking at these problems at the VPX source,

I'm involved and will do my best

 

This would be a dream come true. Roth's work (and nFozzy's) definitely should be rolled up into standard VP physics.

[freezy]

We definitely have a competent team now

[JLouLoulou]

 

And if it can produce better flipper physics eg a tap pass

 

From what I've read here, physics will be ported from VPX, so the core VPX physics engine would need to be enhanced. 

 

I recently did a fairly in depth analysis of flipper behavior and identified a number of areas the current engine either doesn't handle or doesn't handle sufficiently.  I've been able to solve a number of those deficiencies through scripting, although building them into the engine at some point would be ideal.  For example, coil ramp up is linear in VP, while in reality, it should be non-linear.  

 

If you look at Flupper's Totan, Skitso's latest Medival Madness & Twilight Zone, or some of bord's newer tables, tap passes (and a number of other flipper tricks) work on all of those tables.

 

I'm agree with you Rothbauerw, and i add to your exemple, it's the same for return coil that need to be non-linear " Coil Ramp Down "

Edited by JLouLoulou, 10 March 2020 - 08:29 AM.

[rzrfreefr]

 

@chepas what was your bad experience with Unity? What's PinGo? Is it open source? What did you fork? What projects in which solution took time to restore?

Forked the VP engine but each project needed package manager console to install packages.config. Still have a problem restoring Xunit for the unit tests.

 

PinGo is based on PROC board or simulator using godot for display.

 

Does it support GNU/Linux ?

I can try once sources are published

 

Relate-to: https://gist.github....7c65f1b17f3fc40

Edited by rzrfreefr, 10 March 2020 - 09:54 AM.

[dark]

I was wondering if it would be possible for you guys to plot a road map or to-do list for this project?  Perhaps edit first post in thread to include a rough road map,  I'm sure people who are following this with eager anticipation like myself would appreciate it.  Even if it's just what's planned a few steps ahead or what's already been accomplished.

[freezy]

@dark There are milestones on GitHub that you can follow. They are usually up to date, because they are linked to issues (and code). However, I didn't create issues for everything yet, so it doesn't give the whole picture. I'll work on adding more issues, but the further in the future they are, the less predictable they are.

 

Bigger accomplishments will be announced here in the thread of course.

[Ben Logan]

Has potential for “Best WIP thread ever.”

[Mr H]

Has potential for “Best WIP thread ever.”

 

Has my vote already! Think I'm checking it daily.

[freezy]

So yesterday I was working on getting balls spawned, i.e. creating the mesh, getting and applying the material, and placing it in the scene. It's all taking a bit longer because this part we're not porting directly from Visual Pinball. Instead we're using Unity's new DOTS technology that brings high performance, but is still in beta and thus not very well documented. Once I get the hang of it, I expect better velocity though (it already improved a lot).

 

Getting the physics foundation right is the next goal. The plan is to use Unity's DOTS/Havok physics as a base engine, and customize some of the collider resolution. I think we might be able to get away with just integrating VPX's flipper physics, but that remains to be tested and validated by the community. In any case that's how we'll start, and iterate from there.

 

Finally, I want to say that this is a team effort, ravarcade is diving into this as well, and we have a lot of support from other members of the community. Awesome to work with you guys!

[chepas]

 

 

@chepas what was your bad experience with Unity? What's PinGo? Is it open source? What did you fork? What projects in which solution took time to restore?

Forked the VP engine but each project needed package manager console to install packages.config. Still have a problem restoring Xunit for the unit tests.

 

PinGo is based on PROC board or simulator using godot for display.

 

Does it support GNU/Linux ?

I can try once sources are published

 

Relate-to: https://gist.github....7c65f1b17f3fc40

 

PinGo was scripted with C# and not in Godots language. C# mono, so why wouldn't it.

[chepas]

I have got a few days off work and decided to spend a little time with this. I have the solution building now, but what is going on with these unit tests?

 

Nowhere it says that you're building x86 in readme or solution.

Test run will use DLL(s) built for framework .NETFramework,Version=v4.5 and platform X86.

 

 

Any test data isn't copied to the following.

`VisualPinball.Engine.Test\bin\Fixtures~\DecalTest.vpx`

 

[freezy]

Hmm what's the error when you run the unit tests? CI seems to be happy, and locally they run through as well. The fixtures are just files used for asserting data is correctly read, they don't need to be copied anywhere.

[chepas]

Ok, I see. Missed the appveyor badge, cheers!

 

Wasn't able to run from inside VS, but they did pass when pulled down the console runner.

xunit.runner.console.2.4.1\tools\net472\xunit.console.exe VisualPinball.Engine.Test\.build\Release\VisualPinball.Engine.Test.dll
xUnit.net Console Runner v2.4.1 (64-bit Desktop .NET 4.7.2, runtime: 4.0.30319.42000)
  Discovering: VisualPinball.Engine.Test
  Discovered:  VisualPinball.Engine.Test
  Starting:    VisualPinball.Engine.Test
  Finished:    VisualPinball.Engine.Test
=== TEST EXECUTION SUMMARY ===
   VisualPinball.Engine.Test  Total: 113, Errors: 0, Failed: 0, Skipped: 0, Time: 14.185s