811 replies to this topic

[toxie]

For me, main take away was how much everything vibrates, contrarily to current sims where nothing moves a single pixel when hit. I did a test adding subtle vibrations in the hit normal's directions to surfaces in VPE, and it's definitely something to exploit further.

 

I'll dive into those things at some point, but right now I'm optimizing the quadtree generation because it's becoming a drag when starting a game.

What do you mean by vibrating? Varying per-simulation-cycle slightly?

 

Quadtree: By making it parallel? Or how?

[freezy]

Nah I'm talking about ramps wobbling when the ball goes through them like here.

 

Quadtree: In DOTS, Unity tightly packs data into memory blocks to minimize CPU cache misses. So for the quadree I'm creating what they call a blob asset reference, built out of structs. However when I ported this over from VP, I was using VP's (class) collider objects. I was basically creating an object structure first, and then convert it to the struct tree. Which resulted in a ton of GC and was overall a bad plan (but easier to port). So now (when it's done) I'm creating the struct hierarchy directly from the game items that should result in zero GC and might even be burstable. I don't see how we could parallelize it though, given it's a tree that is created recursively.

Edited by freezy, 04 November 2020 - 09:25 AM.

[toxie]

There are some schemes that can do parallel tree construction (which is usually done to build BVHs efficiently on GPUs), so i just wondered. 

I didn't want to use that back then as it makes the code almost unreadable/maintainable for anybody else.

 

Ramps: Ah, so you move the ramps themselves slightly?

[freezy]

Well at some point it would be nice to get away from the static collision model, so ultra-fast BVH creation would be necessary. While I'm at it, I'll have a look how Unity does it, since it's open source.

 

I tried a surface, but yes, that's the goal. To make them oscillate slightly with the direction of the ball. It gave a more "alive" immersion, but I'll need to do more tests and apply it to more elements to get a clearer idea if it's worth the effort.

[rothbauerw]

I think there are multiple ways to attack the physics challenges.  I like where you're going Freezy.  But if that proves to be impractical, I think this could be handled by improved collision models for different types of objects.  For example, I've been working on code to better simulate drop targets and targets and getting very good results IMO. 

 

Let's take a drop target.  If you look at it in slow motion, it's really two collisions.  The first collision knocks the target back and the ball continues through the original position of the target.  Then there's a second collision when the target hits the back stop and the ball strikes it again, sending the ball in the opposite direction.  I use VP physics to detect the first collision, but then use an elastic collision equation to calculate a new path for the ball.  Making the original object non-collidable, the ball passes through the target.  I then use a second object to simulate the second collision using VP physics.  So by using two simple collision calculations instead of one, we get a much more realistic result.

 

The flipper interaction in the slo mo video I found to be the most interesting.  The fact that the flipper almost always strikes the ball twice.  I'm wondering if that's not the reason trajectories aren't quite modeled right by the existing VP physics.  Making sure that's handled correctly might be the biggest link to getting the true flipper physics behavior we're looking for.

 

Does anyone have the ability to see if the flipper currently gets knocked back on a collision with the ball?  I know it can when it's in the up position, but how about a collision mid-flip?

[wiesshund]

 

 

Does anyone have the ability to see if the flipper currently gets knocked back on a collision with the ball?  I know it can when it's in the up position, but how about a collision mid-flip?

 

No, it does not
A flipper in motion, at least visually, remains in motion
Only when the flipper reaches EOS is it displaceable by an object

I tested by manually slamming the ball into the flipper repeatedly.

I can displace it at EOS, based on the eos torque setting
But not in mid travel

Does not seem to be a routine for handling an impact in mid travel?
At least not visually

[pandeli]

Another few updates for the visual side of VPE....   

 

Just a few random tidbits from the exploration and testing.   I've been exploring a few different approaches for dynamic reflections and improved dynamic lighting.   All of these are in the HDRP and are not currently making use of DXR/Raytracing features at the moment.   Obviously, still very WIP and has a long way to go.   Flupper's TOTAN4K (mangled rather horribly in my testing various things so please pardon the various bits I broke)  

 

 Totan4kSSGI.png   2.25MB   25 downloads

 

 

Colors are obviously way off and all of that, but it does hint at some of the fun potentials.  Unlike the previous video using DXR that had some pretty awful performance, this is running at what can be considered a playable frame rate.  More on that later.

 

Ball reflection tests.  Sadly this approach ends up being a bit too expensive the way I'm doing it at the moment.  I plan on exploring this again in the future since I did really like the way the ball felt.

 

Another reflection test.  I liked the lights on the underside of the lamp reflecting in the table below

 

 

Earlier reflection testing with FG.  

Edited by pandeli, 09 November 2020 - 07:53 AM.

[blindpeser]

speechless... This is so awesome. Please keep the videos coming!

[hitman2304]

This is a whole new level of realism. Even commercial pinball simulators do not have this lighting and this level of detail.

[TerryRed]

Bring on the RTX 4xxx and 5xxx series! We're gonna need it!

 

Gorgeous!

[freezy]

Hi folks,

 

Little update. Nothing spectacular, but we've merged the trough and the wire manager. Those are features that will simplify table creation a lot. No code needed, just use the editor to hook up stuff as you like.

 

Then I've played some more around with the logo and I think we could get some vaporwave look going on.This will of course not impact the table creation process, but more the website, the sample table and so on. Here are two posters:

 

 

 

Next up is the lamp manager by @ecurtz, @Pandeli is working on a nice rendering setup, and I'm as usual pulling my hair out over various bugs.

 

Cheers!

[toxie]

Voting for the lower one.. 

[vothar]

same.. voting for the lower one, love the '80'/VHS/ Cyberpunk vibes in it...

[hitman2304]

I agree, lower is better 

[freezy]

You guys are all just craving for CP2077, nothing to do "which is better"

[hitman2304]

Honestly speaking, I am waiting more for VPE because pinball is a game that does not get bored and you can play for a long time on different tables trying to improve records and such an adventure game or RPG will pass up to 2 times and forget

[wiesshund]

Bottom one makes me think of this

 

but honestly, i would not care if the logo was a tuna fish can

[Gravy]

It's hard trying to work a 3 word title into a logo but they look pretty nice considering, I prefer the second one except you obscure the VPE lettering inside the triangle a bit.

[htamas]

Let me be the first to vote for the first one 

[JLouLoulou]

Yeah... Voting for the first one too

Envoyé de mon Redmi Pro en utilisant Tapatalk