pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Mike C. F. <mcf...@vr...>]

On 13-01-14 05:44 PM, Ian Mallett wrote:
> Hey,
>
> I had exactly this same problem some years ago. The solution for me 
> was to replace:
> glShaderSource(self.fragmentShaderId, self.fragmentShader120)
> . . . with:
> glShaderSource(self.fragmentShaderId, [self.fragmentShader120])
Weird, I thought I'd fixed that ages ago.  The wrapper is *supposed* to 
look at the source and say "is this a string or unicode? then wrap it 
with a list"...

Maybe I dreamed I fixed it... ah... the low-level wrapper would only 
convert 8-bit strings into arrays-of-objects, any chance these were 
unicode strings?  The higher-level wrapper 
(OpenGL.GL.shaders.compileShader) *does* do the conversions for Unicode, 
but the low-level stuff was checking just for bytes.

Anyway, wrapping with a list should be fine, as it's what the API 
actually expects.

Thanks for pointing out the error,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Ian M. <geo...@gm...>]

Hey,

I had exactly this same problem some years ago. The solution for me was to
replace:
glShaderSource(self.fragmentShaderId, self.fragmentShader120)
. . . with:
glShaderSource(self.fragmentShaderId, [self.fragmentShader120])

Do the same for the vertex program.

Ian

[PyOpenGL-Users] Code doesn't run on amd/ati hardware

[Marcel P. <pfe...@fr...>]

Hi,

I've got a piece of code that runs flawlessly on Linux and Intel GMA HD
graphics:

http://pastebin.com/GcxAXBk7

Unfortunately with nearly the same software configuration and an ATI
Radeon 5770 using fglrx driver it refuses to run:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
Traceback (most recent call last):
  File
"misc/shadertest120_triangle.py",
line 217, in <module> t.run() File
"misc/shadertest120_triangle.py",
line 203, in run self.init() File
"misc/shadertest120_triangle.py",
line 49, in init self.createShaders() File
"misc/shadertest120_triangle.py",
line 146, in createShaders glUseProgram(self.programId) File
"/usr/lib/python3.3/site-packages/OpenGL/platform/baseplatform.py",
line 379, in __call__ return self( *args, **named ) File
"/usr/lib/python3.3/site-packages/OpenGL/error.py", line 208, in
glCheckError baseOperation = baseOperation, OpenGL.error.GLError:
GLError( err = 1282,
	description = b'invalid operation',
	baseOperation = glUseProgram,
	cArguments = (3,)
)
~~~~~~~~~~~~~~~~~~~~~~~~~~~

glGetProgramInfoLog yields after linking:

~~~~~~~~~~~~~~~~~~~~~~~~~~~
Vertex shader(s) failed to link, fragment shader(s) failed to link.
Vertex link error: INVALID_OPERATION.
ERROR: 1:1: error(#132) Syntax error: "v" parse error
ERROR: error(#273) 1 compilation errors.  No code generated

fragment link error: INVALID_OPERATION.
ERROR: 1:1: error(#132) Syntax error: "v" parse error
ERROR: error(#273) 1 compilation errors.  No code generated
~~~~~~~~~~~~~~~~~~~~~~~~~~~

First I'd like to know if I missed anything codewise and if it runs for
anyone else.

My configuration:
* Archlinux 64bit
* Python 3.3
* python3-opengl 3.0.2
* python-pygame-hg 3149-1

GL_SHADING_LANGUAGE_VERSION:  '4.20'
GL_VERSION:  '4.2.11978 Compatibility Profile Context'

Thanks if you have a look at it.

Have a nice evening,
Marcel

Re: [PyOpenGL-Users] Disable and Enable vsync

[Simone R. <sim...@gm...>]

I'm always searching for a solution.

I've an nvidia video card

The function:
*glXSwapIntervalSGI*(0)

Don't produce any errors but it has no effect.

The function:
*glXSwapIntervalMESA*

Is listed in the package but it return this error:

File "/usr/lib/python2.7/site-packages/OpenGL/platform/baseplatform.py",
line 384, in __call__
    self.__name__, self.__name__,
OpenGL.error.NullFunctionError: Attempt to call an undefined function
glXSwapIntervalMESA, check for bool(glXSwapIntervalMESA) before calling
Exception TypeError: "'NoneType' object is not callable" in <bound method
AxisOgl.__del__ of <pyparticles.ogl.axis_ogl.AxisOgl object at 0x450de90>>
ignored


And the function:
*glXSwapIntervalEXT*

Is not in the package.


Do you have some idea ?



2012/12/5 Simone Riva <sim...@gm...>

> I'm trying to disable or enable via software the *vsync*  with
> pyopengl under Linux and Windows, but at the moment I've not yet found the
> solution.
>
> The functions:
> glXSwapIntervalSGI
> glXSwapIntervalMESA
> glXSwapIntervalEXT
>
> Does not work.
>
> Do you known ho to do this job?
>
> TNX.
>
> SR
>

[PyOpenGL-Users] Disable and Enable vsync

[Simone R. <sim...@gm...>]

I'm trying to disable or enable via software the *vsync*  with
pyopengl under Linux and Windows, but at the moment I've not yet found the
solution.

The functions:
glXSwapIntervalSGI
glXSwapIntervalMESA
glXSwapIntervalEXT

Does not work.

Do you known ho to do this job?

TNX.

SR

Re: [PyOpenGL-Users] confused n00b is confused - rendering simple triangles

[Mike C. F. <mcf...@vr...>]

On 12-11-13 01:28 PM, Dave Curtis wrote:
...
>           GL.glVertexPointer(3, GL.GL_FLOAT, 0, v.astype('float32'))
>           GL.glColorPointer(3, GL.GL_FLOAT,0, colors.astype('float32'))
>           GL.glDrawElements(GL.GL_TRIANGLES, len(t) ,GL.GL_UNSIGNED_SHORT, t)
You do not, as far as I can see, glEnableClientState( ) on the pointers 
you are trying to use.  Without that you won't actually be rendering 
from your arrays.

See method Render here:

http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/gldrawarrays.py 
<http://bazaar.launchpad.net/%7Emcfletch/openglcontext/trunk/view/head:/tests/gldrawarrays.py>

for example of usage.

HTH,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

[PyOpenGL-Users] confused n00b is confused - rendering simple triangles

[Dave C. <dav...@so...>]

I am just getting stated with opengl, and I am working with pyside, 
numpy, and a new constructive solid geometry library called pyPolyCSG.  
My goal is to modify the hellogl.py pyside example found here:
http://qt.gitorious.org/pyside/pyside-examples/blobs/master/examples/opengl/hellogl.py

pyPolyCSG can be found here, if you are interested:
https://github.com/jamesgregson/pyPolyCSG

hellogl.py simply displays the Trolltech logo in a pyside(qt) widget, 
rendered using OpenGL.  Works great.
I gutted the logo construction code and call pyPolyCSG to construct a 
box.  pyPolyCSG returns numpy arrays for vertices and triangles. I 
modified the paintgl() method to paint the mesh -- but clearly I am 
doing something wrong because all I see is a pretty background fill. My 
box is MIA.

I am a total n00b with OpenGL, so I suspect I am missing something very 
basic.

Relevant code:

The Qt widget paintGL callback:

     def paintGL(self):
         # copied from example:
         GL.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT)
         GL.glLoadIdentity()
         GL.glTranslated(0.0, 0.0, -10.0)
         GL.glRotated(self.xRot / 16.0, 1.0, 0.0, 0.0)
         GL.glRotated(self.yRot / 16.0, 0.0, 1.0, 0.0)
         GL.glRotated(self.zRot / 16.0, 0.0, 0.0, 1.0)
         # my code added here:
         v,t = self.object
         v = v/10.0 # Is scaling an issue?
         t = t.astype('uint16')
         colors = numpy.array([1.,0.,0.] * len(v)) # Need some colors?? 
Maybe???
         GL.glVertexPointer(3, GL.GL_FLOAT, 0, v.astype('float32'))
         GL.glColorPointer(3, GL.GL_FLOAT,0, colors.astype('float32'))
         GL.glDrawElements(GL.GL_TRIANGLES, len(t) ,GL.GL_UNSIGNED_SHORT, t)

My geometry construction:

     def makeObject(self):
         self.polyBlock = csg.box(2,4,6) # Call pyPolyCSG to construct a box
         v = self.polyBlock.get_vertices()
         t = self.polyBlock.get_triangles()
         print 'v = '
         print v
         print 't ='
         print t
         return (v,t)

The mesh in numpy arrays:
v =
[[ 0.  0.  0.]
  [ 2.  0.  0.]
  [ 2.  4.  0.]
  [ 0.  4.  0.]
  [ 0.  0.  6.]
  [ 2.  0.  6.]
  [ 2.  4.  6.]
  [ 0.  4.  6.]]
t =
[[4 0 1]
  [4 1 5]
  [6 2 3]
  [6 3 7]
  [0 3 2]
  [0 2 1]
  [7 4 5]
  [7 5 6]
  [5 1 2]
  [5 2 6]
  [7 3 0]
  [7 0 4]]

I'm a total n00b with OpenGL, so don't make too many assumptions about 
what I know :)

Thanks,
   Dave

Re: [PyOpenGL-Users] GLU NURBS precision

[Chris B. <chr...@no...>]

Given OpenGL uses single precision- I'd use single (numpy.float32) for
your numpy arrays, too. One of the nice things about numpy.
-chb
On Oct 26, 2012, at 10:38 AM, "Mike C. Fletcher" <mcf...@vr...> wrote:

> On 12-10-26 10:21 AM, Hugo Gagnon wrote:
>> Hello,
>>
>> I'm writing an application that uses GLU's NURBS capabilities.  I'm
>> passing double-precision numpy arrays to gluNurbsCurve and
>> gluNurbsSurface, which works fine, only that PyOpenGL seems to
>> automatically convert them to single-precision, which slows down my app.
>>  Does this conversion have to do with PyOpenGL or is it an OpenGL
>> limitation?  Is there any way around it?  other than having to keep
>> track of two arrays of different types around...
> The C-level function requires GLfloat * arrays (i.e. single precision).
> PyOpenGL, by default, will copy the array if the type is not compatible
> with the target function.  So the conversion is PyOpenGL, but if it
> didn't do it you'd get a garbage result (each half of your double
> interpreted as a float).
>
> HTH,
> Mike
>
> --
> ________________________________________________
>   Mike C. Fletcher
>   Designer, VR Plumber, Coder
>   http://www.vrplumber.com
>   http://blog.vrplumber.com
>
>
> ------------------------------------------------------------------------------
> The Windows 8 Center
> In partnership with Sourceforge
> Your idea - your app - 30 days. Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] GLU NURBS precision

[Mike C. F. <mcf...@vr...>]

On 12-10-26 10:21 AM, Hugo Gagnon wrote:
> Hello,
>
> I'm writing an application that uses GLU's NURBS capabilities.  I'm
> passing double-precision numpy arrays to gluNurbsCurve and
> gluNurbsSurface, which works fine, only that PyOpenGL seems to
> automatically convert them to single-precision, which slows down my app.
>   Does this conversion have to do with PyOpenGL or is it an OpenGL
> limitation?  Is there any way around it?  other than having to keep
> track of two arrays of different types around...
The C-level function requires GLfloat * arrays (i.e. single precision).  
PyOpenGL, by default, will copy the array if the type is not compatible 
with the target function.  So the conversion is PyOpenGL, but if it 
didn't do it you'd get a garbage result (each half of your double 
interpreted as a float).

HTH,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

[PyOpenGL-Users] GLU NURBS precision

[Hugo G. <sou...@us...>]

Hello,

I'm writing an application that uses GLU's NURBS capabilities.  I'm
passing double-precision numpy arrays to gluNurbsCurve and
gluNurbsSurface, which works fine, only that PyOpenGL seems to
automatically convert them to single-precision, which slows down my app.
 Does this conversion have to do with PyOpenGL or is it an OpenGL
limitation?  Is there any way around it?  other than having to keep
track of two arrays of different types around...

Thanks!

Hugo

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Derakon <de...@gm...>]

