2087 replies to this topic

[toxie]

So far it seems that most elements can be ported quite easily without breaking compatibility. The obvious exceptions are cases where renderer bugs were exploited to achieve special effects; digging through some old threads, it seems that ramps together with Stereo 3D and/or tweaking the RO/RU flags sometimes were used to that effect? Is that still happening? Did the advent of flashers phase that out completely?

 

If someone could give me a brief overview of the "state of the art" of lighting in VP tables, that would be extremely useful. It seems to be a convoluted topic where people have invented many clever hacks.

 

flashers, ramps are basically used as billboards, drawn over the actual playfield area that should be 'lit'. that's why this stereo3D flag was introduced to not have the z value changed by these billboards (as it will disturb the viewers eyes when being converted to stereo 3D).

the problem was that people relied on this disabling of the z buffer write, leading to all kinds of problems with the region updates, too.

plus in combination with (VP-)lights that are basically abused to trigger updates on certain table regions.

 

going forward we should instead use 'real' lightmaps (user-textures in texture/object space and -not- in camera space) and the particles/billboards only in postprocess (fake glare/lens fx).

or even go for the real deal and use full lighting (would require a deferred shading based rendering engine then) instead of artist handled lighting.

[Les73gTx]

+1 for fuzzel, worst case we can have one executable for vp9 dx7 and another for vp10 dx9, it is not a problem for the frontend to have a call to a specific emulator version

.
.
It is really easy to set up another emulator in the frontend that calls to a specific .exe .(thinking PinballX)... lol if I can follow the instructions and get it working anyone can. I vote for a total separate DX9 emulator and not worry about backwards compatibility. I am new here but isn't that what happened from VP8 to VP9?

[mukuste]

flashers, ramps are basically used as billboards, drawn over the actual playfield area that should be 'lit'. that's why this stereo3D flag was introduced to not have the z value changed by these billboards (as it will disturb the viewers eyes when being converted to stereo 3D).

 

I figured as much, but what I don't understand is why a flasher SHOULD ever write to the z-buffer. I mean, it's specifically designed to render an alpha-blended effect on top of the scene, why should it ever write to the z-buffer? It's not geometry.

 

The good thing is that now at least all those region hacks will be going away since the region system doesn't exist anymore.

 

BTW I have another question: the current bumper rendering code goes to great lengths to set up two different geometries to render in 'on' and 'off' states, but in the end it seems that the geometry in both cases is exactly the same and only the textures/lighting changes. Am I missing something or is that just a legacy leftover, and we can use the same vertex buffer for both states?

Edited by mukuste, 05 February 2014 - 06:37 PM.

[toxie]

Flashers: Welcome to the joy of legacy support.. ;-) There is of course no reason other than that it all started a long time ago with ramps writing to the zbuffer, the ramps being abused for 'lighting', then for various compatibility reasons it needed to stay like that throughout..
I guess you'll find out as soon as more is working and you'll load/test a bunch of tables abusing all kinds of legacy..

Bumpers: should be the same, this code we didn't really touch so far as it was prerendered anyhow..

Edited by toxie, 05 February 2014 - 07:07 PM.

[mukuste]

Flashers: Welcome to the joy of legacy support.. ;-) There is of course no reason other than that it all started a long time ago with ramps writing to the zbuffer, the ramps being abused for 'lighting', then for various compatibility reasons it needed to stay like that throughout..
 

 

Flashers were introduced a month ago. There are therefore no legacy tables which use them, so this makes no sense.

[toxie]

Absolutely true, but they have to play along with the rest of the legacy..

Feel free to improve and fix all of this if you want in your fixes branch, I'll port it back to 9.2.1. Even if all of that doesn't seem to make any sense to you, be sure that it always has a stupid legacy reason or we simply didn't look over/change the original code yet.

Edited by toxie, 05 February 2014 - 08:36 PM.

[jimmyfingers]

@ mukuste - First off, a huge thanks for taking this on and going at it with the vigour and speed at which you are working. Also, the level of updates are great and once again, as one of the dev team here, you are more professional in such areas than companies like Farsight and Pro-Pinball seem to be where they even have actually paying customers (you guys all put them to shame in keeping your "customers" in the loop / status updates and delivering the goods).

 

As far as your last post about the flashers, I'm sure what toxie means is the "flashers" that have been used to date via the ramp method. The new flasher object's are indeed not currently used / fully tested yet. It seems in the 9.2.1 Beta thread that there also may be some drawing order difficulties possibly with them as as JPSalas has just recently posted about.

 

Regarding the legacy element and some of the tricks and lighting (not just directed to you but Toxie and fuzzel too). It's a bit funny to hear all the talk about "abuse" and "hacks" where us table builders / modders would probably consider it more like "thinking outside the box" or "being resourceful / creative" J  We all found ways to make VP look better when the program itself ultimately didn't natively provide a means to do so (mainly around the lighting aspects). We weren't intentionally trying to make all of your VP dev. lives more difficult, but instead were trying to produce / give back something as great looking as possible  I get that VP and the tables, in how it's all come to be, will be an immense challenge to improve by moving forward in a large architectural way such as the DX9 upgrade, but some of these "hacks" gave a lot of people a better VP experience up to this point.  I, and I'm sure others, totally get that these elements and other VP constructs are going to be a pain moving forward, but like most have stated, if you can provide a better means of doing so, then we will be fine in using / learning these new methods for the sake of a DX9 port / foundation.  This should be especially more acceptable if things like at least being able to open an old table will exist then having options in retrofitting the necessary elements to conform to the agreed upon structure for VP and DX9 compatibility.

 

A couple things on the way things are lit now. It may still be useful to keep / allow the retention of some ways of doing lights (lamps / table lights and not talking flashers at the moment) as some light objects / lamps really benefit from the hand drawn look with recessed / counter-sunk looking bulbs and filament or hot spots with varying images of expanding areas of the hot spots and overall glow within the lamp "plastic" all while creating on a playfield sized texture than each light individually. Some of the examples of the new Unity 3D pinball have the lamps looking more just like a bloom / colour blob than having what a light bulb looks like under a transparent coloured plastic (the latest Class of 1812 is one where the lamps exhibit this lack of definition – although I recall some really nice shots of TAF with the look of bulbs under the playfield so not sure of the difference on that front or if it’s just a table builder’s choice / coding).  Of course it’s likely not as needed and arguably much more time saving if this can be done in equivalent eye pleasing fashion natively with DX9 VP for things like having a bulb-like object actually be able to sit beneath the playfield, a transparent light object (plastic model) to allow the light to shine through (with probably parameters for it’s transparency levels), as well as the concept of the bulb and the light shape / heat of the filament.  The same issue also may be relevant to flashers as again, as much as the Unity 3D pinball lighting is very impressive and immersive, some flashers are all one solid colour and not necessarily capturing the hotter / whiter centers emanating from the source / bulb, which at least by drawing our own alpha ramp images and using them as flashers in VP, we’ve be able to craft with a visually closer look to a real flasher center and outer dissipating colour edge.   Of course it would be great to go from 2D flashers to truly a spherical / 3D affect on the objects around it.

 

Some things like full table lighting using light objects might be nice to still have as it gives full control over the light and colour changes of the light to the PF images beneath. However, I know I personally would love to get real shadows, full environment interaction with the lights, and not spend necessarily hours having to fake these things in Photoshop. 

 

The real quick way to put it is, as long as the future of VP will provide a means for it to look as good or better than how we’ve done it to date with “hacks”, but with the same or less amount of time involved as a builder, then I think everyone would be happy.  If we end up with less attractive lighting than what we could do by “abusing” the elements currently available, I think the success of the project will be lessened.

 

Like I say, a huge thanks for what you’re doing and have done so far, it’s just that a lot of us have also invested time in VP and want to see some of that investment / level of results protected moving forward (at least speaking for myself).

[mukuste]

@jimmyfingers: Thanks a lot for that in-depth post, that's the kind of information I'm looking for. I'll keep these things in mind going forward.

 

Especially talking about flashers, I think this is an area where HDR (high dynamic range) rendering could really improve the graphical fidelity. We'll have to think about implementing that once we have a shader-based pipeline.

 

I definitely hear you about "true" lighting and shadows. I think the lighting will be helped along a great deal already once we move to a per-pixel lighting model using shaders, perhaps even a deferred lighting model. Shadows are unfortunately a rather tricky problem to solve, especially without killing the framerate. I wonder if one could exploit the static viewpoint of VP to speed up some calculations here, but on the other hand, people have expressed the desire to move towards a dynamic camera, so I'm kind of torn on this.

 

