lightposition behaves weirdly
See original GitHub issuelightposition
behaves similarly for both mesh3d
and surface
, but it’s nearly unusable. Generally x is left (-) to right (+) and y is bottom (-) to top(+), but z has effects that defy easy categorization other than z=1 being “special”. Sometimes x and y flip randomly, and anyway they don’t seem to have the same scales, ie x=y does not put the light at 45 degrees.
Issue Analytics
- State:
- Created 6 years ago
- Comments:6 (4 by maintainers)
Top Results From Across the Web
opengl light position changes weirdly - c++
When I use glRotatef to change the diretion of the objects(table and cups) which are created by my own using plenty of triangles(I...
Read more >ofLight Positioning weirdness? - advanced
Hi, I am getting some weird light shading behavior on the simplest ... with a properly placed Push/Pop,the light behaves in a weird...
Read more >Lights behaving oddly
However, the running lights do not come on with the switch in the running light position and when the headlights are switched to...
Read more >Weird Shader Behavior - Graphics and GPU Programming
The toon shader from Lighthouse3D behaves similarly poorly. I'm assuming that, since nearly every site references Lighthouse3D for their per-fragment ...
Read more >opengl - Unexpected lighting on cube
Instead, the cube gets lit in a very weird way, with some lit areas and some dark areas, in a way that doesn't...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
flatshading
definitely helps - in fact without it I can’t really figure out any physical meaning to the lighting ofmesh3d
traces, but with it there does seem to be, for any givenlightposition
, a light that looks like it’s coming from somewhere fixed wrt the scene as the scene is rotated. And moreover that fixed somewhere is the same for all traces. So based on that alone I’d probably enableflatshading
by default. And I’m highly in favor of standardizing all thelightposition
defaults to something with intelligible consequences, with all traces matching each other. In fact, can we add ascene.lightposition
that all the traces in a scene inherit from if not provided at the trace level?Now, as to where this light appears to be, my description above still seems to hold. I’d add that when both x and y are fairly small (±hundreds or less) or when z is significant (<-10 or >1) it no longer seems possible to assign the light a fixed position as the scene rotates - I can align the cubes or saddle surfaces in what should be symmetric viewpoints (90-degree rotations of the cube, 180-degree rotations of the saddle) and I get different light regions.
So I definitely would not close this issue. To me this would be closed when the meaning of
lightposition.x/y/z
can be precisely defined, something like:I don’t mind waiting on this - doesn’t seem like we have anyone who particularly cares about this. But it’s definitely still a bug.
Here's the dash app I'm using to play with this, based on your codepen @archmoj, plus sliders for `lightposition.x/y/z`. It's actually quite responsive, even though I'm sending the whole figure up with every mousemove. Go `Plotly.react`!
Further, it seems that there is some degree of control available to the light’s position in Z, but I don’t see any change in X, Y