|
forums.silverfrost.com Welcome to the Silverfrost forums
|
View previous topic :: View next topic |
Author |
Message |
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Thu Jul 30, 2015 1:40 pm Post subject: Linewidth in OpenGL |
|
|
Anyone knows how make plotted linewidth glLineWidth(wid) to work in OpenGL ?
What i do is the following
Code: |
call glBegin(GL_LINES)
!call glEnable(GL_LINE_SMOOTH)
call glLineWidth(4.d0)
call glColor4fv(Color_Pie01)
call glVertex3f(X,Y,Z)
call glVertex3f(X+a,Y+b,Z+c)
call glEnd()
|
It plots the line from point X,Y,Z to X+a,Y+b,Z+c but the call glLineWidth(4.d0) gves no effect |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Sun Aug 02, 2015 4:15 am Post subject: |
|
|
I know nothing about the subject myself, but There seems (according to MrGoogle) to be some problems/restrictions with this command.
Not all values of line width are available it seems, depending amongst other things the hardware being used (!), and 'implementation' e.g. is anti-aliasing used - I see you've tried it with/without by the looks of it)
I suggest you ry a range of values and see if any work.
... Or use the specific GL commands to get the available ranges ... see here
https://www.opengl.org/sdk/docs/man3/xhtml/glLineWidth.xml |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Tue Aug 04, 2015 11:04 am Post subject: |
|
|
Thanks John,
You can see or guess by commented line in the example above that i tried these things but did not succeed. The problem is that there is no documentation for all OpenGL features in Fortran and you are permanently guessing using docs or examples in other 20 different other languages. DJIP made some examples when we communicated 15 years back and that's it. He used Compaq/Intel and that not always worked with FTN95
Why Fortraneers do not use OIpenGL is beyond me as this is the most needed graphics tool in science and engineering. Here in the Forum must be the whole separate topic devoted to OpenGL
But if not will help i will look again myself so thanks for this found link which save me some time |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Wed Aug 05, 2015 12:43 pm Post subject: |
|
|
Dan,
Looking at the documentation you were directed to, the parameter for width is in GLfloat which I assume is real*4. You seem to have used 4.d0 which is real*8, try 4.e0.
Ian |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Wed Aug 05, 2015 9:44 pm Post subject: |
|
|
Ian, Well, yes, I tried and polished with my bad butt all these confusing OpenGL options when you often do not know what precision is actually used
This one if you substitute real*8 to real*4 gives Error 29, Call to missing routine, _glLineWidth@4 at 0x00447d53
In FTN95 INCLUDE dir the opengl.ins is defined as
STDCALL GLLINEWIDTH 'glLineWidth' (VAL)
as you can see this the root of old confusion story. Intel/Compaq rewrote all their numerous INS files to Fortran style long long ago
So we work based on intuition and tries and after few punches back into our face things usually work. For example i decided to change the point size and got it almost from the first attempt
Code: |
call glPointSize(2.)
call glBegin(GL_POINTS)
call glVertex3f(x, y, z)
call glEnd()
|
But whatever i have done today or 10 or 15 years ago with glLineWidth did not work.
Who was at Salford who made the OpenGL binding to this Fortran? That was a nice job with good well made examples. But shocking is why in two decades no single line or example was added? I suspect not all OpenGL functions are included into the INS file.
Here follows kind of political point. Don't developers understand that scientists and engineers besides the need for calculations (and for that Fortran is still a king and with continuing support always will be) need then to present their results and data in the most eye catching way? As to the graphics the OpenGL is #1 in this respect and it is actively supported, thanks to our kids-gamers.
All other languages and utilities pay close attention to the ease and quality of data presentation (Matlab, Mathematica etc). All surpassed Fortran in this respect. Even younger languages like Python pay attention and have that. Our postdoc used Mayavi in Python to plot 3D data. The first result still lack the shine but job was fast.
Silverfrost though may overjump all of them as the OpenGL is glued into its libraries and all very easyly and naturally incorporated into the Fortran code. No need of any third party hell. Just the next step needs to be done to create the community and libraries of OpenGL based "lego" blocks and the supporters will steadily grow in numbers. Why for example Silverfrost not invite this guy
http://www.dolfyn.net/dolfyn/f03gl_en.html
to write a guide and make a set of elemetary OpenGL examples for FTN95 ? |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Thu Aug 06, 2015 7:41 am Post subject: |
|
|
Dan,
Have a look at:
https://msdn.microsoft.com/en-us/library/windows/desktop/dd373931%28v=vs.85%29.aspx
This shows the parameter is float not double.
However, if you follow the glget link at the bottom of that page to glgetfloatv and you will see that the gl_line_width parameter is returned as a float. But calling glgetdoublev with the same parameter returns it as a double.
You might like to try this after initialising opengl:
Code: |
include <opengl.ins>
real*4 params(2)
call glgetfloatv(GL_LINE_WIDTH,params)
print *,params(1)
call glgetfloatv(GL_LINE_WIDTH_RANGE,params)
print *,params
end
|
See also the error codes in the msdn gllinewidth definition:
Error codes
The following error codes can be retrieved by the glGetError function.
Name.................................Meaning
GL_INVALID_VALUE..........width was less than or equal to zero.
GL_INVALID_OPERATION..The function was called between a call to glBegin and the corresponding call to glEnd.
i.e. calling it in the wrong place.
Hope this helps, because I haven't tried it myself.
Ian
Last edited by IanLambley on Sat Aug 08, 2015 10:04 am; edited 1 time in total |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Thu Aug 06, 2015 8:27 pm Post subject: |
|
|
Thanks Ian, then the question has to be addressed to Silverfrost: why such strange error report from using glLineWidth with right VAL ?? |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Fri Aug 07, 2015 5:49 am Post subject: |
|
|
correct me if I'm wrong but 4.d0 didn't give an error message ??
but 4.e0 does.
that suggests to me that it's Real*8
did you insert the commands to check the allowable range of values Dan ?
did you simply try using different values ?
Apart from that, using openGL the words sledgehammer and nut spring to mind :O) even though I'm sure it has some interesting characteristics it's a completely new additional programming language to learn and integrate, which is probably why 'there isn't the demand' and hence why understandably from a commercial point of view, Silverfrost aren't really interested in taking it 'to the limit' as far as FTN95 integration is concerned.
Are you sure you need to use a 'sophisticated' solution anyway or are you writing a game ? (maybe 'Revenge of the Mutant Error Messages' or some such ) |
|
Back to top |
|
|
John-Silver
Joined: 30 Jul 2013 Posts: 1520 Location: Aerospace Valley
|
Posted: Fri Aug 07, 2015 3:51 pm Post subject: |
|
|
.... and then I read through the link you posted Dan on 'the man Silverfrost need to get to do ..... this that and the other" and I laughed my socks off when I cam to the end
At the beginning.....
"1. Introduction
Stuff needed:
Fortran 2003 compiler: like"
... spot the feature 'missing' from FTN95 !
And then at the end .....
"6. Warning
You need to know what to do. The codes and files are 'as is'. The software and files are there to give you an impression only without any guarantee whatsoever.
Enjoy fortran and f03gl! "
The first line says it all !!! (although I'm sure it was written tongue in cheek :O). Maybe.
that's not to say it's not all worth investigating and adapting IF you have the time and inclination, it just explains why everytime you go down another 'level' of programming adds a factor of 2 (at least) to the complexity and time (3 levels = 2 **3 = lets say 10 times the effort and time !) if you see what I mean, and that's why more people don't do it, not because they wouldn't want to but because of the time involved. |
|
Back to top |
|
|
DanRRight
Joined: 10 Mar 2008 Posts: 2819 Location: South Pole, Antarctica
|
Posted: Fri Aug 07, 2015 6:51 pm Post subject: |
|
|
What game, John? Time of simple XY graphs is gone. Without top notch graphics you will not get attention, sales, funding, you are basically dead nowadays. Look at the games kids play on 4K monitors, that's not an ascii Tetris on monochrome CGA monitors of our glorious past, no one accepts from scientists and engineers anything less than that kind of visualization quality. Reviewers and program managers demand in plain English text super still and video graphics.
You can briefly scan and review all the graphics in this for example presentation and see what is used https://www.youtube.com/watch?v=fVKD9u_TZMg
or here https://www.google.com/search?q=nanophotonic&source=lnms&tbm=isch&sa=X&ved=0CAgQ_AUoAmoVChMI0ayRjsyXxwIVTTuICh3VNwMG&biw=946&bih=613
Yes, real*8 does not give error, but does not do anything, real*4 produces error by the compiler. I think Paul has to look at that |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Sat Aug 08, 2015 10:11 am Post subject: |
|
|
Dan,
Sorry about my earlier post, the code was incomplete and has now been edited.
I thought I would investigate further and so modified a copy of the "Animate.for" demonstration program supplied with FTN95. I added a function which queries the current line width and range giving the results of :
1.0
1.0 63.0
for these respectively.
Then I set the line width to 4. which by default is real*4 and re-queried the line with setting which then gave a value of 4.000
I used this function as a start-up call back and all the lines in the animation drew thicker than the original program. Have you set the default real type to *8 in the compiler set up? You could try passing the thickness in a real*4 variable instead of as a direct numeric.
Updated demo code attached:
Code: |
integer*4 function ilinw() !start of new function
include <opengl.ins>
real*4 params(2)
ilinw = 1
call glgetfloatv(GL_LINE_WIDTH,params)
print *,params(1)
call glgetfloatv(GL_LINE_WIDTH_RANGE,params)
print *,params
call glLineWidth(4.)
call glgetfloatv(GL_LINE_WIDTH,params)
print *,params(1)
end !end of new function
winapp
**********************************
* *
* Trial OPENGL program *
* *
**********************************
subroutine spinDisplay(spin)
include <opengl.ins>,nolist
include <clearwin.ins>,nolist
double precision spin
logical do_draw,temporary_draw
common /animate_com/ do_draw,temporary_draw
if (do_draw .or. temporary_draw)then
if(temporary_draw)spin=spin-2d0
call glClear (OR(GL_COLOR_BUFFER_BIT,GL_DEPTH_BUFFER_BIT))
call glMatrixMode (GL_MODELVIEW)
call glLoadIdentity()
call glTranslated(0d0,0d0,-10d0)
call glRotated(spin,1d0,0d0,0d0)
call glCallList(101)
call swap_opengl_buffers()
spin=spin+2d0
temporary_draw = .false.
endif
call temporary_yield@()
end
subroutine spinSlab()
logical do_draw,temporary_draw
common /animate_com/ do_draw,temporary_draw
do_draw=.TRUE.
end
subroutine stopSlab()
logical do_draw,temporary_draw
common /animate_com/ do_draw,temporary_draw
do_draw=.FALSE.
end
subroutine assemble_list
include <clearwin.ins>,nolist
include <opengl.ins>,nolist
real*4 white_colour(4), grey_colour(4), dark_grey_colour(4)
real*4 red_colour(4), yellow_colour(4), green_colour(4)
real*4 blue_colour(4), purple_colour(4), cyan_colour(4)
real*8 dimension,scale,d,fd,front,back
integer flags,k
integer hdc
logical ok
external opengl_proc
data white_colour/1.0,1.0,1.0,1.0/
data grey_colour/0.5,0.5,0.5,1.0/
data dark_grey_colour/0.3,0.3,0.3,1.0/
data red_colour/1.0,0.0,0.0,1.0/
data yellow_colour/1.0,1.0,0.0,1.0/
data green_colour/0.0,1.0,0.0,1.0/
data blue_colour/0.0,0.0,1.0,1.0/
data purple_colour/1.0,0.0,1.0,1.0/
data cyan_colour/0.0,1.0,1.0,1.0/
data front,back/-0.01d0,-0.5d0/
call glEnable(GL_DEPTH_TEST)
hDC=clearwin_info@('OPENGL_DEVICE_CONTEXT')
call glColor3f(1.0,1.0,1.0)
|
Last edited by IanLambley on Sat Aug 08, 2015 10:17 am; edited 2 times in total |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Sat Aug 08, 2015 10:14 am Post subject: |
|
|
Continued...
Code: |
ok=wglUseFontOutlines(hDC, 0, 255, 1000, 0.0, 0.1,
& WGL_FONT_POLYGONS,core4(0))
call glMatrixMode (GL_MODELVIEW)
call glLoadIdentity()
call glTranslated(0d0,0d0,-10d0)
C
C Clear the color and depth buffers.
C
call glClear (OR(GL_COLOR_BUFFER_BIT,GL_DEPTH_BUFFER_BIT))
dimension=2.2d0
scale=dimension*0.9d0
call glDisable(GL_LIGHTING)
call glNewList(101,GL_COMPILE)
C Front face
call glBegin(GL_POLYGON)
call glColor3fv(blue_colour)
call glVertex3d(-dimension,-dimension,front)
call glVertex3d(-dimension, dimension,front)
call glVertex3d( dimension, dimension,front)
call glVertex3d( dimension,-dimension,front)
call glEnd()
C Back face
call glBegin(GL_POLYGON)
call glColor3fv(yellow_colour)
call glVertex3d(-dimension,-dimension,back)
call glVertex3d( dimension,-dimension,back)
call glVertex3d( dimension, dimension,back)
call glVertex3d(-dimension, dimension,back)
call glEnd()
C Top face
call glBegin(GL_POLYGON)
call glColor3fv(red_colour)
call glVertex3d(-dimension, dimension,front)
call glVertex3d(-dimension, dimension,back)
call glVertex3d( dimension, dimension,back)
call glVertex3d( dimension, dimension,front)
call glEnd()
C Bottom face
call glBegin(GL_POLYGON)
call glColor3fv(green_colour)
call glVertex3d( dimension,-dimension,front)
call glVertex3d( dimension,-dimension,back)
call glVertex3d(-dimension,-dimension,back)
call glVertex3d(-dimension,-dimension,front)
call glEnd()
C
C Draw graph
C
call glBegin(GL_LINES)
call glColor3fv(white_colour)
call glVertex2d(-scale,0d0)
call glVertex2d(scale,0d0)
call glVertex2d(0d0,-scale)
call glVertex2d(0d0,scale)
k=-10
while(k .LE. 10) do
call glVertex2d((scale/10)*k,0.0d0)
call glVertex2d((scale/10)*k,0.1d0)
call glVertex2d(0.0d0,(scale/10)*k)
call glVertex2d(0.1d0,(scale/10)*k)
k=k+1
endwhile
call glEnd()
call glColor3fv(red_colour)
call glBegin(GL_LINE_STRIP)
d=-10d0
while(d .LT. 10d0)do
fd=5*(d/10)**3+3*(d/10)**2-d/10
call glVertex2d(d*scale/10,fd*scale/10)
d=d+0.05d0
endwhile
call glEnd()
call glColor3fv(green_colour)
call glBegin(GL_LINE_STRIP)
d=-10d0
while(d .LT. 10)do
fd=5*(d/10)**3+6*(d/10)**2-d/10
call glVertex2d(d*scale/10,fd*scale/10)
d=d+0.05d0
endwhile
call glEnd()
call glColor3fv(red_colour)
call glListBase (1000)
call glTranslated(0.15d0,scale*0.95,0d0)
call glScaled(0.2d0,0.2d0,0.2d0)
call glCallLists (5, GL_UNSIGNED_BYTE, '+10.0')
call glEndList()
end
subroutine myinit()
call assemble_list()
end
|
|
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Sat Aug 08, 2015 10:15 am Post subject: |
|
|
Continued ...
Code: | subroutine myreshape(w,h)
include <opengl.ins>,nolist
integer w
integer h
double precision aspect_ratio
logical do_draw,temporary_draw
common /animate_com/ do_draw,temporary_draw
double precision spin
common/current_spin/spin
if(h.NE.0)then
aspect_ratio=dble(w)/h
call glMatrixMode (GL_PROJECTION)
call glLoadIdentity ()
call gluPerspective (30.0d0,aspect_ratio,1d0,15d0)
call glViewport(0,0,w,h)
temporary_draw=.TRUE.
endif
end
integer function opengl_proc()
include <clearwin.ins>,nolist
include <opengl.ins>,nolist
integer w,h
character*256 reason
logical do_draw,temporary_draw
common /animate_com/ do_draw,temporary_draw
opengl_proc=2
reason=clearwin_string@('CALL_BACK_REASON')
! print *,trim(reason)
if(reason.EQ.'SETUP')then
call myinit()
else if(reason.EQ.'RESIZE')then
w=clearwin_info@('OPENGL_WIDTH')
h=clearwin_info@('OPENGL_DEPTH')
call myreshape(w,h)
opengl_proc=1
else if(reason.EQ.'MOUSE_LEFT_CLICK')then
call spinSlab()
else if(reason.EQ.'MOUSE_RIGHT_CLICK')then
call stopSlab()
endif
end
program Animate
include <clearwin.ins>,nolist
double precision spin
common/current_spin/spin
integer i,window
integer opengl_proc
external opengl_proc, ilinw ! modified line
logical do_draw,temporary_draw
common /animate_com/ do_draw,temporary_draw
temporary_draw = .false.
i=winio@('%es%ca[Rotating Slab]&')
i=winio@('%fn[Times New Roman]%ts&',3.0d0)
i=winio@('%sc&',ilinw) ! new line
i=winio@('%sp%ww[no_border]%pv%^og[double,depth16]%lw'
& ,0,0,650,650,opengl_proc,window)
spin=0d0
call spinSlab
while(window .LT. 0)do
call spinDisplay(spin)
endwhile
end
|
|
|
Back to top |
|
|
LitusSaxonicum
Joined: 23 Aug 2005 Posts: 2388 Location: Yateley, Hants, UK
|
Posted: Sat Aug 08, 2015 11:56 am Post subject: |
|
|
Quote: | drew thicker than the original program |
which is because you set it to 4.0 (I think). Interestingly, on a small Lenovo laptop with an Intel graphics chip your 63 became 6.99.
Eddie |
|
Back to top |
|
|
IanLambley
Joined: 17 Dec 2006 Posts: 490 Location: Sunderland
|
Posted: Sun Aug 09, 2015 9:11 am Post subject: |
|
|
Eddie,
Yes that was why. The point of my post was that Dan had been having problems getting the routine to work at all. This showed that it can work and I think the main problem was the position of the call, i.e. it cannot be between a glbegin and glend. But it could also be caused by the implementation on Dan's computer, version of Opengl32.dll etc.
Regards
Ian |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|