New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expanded rendering - light fx #3798

Merged
merged 35 commits into from Oct 25, 2016

Conversation

Projects
None yet
@JeroenDStout
Contributor

JeroenDStout commented Jun 1, 2016

Very early experiment for real-time light. Not for immediate merging.

map

train 3

In this implementation, any bit of code can add a 3d positioned light via lightfx_add_3d_light (3d game space) or lightfx_add_3d_light_magic_from_drawing_tile (relative to drawing tile 3d space). This means many functions can be altered to inject a light. For now, entrances and some vehicles get a larger light, staff gets a smaller light.

The light is calculated into a second 8bpp screen-sized buffer, where each byte represents the intensity. A value of 0x10 is used for 'full bright', anything beyond that is over-exposed. This makes stacking lights possible.

The 8bpp->32bpp step (for hardware rendering) is moved to a separate thread. This means the lighting can be calculated while the game renders the next frame. Some minimal back-buffering has set up. For now the dirty drawing is disabled, but this can be re-enabled.

Two palettes are used. The regular palette (a modified day/night version) and a palette for the lights, which is a yellow-ish version of the regular palette and varies in brightness depending on night-ness. Some extra effects light fog are incorporated in this as well. The 8bpp->32bpp looks up on both of these palettes and combines them through addition.

The lights use 8bpp bitmaps, currently baked at initial start up. Each light type (by design) has 4 versions, each 2× the size of the previous, any of which can be inserted. Zooming out makes the light rendering take one version lower, or remove the light.

lit up 2

For now larger textures and screenshots have no light, this can be fixed.

All of this code, I need to emphasize, is very experimental. A lot of things I wrote as a sketch to get to this working prototype so please cast a forgiving eye on some of the more disagreeable short-cuts I took.

Culling behind landscape (occlusion and underground), as well as user-placed lights, are two features I would be interested in for the near future.

@Wirlie

This comment has been minimized.

Show comment
Hide comment
@Wirlie

Wirlie Jun 2, 2016

Contributor

Hi! I like the new lighting effect! But I noticed that this also have effects with the interface.


w1
Screenshot taken at noon.
Right: Current effect that OpenRCT2 have on the last build.
Left: Effect of this new light effect (excessive contrast).


w2
Screenshot taken at night.
Top: Interface is readable at night. (OpenRCT2 last build).
Bottom Interface is very little readable at night. (Test of this new effect).


I know that this is experimental, but it would not be a bad idea to take this into consideration.
I hope you understand my suggestion and sorry for my bad english.

Greetings, nice day!

Contributor

Wirlie commented Jun 2, 2016

Hi! I like the new lighting effect! But I noticed that this also have effects with the interface.


w1
Screenshot taken at noon.
Right: Current effect that OpenRCT2 have on the last build.
Left: Effect of this new light effect (excessive contrast).


w2
Screenshot taken at night.
Top: Interface is readable at night. (OpenRCT2 last build).
Bottom Interface is very little readable at night. (Test of this new effect).


I know that this is experimental, but it would not be a bad idea to take this into consideration.
I hope you understand my suggestion and sorry for my bad english.

Greetings, nice day!

@janisozaur

This comment has been minimized.

Show comment
Hide comment
@janisozaur

janisozaur Jun 2, 2016

Member

@Wirlie this is an inherent limitation of our rendering pipeline. For day/night cycle we simply alter the palette used for drawing, not the surface itself, which is still 8bpp.

@JeroenDStout perhaps this is something you could address, by copying UI (non-viewport) pixels to your other surface/texture and leaving them intact?

Member

janisozaur commented Jun 2, 2016

@Wirlie this is an inherent limitation of our rendering pipeline. For day/night cycle we simply alter the palette used for drawing, not the surface itself, which is still 8bpp.

@JeroenDStout perhaps this is something you could address, by copying UI (non-viewport) pixels to your other surface/texture and leaving them intact?

@IntelOrca

This comment has been minimized.

Show comment
Hide comment
@IntelOrca

IntelOrca Jun 2, 2016

Contributor

For day/night cycle we simply alter the palette used for drawing, not the surface itself, which is still 8bpp.

That said, the current filter isn't too noticeable with with the window colours as it leaves high saturated colours intact. But the new night filter and sunset filter kind of changes it a bit too much.

perhaps this is something you could address, by copying UI (non-viewport) pixels to your other surface/texture and leaving them intact?

It could impact performance as you have to account for transparency.

Contributor

IntelOrca commented Jun 2, 2016

For day/night cycle we simply alter the palette used for drawing, not the surface itself, which is still 8bpp.

That said, the current filter isn't too noticeable with with the window colours as it leaves high saturated colours intact. But the new night filter and sunset filter kind of changes it a bit too much.

perhaps this is something you could address, by copying UI (non-viewport) pixels to your other surface/texture and leaving them intact?

It could impact performance as you have to account for transparency.

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 2, 2016

Contributor

@Wirlie Thank you for bringing this up! I have given it some thought.

Right now the lights shine through the interface. Rather than culling them entirely, the interface could be rendered with the default palette, removing both night and light. The transparency is a concern but I think for regular windows this would pose no problem.

In the code that draws the interface I could catch the largest (parent) boxes (not sure what the right terms are here) and add them to an 'exception' list. That could be turned into a series of scanlines. That way the blitting function could still work fast, but it would do 8bpp->32bpp in two passes, one doing the lighting fx and one leaving the pixels with the regular game palette.

Really what-ever happens the window boxes need to occlude the light in some way, be it through replacement entirely or through changing the light buffer.

Contributor

JeroenDStout commented Jun 2, 2016

@Wirlie Thank you for bringing this up! I have given it some thought.

Right now the lights shine through the interface. Rather than culling them entirely, the interface could be rendered with the default palette, removing both night and light. The transparency is a concern but I think for regular windows this would pose no problem.

In the code that draws the interface I could catch the largest (parent) boxes (not sure what the right terms are here) and add them to an 'exception' list. That could be turned into a series of scanlines. That way the blitting function could still work fast, but it would do 8bpp->32bpp in two passes, one doing the lighting fx and one leaving the pixels with the regular game palette.

Really what-ever happens the window boxes need to occlude the light in some way, be it through replacement entirely or through changing the light buffer.

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 2, 2016

Contributor

That said, the current filter isn't too noticeable with with the window colours as it leaves high saturated colours intact. But the new night filter and sunset filter kind of changes it a bit too much.

@IntelOrca Probably I should be bringing the saturated colour safety back to some extent anyway, it is a really elegant solution and makes night-light look better than what I have going now :)

Contributor

JeroenDStout commented Jun 2, 2016

That said, the current filter isn't too noticeable with with the window colours as it leaves high saturated colours intact. But the new night filter and sunset filter kind of changes it a bit too much.

@IntelOrca Probably I should be bringing the saturated colour safety back to some extent anyway, it is a really elegant solution and makes night-light look better than what I have going now :)

@janisozaur

This comment has been minimized.

Show comment
Hide comment
@janisozaur

janisozaur Jun 2, 2016

Member

@JeroenDStout what about windows that have viewports in them? Ride window or peep window opened with first tab selected.

Member

janisozaur commented Jun 2, 2016

@JeroenDStout what about windows that have viewports in them? Ride window or peep window opened with first tab selected.

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 2, 2016

Contributor

@janisozaur I suppose you let the rendering code know about the viewport so that it shows light in there, relative to that viewport. Ideally.

The light rendering code now just uses main window coordinates but I guess that isn't strictly needed for every pixel. Some solution is certainly possible that divides the screen in a series of rectangles that can be drawn quickly, each with their own relative coordinates as far as light goes. Then you can use that same rectangle information to not do colour grading for certain boxes.

Contributor

JeroenDStout commented Jun 2, 2016

@janisozaur I suppose you let the rendering code know about the viewport so that it shows light in there, relative to that viewport. Ideally.

