The skybox should use glDrawElements and a cubemap shader
jdolan opened this issue · comments
The current skybox is literally a huge box. This is simple and easy to understand, but it has its problems:
-
Because the sky vertexes are very far away from the view origin, they are almost always under-sampled by the fog shader. The lightgrid, where the fog comes from, is clipped to the BSP bounding box. This means that for most of the sample positions tried for each sky fragment, there is simply no fog to be had.
-
Sky faces can no longer occlude world geometry. Some levels actually rely on this (unrealistic) trick to "hide" world geometry in the sky. An example of this is the upper conveyor belt on Warehouse. With our current big sky box, the conveyor belt is visible "in the sky" instead of being occluded.
A better solution would be to include bsp_draw_elements_t for sky faces in the BSP file, and then render only those draw elements in the sky shader, using a cube map to project the correct texture coordinates that simulate a distant sky. This would address both of these problems, and may even perform better than the current implementation, which suffers from a lot of overdraw.
@SpineyPete this was your idea (the cube map shader). Do you have any thoughts, or any resources to share on how to do this well?
The changes to include draw elements for sky faces in quemap are trivial, but I know I have the most familiarity with quemap. I can make those for whoever wants to take this issue on, if that would be helpful.
This looks fairly trivial:
This is now implemented, but there is a visual bug. The top and bottom images of the skybox are rotated, or mirrored, and I'm not sure why. All sides of the skybox look correct and seamless. This has something to do with Quake's odd orientation (Z up). I tried several swizzles on the texture coordinate, and I even tried sending a matrix that includes Quake orientation and the view origin. I was actually able to achieve the same exact (wrong) result with both methods.
@Paril or @SpineyPete would either of you mind looking at this?
Side note, pull data and rebake q2dm* to test this. Most of our .map files had SURF_NO_DRAW on half of the sky surfaces.
@Paril Thank you for your work on stitching the skyboxes together and adjusting the loading code to handle them. This is so much cleaner!
You mentioned that the fog still doesn't look right on the sky geometry. Does this warrant further work, or do you think it's acceptable for the typical global fog we use on levels?
Love how fast Paril got the merged skyboxes to work. The new system is much more practical.
For the AO-ish fog, we could solve this by decoupling global and local fog. The global fog will be distance based, we already compute the distance before raymarching, so blending it in somewhere in the pipeline there will probably work. I started to work on that but got sidetracked. Distance based global fog doesn't rely on the lightgrid so it shouldn't have the artifacts, and the artifacts are mostly visible due to high density global fog.
Yep, I recall that idea. I would love to not have separate fog implementations, if at all possible. We have a nice noise implementation for the lightgrid approach. It looks really good, and the entire implementation is relatively clean and easy to follow. If we can either tune the approach in the sky shader, or just live with it (I haven't seen these artifacts at 'normal' global fog densities), that is definitely my preference.
The real reason I want distance based fog back is because it fades more naturally with distance than the current sampling approach. This was the reason why I went with the fixed-step-size approach which solved that but turned out to be too expensive. I'll see if I can get it to work in a feature branch and play nicely with the volumetric fog we have now. Two different approaches sound like shit unless they're unified naturally inside the same function, so that's a requirement for me.
Our foggiest map, Tokays Towers, has nice noisy fog and the sky looks great. I'm calling this one done :)