Bookstore

 Computer Math and Games in Pascal (preview) Lazarus Handbook

Author Topic: Clipboard problem...  (Read 3846 times)

ranny

• Jr. Member
• Posts: 53
Re: Clipboard problem...
« Reply #15 on: June 14, 2019, 09:16:02 am »
Thanks again, the clipboard fix worked perfectly and that's one ticked off my list.

Your additional code regarding text and spheres looks like it will be worth incorporating once I understand it all and get it to fit my application.  However, it's not on the list until my "not being able to calculate the solution" is resolved.

I am solving polynomials which are y:=a0.x^n.z^n+a1.x^n.z^n-1....a(n+1)^2.x^0.z^0.  Its an old routine a put together many years ago and has work perfectly since.  My current cases take 200 points and a degree of fit (n) =4.  My old pre OpenGL program solves easily even up to n=7.  The new program with OpenGL facility is the same program with the OpenGL content added.  Now it works for one case with 204 points and n=3,4,5 but the original case which worked perfectly well before now does not.  It returns nan for the coefficients.  In debugging I saw some numbers in the routine returned -inf but there is absolutely no reason for them to do so if it worked before.

Its beyond me where it has gone wrong.  I am prepared to re-write the lot from scratch if it ultimately fixes everything but thats just a risk of wasted time.

Here is the routine, it uses x,y,z data that are global arrays and returns coefficients in c as a global array.

