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.

Sign up for GitHub

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

Jump to bottom

Compute sprite vertexes on CPU, not with GLSL #1281

Draft
wants to merge 4 commits into
base: master
Choose a base branch
from
Draft

Compute sprite vertexes on CPU, not with GLSL #1281

wants to merge 4 commits into from

Commits on Sep 19, 2024

  1. Don't omit light factor when using depth fade 

    The overbright correction shouldn't be skipped here.
Currently all depth fade assets also use vertex sprite so the
USE_DEPTH_FADE variant of the depth fade code is never run,
only the USE_VERTEX_SPRITE one.
    @slipher
    slipher committed Sep 19, 2024
    Configuration menu
    Copy the full SHA
    40c3fe3 View commit details
    Browse the repository at this point in the history

  2. Tess_SurfacePolychain: don't skip tangents randomly 

    I needed this to test depth fade with /testshader
    @slipher
    slipher committed Sep 19, 2024
    Configuration menu
    Copy the full SHA
    3ade40a View commit details
    Browse the repository at this point in the history

  3. Do autosprite calcs with CPU, not GLSL 

    Get rid of vertexSprite_vp.glsl/USE_VERTEX_SPRITE and return to doing
deformvertexes autosprite/autosprite2 vertex calculations on the CPU
(like it was until 2015). This fixes various bugs with autosprite[2]
BSP surfaces. Also it
fixes some particle systems which were broken for unknown reasons.

One problem with the vertex sprite GLSL is that it always applied depth
fade, regardless of whether it was requested. Depth fade means the alpha
will be reduced if there is something close behind the particle within a
certain depth (judging by the z buffer). With autosprite1, this depth
parameter was set equal to the size of the sprite. So it is like a
cube-shaped cloud (which matters when part of the cloud is inside a
wall). The shader-specified fade depth, if any, was ignored. With
autosprite2, the shader used a negative depth parameter, which just
breaks everything. By removing unwanted depth fade for
BSP surfaces, this fixes #997
(non-opaque autosprite2 BSP surfaces do not show up, as seen with the
various flames on KOsAD's metro map).

Also depth fade will no longer be automatically applied to all
particles. I believe we have just 3 Unvanquished shaders configured with
depth fade: acid tube acid, booster effect, and grenade smoke. Any other
particles could potentially look different due to removing depth fade.
So we may need some asset changes to adjust to this change.

Another issue is that USE_VERTEX_SPRITE was not available for lightmap
shaders. This meant that vertex positions were out of sync between
the generic and lightmap shaders, and the lightmap shader failed to render
anything. So this commit fixes #1246 (wrong lighting for autosprite[2]
BSP surfaces with lightmaps, as seen on map "defenxe") by calculating
the final vertex positions before uploading them, which ensures they are
the same for all GLSL shaders used.

With this commit, some particles that were previously not visible are
now rendered, for example:
- ones with the gfx/players/alien_base/green_acid shader
  which are emitted upon evolving, or damaging or destroying an alien
  buildable
- orange glowing "mark" (which is actually a particle) added at impact
  point of several weapons (rifle, shotgun...)
I believe the problem must have been that Tess_AddSprite
oriented the triangles backward (CW instead of CCW or vice versa). And
unlike most particle shaders, the acid one fails to specify double-sided
culling, so it would disappear if oriented backward.

To implement CPU-side autosprite/autosprite2 transformations, I took the
code from an old (~2015) version of the file. But I ended up completely
writing the autosprite2 one.

When autosprites were first implemented in GLSL, there was also a
change in how the polygon is positioned: in the GLSL implementation it
faces towards the viewer, rather than Tremulous' behavior to face
opposite the view direction. I decided that the GLSL behavior is
superior for autosprite2 and reimplemented the CPU version that way (but
you can get the old behavior by setting the r_autosprite2Style cvar).
For autosprite the old behavior seems good enough so it once again faces
opposing the view direction.

This commit makes autosprite2 surfaces work with material system enabled
for the first time, by virtue of rendering them without using the
material system.
    @slipher
    slipher committed Sep 19, 2024
    Configuration menu
    Copy the full SHA
    0dad856 View commit details
    Browse the repository at this point in the history

  4. Make particles face in view direction (not toward viewer) 

    Make RT_SPRITE entities whose shaders were registered with RSF_SPRITE
face opposite the view direction, instead of toward the viewer. This
prevents pathological cases where the normal of a closeby sprite
is oriented nearly orthogonally to the view direction, making its 2-D nature
obvious and ugly. I found that to happen with the alien evolve acid
particle system if I walked backward right after evolving from Dretch to
Mantis.

RT_SPRITE entities without the RSF_SPRITE shader flag continue to face
toward the viewer. Light flares go in this category.
    @slipher
    slipher committed Sep 19, 2024
    Configuration menu
    Copy the full SHA
    d440b4f View commit details
    Browse the repository at this point in the history