On Mon, Oct 22, 2012 at 12:41 PM, Mike C. Fletcher
<mcf...@vr...> wrote:
>
> I'm guessing you want to update the stars so that you see more stars as
> you move out of the central star-field?  That is, as you move positions
> you want to add another "slice" of stars off to the side toward which
> you are walking? Unless you are travelling faster than light (or dealing
> with extremely long time-scales) you don't actually see any significant
> parallax with a star-field AFAIK.

The suggestion I made off-thread was to have a repetitive starfield --
a 3x3 grid of the same pattern. That way you can invisibly loop the
scrolling of the pattern when you get far enough from the center --
since it's repetitive, there's no way to tell, say, the position (-10,
0) from the position (0, 0) (if each "cell" in the grid were 10x10).
Make the base pattern large enough (2x screen resolution should do)
and the repetition should be hard to notice.

Real-life parallax would be very hard to notice on these scales, but
scrolling starfields are a time-honored tradition for space games. :)

-Chris

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Mike C. F. <mcf...@vr...>]

On 12-10-19 12:52 PM, Ryan Hope wrote:
> I am working on a pygame app that I recently converted to using opegl
> for the backend. The game has a parallax star field in the background
> so I have been looking for the most efficient way of drawing multiple
> points. My game updates the display every 33ms. Bellow are the draw
> points methods I have tried.
VBO approach on my machine fullscreen at 1920x1200 shows around 280 fps 
(no actually change with resolution change, btw).  I'm just rendering a 
random starfield of the same size as the Bright Star Catalog (9,100 
stars).  That looks good if you wander around near the center, but if 
you make it small enough to see changes you rapidly run out of stars.  
I'm guessing you want to update the stars so that you see more stars as 
you move out of the central star-field?  That is, as you move positions 
you want to add another "slice" of stars off to the side toward which 
you are walking? Unless you are travelling faster than light (or dealing 
with extremely long time-scales) you don't actually see any significant 
parallax with a star-field AFAIK.

