228 replies to this topic

[unclewilly]

I know we have to be a couple of months out for the dx9 vp compatibility release.
I was wondering if the devs were thinking forward to vp10. If maybe there is some interest in getting a brainstorming thread of ideas and possible feature additions.

Just curious.

[Joe]

64 bit build

 

multi core / Multi threading

[atlantis1982]

Mac and/or Linux support.

[Slydog43]

- like stated before, multiple formats in 1 table file (ie cabinet, desktop, Hybrid all in 1 file)

 

-version control of some sort, like auto updating table to latest version

[zany]

- Global/ambient lightning...instead of day/night versions.

Edited by zany, 16 March 2014 - 04:38 PM.

[fuzzel]

Here are some ideas we collected already (as far as I remember):

- proper lighting: The idea here is to make it as easy as possible to lighten a table, bulb support, real shadows or at least ambient occlusion

- material editor: Instead of applying physic settings for each wall again and again, you define a material and assign that material to a table element

- physics engine update

- library support such like in FP to exchange materials, sound and stuff like that

- improved visual effects based on shaders

- editor improvements and clean ups because of the mentioned features

 

Let's see how all that will work out in the future

[mukuste]

This would probably be best with having all devs around for discussion and feedback... toxie is currently on a one month break as far as I understood, and I don't know about Fuzzel's status, haven't heard from him in a while. EDIT: Ah, and just as I post this, he appears. Fine then!

 

Anyway, since it's already started, keep the ideas coming!

Some of the things toxie and me discussed on new graphics features:

• HDR rendering, this will improve the appearance of lights and also make night mods etc. easier to make by simply having a slider for overall brightness of the scene
• what Fuzzel already said, real per-pixel lights, possibly shadows, more realistic GI light bulbs
• fake indirect lighting from the playfield to make lit insert lights etc illuminate nearby objects

And some plans I have for the physics engine:

• increase the physics framerate from currently 100Hz to something higher (this is already working pretty well in a branch I'm working on)
• eliminate FPS dependence of physics (ditto)
• true simulation of ball spin and its effect on ball movement and collisions
• improve flipper-ball interaction by simulating contact effects properly

Edited by mukuste, 16 March 2014 - 07:26 PM.

[LoadedWeapon]

yea if the editor could be more like FP it would be so much easier to build tables for noobs such as myself..

[unclewilly]

I'd like to see a primitive based shapable rubber object similar to fp s rubber object

[jimmyfingers]

• increase the physics framerate from currently 100Hz to something higher (this is already working pretty well in a branch I'm working on)
• eliminate FPS dependence of physics (ditto)

Is the physics frame rate isolation / increase from 100Hz something that may be able to make it's way to the VP9_DX9 builds as that would allow for vsync to actually be used and smooth out any remaining aspects or concerns about stutter for good it would seem.  Also, a huge benefit of getting the vysnc working / physics decoupled from frame rate is that once we can use vsync, not only would stutter be resolved completely, but the requirements on system specs. / graphics cards would drop immensely only needing to run at 60-75 Hz / FPS vs. the several hundred we have been used to in the past (and still currently) as necessary to smooth out game play.  A win-win when vsync is working correctly with physics for smoothness and lower system costs / demands.

 

I believe it would be extremely valuable if this physics rate independence branch could be incorporated in the main / final VP9_DX9 builds as VP10 will be a long way off and as long as the physics decoupling from FPS didn't affect game play in any adverse ways, I think this would be an awesome addition for the current VP9_DX9 stream for the reasons above.  I would not propose, however, adding the more advanced physics elements / changes until later (like ball spin - as much as I personally would love to see this eventually), but the independent physics rate and vsync working without physics issues would be a beautiful and very useful thing to get going now / before VP10.

Edited by jimmyfingers, 16 March 2014 - 07:09 PM.

[mfuegemann]

Hi,

 

I would like to see the editor options from FP in VP too. Easy standard object placement, rich (maybe extendable)  libraries to choose from, shapeable rubbers and better ramps! The above mentioned lights/lighting and improved GI would also be really nice.

The best thing is already under construction, though: with the DX9 version all the performance issues related to visual impressing tables will be gone!

 

Regards

Michael 

[mukuste]

@JF

 

Unfortunately, it's not quite that easy. To have the physics behave independently of FPS, we need to force the physics to always use a fixed timestep. As you saw in the "physmod" test that I once sent you, this currently leads to somewhat increased stutter since the current 100Hz physics just are not fine-grained enough to produce smooth results then. So then we need to increase the physics framerate to make up for this. And here the bugs and design limitations in the current VP physics engine come into play: doing this impacts the behavior of the physics quite noticeably, for instance with respect to friction. So then a general physics overhaul, complete with retuning of all physics parameters for existing tables, becomes necessary.

 

So as you can see, these are all interrelated subjects and it's not possible to isolate just one or two of these changes without impacting overall behavior. Ultimately such a change wouldn't be a good match for a VP9 compatibility release where behavior as close as possible to old VP is desired.

Edited by mukuste, 16 March 2014 - 07:21 PM.

[ClarkKent]

And some plans I have for the physics engine:

• increase the physics framerate from currently 100Hz to something higher (this is already working pretty well in a branch I'm working on)
• eliminate FPS dependence of physics (ditto)
• true simulation of ball spin and its effect on ball movement and collisions
• improve flipper-ball interaction by simulating contact effects properl

I thought the physics engine will already be improved in DX9 version?

[The Loafer]

It is but not intentionally, rather because there's more free time for the physics engine to do its thing

[jimmyfingers]

@JF

 

Unfortunately, it's not quite that easy. To have the physics behave independently of FPS, we need to force the physics to always use a fixed timestep. As you saw in the "physmod" test that I once sent you, this currently leads to somewhat increased stutter since the current 100Hz physics just are not fine-grained enough to produce smooth results then. So then we need to increase the physics framerate to make up for this. And here the bugs and design limitations in the current VP physics engine come into play: doing this impacts the behavior of the physics quite noticeably, for instance with respect to friction. So then a general physics overhaul, complete with retuning of all physics parameters for existing tables, becomes necessary.

 

So as you can see, these are all interrelated subjects and it's not possible to isolate just one or two of these changes without impacting overall behavior. Ultimately such a change wouldn't be a good match for a VP9 compatibility release where behavior as close as possible to old VP is desired.

Understood, thanks for the explanation.  I can see, as you say, that the concept of it being a compatibility version will be stretched too far considering the aspects you mention.  

 

As it would have it, the latest test builds are running pretty good / smooth now even with FXAA enabled using the approach I as mentioned in the road to DX9 topic (using 600 / 601 for matching an even multiple of both monitor and 100 Hz physics rate - works with 60 and 75 Hz display modes). The 601 was a tweak as I saw the average / typical FPS actually about 1 lower than the desired 600 without it.  Thanks again for your work on assessing and reducing the stutter in the latest builds

[mukuste]

 

And some plans I have for the physics engine:

• increase the physics framerate from currently 100Hz to something higher (this is already working pretty well in a branch I'm working on)
• eliminate FPS dependence of physics (ditto)
• true simulation of ball spin and its effect on ball movement and collisions
• improve flipper-ball interaction by simulating contact effects properl

I thought the physics engine will already be improved in DX9 version?

 

 

No, the DX9 port focuses only on moving the rendering engine to DirectX 9, while trying to keep all other things as equal as possible. The increased framerate that many people are seeing in the DX9 version does have a slight unintended side effect on the physics engine, however this can be avoided by using the frame limiter for now, if desired.

[StevOz]

Corrected nudge physics for desktop usage.

[melon]

I think the editor should be upgraded. As a table autor, I think we should take a look at future pinball:

 

Rubber object. Now I'm making it with 6 ramps with different heights and colors

Guide object.

Sensor object

target and droptarget object made with a primitive.

New bumpers (nobody uses the default bumper as is)

B2b collision integrated in the engine. 

Transparent walls, not only ramps.

Wire ramps really need to be updated. I don't think the solution is making it with Future pinball, exporting to blender and exporting to visual pinball.

 

I know that all the things above can be made with tricks, but it's a lot of work. 

 

For the visuals:

Light/Flasher object. We specify a point where there is a bulb/ flasher.

Playfield reflections. This adds a lot of realism, I think this is very important. Not everything needs to be reflected, we could have a property for that for every object.

Holes in the playfield

[mukuste]

Wire ramps really need to be updated. I don't think the solution is making it with Future pinball, exporting to blender and exporting to visual pinball.

 

What improvements do the wire ramps need?

[fuzzel]

The overall look of a wire ramp needs an update At present you can't apply a texture to a wire ramp. Applying a sphere map to a wire ramp would be nice and easy to add into the current version.