Skip to content
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

WIP: renderer: merge lightmap and vertex (lightgrid) world and entity lighting #301

Open
wants to merge 4 commits into
base: master
from

Conversation

@illwieckz
Copy link
Member

illwieckz commented Mar 9, 2020

Also includes commits from #300.

This is work in progress. There is currently a nasty bug that makes it unmergeable.

This merges world lightmapping glsl, world lightgrid lighting glsl (wrongly called vertex world) and entity lightgrid glsl (wrongly called vertex entity).

This prevent the risk of mistakes by not copy pasting 90% of the same code between files. This also helps to improve feature parity between all rendering options.

It makes possible to do or to implement:

  • normal mapping on maps without deluxe maps (useful to improve legacy maps)
  • deluxe mapping disablement to rely on lightgrid direction instead (useful for debugging purposes, this may also use less gpu memory)
  • render some world part with lightmap and other world part with lightgrid like moving platforms to avoid moving shadows and to enable ambient lighting on them instead.
  • lightgrid lighting with deluxe map-based normal lighting (I don't see any usage, but it would work)
  • do reflective specular on world (what is it?)

Also it would be possible to implement rim lighting on world but I don't think there is any usage for that, in any way it would be very easy to do.

The implementation is rendering properly world and entities using either light maps or light grid, and normal maps are rendererd properly using either deluxe maps or light grid.

BUG: an unknown bug that is not yet solved is making some surfaces going void (like if all their pixels were discarded) depending on the angle of view? Once this bug is fixed this change may be mergeable I guess. I need help to fix this bug.

@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Mar 9, 2020

Once this is merged, merging cube reflection within diffuse lighting stage would only require to edit one glsl code instead of three, same for any future feature we would want to add.

Maybe one day we would be able to also merge the liquid code.

@illwieckz illwieckz force-pushed the illwieckz:glslmerge branch from fe0119e to 3c2aed7 Mar 9, 2020
@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Mar 9, 2020

The “invisible surface” bug related to viewing angle is probably not in GLSL code.

The bug is probably not in lightMapping_fp.glsl file (fragment program) since replacing the whole main by a simple 3-èline code displaying the diffuse texture is reproducing the bug. There is very low chance the bug would be in lightMapping_vp.glsl file (vertex program) since this file is small and simple.

On C++ side, there is low chance the bug would be in gl_shader.cpp or gl_shader.h (code is not very complex). So there is high chance this code is in tr_shade.cpp.

@illwieckz

This comment has been minimized.

Copy link
Member Author

illwieckz commented Mar 10, 2020

One interesting thing is that the code stores lighgrid1 (used to compute light color) as lightmap when lightmap is disabled or unavailable, and stores lightgrid2 (used to compute light direction) as deluxemap when deluxe map is disabled or unavailable. This way there is only two binds for light color and light direction whatever the combination of features used. Then some #ifdef enable the related code in GLSL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

1 participant
You can’t perform that action at this time.