The light rendering code now just uses main window coordinates but I guess that isn't strictly needed for every pixel. Some solution is certainly possible that divides the screen in a series of rectangles that can be drawn quickly, each with their own relative coordinates as far as light goes. Then you can use that same rectangle information to not do colour grading for certain boxes.

@IntelOrca

This comment has been minimized.

Show comment
Hide comment
@IntelOrca

IntelOrca Jun 2, 2016

Contributor

Getting the viewports is very easy, there is a list of them with positions and sizes. But windows can be on top of them covering them up.

Contributor

IntelOrca commented Jun 2, 2016

Getting the viewports is very easy, there is a list of them with positions and sizes. But windows can be on top of them covering them up.

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 2, 2016

Contributor

Grand!

Interestingly, because I used the paint function to insert lights, the viewport being drawn at all will guarantee there is light data for it.

Contributor

JeroenDStout commented Jun 2, 2016

Grand!

Interestingly, because I used the paint function to insert lights, the viewport being drawn at all will guarantee there is light data for it.

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 2, 2016

Contributor

Here are some major issues I will be looking into, probably in that order, but please let me know your any thoughts.

  • Divide the screen in rectangles with unique properties to remove light from interface and make multiple view-ports possible.
  • Cull lights based on being behind terrain (surface). Probably with some softening effect so they don't just all blink in and out.
  • Attempt to create a light-giving map_element, see if that survives save/load and whether it is backwards compatible; hook that up to the tile inspector; create more light types so rides can be lit with spot-lights. &c.
  • Add patterns to lights so some can have a very gentle flicker or other scenic effect

Some less major issues:

  • Add light flashes for photos by peeps or rides
  • Remove light from ride entry/exit when invisible
  • Look into CC and lanterns and see whether it may be possible to do something dirtily
Contributor

JeroenDStout commented Jun 2, 2016

Here are some major issues I will be looking into, probably in that order, but please let me know your any thoughts.

  • Divide the screen in rectangles with unique properties to remove light from interface and make multiple view-ports possible.
  • Cull lights based on being behind terrain (surface). Probably with some softening effect so they don't just all blink in and out.
  • Attempt to create a light-giving map_element, see if that survives save/load and whether it is backwards compatible; hook that up to the tile inspector; create more light types so rides can be lit with spot-lights. &c.
  • Add patterns to lights so some can have a very gentle flicker or other scenic effect

Some less major issues:

  • Add light flashes for photos by peeps or rides
  • Remove light from ride entry/exit when invisible
  • Look into CC and lanterns and see whether it may be possible to do something dirtily
@IntelOrca

This comment has been minimized.

Show comment
Hide comment
@IntelOrca

IntelOrca Jun 2, 2016

Contributor

@JeroenDStout there is one other possible solution... render to a 32bpp surface.

Contributor

IntelOrca commented Jun 2, 2016

@JeroenDStout there is one other possible solution... render to a 32bpp surface.

@IntelOrca IntelOrca referenced this pull request Jun 2, 2016

Merged

Refactor drawing #3803

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 2, 2016

Contributor

@IntelOrca For which problem do you mean? It in my view remains still best done in screenspace (post) because the light effect has no good way to sort with sprites. With a depth buffer the screenspace effect can take the depth into account a lot better. uint8 might just be enough for that but it wouldn't be rich.

Contributor

JeroenDStout commented Jun 2, 2016

@IntelOrca For which problem do you mean? It in my view remains still best done in screenspace (post) because the light effect has no good way to sort with sprites. With a depth buffer the screenspace effect can take the depth into account a lot better. uint8 might just be enough for that but it wouldn't be rich.

@IntelOrca

This comment has been minimized.

Show comment
Hide comment
@IntelOrca

IntelOrca Jun 2, 2016

Contributor

Lights need to be drawn after viewports, under windows etc. it can't all be done at the end.

Contributor

IntelOrca commented Jun 2, 2016

Lights need to be drawn after viewports, under windows etc. it can't all be done at the end.