Code: Pascal  [Select][+][-]
1. procedure polyfit3 (var p,n,en:integer);
2.     var
3.     i,j,k,l,m:integer;
4.     col,row,mat,d:integer;
5.     aa:extended;
6.     g:array[0..65,0..65] of double;
7.     r:array [0..65] of double;
8.     c1:array [0..65] of double;
9.     begin
10.     //p=number of data points, n=degree of fit, er=err no for failures
11.     //x[], y[], z[] is global data from 1 to p
12.     //c[]=coefficients returned, global, c[1] is first, i.e. y=c1+c2.x+c3.x^2
13.     try
14.     //set error to zero
15.     en:= 0;
16.     d:=(n+1)*(n+1);
17.     //initialise the arrays
18.     for i:=1 to d do
19.         begin
20.         r[i]:=0.0;
21.         for j:=1 to d do
22.             begin
23.             g[i,j]:=0.0;
24.             end;
25.         end;
26.     For i:= 0 To n do
27.         begin
28.         For j:= 0 To n do
29.             begin
30.             For k:= 1 To p do
31.                 begin
32.                 row:= i * (n+1) + j + 1;
33.                 r[row]:= r[row] + y[k] * power(x[k],i) * power(z[k],j);
34.                 For l:= 0 To n do
35.                     begin
36.                     For m:= 0 To n do
37.                         begin
38.                         col:= l * (n+1) + m + 1;
39.                         g[row,col]:= g[row,col] + power(x[k],l) * power(z[k],m) *
40.                         power(x[k],i) * power(z[k],j);
41.                         end;
42.                     end;
43.                 end;
44.             end;
45.         end;
46.     //solve simultaneous equations using Gaussian elimination
47.     mat:= d;
48.     For i:= 1 To mat - 1 do
49.         begin
50.         For j:= i + 1 To mat do
51.             begin
52.             aa:= g[j,i] / g[i,i];
53.             For k:= i To mat do
54.                 begin
55.                 g[j,k]:= g[j,k] - (g[i,k] * aa);
56.                 end;
57.             r[j]:= r[j] - (r[i] * aa);
58.             end;
59.         end;
60.     //solve constants c1[]by back substitution
61.     c1[mat]:= r[mat]/g[mat,mat];
62.     For k:=1 to mat-1 do
63.         begin
64.         i:=mat-k;
65.         For j:= i+1 To mat do
66.             begin
67.             r[i]:=r[i]-(c1[j]*g[i,j]);
68.             end;
69.         c1[i]:=r[i]/g[i,i];
70.         end;
71.     for i:=1 to d do
72.         begin
73.         c[i]:=c1[i];
74.         end;
75.     exit;
76.     except
77.     messagedlg('Calculation error in procedure polyfit3.'+#10+'Check file structure.',mtWarning,[mbok],0);
78.     end;
79.     end;
80.
« Last Edit: June 14, 2019, 09:43:27 am by ranny »

wp

• Hero Member
• Posts: 7534
Re: Clipboard problem...
« Reply #16 on: June 14, 2019, 10:37:31 am »
Since the OpenGL output has nothing to do with your calculation this is probably a bug which has been there all the time but did not show up.

I did not study your code in detail, but I noticed that arrays are dimensioned to begin with index 0, but in the initialization routine you begin with 1, i.e. the elements g[*,0] and g[0,*], r[0] are undefined. You don't show the declaration of the x,y,z arrays, maybe the same issue exists there too. For me personally, mixing array index bases always has been a source of error.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

ranny

• Jr. Member
• Posts: 53
Re: Clipboard problem...
« Reply #17 on: June 18, 2019, 10:25:29 am »
I know that the arrays are zero based but zero is never used as an index.  I had changed them all to start from 1 but it makes no difference.  I cannot see where it is going wrong since the same code has worked for years with no issue and now it doesn't!  Looks like I am going to have to start from scratch checking as I go....

wp

• Hero Member
• Posts: 7534
Re: Clipboard problem...
« Reply #18 on: June 18, 2019, 10:40:33 am »
I know that the arrays are zero based but zero is never used as an index.
Don't do this, I guarantee that it will go wrong at some place. When you need n elements (1..n) you still have to create the array for n+1 elements! This is very easily overlooked.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

ranny

• Jr. Member
• Posts: 53
Re: Clipboard problem...
« Reply #19 on: June 19, 2019, 01:46:45 pm »
@WP

Fixed it now.  I started to rewrite the whole program from the ground up, pasting in each routine and trying it as I go.  It wasn't long before it was clear where the problem was.  I had been mucking about with the routines to raise x^n and had changed the output to single when it was double before.  Some of the numbers I am working with are pretty big so it failed.  However in my rewrite exercise, an error was flagged up and it was possible to see where the issue was, but my other program did not throw up an error and it just carried on with rubbish data.

Anyway all fixed and onwards with finalising the version with OpenGL.

Thanks for the support.

ranny

• Jr. Member
• Posts: 53
Re: Clipboard problem...
« Reply #20 on: June 20, 2019, 11:28:48 am »
@WP

Quick question....

You stated:-

"Spheres appear very simplistic when OpenGL does not use lighting. Therefore, the demo also shows how to "turn on the light". These are the essential ingredients: activate lights by calling "glEnable(GL_LIGHTING)", and define the parameters of one or several light sources (see "InitLight"). And every vertex must have a normal - for a sphere with r = 1 it is easy: it is just equal to the radius vector to a surface point. The surface normal is needed to calculate the angle to the light source which determines the brightness of each surface element due to diffuse or specular scattering of light".

I can see in your demo that the spheres are "lit" but the cube is not.  I assume that the cube has no specified normals.  So how do you create normals for quads or polygons?  is there a way they are generated based on the creation of the quad/polygon?  I am looking to show a surface in a single colour but with shading based on light direction.

I could calculate them with a cross product routine I suppose.

Don't know how to properly insert a quote!
« Last Edit: June 20, 2019, 11:32:39 am by ranny »

wp

• Hero Member
• Posts: 7534
Re: Clipboard problem...
« Reply #21 on: June 20, 2019, 07:03:30 pm »
I can see in your demo that the spheres are "lit" but the cube is not.
I suppose that you refer to the demo of reply #13... No, both are lit programmatically (when the "Light" checkbox is marked, but because lighting effects are calculated per surface element each face of the cube gets a uniform color.

I assume that the cube has no specified normals.  So how do you create normals for quads or polygons?  is there a way they are generated based on the creation of the quad/polygon?
Look at the cube generation code:
Code: Pascal  [Select][+][-]
1.   glBegin(GL_POLYGON);
2.     glColor3f(1, 0, 0);
3.     glNormal3f(0.0, 0.0, 1.0);          // <--- this defines the normal
4.     glVertex3f(1.0, 1.0, 1.0);
5.     glVertex3f(-1.0, 1.0, 1.0);
6.     glVertex3f(-1.0, -1.0, 1.0);
7.     glVertex3f(1.0, -1.0, 1.0);
8.   glEnd;
The normal is defined by the glNormal call. It is used for all vertices until the next glNormal is called. In the example the normal is valid for all four vertices; the face, therefore, appears flat. Normally you call glNormal before each vertex, then lighting calculation will interpolate between normals pointing into different directions.

In order to calculate a normal for a vertex you can calculate the cross product of the vectors to adjacent vertices and compute the average. In case of analytical functions you can also calculate the partial derivatives with respect to x and y; the normal vector is then (-dz/dx, -dz/dy, 1).

Note that normals should be normalized to unit length, otherwise their length may enter color calculation.

I am looking to show a surface in a single colour but with shading based on light direction.
As I said the surface must be divided into many patches, and normals must be given for each vertex, or at least for each patch (which will make the patches being rendered as flat). The lighting effects in OpenGL are determined by the properties of the light source and the material of the object. There are three classes of such properties: ambient (light coming from everywhere), diffuse (diffuse scattering), specular (specular scattering).

If you want to give a surface a uniform color (with shades varying according to lighting) the easiest way is to enable COLOR_MATERIAL mode, glEnable(GL_COLOR_MATERIAL). This way the surface keeps the color that you assign to the vertices, but the color shades vary depending on the lighting condition.

I modified an earlier program to show lighting effects and normal calculation - find it in the attachment. Please study the code and ask if you don't understand parts (sorry it's getting bigger and bigger).