VBO approach looks like this:

     from numpy import random
     numpy_pointset = random.rand( 9110, 3 )
     points = vbo.VBO( numpy_pointset )

then, during render:

     glVertexPointerf(points)
     glEnableClientState( GL_VERTEX_ARRAY )
     glDrawArrays( GL_POINTS, 0, len(points))
     glDisableClientState( GL_VERTEX_ARRAY )

I'm guessing that each update will wind up scatter-shot across your VBO 
so you'll likely want to re-upload the whole thing each time you change 
the star-field.

Code I'm using to test is here:

http://bazaar.launchpad.net/~mcfletch/openglcontext/trunk/view/head:/tests/starfield.py 
<http://bazaar.launchpad.net/%7Emcfletch/openglcontext/trunk/view/head:/tests/starfield.py>

Hope that helps,
Mike

-- 
________________________________________________
   Mike C. Fletcher
   Designer, VR Plumber, Coder
   http://www.vrplumber.com
   http://blog.vrplumber.com

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Greg E. <gre...@ca...>]

Ian Mallett wrote:
> I personally have gotten compelling results by 
> simply making several static starfields of different sizes and then 
> scrolling them with glTranslatef at different rates.

Or you could create a true 3D starfield and use a perspective
projection.

-- 
Greg

[PyOpenGL-Users] Fwd: 3d globe?

[Ian M. <geo...@gm...>]

---------- Forwarded message ----------
From: Tony Peña <emp...@gm...>
Date: Fri, Oct 19, 2012 at 2:31 PM
Subject: Re: [PyOpenGL-Users] 3d globe?
To: Ian Mallett <geo...@gm...>


i wish really some like have a big world map .. convert into sphere just
like your, and put all that positions and can rotate to see around...
i don't have a map 2d... just big map as texture to paint that sphere... in
the screenshot case is just googlemaps javascripts api to can see that..
my problem is.. here in Cuba where I live.. not all people have internet so
googlemaps not works .. I want to try put that. locally so need with my
texture map contert into globe and anyone can see normal without stay
updating any tile of googlemaps -


