[OpenSCAD] Light source and default camera position different on command line

nop head nop.head at gmail.com
Sun Sep 16 08:28:02 EDT 2018

I found that calling glLoadIdentity after gluLookAt does not erase its
effect, so I think despite all the documentation on the web saying it just
modifies the modelview matrix, it must do something else.

On 16 September 2018 at 11:56, nop head <nop.head at gmail.com> wrote:

> Using the formula here: https://www.khronos.org/
> registry/OpenGL-Refpages/gl2.1/xhtml/gluLookAt.xml I hand calculated the
> modelview matrix to be
> 1  0  0  0
> 0  0  1  0
> 0 -1  0  0
> 0  0  0  1
> Which looks like a 90 degree rotation about X to me. When this is
> overwritten by the identity matrix how does that affect the lights, which
> are supposed to be fixed relative to the eye and not the view of the model?
> It's getting on for 20 years since I last did OpenGL but this is doing my
> head in.
> On 16 September 2018 at 11:00, nop head <nop.head at gmail.com> wrote:
>> Yes I have reviewed them and they all see to just differ in lighting,
>> apart from the few that fail on my machine due to different Z fighting. If
>> I update those for the lighting change then presumably they will fail on
>> somebody else's hardware. Is that OK?
>> I am thinking the vector mode can only do a subset of the gimbal mode
>> because it can't rotate around Y. If so, to avoid GUI and command line
>> diverging again, we can remove all the vector camera code and just convert
>> command line vector parameters to gimbal parameters.
>> If we do unify the camera modes we have some decisions to make. As well
>> as lighting differences the default view is at a different angle and
>> distance. The command line looks towards the first quadrant at a shallower
>> angle [70.53, 0, 315]. The GUI looks at the second quadrant with a steeper
>> downwards angle [55, 0, 25] The default distance is 500 on the command line
>> but 140 in the GUI.
>> I think looking to the first quadrant is more logical, so the azimuth
>> should always be 315. To avoid big changes to the tests I think we should
>> adopt 70 for the altitude. That will make tiny changes to the tests but the
>> lighting means they all need regenerating anyway.
>> Distance 500 means you can see about +/- 100 in the Y direction. 140
>> shows about +/- 30. I propose to make the GUI distance 500 to match the
>> command line and the tests. When you reset the view it is better to be able
>> to see more.
>> Although I have fixed the lighting bug I don't totally understand why. I
>> think when you call gluLookAt with the centre at the origin and the eye on
>> the X axis you will end up with a matrix similar to the identity matrix but
>> with a few different signs. I don't understand how that can change the
>> lighting without altering the view in any other way. If the modelview
>> matrix is different in any way, surely the view should change spatially?
>> On 16 September 2018 at 00:55, Marius Kintel <marius at kintel.net> wrote:
>>> > On Sep 15, 2018, at 8:18 AM, nop head <nop.head at gmail.com> wrote:
>>> >
>>> > The few tests that failed now pass and all the vector camera tests
>>> fail, about 40% of the total. Is there a quick way of updating all the test
>>> images or do I have to manually dig them out and replace them all?
>>> >
>>> Regenerating failing tests is a necessary evil, and requires some manual
>>> review.
>>> ..but we can automatically generate these expected files on the cmd-line:
>>> $ TEST_GENERATE=1 ctest -R <test regex>
>>> Some info here, but not too well organized:
>>> https://github.com/openscad/openscad/blob/master/doc/testing.txt
>>>  -Marius
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss at lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscad.org/pipermail/discuss_lists.openscad.org/attachments/20180916/967943a7/attachment.html>

More information about the Discuss mailing list