Finally, on the "hack" wording: I'm completely with you there. I'm constantly in awe how good you table authors make VP tables look within the restrictions of the engine, and I would never think to blame you for using all tools at your disposal. In fact, the word "hack" in programming lingo, at least originally, denoted an unusually clever and "outside the box" solution to a tricky problem, without any negative connotation. I'm sorry if any offense was caused by that wording, it was definitely unintentional.

 

And I fully agree that previously established methods, "hacks" or not, need to be either supported or an all-around better alternative implemented.

[DJRobX]

What you guys do with VP reminds me very much of the Commodore 64 days, where very talented and creative coders "abused" the hell out of what the hardware was designed to do, in order to get more out of it.     I definitely see "hacking" and "abusing" in this context as positive nod to the table designer. 

 

I wonder if one could exploit the static viewpoint of VP to speed up some calculations here, but on the other hand, people have expressed the desire to move towards a dynamic camera, so I'm kind of torn on this.

I strongly think you should focus on being able to have a dynamic camera.     If you've played Farsight's TPA at all, being able to move the camera around is a big benefit when playing on small screen (desktop/tablet) situation.   Even cabinet people are using Future Pinball with BAM's head tracking capabilities, giving people a way to virtually "look around" inside a cab.    I think even if we had VP looking as good as Future Pinball in realtime 3D rendering,  it would be a smashing success.   

Edited by DJRobX, 05 February 2014 - 10:19 PM.

[jimmyfingers]

@mukuste - See, there you go again with the great customer service and understanding I wasn't really complaining and certainly no need to apologize - no offence was taken at all. Plus, you've barely used the terms that much - you've only been around for a few weeks (but what a freakin' few weeks!) - and if anything I was busting Toxie's chops more as I think I've heard him use "abuse" or "hack" the most But all of it light hearted and just saying a little "what the hell man" with a smile as to when I hear those definitions. You're right though on the "hack" aspect and what you suggest is indeed a fair definition and also pretty close to what I was already suggesting as an alternative thought / wording from the table builders perspective - so we're both right! Hearing "abuse" though sometimes made me think social services was going to be knocking at my door But like DJRobX referred to above, people who "abuse" there systems to get more out of it can also be considered in a positive context (e.g. today's overclockers)

 

But really, you guys pull off this VP port to DX9, you can call me or any technique I use anything you want! I can't tell you how stoked I am for the potential of what is shaping up. Your progress so far is wicked and, like others have said, I find myself addicted to this thread and looking back very frequently and surprisingly, in shorter timeframes than should seem feasible, you actually end up with further progress (watching those screenshots go from grey to essentially fully textured yesterday seems to be beyond belief). I also agree that keeping the dynamicness of the entire environment would be pretty key for future elements like the camera views and even head tracking possibilities. Maybe there's a way that you could have both with the shadows statically rendered (but with real-time ability to be completely disabled like a table size alpha ramp) and not necessarily dynamic until one enables other functions that would require it to be dynamic?

 

On a side note, seeing what your favourite pinball is in your profile, fuzzel and I have a treat for you that should be released in the next week or so - filled to the brim with lot's of wonderful "hacks"

 

Thanks again for this undertaking and the future of VP is indeed very exciting at this moment!

[toxie]

As all lights are usually static and even most of the geometry is static, precomputing some shadow maps is simple. So i guess no need for a static camera there.

 

I guess in general we could even use something similar as what will be/is used in Timeshock (lightmaps, stored separately on a per light basis to have them switchable on/off), but not in cam space (and of course missing the global illumination part). The memory usage during gameplay will be fairly high though then (but maybe not, after all this could be compressed pretty good). Rendering performance would be pretty good though.

 

Lots of room for experiments there.. 

 

@jimmyfingers: i know i use the 'abuse' wording often, but also don't take that serious, after all this is what was bringing VP forwards all these years.

Edited by toxie, 05 February 2014 - 11:33 PM.

[mukuste]

As all lights are usually static and even most of the geometry is static, precomputing some shadow maps is simple. So i guess no need for a static camera there.

 

I was thinking about precomputing camera space lighting, which would have made further optimizations possible, not to mention possibly better image quality. But having a dynamic camera would be really neat so I guess we won't go there.

[insx]

In layman's terms, is this likely to bring an end to stutter and performance issues and strange situations where hardware is upgraded and VP performance is downgraded?

[fuzzel]

Perhaps...If we optimized the new render engine....

[StevOz]

I propose it comes down to the the drivers of the relative graphics cards, when DX9, is no longer natively encoded within those drivers and becomes emulation driven then the same anomalies we have now will occur.

Edited by StevOz, 06 February 2014 - 12:42 PM.

[mukuste]

In layman's terms, is this likely to bring an end to stutter and performance issues and strange situations where hardware is upgraded and VP performance is downgraded?

 

First, with this port, you should definitely always see better performance with a better graphics card since now all the rendering will be done on the GPU. No more weird interactions in that respect.

 

About the microstutter: I hoped that the DX9 port alone would fix it, but at the moment it still seems to occur. By this I mean the phenomenon where the framerate seems good enough (say, between 60 and 200 fps), but the ball still doesn't seem to move quite smoothly. We have to wait and see until the port is completed to find out if it helps, but at the moment my suspicion is that it's a quirk of the VP physics/timing code. I definitely want to investigate this once the DX9 port is complete and stable.

 

 

I propose it comes down to the the drivers of the relative graphics cards, when DX9, is no longer natively encoded within those drivers and becomes emulation driven then the same anomalies we have now will occur.

 

DX9 is still hugely popular in many games out there, so I don't see native support for it going away soon.

Edited by mukuste, 06 February 2014 - 12:52 PM.

[insx]

Thanks for the reply. Perhaps not a magic bullet but a glimmer of hope.

[toxie]

Microstutter: as mentioned in the other thread already this is due to various things:
a) if the frame rate is below 100 (in theory even below 200) one gets temporal aliasing as the physics are running at a fixed 100hz
b) as soon as only some single frames take longer (vpm, physics, script, anims) this also leads to tiny stutter
c) vsync not enabled always leads to stutter/tear as common in all kinds of games

In an optimal world we could tweak the physics engine to allow for a more flexible update rate and/or have the rendering synched to the 100hz. Hopefully as technologies like gsync will become common, this would then go in combination with perfect vsync/refresh.

As for lighting again: so what about the idea of pre-baking all lights into a separate lightmap (incl. Shadows) each? This would allow for some very quick and high quality lighting, but at the cost of memory plus a lot of texture reads per pixel (so deferred rendering will be necessary -> meh, especially with all the transparency :-\ )

Edited by toxie, 06 February 2014 - 04:44 PM.

[mukuste]

Microstutter: as mentioned in the other thread already this is due to various things:
a) if the frame rate is below 100 (in theory even below 200) one gets temporal aliasing as the physics are running at a fixed 100hz
b) as soon as only some single frames take longer (vpm, physics, script, anims) this also leads to tiny stutter
c) vsync not enabled always leads to stutter/tear as common in all kinds of games

In an optimal world we could tweak the physics engine to allow for a more flexible update rate and/or have the rendering synched to the 100hz. Hopefully as technologies like gsync will become common, this would then go in combination with perfect vsync/refresh.

As for lighting again: so what about the idea of pre-baking all lights into a separate lightmap (incl. Shadows) each? This would allow for some very quick and high quality lighting, but at the cost of memory plus a lot of texture reads per pixel (so deferred rendering will be necessary -> meh, especially with all the transparency :-\ )

 

I've tried a few times to understand the physics stepping code, but haven't completely wrapped my head around it yet, it's pretty convoluted. However, it's not true that the physics simulation runs at a fixed frequency: from what I understand so far, the PhysicsSimulateCycle() gets a dtime parameter which is usually 1/100 s, but may be smaller if the game wants to simulate a shorter step to make the physics catch up to the current frame time. Something may be not quite right in that logic. At least it means if you run at >100 fps, you consistently have smaller physics steps than if you ran at, say, 60 fps.

 

Something simple to try would be to force the physics to actually run at a fixed 100 Hz and see if it changes anything for better or worse.

 

About the lightmaps: wouldn't you need a separate lightmap for every object that is affected by a light? Seems like you'd need quite many lightmaps in that case. Deferred shading seems attractive, but as you say, the transparencies... to be honest, I haven't read enough about it.

[DJRobX]

as soon as only some single frames take longer (vpm, physics, script, anims) this also leads to tiny stutter

Yeah, I was thinking it might be a good idea to add another measurement to the F11 display - the largest time delta between two frames (maybe periodically resetting every 10 seconds or something).   You may be able to generate 1000 frames per second, but if one frame takes 100ms and the other 999 are generated in the remaining 900ms, there's going to be a lot of stutter, despite an apparent high frame rate.   For smooth 60hz play you need every frame to be generated in under 16.6ms.

Edited by DJRobX, 06 February 2014 - 10:51 PM.