I am planning the write a component for 3D charting with OpenGL. This should make it possible to create 3d plot without knowing details of OpenGL.

For refreshing my OpenGL knowledge I stumbled across the site http://www.songho.ca/opengl/index.html which appears rather good to me. I ported some of his demo programs to Lazarus, unfortunately with additional files they are too large for an upload here.

Don't know how to properly insert a quote!
Select the post that you want to quote and click on the "Insert Quote" at the top/right of the post - this will copy the post into your message. You should delete the parts that are not needed.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

wp

• Hero Member
• Posts: 7534
Re: Clipboard problem...
« Reply #22 on: June 21, 2019, 07:22:02 pm »
For refreshing my OpenGL knowledge I stumbled across the site http://www.songho.ca/opengl/index.html which appears rather good to me. I ported some of his demo programs to Lazarus, unfortunately with additional files they are too large for an upload here.
Song gave me the permission that I can modify, port and redistribute his codes without any restrictions. Therefore, I uploaded the adapted Lazarus versions to my github (https://github.com/wp-xyz/OpenGL_SongHoAhn).
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

ranny

• Jr. Member
• Posts: 53
Re: Clipboard problem...
« Reply #23 on: June 25, 2019, 08:06:42 am »
@WP

Thanks for the information which is really helpful.  I had some routines for dot product and cross product and tried them but I don't think I have control over the lighting yet, your code should help me get a good solution.  I also need to get display lists included to improve the overall functionality.

At one point in the draw function routine I had a check of a checkbox being true or false and it dramatically slowed down the drawing of the function.  I then set a variable to the checkbox status and used that in the "if" condition and it was restored to the original performance.  Is this expected, in that checking the status of an object is slow?

wp

• Hero Member
• Posts: 7534
Re: Clipboard problem...
« Reply #24 on: June 25, 2019, 09:50:07 am »
Is this expected, in that checking the status of an object is slow?
No. It must be something else that you are doing. Without seeing any code, I cannot tell.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

ranny

• Jr. Member
• Posts: 53
Re: Clipboard problem...
« Reply #25 on: June 25, 2019, 02:15:09 pm »
Most likely is something I am doing wrong, that is usually the case!

Can I ask a quick question, am I right in thinking that to fix the light source it must be re established again before transformations? Otherwise it moves with the rotation of the model?

wp

• Hero Member
• Posts: 7534
Re: Clipboard problem...
« Reply #26 on: June 27, 2019, 12:02:32 pm »
It depends where the light position is set in your code. Usually the OpenGL drawing code consists of
- initialization
- transformations (glRotate, glTranslate)
- model generation

When the light is placed after transformations the light can be considered to be part of the model, i.e. the light rotates along with the model when you drag the mouse. As a consequence the light will always illuminate the same side of the model, and because the camera is stationary illuminated and dark parts will rotate along with the model.

On the other hand, when the light is placed in the initialization, the light can be considered to be attached to the "camera". When now the model is rotated always different areas will be illuminated; the overall effect on the imuage is that reflection highlights and darker parts are always at the same place, no matter how the model is rotated.

Note that you can have several light sources in a scene, so that both effects can co-exist.

P.S.
If you would like to add another question on OpenGL I'd recommend that you put it into a separate thread (on the "Graphics" board), nobody excepts a lengthy OpenGL discussion under a title "Clipboard problem"...
« Last Edit: June 27, 2019, 02:18:27 pm by wp »
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

ranny

• Jr. Member
• Posts: 53
Re: Clipboard problem...
« Reply #27 on: June 27, 2019, 07:46:53 pm »
Thanks for that explanation, it makes sense.  I think just now I am just trying to make OpenGL work for me but need to get to understand it and your comments help indeed.  Unfortunately I cannot download anything from github at the moment, my works laptop doesn't allow it and I am hundreds of miles from home at the moment.

Agree on OpenGL questions should be moved to/continued in Graphics, I did think that a few days ago as this is off topic to the original question, which has been solved.

Thanks again.