@RobertWHurst

This comment has been minimized.

Show comment
Hide comment
@RobertWHurst

RobertWHurst Jun 5, 2016

Wow, this looks great. Never thought I'd see working night time graphics for RCT. Very nicely done :)

RobertWHurst commented Jun 5, 2016

Wow, this looks great. Never thought I'd see working night time graphics for RCT. Very nicely done :)

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 5, 2016

Contributor

I tried implementing a depth-buffer based effect to cull lights per-pixel. It works rather well, though the actual culling is quite expensive. Not updating it yet, as this is experimental, slightly buggy and doesn't work for either zoom or viewing directions.

rt light
foggy light 4

Contributor

JeroenDStout commented Jun 5, 2016

I tried implementing a depth-buffer based effect to cull lights per-pixel. It works rather well, though the actual culling is quite expensive. Not updating it yet, as this is experimental, slightly buggy and doesn't work for either zoom or viewing directions.

rt light
foggy light 4

@Nubbie

This comment has been minimized.

Show comment
Hide comment
@Nubbie

Nubbie Jun 8, 2016

Contributor

Know everyone is hyped and really want it so I'm going to be that guy:
Is there a way to turn it off? 😅

I love this PR and all, would myself always use it, heck, would even love to have a cheat so there's always night, just thinking about people with low-end PC's and people who doesn't like the concept 😄

Contributor

Nubbie commented Jun 8, 2016

Know everyone is hyped and really want it so I'm going to be that guy:
Is there a way to turn it off? 😅

I love this PR and all, would myself always use it, heck, would even love to have a cheat so there's always night, just thinking about people with low-end PC's and people who doesn't like the concept 😄

@AaronVanGeffen

This comment has been minimized.

Show comment
Hide comment
@AaronVanGeffen

AaronVanGeffen Jun 8, 2016

Member

Is there a way to turn it off? 😅

Having the game do a day-night cycle is currently opt-in already. ;)

Member

AaronVanGeffen commented Jun 8, 2016

Is there a way to turn it off? 😅

Having the game do a day-night cycle is currently opt-in already. ;)

@mrtnptrs

This comment has been minimized.

Show comment
Hide comment
@mrtnptrs

mrtnptrs Jun 15, 2016

Contributor

Is @JeroenDStout still working on this amazing feature? You have to also keep in mind that this also "has" to be made compatible with the new OpenGL renderengine. So far, it really deserves the epic-tag :)

Contributor

mrtnptrs commented Jun 15, 2016

Is @JeroenDStout still working on this amazing feature? You have to also keep in mind that this also "has" to be made compatible with the new OpenGL renderengine. So far, it really deserves the epic-tag :)

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 15, 2016

Contributor

@mrtnptrs I will be resuming work when I get a spot of time!

My first aim is to use the default rendering line but render the light mix with OpenGL. That seems a bit more stable in the short run and can eventually just be modified to use the full OpenGL rendering line.

Contributor

JeroenDStout commented Jun 15, 2016

@mrtnptrs I will be resuming work when I get a spot of time!

My first aim is to use the default rendering line but render the light mix with OpenGL. That seems a bit more stable in the short run and can eventually just be modified to use the full OpenGL rendering line.

@janisozaur

This comment has been minimized.

Show comment
Hide comment
@janisozaur

janisozaur Jun 15, 2016

Member

Yes, though this contribution will require lots of processing power, so it spurred work on opengl rendering precisely to alleviate that.

Initial version of opengl has now been merged, but it is not yet in a state good enough to offer any major advantage over software rendering. We are still working on getting it better, then the plan is for @JeroenDStout to rebase on top of that and use some newly enabled features.

Member

janisozaur commented Jun 15, 2016

Yes, though this contribution will require lots of processing power, so it spurred work on opengl rendering precisely to alleviate that.

Initial version of opengl has now been merged, but it is not yet in a state good enough to offer any major advantage over software rendering. We are still working on getting it better, then the plan is for @JeroenDStout to rebase on top of that and use some newly enabled features.

