Missing candle flame/fire in Metro map #997
Labels
Comments
|
Missing flame:
|
|
I have work in progress for nuking the GLSL-based autosprite implementation as described in #1246 (comment). I guess the flames must all be rendered with the
|
|
Excellent! |
Actually I think those specifically were broken because they are not opaque. The depth fade code intended for soft particles (unwantedly) runs for all sprites, including BSP ones. For opaque surfaces, alpha is ignored so the depth fade has no effect. For autosprite2 surfaces, the depth fade code gets run with a negative depth value which results in undefined output from the GLSL |
slipher
added a commit
that referenced
this issue
Sep 7, 2024
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. All 'cloud of gas'-type effects. Any other particles could potentially look different due to removing depth fade. However, I have failed to notice any (other than broken ones that started working). For small particles, the depth fade is unlikely to make any difference. 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: the ones with the gfx/players/alien_base/green_acid shader which are emitted upon evolving, or damaging or destroying an alien buildable. 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
added a commit
that referenced
this issue
Sep 9, 2024
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
added a commit
that referenced
this issue
Sep 19, 2024
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
added a commit
that referenced
this issue
Oct 4, 2024
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
added a commit
that referenced
this issue
Oct 7, 2024
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 with green_acid 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. The problem with the orange mark (and some other impact particles) is that it is positioned very close to the surface. The alpha more or less goes to zero when using depth fade, if you are looking from a direction close to the impact surface's normal. The impact mark particle was only visible from tangential angles. 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
added a commit
that referenced
this issue
Oct 7, 2024
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 with green_acid 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. The problem with the orange mark (and some other impact particles) is that it is positioned very close to the surface. The alpha more or less goes to zero when using depth fade, if you are looking from a direction close to the impact surface's normal. The impact mark particle was only visible from tangential angles. 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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Extracted from this issue that described two bugs:
This thread is for the missing candle flame/fire sprite effect.
It is believed the bug is related to:
The text was updated successfully, but these errors were encountered: