-
Notifications
You must be signed in to change notification settings - Fork 62
WIP: renderer: compute normalmap from heightmap when missing normalmap, aka bumpmap #258
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
base: master
Are you sure you want to change the base?
Conversation
hmmm, currently that code seems to only run with lightMapping glsl shader, I'll enable vertex ones later. This does not prevent to review the code as it would just require some boilerplate to plug the feature in other glsl shaders, in fact this single line: gl_lightMappingShader->SetNormalMapFromHeightMap( hasHeightMap && !hasNormalMap ); |
48c242b
to
7b71475
Compare
Hmm, the normalmap computation itself seems to be OK. but, I was testing it with Xonotic's solarium map which has such kind of "bumpmap" and everything looked good, until I remembered I had disabled normalScaling and then, all the classic normalmaps (not computed ones) were using DirectX format, hence meaning that if the generated normalmap from heightmap looks good, it is produced produced reverted the DirectX way… Which makes sense since I mostly read HLSL examples and found no one GLSL example to read to implement this. I may edit the |
I prefer to merge this after #260 (renderer: fix normalmap dark blotches) in order to be able to reuse the normalmap dark-blotch fix instead of duplicating it. |
0d83c91
to
50ed18e
Compare
Any screenshots? What should we see if it is working? |
I'll do screenshot, I also want to make a test map. |
The generated normal map from heightmap is the sand on the beach (using So, this is with sobel filtering: With the other less good but faster algorithm: Close look, with sobel: Without: Fully textured render, with sobel: Without sobel: Without normal map computation (flat normal map): |
08e6a21
to
0639b68
Compare
What seems to be is missing is a decision of how steep of an angle a certain height delta represents. So trying to reason this out geometrically... Now so far you've calculated your height differential over 1 pixel in the x direction. So the heightmap should have some physical scale for the difference between a value of 0 and a value of 1 (I don't suppose there's any standard for this?) which you would multiply by to get the physical delta-height. And you have a physical delta-x which is the distance between neighboring pixels on the texture. So (physical delta-x, 0, physical delta-height(x)) would be a tangent vector to your surface. And with reasoning from the y-coordinate calculations, another tangent is (0, physical delta-y, physical delta-height(y)). Then you could cross-product those to get a normal vector. |
I'm not sure to have the knowledge to fully understand that (euphemism). |
…a bumpmap compute normalmap from heightmap when missing normalmap, also known as bumpmapping two algorithms available: - one naive that does the job, uses 3 samples - one advanced that does better job, uses 8 samples (sobel operation) a new cvar is added: r_sobelFiltering, which would be used to disable or enable various sobel filtering operation including this one the engine is likely to implement other sobel filters in the future, for example DarkPlaces has a postprocessing effect that does such kind of compute, maybe Dæmon based games will want such kind of effect, in this case a common cvar to enable or disable various sobel compute does not look bad the r_sobelFiltering cvar is enabled by default
I rebased this on master after the great merge. |
compute normalmap from heightmap when missing normalmap, also known as bumpmapping
two algorithms available:
a new cvar is added:
r_sobelFiltering
, which would be usedto disable or enable various sobel filtering operation including this one
the engine is likely to implement other sobel filters in the future,
for example DarkPlaces has a postprocessing effect that does such kind of compute,
maybe Dæmon based games will want such kind of effect, in this case
a common cvar to enable or disable various sobel compute does not look bad
the
r_sobelFiltering
cvar is enabled by default