@IntelOrca

This comment has been minimized.

Show comment
Hide comment
@IntelOrca

IntelOrca Jun 15, 2016

Contributor

Unless the light FX can work without needing to redraw the entire frame every frame in software mode, it won't be fast enough for most people. Lights showing through windows is also a problem but there are ways around that.

Contributor

IntelOrca commented Jun 15, 2016

Unless the light FX can work without needing to redraw the entire frame every frame in software mode, it won't be fast enough for most people. Lights showing through windows is also a problem but there are ways around that.

@mrtnptrs

This comment has been minimized.

Show comment
Hide comment
@mrtnptrs

mrtnptrs Jun 15, 2016

Contributor

Maybe make the light FX OpenGL only or isn't that an option?

Contributor

mrtnptrs commented Jun 15, 2016

Maybe make the light FX OpenGL only or isn't that an option?

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 15, 2016

Contributor

Unless the light FX can work without needing to redraw the entire frame every frame in software mode, it won't be fast enough for most people.

It certainly can be done! It is just a matter of getting the right 'previous frame' information to each rendering call.

Lights showing through windows is also a problem but there are ways around that.

I think that will be quite possible as well; just need to catch the window position and work around it. Anything in a windowed box could be without extra light FX.

Maybe make the light FX OpenGL only or isn't that an option?

It will certainly only run via OpenGL in the sense that for the lighting calculation it will be OpenGL... it could run with soft and GL. I suppose because the CPU (or command buffers) will be the bottleneck either way I slightly suspect it will not cost too much in performance.

Contributor

JeroenDStout commented Jun 15, 2016

Unless the light FX can work without needing to redraw the entire frame every frame in software mode, it won't be fast enough for most people.

It certainly can be done! It is just a matter of getting the right 'previous frame' information to each rendering call.

Lights showing through windows is also a problem but there are ways around that.

I think that will be quite possible as well; just need to catch the window position and work around it. Anything in a windowed box could be without extra light FX.

Maybe make the light FX OpenGL only or isn't that an option?

It will certainly only run via OpenGL in the sense that for the lighting calculation it will be OpenGL... it could run with soft and GL. I suppose because the CPU (or command buffers) will be the bottleneck either way I slightly suspect it will not cost too much in performance.

@ageekhere

This comment has been minimized.

Show comment
Hide comment
@ageekhere

ageekhere Jun 17, 2016

Great work, now you need to be able to sell flashlights at the kiosk and have the peeps say "it is too dark here"

ageekhere commented Jun 17, 2016

Great work, now you need to be able to sell flashlights at the kiosk and have the peeps say "it is too dark here"

@Mte90

This comment has been minimized.

Show comment
Hide comment
@Mte90

Mte90 Jun 19, 2016

I can say only amazing and I want asap!

Mte90 commented Jun 19, 2016

I can say only amazing and I want asap!

@devnoname120

This comment has been minimized.

Show comment
Hide comment
@devnoname120

devnoname120 Jun 22, 2016

Contributor

I really like this change but I think that the background is too dark. While light effects look amazing this way, I think that it makes it hard to manage the park.

Contributor

devnoname120 commented Jun 22, 2016

I really like this change but I think that the background is too dark. While light effects look amazing this way, I think that it makes it hard to manage the park.

@X123M3-256

This comment has been minimized.

Show comment
Hide comment
@X123M3-256

X123M3-256 Jun 22, 2016

Contributor

I agree - I often find myself fast-forwarding through the night. The lighting is great when viewing the park but a bit awkward for building. I think there should be a quick way to turn the night mode on/off without going through the options menu - perhaps a toggle on the toolbar like with the fast forward?

Contributor

X123M3-256 commented Jun 22, 2016

I agree - I often find myself fast-forwarding through the night. The lighting is great when viewing the park but a bit awkward for building. I think there should be a quick way to turn the night mode on/off without going through the options menu - perhaps a toggle on the toolbar like with the fast forward?

@RobertWHurst

This comment has been minimized.

Show comment
Hide comment
@RobertWHurst

RobertWHurst Jun 22, 2016

Perhaps it turns off or the effect is reduced in build mode? Didn't RCT3 do this?

RobertWHurst commented Jun 22, 2016

Perhaps it turns off or the effect is reduced in build mode? Didn't RCT3 do this?

@JeroenDStout

This comment has been minimized.

Show comment
Hide comment
@JeroenDStout

JeroenDStout Jun 22, 2016

Contributor

Perhaps it turns off or the effect is reduced in build mode?

I feel so silly for not considering this. All I had thought of so far was either disabling it or placing a light at the next build location of tracks.

Implementing a "safe mode" which still represents the effect but in much reduced form sounds like a good option.

Contributor

JeroenDStout commented Jun 22, 2016

Perhaps it turns off or the effect is reduced in build mode?

I feel so silly for not considering this. All I had thought of so far was either disabling it or placing a light at the next build location of tracks.

Implementing a "safe mode" which still represents the effect but in much reduced form sounds like a good option.

@IntelOrca

This comment has been minimized.

Show comment
Hide comment
@IntelOrca

IntelOrca Jun 22, 2016

Contributor

I think RCT3 gives a floodlight effect when in construction mode, a much brighter ambient light. It also provides the user the ability to change from day, night and cycle in sandbox mode.

Contributor

IntelOrca commented Jun 22, 2016

I think RCT3 gives a floodlight effect when in construction mode, a much brighter ambient light. It also provides the user the ability to change from day, night and cycle in sandbox mode.

@Dracheron

This comment has been minimized.

Show comment
Hide comment
@Dracheron

Dracheron Sep 18, 2016

I'm going to go ahead and contribute some experiences about this issue, probably only for discussion immediately, though worth considering.

Most tracked rides of any sort do NOT have any light on the front of the train/car. The only exceptions I've seen so far of this is on Monorails and other transportation rides (and not all of the transportation rides will have this either).

With that in mind, would it be more realistic to add yet a fourth paint function to the coaster car paint (with this only applying to the first car if they are doing it per car, and would on default be black (black would represent no light and thus not be rendered on that car/train)). What do you guys think about this with the realism (some coaster types also do not have any lights on them at all and would be a mute issue to add a light on the front of them, such as the Floorless Roller Coaster)?

Dracheron commented Sep 18, 2016

I'm going to go ahead and contribute some experiences about this issue, probably only for discussion immediately, though worth considering.

Most tracked rides of any sort do NOT have any light on the front of the train/car. The only exceptions I've seen so far of this is on Monorails and other transportation rides (and not all of the transportation rides will have this either).

With that in mind, would it be more realistic to add yet a fourth paint function to the coaster car paint (with this only applying to the first car if they are doing it per car, and would on default be black (black would represent no light and thus not be rendered on that car/train)). What do you guys think about this with the realism (some coaster types also do not have any lights on them at all and would be a mute issue to add a light on the front of them, such as the Floorless Roller Coaster)?

@IntelOrca IntelOrca merged commit 9be8941 into OpenRCT2:develop Oct 25, 2016

1 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build failed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details

IntelOrca added a commit that referenced this pull request Oct 25, 2016

Merge pull request #4696 from IntelOrca/render/night-lights
The light effects mod branch #3798 by @JeroenDStout has become quite out of date. I plan to properly implement it, but first I want to merge in what we have already, so that I can branch off develop again and rebase (currently rebasing this branch is too difficult, far too many commits).

Most code that this is merging is protected by the __ENABLE_LIGHTFX__ directive, so it should not make any difference until its time to enable it via a new pull request.

I have isolated it as much as possible to lightfx.c.
@Patrik356b

This comment has been minimized.

Show comment
Hide comment
@Patrik356b

Patrik356b Jul 4, 2017

Lights in tunnels should be a thing to consider too

Patrik356b commented Jul 4, 2017

Lights in tunnels should be a thing to consider too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment