I am having a devil of a time with GLLines in 3-space. Attached is a screenshot of an example. Both points are in positive space, and the 2nd point is supposed to go UP, but instead dives down into negative space.
The nodes are added via Nodes.AddNode() and it does not matter whether the points are added via (.x .y .z) or as a taffinevector. As you can see from the screenshot both the UP and Direction settings are shown. The first point is correctly placed, however, EVERY point provided after that is incorrect, regardless of value.
I am using the GLScene version provided in codetyphon 6.8 on Linux.
I need to provide absolute coordinates and get them plotted without having to guess where they are going. Can anyone provide documentation on what EXACTLY the direction property is supposed to do? I undertand the up property defines whether the axes are XZY or XYZ, however I can find no documentation on what the Direction property is supposed to be doing. I can guess, but guessing is not documention.
A similar issue is happening with GLPipes though I suspect that they share code.
Is this a bug, or am I doing something incorrectly?
Thanks in advance
Lynne
BTW, I have over 20 years of programming experience and am not a novice.
I have never fully understood the meaning of the confusing ‘up’ and ‘direction’ properties, but it should not be necessary to use them. At least I use both points and lines without worrying about them. It is sufficient to add the points as you do, as long as you remember that the coordinate system in OpenGL is right hand, with Y going up. When viewed from the front, X is to the right, Y is up, and Z is towards you.
I am having a devil of a time with GLLines in 3-space. Attached is a screenshot of an example. Both points are in positive space, and the 2nd point is supposed to go UP, but instead dives down into negative space.
The nodes are added via Nodes.AddNode() and it does not matter whether the points are added via (.x .y .z) or as a taffinevector. As you can see from the screenshot both the UP and Direction settings are shown. The first point is correctly placed, however, EVERY point provided after that is incorrect, regardless of value.
I am using the GLScene version provided in codetyphon 6.8 on Linux.
I need to provide absolute coordinates and get them plotted without having to guess where they are going. Can anyone provide documentation on what EXACTLY the direction property is supposed to do? I undertand the up property defines whether the axes are XZY or XYZ, however I can find no documentation on what the Direction property is supposed to be doing. I can guess, but guessing is not documention.
A similar issue is happening with GLPipes though I suspect that they share code.
Is this a bug, or am I doing something incorrectly?
Thanks in advance
Lynne
BTW, I have over 20 years of programming experience and am not a novice.
Thanks everyone for the input. The camera's up and direction properties match those of the gllines.
I've also found during testing that if the camera's "autoleveling" property is set to true the camera will invert (turn upside down) instead of leveling. I am thinking something got broken at pilotlogic with the vector math.
In response to the direction/up. Changing one will totally screw the other. So they are supposed to be connected in some way but from what I'm seeing, there is no documented reasoning for both of them to exist for gllines and glpipes. One could see a reasoning for a camera: Up is how the camera is oriented and direction is which way it is pointing. Such things do not exist for gllines and glpipes so (IMO) direction needs to go away for these.
Upon further testing, it seems that if I type the values into a gllines entry from the GUI, the line is displayed properly. But clearing the nodes and adding it to the exact same gllines entry in runtime results in the erroneous behavior.
In any case, none of this solves my problem.
Lynne
Last edit: Lynne Stone 2019-10-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Lynne first the CodeTyphon's GLScene is based on the current Delphi branch . I don't have the "Autolevelling" property in Lazarus. But Pavel could be verify this.
Such things do not exist for gllines and glpipes so (IMO) direction needs to go away for these.
A line can be described by a Direction and an Length. This direction must be compute with the start and the en point if present. So if you change the Dir of one point it's normal to have "bad value". The up is not essential for a line so just discard this with line .
But remove it it's not possible because those properties are commons and shared by all 3D objects like the position or the rotation
Upon further testing, it seems that if I type the values into a gllines entry from the GUI, the line is displayed properly. But clearing the nodes and adding it to the exact same gllines entry in runtime results in the erroneous behavior.
Hum, it will be fine to trace the code for see where is the problem at runtime. When i'll have more free time, i try to make some test with Lazarus
Can you try with bigger values like 1,2 --> 1.8 ... instead of 0.02 --> 0.03, 0.87 --> 0.88 etc....
Best regards
Sorry for my bad english ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jerome,
Firstly, your English is fine, no worries there.
The AUTOLEVELING property is in the Lazarus setup for CodeTyphon on my Linux (partial screencap included), however as mentioned previously, it doesn't function correctly. That property has been available as far back as CodeTyphon 6.1, and the same error exists there. It may even exist earlier than that, but 6.1 is the earliest installed version I have available on any of my machines.
As far as the "lines" go, it is indeed possible to describe a line with an origin point, a direction and a magnitude. However, in 3 of 4 modes TGLLines does not work this way (designtime also uses absolute coordinates). TGLLines provides 3 absolute position AddNode modes (no magnitude) and only a single AddNode that includes a TVector with a magnitude.
In 75% of its use cases TGLLines points are described by a series of absolute positions in 3-space placed in the nodes list - (x,y,z) in either float, TGLCoordinates, or TAffineVector. In these cases, the UP property makes sense in that it defines the coordinate space (XZY XYZ ZYX ZXY etc) and the DIRECTION property plays no meaningful part. However, the DIRECTION property will modify the UP property absolutely and will not be ignored. A value must be provided to DIRECTION and the library will use this value to recompute the UP values absolutely.
It is my thought that code for the 4th mode, AddNode using TVector (which includes a magnitude), has introduced an error into the absolute position modes. I have not yet delved into the source for TGLLines deeply because I wanted to see if I was just using something incorrectly before spending the time tracing through hundreds of lines of code.
As for the using the larger values, the points provided above were scaled down by 2 orders of magnitude so that they could fit into a screen space that could be seen when posting. In their normal scale the line dives ~89 units into the negative space from ~89 units in the positive space. In order for the camera to show this it has to be so far away that the line is so tiny it cannot realistically provide meaningful information.
I am just guessing, but, GLScene uses single precision floats which gives you 7-8 significant digits. If you add points with more digits than that, you could get strange results.
Hi Jerome,
Firstly, your English is fine, no worries there.
The AUTOLEVELING property is in the Lazarus setup for CodeTyphon on my Linux (partial screencap included), however as mentioned previously, it doesn't function correctly. That property has been available as far back as CodeTyphon 6.1, and the same error exists there. It may even exist earlier than that, but 6.1 is the earliest installed version I have available on any of my machines.
As far as the "lines" go, it is indeed possible to describe a line with an origin point, a direction and a magnitude. However, in 3 of 4 modes TGLLines does not work this way (designtime also uses absolute coordinates). TGLLines provides 3 absolute position AddNode modes (no magnitude) and only a single AddNode that includes a TVector with a magnitude.
In 75% of its use cases TGLLines points are described by a series of absolute positions in 3-space placed in the nodes list - (x,y,z) in either float, TGLCoordinates, or TAffineVector. In these cases, the UP property makes sense in that it defines the coordinate space (XZY XYZ ZYX ZXY etc) and the DIRECTION property plays no meaningful part. However, the DIRECTION property will modify the UP property absolutely and will not be ignored. A value must be provided to DIRECTION and the library will use this value to recompute the UP values absolutely.
It is my thought that code for the 4th mode, AddNode using TVector (which includes a magnitude), has introduced an error into the absolute position modes. I have not yet delved into the source for TGLLines deeply because I wanted to see if I was just using something incorrectly before spending the time tracing through hundreds of lines of code.
As for the using the larger values, the points provided above were scaled down by 2 orders of magnitude so that they could fit into a screen space that could be seen when posting. In their normal scale the line dives ~89 units into the negative space from ~89 units in the positive space. In order for the camera to show this it has to be so far away that the line is so tiny it cannot realistically provide meaningful information.
Thanks for the response, Lars. I thought the same thing early on. I considered that there might be an overflow condition occurring. However, I ran the tests using only 3 significant digits with the same results. As I stated starting out, the situation occurs regardless of the value of the 2nd point. Even using integer values causes the issue.
The more I look into this the more I'm thinking something got seriously broken in the vector computation routines. To me, it is acting like once there is an 'anchor point' the code is trying to convert all following points into TVector draws instead of staying with absolute positioning. What supports this is that the following points after the 'dive' are 'almost' correct (except that all points become planar -- another indication of vector mathematics errors) and resemble the curve they are supposed to represent, except now in 2-space instead of 3-space.
It may be that someone tried to be "too elegant" and make a single routine handle all 4 procedure calls instead of staying with the simple route of separate code for vector and absolute.
I am going to attempt to put together a custom Lazarus build with the fixes outlined in the Lazarus area to see if the guys over at pilotlogic did indeed make an error or if this is a more pervasive problem in the GLScene trunk.
Lynne
PS
It seems that there are now other reports of problems that can be possibly attributed to vector miscalculations.
Last edit: Lynne Stone 2019-10-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, this is my first post here.
I am having a devil of a time with GLLines in 3-space. Attached is a screenshot of an example. Both points are in positive space, and the 2nd point is supposed to go UP, but instead dives down into negative space.
The nodes are added via Nodes.AddNode() and it does not matter whether the points are added via (.x .y .z) or as a taffinevector. As you can see from the screenshot both the UP and Direction settings are shown. The first point is correctly placed, however, EVERY point provided after that is incorrect, regardless of value.
I am using the GLScene version provided in codetyphon 6.8 on Linux.
I need to provide absolute coordinates and get them plotted without having to guess where they are going. Can anyone provide documentation on what EXACTLY the direction property is supposed to do? I undertand the up property defines whether the axes are XZY or XYZ, however I can find no documentation on what the Direction property is supposed to be doing. I can guess, but guessing is not documention.
A similar issue is happening with GLPipes though I suspect that they share code.
Is this a bug, or am I doing something incorrectly?
Thanks in advance
Lynne
BTW, I have over 20 years of programming experience and am not a novice.
Hi Lynne,
I have never fully understood the meaning of the confusing ‘up’ and ‘direction’ properties, but it should not be necessary to use them. At least I use both points and lines without worrying about them. It is sufficient to add the points as you do, as long as you remember that the coordinate system in OpenGL is right hand, with Y going up. When viewed from the front, X is to the right, Y is up, and Z is towards you.
Lars Nebel
From: Lynne Stone lynnestone@users.sourceforge.net
Sent: Wednesday, 30 October 2019 01.56
To: [glscene:discussion] 93606@discussion.glscene.p.re.sourceforge.net
Subject: [glscene:discussion] Help with GLLines issue
Hello, this is my first post here.
I am having a devil of a time with GLLines in 3-space. Attached is a screenshot of an example. Both points are in positive space, and the 2nd point is supposed to go UP, but instead dives down into negative space.
The nodes are added via Nodes.AddNode() and it does not matter whether the points are added via (.x .y .z) or as a taffinevector. As you can see from the screenshot both the UP and Direction settings are shown. The first point is correctly placed, however, EVERY point provided after that is incorrect, regardless of value.
I am using the GLScene version provided in codetyphon 6.8 on Linux.
I need to provide absolute coordinates and get them plotted without having to guess where they are going. Can anyone provide documentation on what EXACTLY the direction property is supposed to do? I undertand the up property defines whether the axes are XZY or XYZ, however I can find no documentation on what the Direction property is supposed to be doing. I can guess, but guessing is not documention.
A similar issue is happening with GLPipes though I suspect that they share code.
Is this a bug, or am I doing something incorrectly?
Thanks in advance
Lynne
BTW, I have over 20 years of programming experience and am not a novice.
Help with GLLines issue https://sourceforge.net/p/glscene/discussion/93606/thread/9e36cb4b8e/?limit=25#f8e7
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/glscene/discussion/93606/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Hi, Inebel is on the way ;) Lynne how do you set you camera ? the Up and Dir we see it is the values from your camera ?
Thanks everyone for the input. The camera's up and direction properties match those of the gllines.
I've also found during testing that if the camera's "autoleveling" property is set to true the camera will invert (turn upside down) instead of leveling. I am thinking something got broken at pilotlogic with the vector math.
In response to the direction/up. Changing one will totally screw the other. So they are supposed to be connected in some way but from what I'm seeing, there is no documented reasoning for both of them to exist for gllines and glpipes. One could see a reasoning for a camera: Up is how the camera is oriented and direction is which way it is pointing. Such things do not exist for gllines and glpipes so (IMO) direction needs to go away for these.
Upon further testing, it seems that if I type the values into a gllines entry from the GUI, the line is displayed properly. But clearing the nodes and adding it to the exact same gllines entry in runtime results in the erroneous behavior.
In any case, none of this solves my problem.
Lynne
Last edit: Lynne Stone 2019-10-31
Hi Lynne first the CodeTyphon's GLScene is based on the current Delphi branch . I don't have the "Autolevelling" property in Lazarus. But Pavel could be verify this.
A line can be described by a Direction and an Length. This direction must be compute with the start and the en point if present. So if you change the Dir of one point it's normal to have "bad value". The up is not essential for a line so just discard this with line .
But remove it it's not possible because those properties are commons and shared by all 3D objects like the position or the rotation
Hum, it will be fine to trace the code for see where is the problem at runtime. When i'll have more free time, i try to make some test with Lazarus
Can you try with bigger values like 1,2 --> 1.8 ... instead of 0.02 --> 0.03, 0.87 --> 0.88 etc....
Best regards
Sorry for my bad english ;)
Hi Jerome,
Firstly, your English is fine, no worries there.
The AUTOLEVELING property is in the Lazarus setup for CodeTyphon on my Linux (partial screencap included), however as mentioned previously, it doesn't function correctly. That property has been available as far back as CodeTyphon 6.1, and the same error exists there. It may even exist earlier than that, but 6.1 is the earliest installed version I have available on any of my machines.
As far as the "lines" go, it is indeed possible to describe a line with an origin point, a direction and a magnitude. However, in 3 of 4 modes TGLLines does not work this way (designtime also uses absolute coordinates). TGLLines provides 3 absolute position AddNode modes (no magnitude) and only a single AddNode that includes a TVector with a magnitude.
In 75% of its use cases TGLLines points are described by a series of absolute positions in 3-space placed in the nodes list - (x,y,z) in either float, TGLCoordinates, or TAffineVector. In these cases, the UP property makes sense in that it defines the coordinate space (XZY XYZ ZYX ZXY etc) and the DIRECTION property plays no meaningful part. However, the DIRECTION property will modify the UP property absolutely and will not be ignored. A value must be provided to DIRECTION and the library will use this value to recompute the UP values absolutely.
It is my thought that code for the 4th mode, AddNode using TVector (which includes a magnitude), has introduced an error into the absolute position modes. I have not yet delved into the source for TGLLines deeply because I wanted to see if I was just using something incorrectly before spending the time tracing through hundreds of lines of code.
As for the using the larger values, the points provided above were scaled down by 2 orders of magnitude so that they could fit into a screen space that could be seen when posting. In their normal scale the line dives ~89 units into the negative space from ~89 units in the positive space. In order for the camera to show this it has to be so far away that the line is so tiny it cannot realistically provide meaningful information.
Lynne
I am just guessing, but, GLScene uses single precision floats which gives you 7-8 significant digits. If you add points with more digits than that, you could get strange results.
Lars
From: Lynne Stone lynnestone@users.sourceforge.net
Sent: Thursday, 31 October 2019 14.25
To: [glscene:discussion] 93606@discussion.glscene.p.re.sourceforge.net
Subject: [glscene:discussion] Re: Help with GLLines issue
Hi Jerome,
Firstly, your English is fine, no worries there.
The AUTOLEVELING property is in the Lazarus setup for CodeTyphon on my Linux (partial screencap included), however as mentioned previously, it doesn't function correctly. That property has been available as far back as CodeTyphon 6.1, and the same error exists there. It may even exist earlier than that, but 6.1 is the earliest installed version I have available on any of my machines.
As far as the "lines" go, it is indeed possible to describe a line with an origin point, a direction and a magnitude. However, in 3 of 4 modes TGLLines does not work this way (designtime also uses absolute coordinates). TGLLines provides 3 absolute position AddNode modes (no magnitude) and only a single AddNode that includes a TVector with a magnitude.
In 75% of its use cases TGLLines points are described by a series of absolute positions in 3-space placed in the nodes list - (x,y,z) in either float, TGLCoordinates, or TAffineVector. In these cases, the UP property makes sense in that it defines the coordinate space (XZY XYZ ZYX ZXY etc) and the DIRECTION property plays no meaningful part. However, the DIRECTION property will modify the UP property absolutely and will not be ignored. A value must be provided to DIRECTION and the library will use this value to recompute the UP values absolutely.
It is my thought that code for the 4th mode, AddNode using TVector (which includes a magnitude), has introduced an error into the absolute position modes. I have not yet delved into the source for TGLLines deeply because I wanted to see if I was just using something incorrectly before spending the time tracing through hundreds of lines of code.
As for the using the larger values, the points provided above were scaled down by 2 orders of magnitude so that they could fit into a screen space that could be seen when posting. In their normal scale the line dives ~89 units into the negative space from ~89 units in the positive space. In order for the camera to show this it has to be so far away that the line is so tiny it cannot realistically provide meaningful information.
Lynne
Attachments:
Help with GLLines issue https://sourceforge.net/p/glscene/discussion/93606/thread/9e36cb4b8e/?limit=25#e8ab/230d
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/glscene/discussion/93606/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/
Thanks for the response, Lars. I thought the same thing early on. I considered that there might be an overflow condition occurring. However, I ran the tests using only 3 significant digits with the same results. As I stated starting out, the situation occurs regardless of the value of the 2nd point. Even using integer values causes the issue.
The more I look into this the more I'm thinking something got seriously broken in the vector computation routines. To me, it is acting like once there is an 'anchor point' the code is trying to convert all following points into TVector draws instead of staying with absolute positioning. What supports this is that the following points after the 'dive' are 'almost' correct (except that all points become planar -- another indication of vector mathematics errors) and resemble the curve they are supposed to represent, except now in 2-space instead of 3-space.
It may be that someone tried to be "too elegant" and make a single routine handle all 4 procedure calls instead of staying with the simple route of separate code for vector and absolute.
I am going to attempt to put together a custom Lazarus build with the fixes outlined in the Lazarus area to see if the guys over at pilotlogic did indeed make an error or if this is a more pervasive problem in the GLScene trunk.
Lynne
PS
It seems that there are now other reports of problems that can be possibly attributed to vector miscalculations.
Last edit: Lynne Stone 2019-10-31