Ian Mallett wrote:
I may be
mistaken, but the speed issue is related to the number of OpenGL calls
made and glBegin/End aren't especially long.
Yes, and this is even more true in Python, where
function calls are relatively expensive. So using
array-oriented calls whenever possible should help
This stuff was discussed on the pyglet mailing list a while back. One relevant
thread is here:
http://groups.google.com/group/pyglet-users/browse_thread/thread/8b35f0e0971939f3
Richard
> René Dudfield <[EMAIL PROTECTED]> wrote:
>
> Indeed. Generally strings, lists and tuples are copied
Indeed. Generally strings, lists and tuples are copied in python - so
the array types are faster.
Another option is to use ctypes arrays. However neither ctypes or
numpy are available on all versions of python... but if you're using
pyopengl 3.x that uses ctypes already :)
cu,
On Wed, Aug 6,
Ian Mallett wrote:
This thread has more moved into: "optimizing opengl landscape loading"
The speed problem is simply the converting the height data into an
OpenGL display list.
For that I'd investigate using numpy arrays together with
the array-oriented OpenGL calls.
--
Greg
sorry, the link I gave doesn't use vertex arrays very well.
A better example is this one:
http://www.google.com/codesearch?hl=en&q=file:\.py+drawarrays+demo+show:r0dvt8wsEt4:1Ns9Y_oHlDQ:LUdS7R6LMrU&sa=N&cd=6&ct=rc&cs_p=http://downloads.sourceforge.net/pyopengl/OpenGL-3.0.0a4.zip&cs_f=OpenGL-3.0.0a
hi,
Have a look in the PyOpengl Demo directory... there's lots of vertex
array examples.
Here's a pretty small example: http://developer.nomadph.com/guest001.html
Note that glBegin/glEnd have been removed from OpenglES, since they
really are not suitable to use for high speed.
cheers,
On Wed
2008/8/5 Ian Mallett <[EMAIL PROTECTED]>:
> we're doing now). I may be mistaken, but the speed issue is related to the
> number of OpenGL calls made and glBegin/End aren't especially long.
You could optimize the code you posted earlier by removing the
divisions by fwidth and fheight and instead
On Tue, Aug 5, 2008 at 3:03 PM, Jake b <[EMAIL PROTECTED]> wrote:
> ian: If I understand right, I think that for speed you're supposed to
> avoid immediate mode ( begin/end) as much as possible. Looking at your
> loop, is it possible to move begin/end out one more level, or not?
Nope. Each pixel
> I think you have it backwards, vertex arrays are widely supported (OpenGL
> 1.1 or greater), VBOs are much newer.
>
> -Casey
Does Immediate mode means using glBegin()/glEnd() blocks?
Can you post / link to example code using vertex arrays? ( Preferably
in python +numpy/numeric )
ian: If I unde
OK, but I still can't do VBOs. From what I can tell, they are much faster.
Anyone have a good PyOpenGL example?
I was going off of one of my OpenGL programs which no one could use because
it had vertex arrays.
Ian
On Aug 5, 2008, at 11:28 AM, Ian Mallett wrote:
Again, I don't know how to do VBOs (just vertex arrays which aren't
widely supported), and I am already loading the array from
precomputed data stored on the hard drive.
I think you have it backwards, vertex arrays are widely supported
(Open
Again, I don't know how to do VBOs (just vertex *arrays* which aren't widely
supported), and I am already loading the array from precomputed data stored
on the hard drive.
On Aug 5, 2008, at 12:24 AM, Ian Mallett wrote:
#World
HeightMapTexture,HeightMapSurface = LoadSurfaceTexture('Data/
Landscapes/'+World+'/HeightMap.png',Surface=True,filter=False)
WorldTexture = LoadSurfaceTexture('Data/Landscapes/'+World+'/
Texture.png')
dlSeaBed = glGenLists(1)
glNewList(dl
#World
HeightMapTexture,HeightMapSurface =
LoadSurfaceTexture('Data/Landscapes/'+World+'/HeightMap.png',Surface=True,filter=False)
WorldTexture = LoadSurfaceTexture('Data/Landscapes/'+World+'/Texture.png')
dlSeaBed = glGenLists(1)
glNewList(dlSeaBed, GL_COMPILE)
glPushMatrix()
glDisable(GL_LIGHTING
are you using vertex buffers or making calls for each vertex or what?
On Mon, Aug 4, 2008 at 11:16 PM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> This thread has more moved into: "optimizing opengl landscape loading"
> The speed problem is simply the converting the height data into an OpenGL
> disp
This thread has more moved into: "optimizing opengl landscape loading"
The speed problem is simply the converting the height data into an OpenGL
display list.
Ian
Without seeing your code, I'm not sure what the error is.
> Speaking of time, even though the data is currently being prebuilt, it still
> takes an annoying amount of time to convert the height data into an OpenGL
> display list. I know that C can do it much faster. Anyone have any ideas
> for
Ian Mallett wrote:
Ideally, the display list data should be send directly to the GPU, no
processing at all. Is there any way to save/load a display list?
No, the only way to create a display list is to make
the appropriate series of OpenGL calls while compiling
one, and there's no way of read
My primary image editor is Paint Shop Pro 6.02--pretty old, but with
brilliant functionality.
Ideally, the display list data should be send directly to the GPU, no
processing at all. Is there any way to save/load a display list?
Ian
Knapp wrote:
Why not just use an array of floats?
I expect the problem is more related to the tool being
used to create the heightmap -- if it's an image editor,
it might not be able to cope with any more than 8 bits
per channel.
Finding image editor capable of dealing with 16 or 32 bit
greys
Here is a decorator that speeds up a function using screen lists:
def screen_list(func):
func.sl = None
def x():
if not func.sl:
func.sl = glGenLists(1)
glNewList(func.sl, GL_COMPILE)
func()
glEndList()
glCallList(func.sl)
On Mon, Aug 4, 2008 at 12:48 PM, Casey Duncan <[EMAIL PROTECTED]> wrote:
> What type of interpolation? Linear interpolation between points would
> require no extra vertices.
That was what I was doing at the outset, but it gives the "stepping" effect.
> You may need to implement some sort of var
On Aug 4, 2008, at 12:53 PM, Ian Mallett wrote:
Exactly, no. In OpenGL, surfaces must be made out of flat 2D
polygons. To interpolate a single pixel, I think five steps would
be minimally acceptable. That changes one quad into 25. My current
heightmap is 257x257 pixels = 256x256 = 65,53
> >>> I'm curious why? ( My thought is that doing a get on r,g,b,a would be
> >>> fast relative the blur operation? )
> >>>
> >>> Does this fix it?
> >>>
> >>> soften[1:][0:] += Data[0:-1][0:]*8
>
Traceback (most recent call last):
File "", line 1, in
antialias(array)
File "", line 3, in a
On Mon, Aug 4, 2008 at 11:00 AM, DR0ID <[EMAIL PROTECTED]> wrote:
>
>
> Knapp schrieb:
>>
>> On Mon, Aug 4, 2008 at 10:15 AM, Jake b <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> On Sun, Aug 3, 2008 at 2:46 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
>>>
If colors had only a red component, suppose
Knapp schrieb:
On Mon, Aug 4, 2008 at 10:15 AM, Jake b <[EMAIL PROTECTED]> wrote:
On Sun, Aug 3, 2008 at 2:46 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
If colors had only a red component, suppose, there would be 256 shades of
red. Because this is the case with grey heightmaps (only
On Mon, Aug 4, 2008 at 10:15 AM, Jake b <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 3, 2008 at 2:46 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
>> If colors had only a red component, suppose, there would be 256 shades of
>> red. Because this is the case with grey heightmaps (only 256 shades of
>> grey
On Sun, Aug 3, 2008 at 2:46 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> If colors had only a red component, suppose, there would be 256 shades of
> red. Because this is the case with grey heightmaps (only 256 shades of
> grey), there can only be 256 heights encoded. The obvious solution is to
>
The "stepping problem" I referred to has to do with the number of possible
colors and the time it takes to load them.
If colors had only a red component, suppose, there would be 256 shades of
red. Because this is the case with grey heightmaps (only 256 shades of
grey), there can only be 256 heigh
On Sun, Aug 3, 2008 at 8:24 AM, Ian Mallett <[EMAIL PROTECTED]> wrote:
> Hello,
>
> For a 3D game I'm making, I need to load a grey heightmap*. Obviously, only
> 256 heights are possible. In game, this translates to a landscape having
> "steps".
>
> -My current method, loading the data pixel by p
Hello,
For a 3D game I'm making, I need to load a grey heightmap*. Obviously, only
256 heights are possible. In game, this translates to a landscape having
"steps".
-My current method, loading the data pixel by pixel with Surface.get_at()
seems inefficient. There is a faster way through Numeri
31 matches
Mail list logo
