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

Remove Opacity Fader from Plasma flare function #319

Merged
merged 2 commits into from
Mar 13, 2022

Conversation

DoobesURU
Copy link
Contributor

Removes opacity fader from the flare mod, which has been causing problems for end users.

I'm open to possibly adjusting the settings to make things work properly initially if that's preferred. Currently, the settings cause the flares to "blink" out at odd angles per both myself and Tweek. It could also be argued that it could/should be left up to the end user whether to add it.

Takes out opacity fader, which has been causing problems for end user.
@Hoikas
Copy link
Member

Hoikas commented Mar 4, 2022

There was a bug, which could impact an object's visibility in the fade mod, that was fixed in #300 after Korman 0.12a released. Have you and/or Tweek tested that the issue is still present with this fix?

@Jrius
Copy link
Collaborator

Jrius commented Mar 5, 2022

I also noticed two problems with the opacity fader when its fading is set to line-of-sight, which seems unrelated to the fix Hoikas mentioned:

  • LOS fails to be occluded by some rare multilayer objects (even though the material writes to the depth buffer). I couldn't figure out why, since it responded correctly to other objects. Could be a very uncommon bug though.
  • LOS performance is bad and scales horribly with number of triangles in the scene (especially near terrain, since those require more vertices).

Due to the performance cost, I'm in favor of removing it from the template. Best we avoid the users some tedious troubleshooting IMHO...

@DoobesURU
Copy link
Contributor Author

FWIW, after implementing #300 to my local scripts and exporting, things seem to be working as they should. Still, as @Jrius said, it'd probably be best to exclude the fader in the template just to keep things simple. IMHO, of course.

@Deledrius
Copy link
Member

Deledrius commented Mar 7, 2022

The purpose of these helpers is to set a consistent baseline quality level that is easy for artists to use. If it's not accomplishing that, then it's probably a good idea to remove the part that's not working.

I'm glad to hear that the primary bug reported here has already been fixed, but the performance issues are definitely an important question as well. We don't want to be littering Ages with something that tanks performance. I do wonder (not knowing enough about the rendering pipeline) how fixable this is. Is this an issue that can be fixed relatively easily now that eyes are on it, or does it fall under "needs a complete rendering rewrite" to improve? If this can't easily be fixed, and soon, then I agree it would be best to remove the Opacity Fader from the default flare.

@Jrius
Copy link
Collaborator

Jrius commented Mar 7, 2022

Is this an issue that can be fixed relatively easily now that eyes are on it, or does it fall under "needs a complete rendering rewrite" to improve?

Needs a complete rewrite. (Not of the whole renderer, mind you, but of the LOS code.)

The LOS is computed on the CPU by the plVisLOSMgr. It casts a ray through the space tree, and checks which drawables are hit. If any of those drawables are hit, then it naively proceeds to check whether the ray is intersecting with ANY triangle in the mesh. There is the bottleneck, when a terrain with 30k triangles overlaps the flare.

There is no fix that isn't a major PITA to implement, unfortunately. Using GPU queries (prediction query on D3D, occlusion query on OGL) seems to be the "correct" way to fix this, AFAIK. This is what Blender uses when selecting objects. I guess alternatively, one could also just sample the depth buffer ? In either case, this requires fiddling with the plPipeline and hoping the features are available to D3D9's fixed function pipeline.
(Or, if you're a madlad, you could put the whole rendered geometry into PhysX and raycast against it, like cameras do.)

In any case, we don't want that modifier enabled by default for PotS (or at least, not with LOS fading).

Now that I think about it @DoobesURU, it would also be a good idea to disable "skip depth test" on the flare's layers so they aren't drawn over other geometry. (That's a shame since it doesn't look as good 😢 )

Removes the Skip Depth Test (per Jrius) while also implementing updated emissive functions.
@DoobesURU
Copy link
Contributor Author

DoobesURU commented Mar 7, 2022

Now that I think about it @DoobesURU, it would also be a good idea to disable "skip depth test" on the flare's layers so they aren't drawn over other geometry. (That's a shame since it doesn't look as good 😢 )

Agreed. I removed that and also gave the material and texture the proper emissive properties instead of making it shadeless.

@Hoikas
Copy link
Member

Hoikas commented Mar 13, 2022

I think, with all these things considered, and with LOS not being blocked by avatars until H-uru/Plasma#980 that this is probably for the best. At some point, I think I would like to see this type of flare be available as an option, however, for Ages that have spare room in the performance budget. The effect is quite nice.

@Hoikas Hoikas merged commit f5f0147 into H-uru:master Mar 13, 2022
@DoobesURU DoobesURU deleted the RemoveFlareOpacityMod branch March 19, 2022 23:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants