834 replies to this topic

[unclewilly]

Thanks. I knew that. I have already converted those over in mb so I could experiment with the last demo.

Appreciate it
Thanks. I knew that. I have already converted those over in mb so I could experiment with the last demo.

Appreciate it

[unclewilly]

If it works the way I think it does. I see a brand new way for me to do lights.
Can't wait to play with this.

Plain inserts on the bottom. With the light just illuminating the insert on the pplayfield.insert writing on top with a small alpha ramp. And a flasher object about 5 units above with a light halo
If it works the way I think it does. I see a brand new way for me to do lights.
Can't wait to play with this.

Plain inserts on the bottom. With the light just illuminating the insert on the pplayfield.insert writing on top with a small alpha ramp. And a flasher object about 5 units above with a light halo

[fuzzel]

UW you really have to tweak you phone

[mukuste]

It does...but I think it's better if you play around by yourself Here is a small demo I've just compiled from the main trunk. Because VP10 doesn't support commands like triggersingleupdate or topvisible you can't just load and play VP9 tables anymore. For porting a VP9 table you have to remove the tiggersingleupdate calls and change "topvisible" to "visible".

 

Always a good idea to link to this at this point: https://github.com/c...e-Upgrade-Guide

 

There were also some other changes since the last build which should probably be mentioned... not at my dev laptop right now, but off the top of my head: I did some major optimizations to the primitives rendering in the editor (I can now drag Frank around on MB almost in real-time whereas before, each editor refresh would take 1-2s, yay!), and the new scripting functions I added. Probably more changes, can't recall everything now.

 

Idea: put an "if" clause into the light shader to check for intensity=0 and skip all the calculations so that people who only use the old texture-switching method don't pay the performance price for the light map calculations.

[unclewilly]

Really like the new lights. A lot of possibilities with what you have done

[fuzzel]

Yes I think it's much easier to achieve good results without needing deep photoshop/gimp knowledge Using defered lighting would rock but that needs a complete render engine overhaul

[unclewilly]

They are definately a step up from what we had. With more play I think I can get something really nice.

The bulb setting is much brighter then the normal I noticed.
I'm much looking forward to working with this. Will play more with them tonight

[mukuste]

Yes I think it's much easier to achieve good results without needing deep photoshop/gimp knowledge Using defered lighting would rock but that needs a complete render engine overhaul

 

From the reading I did, I'm not even sure a deferred renderer would be so great for VP... it seems to be only worth it if you have lots of overdraw, which is generally not the case on a VP table, I think. Then there's the issue that you can't handle transparency, so you need a second pass with a classical forward renderer anyway, basically meaning you have to implement everything twice... I'm just not convinced for our use case.

 

Deferred is hip though, sure

[lio]

I thought the big advantage of a deferred renderer was that you could have more "real" lights with less of a performance hit since the lights would really only be calculated for the screen pixels that they affect, but then I also read that it is a pain to get it to work with proper anti-aliasing in anything lower than dx 10.1 - but then these are just things I picked up somewhere with no first hand experience and almost zero programming knowledge so I might as well not have said anything :-)

[fuzzel]

I thought the big advantage of a deferred renderer was that you could have more "real" lights with less of a performance hit since the lights would really only be calculated for the screen pixels that they affect, but then I also read that it is a pain to get it to work with proper anti-aliasing in anything lower than dx 10.1 - but then these are just things I picked up somewhere with no first hand experience and almost zero programming knowledge so I might as well not have said anything :-)

You're right. Defered lighting helps on scenes with a lot of light sources. So for a pinball table you have a lot of bulb lights which illimunate the table. Calculating the shading for each bulb in the classic way would take much too long. There exist techniques to solve the AA and transparency problem thoug but you need a descent graphics card for doing so. With descent I mean a graphics card with a lot and mainly fast RAM. To support even low or midrange graphics cards you need a good render engine to handle such problems.

[mukuste]

The blanket statement "you can use more dynamic lights" gets bandied around a lot when people talk about deferred rendering, but I think it's a bit of an oversimplification. A lot depends on how your geometry is structured. For instance, look at this scene which is shown in one of the online tutorials for DR:

 

 

There are many light sources, so the first impulse is, "oh, I need a deferred renderer here". Then you realize that each of these spheres is actually only affected by one, maybe two point lights. So you can get the exact same effect with a classical forward shader which simply implements a loop over two light sources as long as you assign the proper light sources to each object -- and you'll be faster because you don't have to have these huge G-buffers eating up your memory bandwidth which you need when you go deferred!

 

The one place where I could imagine a sort of deferred lighting approach in VP is the playfield. It's large and will be affected by most lights; and also its normal is constant, and you can just specify the other material parameters globally to the shader, so you don't even need a G-buffer! So that seems like it would be worth trying. In fact, you could say that the new bulb lights are already a step towards a deferred lighting approach for the playfield.

[ravarcade]

For last few months i read a lot about deferred engine (i start work on my own). So here are my 2 cents:

 

Big company, smart people with experience, choose deferred engine. So if You don't know what to choose, find someone smart and follow him.

 

Main problem with game performance is overhead related to number of draw calls. That's why we hear about Mantle, OpenGL 5 and DX12.

If You have to change rendering pipline params between draw calls, performance will decrease. Changes like update shader program params will do "small" slowdown. Change of texture will do bigger slowdown, change of shader program -> huge slowdown.

 

Here are few scenarios where forward rendering will fail when You want to choose few light sources for object to draw:

- You will have to pass to shader diferent lights params every (or few) draw calls -> more render pipline changes

- You will have to change texterues with "light maps" when You do switch between lights (or You can use texture atlases) -> more render pipline changes

- You will have to dive "big objects" to small parts. Not only playfield buf for example long ramp. -> more objects -> more draw calls

- To speed up drawing You want to draw many objects with smallest possible number of "render pipeline changes". It will be hard to optimize. For example You have same object on 2 parts of table, You have to choose between drawing it twice and change lights between draw calls or draw all objects in one region (for one set of lights sources).

- Shader programs become long and complicated. If You want to add "new" draw model/style You will have to copy huge part of "light processing" code. When You want to update light processing You will have to do changes in many shader programs.

 

In other words: with forward rendering You will have to very often change render state and do a lot of draw calls with different params. It will be main performance bottleneck.

 

If You choose forward rendering, You can for example use texture lookup with encoded light sources positions and prams.

 

-----------------------------------------

 

... and then someone come and say: Where is option to enable SAO/HBAO/SSAO?

 

Deferred rendering may be better choice:

- ssao is easy. You need point position (reconstructed from depth buffer) and normal vectors (already in g-buffer). It is easy to do it and easy to switch it off If you need performance.

- on table You need MANY lights. There are tables with few dozen lights. There are also many types of lights, not only point lights. I think 8 light source per object may not be enough.

- "fake" light sources -> more lights. For example: we have light bulb close to very reflective wall. I can for example put another "fake" light behind wall to add reflected light. This "fake" light will be activeted when "real" one is on and it needs own position and shadow/depth map.

- on many tables light show is main part of "fun". See last "timeshock".

- optimalization. It will be easier to reduce number of draw calls/render pipline changes. For realy slow computers You can: Render all "static" objects to G-bufer, backup whole bufer and for next frame You don't need to draw so many objects but only movable and draw "lights" (+transparent objects with forward rendering)

- easier to manage features. You work on SAO, shadows, postprocessing with separate smaller simpler shader programs.

- again optimalization. When rendering of frame is divided to few steps, GPU can do things like this: Process few draw calls for sao and same time recive data (and put it in pipline) to draw many small objects. Someware is presentation of "Killzone 2" rendering engine. 

- all work is dived to "smaller" parts.

 

I see a lot of problems with deferred rendering. For example i plan to use 16 - 24 bytes for one pixel in g-bufer in my own engine. It will be 128-192 MB for g-buffer with QHD resolution. I know it may be problem. So there is another question: where are big AAA games with forward rendering? 

[mukuste]

Hi Rav, thanks for you input.

 

For last few months i read a lot about deferred engine (i start work on my own). So here are my 2 cents:

 

Big company, smart people with experience, choose deferred engine.

 

Yes, I agree with this. A large company with many smart people working full-time on their engine can afford to use this approach. We are just a few people hacking away at this in our spare time -- we don't have the resources to convert to an entirely new rendering model. It's a lot of work.

 

Also, we shouldn't forget that a modern AAA game has completely different type of content to render -- much higher scene complexity, higher variance in depth, much more dynamic viewpoint and environment, more light sources, etc. What is best for them doesn't have to be best for us. Rendering a pinball table allows for a lot of special assumptions which you can't make in a generic 3D game, and I think we can do some clever optimizations.

 

I already found a very promising approach for reducing the number of state changes in the forward renderer: tiled forward shading (http://www.cse.chalm...ng_preprint.pdf). It means that you don't have to assign the lights to the individual objects, but simply group them in screen space buckets. So we never have to split large objects into smaller ones. It should also be much easier to implement. A quote from the paper:

 

One scenario where tiled forward shading should work well is when scene depth complexity is low, and most light volumes are overlapping to the geometry. [...] This description would match a Real Time Strategy (RTS) game pretty well, assuming a top down view and lots of action on, or near, the terrain.

 

 

Now replace "terrain" with "playfield" -- does it sound familiar?

[ravarcade]

I already found a very promising approach for reducing the number of state changes in the forward renderer: tiled forward shading (http://www.cse.chalm...ng_preprint.pdf). ,,,,

This is exacly what i want to say when i write: "You can for example use texture lookup with encoded light sources positions and prams.", but forgot right term.

With this solution You will need texture atlases or one big texture for all lights with shadow/depth maps.

 

For sao You will need another geometry pass, but it can be combined with z-prepass.

It seems best option.

[unclewilly]

This sounds good, but way above my head

[ClarkKent]

I do not remember if I already requested this - but the cabinet perspective is still not correct. Somehow the depth of the desktop perspective is totally missing.

 

To demonstrate the differences between the real and the virtual version of Roadshow I photographed each from the same perspective. If you download the Photoshop file with layers and switch between the layers you can see that it looks totally different. Maybe this would be a nice thing to fix for VP10?

 

https://www.dropbox....nal+Virtual.psd

[fuzzel]

I do not remember if I already requested this - but the cabinet perspective is still not correct. Somehow the depth of the desktop perspective is totally missing.

 

To demonstrate the differences between the real and the virtual version of Roadshow I photographed each from the same perspective. If you download the Photoshop file with layers and switch between the layers you can see that it looks totally different. Maybe this would be a nice thing to fix for VP10?

 

https://www.dropbox....nal+Virtual.psd

 

Ah cool capture! Thanks. The camera settings are indeed really strange and should be changed to a real camera with a target (like in Blender, Maya or 3DSMAX).

[boiydiego]

I do not remember if I already requested this - but the cabinet perspective is still not correct. Somehow the depth of the desktop perspective is totally missing.

 

To demonstrate the differences between the real and the virtual version of Roadshow I photographed each from the same perspective. If you download the Photoshop file with layers and switch between the layers you can see that it looks totally different. Maybe this would be a nice thing to fix for VP10?

 

https://www.dropbox....nal+Virtual.psd

indeed this should be corrected this would take fs tables a level up

[ClarkKent]

I think the camera perspective problem is the cause of the "flat" impression...

[mukuste]

I think it's less about the camera angle... in my opinion there are two reasons: 1. most people put their playfield monitor relatively low and put glass above it... in my opinion, a more realistic view could be achieved by having the playfield monitor in place of the glass, since this would mean that the screen can show everything that would be located under the glass on a real pinball table. 2. What is faked with the "layback" parameter right now should be handled with a true off-center projection matrix as used in VR applications (otherwise known as "BAM view" round these parts). Note that this is separate from head tracking, which is a different issue.

Edited by mukuste, 10 June 2014 - 08:34 PM.