2012/10/19 Ian Mallett <geo...@gm...>

> On Fri, Oct 19, 2012 at 12:34 PM, Tony Peña <emp...@gm...> wrote:
>
>> yes.....I'm tried to adapt your world into my hobby, but i failed :-)
>> need a little help
>>
>>
>> https://github.com/emper0r/IVAO-status/blob/master/screenshots/screenshot-ivaos8.png
>>
>> trying to change this image in my app into globe 3d :-)
>>
> So, you have a 2D image (or a rendered 2D image) and you want to map it
> onto a sphere?
>



-- 
Antonio Peña
Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
 Fingerprint: 74E6 2974 B090 366D CE71  7BB2 6476 FA09 8B02 1001

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Henry G. <he...@ca...>]

On Fri, 2012-10-19 at 11:41 -0700, Derakon wrote:
> On Fri, Oct 19, 2012 at 11:37 AM, Henry Gomersall <he...@ca...>
> wrote:
> > On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote:
> >> Thanks for the ideas guys. I am a complete OpenGL noob, just
> started
> >> using it last week so things like VBOs and shaders are a little
> over
> >> my head at the moment. I start looking into these things though.
> >>
> > They're the modern way to do things. To the point that it's probably
> not
> > much worth learning anything else.
> 
> To be fair, glPoints is a heck of a lot easier to wrap your head
> around than VBOs are. To some extent it's worth learning the "wrong
> but functional" approach only to unlearn it later, in the interests of
> smoothing out the learning curve. 

True, but when I was learning I spent ages wondering why there were
multiple ways of doing everything. It was much easier for me when I
realised most of them were legacy!

My email was more to make that point that anything else.

Henry

Re: [PyOpenGL-Users] 3d globe?

[Ian M. <geo...@gm...>]

On Fri, Oct 19, 2012 at 12:34 PM, Tony Peña <emp...@gm...> wrote:

> yes.....I'm tried to adapt your world into my hobby, but i failed :-)
> need a little help
>
>
> https://github.com/emper0r/IVAO-status/blob/master/screenshots/screenshot-ivaos8.png
>
> trying to change this image in my app into globe 3d :-)
>
So, you have a 2D image (or a rendered 2D image) and you want to map it
onto a sphere?

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Ryan H. <rm...@gm...>]

I made a library that is API consistent with pygame 2d calls but uses
opengl in the background. I did this because things were starting to
slow down in my non HW accelerated pygame game. Now that I have the
basics working I do want to learn the right way to do things.

On Fri, Oct 19, 2012 at 2:41 PM, Derakon <de...@gm...> wrote:
> On Fri, Oct 19, 2012 at 11:37 AM, Henry Gomersall <he...@ca...> wrote:
>> On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote:
>>> Thanks for the ideas guys. I am a complete OpenGL noob, just started
>>> using it last week so things like VBOs and shaders are a little over
>>> my head at the moment. I start looking into these things though.
>>>
>> They're the modern way to do things. To the point that it's probably not
>> much worth learning anything else.
>
> To be fair, glPoints is a heck of a lot easier to wrap your head
> around than VBOs are. To some extent it's worth learning the "wrong
> but functional" approach only to unlearn it later, in the interests of
> smoothing out the learning curve.
>
> Plus, it's not like support for the old functions is going to go away.
> They just don't work quite as well.
>
>>
>> Henry
>>
>
> -Chris
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users



-- 
Ryan Hope, M.S.
CogWorks Lab
Cognitive Science Department
Rensselaer Polytechnic Institute

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Ian M. <geo...@gm...>]

On Fri, Oct 19, 2012 at 12:37 PM, Henry Gomersall <he...@ca...> wrote:

> On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote:
> > Thanks for the ideas guys. I am a complete OpenGL noob, just started
> > using it last week so things like VBOs and shaders are a little over
> > my head at the moment. I start looking into these things though.
> >
> They're the modern way to do things. To the point that it's probably not
> much worth learning anything else.
>
> Henry

Just because they won't be supported in hardware in 10 years doesn't mean
they're inherently a bad thing. Derakon is right; immediate-mode OpenGL is
easy to use. No, high-end, forward-thinking applications don't use it (as
much), but that doesn't mean it's a worthless technology. Plus, it sounds
like the OP already knows how to use them (and they aren't hard to learn
anyway). They may even have lower overhead than VBOs, because they don't
require expensive buffer glBind(...).

It occurs to me that you could probably rig up a procedural texture
> that would simulate a starfield for you. Then you could just use a set
> of textured quads to do your parallax scrolling starfield. I'm not an
> OpenGL expert though; would anyone more experienced have a sense of
> how this would compare speedwise to the VBO approach? The advantages
> to a procedural texture would be that there'd be no repetition to the
> field, and that of course you'd never have to send more data over to
> the card, except for the parameters to the shader used to generate the
> texture.
>
I would suspect that this would be much slower: any such implementation
would probably be implemented as a fragment program (or at best, and OpenCL
kernel). As such, unless you were very *very* careful, it would be linear
with the number of pixels on the screen, and opposed to linear in the
number of stars. Randomly generating the stars on the CPU into a mapped VBO
implementing a circular buffer would probably accomplish much the same
thing, but faster.

Ian

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Derakon <de...@gm...>]

On Fri, Oct 19, 2012 at 11:37 AM, Henry Gomersall <he...@ca...> wrote:
> On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote:
>> Thanks for the ideas guys. I am a complete OpenGL noob, just started
>> using it last week so things like VBOs and shaders are a little over
>> my head at the moment. I start looking into these things though.
>>
> They're the modern way to do things. To the point that it's probably not
> much worth learning anything else.

To be fair, glPoints is a heck of a lot easier to wrap your head
around than VBOs are. To some extent it's worth learning the "wrong
but functional" approach only to unlearn it later, in the interests of
smoothing out the learning curve.

Plus, it's not like support for the old functions is going to go away.
They just don't work quite as well.

>
> Henry
>

-Chris

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Henry G. <he...@ca...>]

On Fri, 2012-10-19 at 14:29 -0400, Ryan Hope wrote:
> Thanks for the ideas guys. I am a complete OpenGL noob, just started
> using it last week so things like VBOs and shaders are a little over
> my head at the moment. I start looking into these things though.
> 
They're the modern way to do things. To the point that it's probably not
much worth learning anything else.

Henry

Re: [PyOpenGL-Users] 3d globe?

[Tony P. <emp...@gm...>]

yes.....I'm tried to adapt your world into my hobby, but i failed :-)
need a little help

https://github.com/emper0r/IVAO-status/blob/master/screenshots/screenshot-ivaos8.png

trying to change this image in my app into globe 3d :-)


2012/10/19 Ian Mallett <geo...@gm...>

> On Fri, Oct 19, 2012 at 11:05 AM, Tony Peña <emp...@gm...> wrote:
>
>> how can i get example of 3d glboe earth projection with simple texture
>> image of the blue marble or openstreetmap or like satellite . with a simple
>> point into 0,0 and of course could be rotate ?
>> is for try including into pyqt qtabwidget ...
>> any idea?
>>
>> --
>> Antonio Peña
>> Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
>>  Fingerprint: 74E6 2974 B090 366D CE71  7BB2 6476 FA09 8B02 1001
>>
> I wrote an ancient and crufty demo that does exactly this:
> http://www.pygame.org/project-World-472-.html
>
> Perhaps you can clarify what you're looking for?
>



-- 
Antonio Peña
Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
 Fingerprint: 74E6 2974 B090 366D CE71  7BB2 6476 FA09 8B02 1001

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Ryan H. <rm...@gm...>]

Thanks for the ideas guys. I am a complete OpenGL noob, just started
using it last week so things like VBOs and shaders are a little over
my head at the moment. I start looking into these things though.

On Fri, Oct 19, 2012 at 2:27 PM, Derakon <de...@gm...> wrote:
> On Fri, Oct 19, 2012 at 11:16 AM, Ian Mallett <geo...@gm...> wrote:
>> On Fri, Oct 19, 2012 at 11:59 AM, Chris Barker <chr...@no...>
>> wrote:
>>>
>>> Display lists probably wont' help as you would still need to build up
>>> the list -- it's also old-style and practically deprecated approach.
>>
>> You have to build the VBO too, but yes, display lists are deprecated.
>>
>> As far as dynamic stars, yes, the idea is to use either a display list or a
>> VBO and either transform or use a vertex program to move your stars. For
>> starfields, I personally have gotten compelling results by simply making
>> several static starfields of different sizes and then scrolling them with
>> glTranslatef at different rates. This gives a nice parallax effect, and is
>> essentially just as fast as drawing the stars completely static.
>
> It occurs to me that you could probably rig up a procedural texture
> that would simulate a starfield for you. Then you could just use a set
> of textured quads to do your parallax scrolling starfield. I'm not an
> OpenGL expert though; would anyone more experienced have a sense of
> how this would compare speedwise to the VBO approach? The advantages
> to a procedural texture would be that there'd be no repetition to the
> field, and that of course you'd never have to send more data over to
> the card, except for the parameters to the shader used to generate the
> texture.
>
> -Chris
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users



-- 
Ryan Hope, M.S.
CogWorks Lab
Cognitive Science Department
Rensselaer Polytechnic Institute

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Derakon <de...@gm...>]

On Fri, Oct 19, 2012 at 11:16 AM, Ian Mallett <geo...@gm...> wrote:
> On Fri, Oct 19, 2012 at 11:59 AM, Chris Barker <chr...@no...>
> wrote:
>>
>> Display lists probably wont' help as you would still need to build up
>> the list -- it's also old-style and practically deprecated approach.
>
> You have to build the VBO too, but yes, display lists are deprecated.
>
> As far as dynamic stars, yes, the idea is to use either a display list or a
> VBO and either transform or use a vertex program to move your stars. For
> starfields, I personally have gotten compelling results by simply making
> several static starfields of different sizes and then scrolling them with
> glTranslatef at different rates. This gives a nice parallax effect, and is
> essentially just as fast as drawing the stars completely static.

It occurs to me that you could probably rig up a procedural texture
that would simulate a starfield for you. Then you could just use a set
of textured quads to do your parallax scrolling starfield. I'm not an
OpenGL expert though; would anyone more experienced have a sense of
how this would compare speedwise to the VBO approach? The advantages
to a procedural texture would be that there'd be no repetition to the
field, and that of course you'd never have to send more data over to
the card, except for the parameters to the shader used to generate the
texture.

-Chris

Re: [PyOpenGL-Users] 3d globe?

[Ian M. <geo...@gm...>]

On Fri, Oct 19, 2012 at 11:05 AM, Tony Peña <emp...@gm...> wrote:

> how can i get example of 3d glboe earth projection with simple texture
> image of the blue marble or openstreetmap or like satellite . with a simple
> point into 0,0 and of course could be rotate ?
> is for try including into pyqt qtabwidget ...
> any idea?
>
> --
> Antonio Peña
> Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
>  Fingerprint: 74E6 2974 B090 366D CE71  7BB2 6476 FA09 8B02 1001
>
I wrote an ancient and crufty demo that does exactly this:
http://www.pygame.org/project-World-472-.html

Perhaps you can clarify what you're looking for?

Re: [PyOpenGL-Users] Fastest way to draw lots of points

[Ian M. <geo...@gm...>]

On Fri, Oct 19, 2012 at 11:59 AM, Chris Barker <chr...@no...>wrote:

> Display lists probably wont' help as you would still need to build up
> the list -- it's also old-style and practically deprecated approach.
>
You have to build the VBO too, but yes, display lists are deprecated.

As far as dynamic stars, yes, the idea is to use either a display list or a
VBO and either transform or use a vertex program to move your stars. For
starfields, I personally have gotten compelling results by simply making
several static starfields of different sizes and then scrolling them with
glTranslatef at different rates. This gives a nice parallax effect, and is
essentially just as fast as drawing the stars completely static.

Ian