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

Clientside hologram custom mesh lighting screwed up when halo is drawing #680

Open
thegrb93 opened this issue Sep 16, 2019 · 3 comments
Open

Comments

@thegrb93
Copy link
Owner

No description provided.

@thegrb93 thegrb93 added the bug label Sep 16, 2019
@thegrb93
Copy link
Owner Author

@Neatro
Copy link
Contributor

Neatro commented May 8, 2020

Possible fix
I might've found a possible fix, and it's to run ENT:DrawTranslucent() before drawing the mesh.
this will fix the lighting, though it's a bit of a hacky workaround, since the color of the original hologram model has to be set to Color( 0, 0, 0, 1 ) (or any other color with alpha 1).

Additional information to the possible fix
I've been writing a Voxel engine, and drawing the meshes always turned out to look bad, so i had found this as a fix for drawing the mesh.

render.SuppressEngineLighting( false )
if self.mesh then
self:DrawTranslucent() --draw itself, but it should be hidden
render.OverrideDepthEnable( true, true ) --fix depth 
render.SetMaterial( Voxy.VAtlas, true ) --set material
self.mesh:Draw() --draw wanted mesh with correct lighting now
render.OverrideDepthEnable( false, true ) --default again
end

and to hide the original hologram model, i set the color to Color( 0, 0, 0, 1 )

The Material used on the mesh used VertexLitGeneric as shader and uses $alphatest 1, therefore the render.OverrideDepthEnable() function.

render.SuppressEngineLighting( false ) was just to make sure i did get lighting, might be obsolete in this case though, since it's usually false by default.

Theory
My theory on why the mesh's lighting bugs out like it does is probably because the model has to true "lighting origin", so it doesn't know where to grab the "lighting origin" from, instead, it probably grabs the lighting origin from another rendered entity, or entity in view (that might not be in PVS) which has a lighting origin either located outside the map area (which is why the mesh turns out to be dark, as if it's not lit at all), or shaded weirdly, like as if it's put in a dark garage, even though it's outside in a bright light.

I think it's a similar bug relating to why you can't really use VertexLitGeneric on GUI rendered elements in some cases, causing corners or vertices of the rendered (textured) objects and/or shapes to discolor or just become black. In this case you'd use Unlitgeneric as your material shader to fix it, which is not a nice solution for meshes that are in the world, as you'd lose the dynamic lighting. The above fix seems to be reliable to mitigate the issue.

@Neatro
Copy link
Contributor

Neatro commented May 8, 2020

Additional comment, this lighting bug also happens in general, even when it doesn't seem that halos aren't even drawn at all, the possible fix should still fix the issue though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants