pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] Recommendations for font rendering

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

Oh dear, I knew I forgot to mention something. I was using PyGame
before, but I'm switching to OpenGL for performance reasons, which of
course prevents direct blitting to the screen using PyGame. I tried
using a "blit text to surface and convert to quad and draw" approach,
but with text that changes frequently that means making a ton of new
surfaces and it just doesn't perform well at all (in particular, my
in-game console was unusably slow). It seems likely I'd need an
approach that allows for each character to be on its own textured quad
that I can toss anywhere as needed.

On Wed, Jun 30, 2010 at 10:16 PM, Ian Mallett <geo...@gm...> wrote:
> Hi,
>
> I use PyGame, which is cross-platform, and can load standard font types.
> The font is rendered as a "surface", which can be changed to a texture and
> mapped your polygon(s).
>
> Ian
>

Re: [PyOpenGL-Users] Recommendations for font rendering

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

Hi,

I use PyGame, which is cross-platform, and can load standard font types.
The font is rendered as a "surface", which can be changed to a texture and
mapped your polygon(s).

Ian

[PyOpenGL-Users] Recommendations for font rendering

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

I'm searching for a decent approach to font rendering for my game
project. Apparently this is a big deal! Ideally I'd like something
that:

a) Is cross-platform, and
b) Can load fonts in a standard format (precludes GLUT's stroke- and
bitmap-fonts)

I found PyFTGL, but I cannot for the life of me get it to build on my
target platform (OSX)*, and if I can't then I doubt any potential
future collaborators could either. I can't find any other solutions;
am I going to have to make my own homebrew textured-quads-based
approach (or make my own FTGL bindings)? Text rendering seems like
such a basic part of game development that I'm amazed there aren't
more general-purpose libraries available...

* It doesn't know to use frameworks instead of searching directly for
the OpenGL libraries. It can't find my Boost libraries, which are
installed in a standard location. Hacking together my own build
invocation doesn't seem to generate usable files for some reason. I'd
give more details but frankly I spent two very painful evenings on it
several weeks ago and only now am able to return to this hobby for a
bit...I suspect the memories may be repressed.

-Chris

Re: [PyOpenGL-Users] Building an interleaved buffer for pyopengl

[Nick S. <ni...@so...>]

Hello, thanks for your response!

On Thu, Jul 1, 2010 at 4:40 AM, Dan Helfman <Dan...@no...> wrote:
> I think the answer to improving performance here is actually in one of
> the responses to the stackoverflow question you posted: "The real
> savings will be realized by a recasting of the render routine so that
> you don't have to create a python object for every value that ends up
> being placed in the buffer."

I believe the point the poster bpowah on stackoverflow was making was
just that I should reduce the number of objects (eg pregenerating
texture coord lists)?  At least I guess that's how I interpreted it.

> In other words, don't create a separate object for each sprite, and
> don't call a render() function once for each sprite. Structure your code
> so that it's more data oriented rather than object oriented: Fill up a
> NumPy array all at once with all of your sprites, trying to avoid any
> looping in Python. Then send that array (interleaved or not) to a
> PyOpenGL VBO.

The problem is that I can't really see how to do things such as
collision detection and response without doing at least one loop
through all sprite objects. (I step through each sprite individually
and do sprite movement and collision response to ensure no overlapping
sprites).  Wouldn't things such as updating sprite position and
adjusting for collision response mean the vertices change on every
update? I can fill up a numpy array but it seems that modifying the
array is slower than just creating a new numpy array from a python
list.

The random() methods may be a red herring.  Testing with a dummy
method (that doesn't add data to a list) shows that render() in the
example does take a while to run.  It doesn't quite explain why
generating a new numpy array from a list is quicker than just
modifying a preallocated numpy array though.

# dummy array.. just iterate but don't save
def create_array_dummy():
    for x in xrange(4096):
        render(x)
    return []

$ python testing2.py   # on another slower machine.
from dummy: 9.96989965439 ms
from list: 16.1171197891 ms
etc...

- Nick

Re: [PyOpenGL-Users] Building an interleaved buffer for pyopengl

[Dan H. <Dan...@no...>]

On 06/30/2010 07:04 AM, Nick Sonneveld wrote:
> Hello!
>
> (Full disclosure: I actually posted this on stackoverflow a few months
> ago but I didn't really receive a good response. url:
> http://bit.ly/a8W5hR )
>
> I have a series of sprite objects rendering to textured quads.  Right
> now they all have individual render() methods which return an
> interleaved buffer. I call them all in order and batch these vertices
> and texture coords before sending to pyOpengl's
> glInterleavedArrays/glDrawArrays.  Is there a better way to be doing
> this?  The fastest way seems to be generating a python list and
> converting to a numpy array later which doesn't seem right.
>
> Thankyou for any help?

I think the answer to improving performance here is actually in one of 
the responses to the stackoverflow question you posted: "The real 
savings will be realized by a recasting of the render routine so that 
you don't have to create a python object for every value that ends up 
being placed in the buffer."

In other words, don't create a separate object for each sprite, and 
don't call a render() function once for each sprite. Structure your code 
so that it's more data oriented rather than object oriented: Fill up a 
NumPy array all at once with all of your sprites, trying to avoid any 
looping in Python. Then send that array (interleaved or not) to a 
PyOpenGL VBO.

Dan

[PyOpenGL-Users] Building an interleaved buffer for pyopengl

[Nick S. <ni...@so...>]

Hello!

(Full disclosure: I actually posted this on stackoverflow a few months
ago but I didn't really receive a good response. url:
http://bit.ly/a8W5hR )

I have a series of sprite objects rendering to textured quads.  Right
now they all have individual render() methods which return an
interleaved buffer. I call them all in order and batch these vertices
and texture coords before sending to pyOpengl's
glInterleavedArrays/glDrawArrays.  Is there a better way to be doing
this?  The fastest way seems to be generating a python list and
converting to a numpy array later which doesn't seem right.

Thankyou for any help?

I have attached some example code and their timings.  Timings using
random numbers on my machine:

$ python testing2.py
from list: 9.02473926544 ms
array: indexed: 14.8707222939 ms
array: slicing: 30.3278303146 ms
array: concat: 26.5012693405 ms
array: put: 45.0277900696 ms
ctypes float array: 26.240530014 ms

- Nick

[PyOpenGL-Users] AntTweakBar python bindings

[Nicolas R. <Nic...@lo...>]

Hello,

I've coded AntTweakBar pythong bindings, they're available at:

http://www.loria.fr/~rougier/coding/index.html
(atb entry). There is a GLUT example with the package that show basic usage.


For those who do not know AntTweakBar, it is "a small and easy-to-use C/C++ library that allows programmers to quickly add a light and intuitive graphical user interface into graphic applications based onOpenGL, DirectX 9 or DirectX 10 to interactively tweak their parameters on-screen."

Website: http://www.antisphere.com/Wiki/tools:anttweakbar?sb=tools



Nicolas

Re: [PyOpenGL-Users] Install on Windows 7 64 bit.

[Nils S. <su...@gm...>]

Hi,

msvcr71.dll is neither part of Visual Studio 2008 nor 2010 (express).
Installed python from source (python setup install) and it worked like a
charm.

Today's hint: If you plan to write/build python extensions in C/C++ go with
VS 2008, VS 2010 is not recognized by setuptools.

Thanks for all the help.

On Fri, Jun 18, 2010 at 3:44 AM, Marcelo de Freitas Rigon <
are...@ig...> wrote:

>  Hi Nils,
>
> I have a similiar problem here and there are 2 solutions.
> 1) install VS (don't know which version however)
> 2) get the package in the site (not via easy_install as i don't know if you
> change the default compiler) and get mingw32 with g++, put de
> c:\<mingwdir>\bin in the path, then use:
> python setup.py installl build --compiler=mingw32
>
> Good luck ^^
> Marcelo
>
>  *From:* Nils Sudmann <su...@gm...>
> *Sent:* Thursday, June 17, 2010 12:34 AM
> *To:* pyo...@li...
> *Subject:* [PyOpenGL-Users] Install on Windows 7 64 bit.
>
> Installing PyOpenGL on Windows 7 (x64) is giving me headaches. Searching
> previous postings on the list reveals that different people have had the
> same kind of problems, but never all of them at once, as it seems I have:
>
>
> 1. Using easy_install (recommended method) complains that it "Couldn't find
> a setup script" (as reported by horace grant on may 2).
> 2. Missing msvcr71.dll as reported by several people when trying to use the
> executable installer (PyOpenGL-3.0.1.win32.exe).
>
> What is next? I'll try downloading the source and "compiling it". Dunno if
> I need a vc-like compiler for this, but I'm guessing not. The thing is that
> PyOpenGL-accelerated installer installed just fine.
>
>
> --
> If Atheism is a religion, then not collecting stamps is a hobby.
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
>
> ------------------------------
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>



-- 
If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] Install on Windows 7 64 bit.

[Marcelo de F. R. <are...@ig...>]

Hi Nils,

I have a similiar problem here and there are 2 solutions.
1) install VS (don't know which version however)
2) get the package in the site (not via easy_install as i don't know if you change the default compiler) and get mingw32 with g++, put de c:\<mingwdir>\bin in the path, then use:
python setup.py installl build --compiler=mingw32

Good luck ^^
Marcelo


From: Nils Sudmann 
Sent: Thursday, June 17, 2010 12:34 AM
To: pyo...@li... 
Subject: [PyOpenGL-Users] Install on Windows 7 64 bit.


Installing PyOpenGL on Windows 7 (x64) is giving me headaches. Searching previous postings on the list reveals that different people have had the same kind of problems, but never all of them at once, as it seems I have:


1. Using easy_install (recommended method) complains that it "Couldn't find a setup script" (as reported by horace grant on may 2). 
2. Missing msvcr71.dll as reported by several people when trying to use the executable installer (PyOpenGL-3.0.1.win32.exe).

What is next? I'll try downloading the source and "compiling it". Dunno if I need a vc-like compiler for this, but I'm guessing not. The thing is that PyOpenGL-accelerated installer installed just fine.  


-- 
If Atheism is a religion, then not collecting stamps is a hobby.


--------------------------------------------------------------------------------


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo 


--------------------------------------------------------------------------------


_______________________________________________
PyOpenGL Homepage
http://pyopengl.sourceforge.net
_______________________________________________
PyOpenGL-Users mailing list
PyO...@li...
https://lists.sourceforge.net/lists/listinfo/pyopengl-users

Re: [PyOpenGL-Users] Install on Windows 7 64 bit.

[Alejandro S. <as...@gm...>]

Hi Nils,

On Thu, Jun 17, 2010 at 12:34 AM, Nils Sudmann <su...@gm...> wrote:

> Installing PyOpenGL on Windows 7 (x64) is giving me headaches. Searching
> previous postings on the list reveals that different people have had the
> same kind of problems, but never all of them at once, as it seems I have:
>
> 1. Using easy_install (recommended method) complains that it "Couldn't find
> a setup script" (as reported by horace grant on may 2).


I don't know about this one, maybe someone else has some advice?


> 2. Missing msvcr71.dll as reported by several people when trying to use the
> executable installer (PyOpenGL-3.0.1.win32.exe).
>

These errors usually show up when you don't have Visual Studio installed and
your Windows box is missing the C/C++ runtime.

You should be able to fix this either by installing VS or the Visual C++
Redistributable Package. Keep in mind though that what's being reported
missing is the C runtime version 7.1, which is very dated (2003). I don't
know if the latest C++ runtime includes dll's for that version.


> What is next? I'll try downloading the source and "compiling it". Dunno if
> I need a vc-like compiler for this, but I'm guessing not. The thing is that
> PyOpenGL-accelerated installer installed just fine.
>

Let us know how it goes.

Best regards,
Alejandro.-

-- 
Alejandro Segovia Azapian
Director, Algorithmia: Visualization & Acceleration
http://web.algorithmia.net

[PyOpenGL-Users] Install on Windows 7 64 bit.

[Nils S. <su...@gm...>]

Installing PyOpenGL on Windows 7 (x64) is giving me headaches. Searching
previous postings on the list reveals that different people have had the
same kind of problems, but never all of them at once, as it seems I have:


1. Using easy_install (recommended method) complains that it "Couldn't find
a setup script" (as reported by horace grant on may 2).
2. Missing msvcr71.dll as reported by several people when trying to use the
executable installer (PyOpenGL-3.0.1.win32.exe).

What is next? I'll try downloading the source and "compiling it". Dunno if I
need a vc-like compiler for this, but I'm guessing not. The thing is that
PyOpenGL-accelerated installer installed just fine.


-- 
If Atheism is a religion, then not collecting stamps is a hobby.

Re: [PyOpenGL-Users] glGetUniformfv

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

Hi,

I tried the sample and it works well as a workaround.  Note that the *12
must be *16 for 4x4 matrices, and I imagine something else for other types
(otherwise the application terminates "in an unusual way".

Thanks,
Ian

Re: [PyOpenGL-Users] Need help about Picking

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

Awesome!  Glad I could help.

[PyOpenGL-Users] R: Need help about Picking

[Marco A. <mar...@ex...>]

Hi Ian,

 

I followed your advice ( I convert now in OpenGL units) and it works.

 

Thank you for your precious help !!!

 

Marco

  _____  

Da: Marco Avellino [mailto:mar...@ex...] 
Inviato: lunedì 7 giugno 2010 13.52
A: 'Ian Mallett'
Cc: 'pyopengl-users'
Oggetto: R: [PyOpenGL-Users] Need help about Picking

 

Ok, I’ll try to follow your advice

 

If it works, I will send a new mail to confirm it.

 

Thank you for your precious help

 

Marco

 

  _____  

Da: Ian Mallett [mailto:geo...@gm...] 
Inviato: venerdì 4 giugno 2010 19.33
A: Marco Avellino
Cc: pyopengl-users
Oggetto: Re: [PyOpenGL-Users] Need help about Picking

 

On Thu, Jun 3, 2010 at 2:31 AM, Marco Avellino
<mar...@ex...> wrote:

Challenge: 

Obtain reliable values of min_depth in everywhere I see models in the scene.
Actually I obtain reliable values of min_depth only in a great level of zoom
(= Page Down).

Seems picking is working . . .

Also, the depth seems to be working fine too.  Do however remember that it's
returning the depth value in z-buffer units.  These measure the part
difference of the fragment from the near plane to the far one.  For example,
in your code, the near and far planes are at 0.1 and 2.0, respectively.  If
a fragment is 1.05 OpenGL units away from the camera, then in Z, your
fragment is 0.5, because it is halfway between the near and far planes.
However, in practice, the Z-buffer is mapped to be non-linear, so the
conversion is more difficult.  

Do note that for selecting, you can just use the values returned from the
selection buffer "as-is".  Conversion is not necessary for a
comparison--only for getting actual OpenGL coordinates.

If you still need to convert to OpenGL units, you can do the following:


mpos = #mouse position--ensure that it is measured in
       #pixels from the *lower right* of the screen!

returned_z_value = #whatever value you want to convert

viewport = glGetIntegerv(GL_VIEWPORT)
modelview = glGetDoublev(GL_MODELVIEW_MATRIX)
projection = glGetDoublev(GL_PROJECTION_MATRIX)

#pos is the actual position of the object in OpenGL coordinates
pos =
gluUnProject(mpos[0],mpos[1],returned_z_value,modelview,projection,viewport)


#tells how far away, in OpenGL units, the object is
distance = length(pos-camerapos)


Other than this possible pitfall, I don't see any problem.

Ian

Re: [PyOpenGL-Users] glGetUniformfv

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

On 10-06-06 12:26 PM, Gijs wrote:
> Glad we cleared that up :)
>
> Anyway, I tried it out, but I couldn't get it to work either.
> glGetUniformfv seemed to be defined as glGetUniformfv(programloc,
> varloc, returnvalues) in PyOpenGL, same as the default C spec. Normal
> PyOpenGL functions aren't defined this way. As you said, the return
> values are normally returned instead of passed along with the function
> call.
>
> When I tried to call it with three parameters, it did not even touch
> the returnvariable. So I assume there is a bug somewhere. Also, the
> function requires an array to be passed as a returnvariable, but the
> return value is always one value, never an array. You simply cannot
> ask for the values of an entire shader-array. You'd need to call
> glGetUniformfv for each element of the array.
>
> It might work if you pass a ctypes float along with it, however I have
> no experience with ctypes stuff, so I'll leave that to the experts.

This function should get wrapped to create the array automatically.  In
the meantime, this is a sample that should work:

                glUniform4fv(
                    self.uniform_locations['lights'],
                    12,
                    self.LIGHTS
                )
                test_lights = (GLfloat * 12)()
                glGetUniformfv( self.shader,
self.uniform_locations['lights'], test_lights )
                print 'Lights', list(test_lights)

You should be able to pass any writable PyOpenGL array type (e.g. a
numpy array) as params.

HTH,
Mike

> On 6/6/10 16:06 , Ian Mallett wrote:
>> On Sun, Jun 6, 2010 at 1:31 AM, Gijs <in...@bs...
>> <mailto:in...@bs...>> wrote:
>>
>>     I don't think I've ever had to use it before, but you usually
>>     give the program location and the variable location. So it would
>>     be something like this:
>>     value = glGetUniformfv(programloc, varloc)
>>
>> Oops!  I actually tried that.  Typo. 
>> value=glGetUniformfv(programlocation)
>> Should have been:
>> value=glGetUniformfv(program,location)
>> Ian
>

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

[PyOpenGL-Users] R: Need help about Picking

[Marco A. <mar...@ex...>]

Ok, I’ll try to follow your advice

 

If it works, I will send a new mail to confirm it.

 

Thank you for your precious help

 

Marco

 

  _____  

Da: Ian Mallett [mailto:geo...@gm...] 
Inviato: venerdì 4 giugno 2010 19.33
A: Marco Avellino
Cc: pyopengl-users
Oggetto: Re: [PyOpenGL-Users] Need help about Picking

 

On Thu, Jun 3, 2010 at 2:31 AM, Marco Avellino
<mar...@ex...> wrote:

Challenge: 

Obtain reliable values of min_depth in everywhere I see models in the scene.
Actually I obtain reliable values of min_depth only in a great level of zoom
(= Page Down).

Seems picking is working . . .

Also, the depth seems to be working fine too.  Do however remember that it's
returning the depth value in z-buffer units.  These measure the part
difference of the fragment from the near plane to the far one.  For example,
in your code, the near and far planes are at 0.1 and 2.0, respectively.  If
a fragment is 1.05 OpenGL units away from the camera, then in Z, your
fragment is 0.5, because it is halfway between the near and far planes.
However, in practice, the Z-buffer is mapped to be non-linear, so the
conversion is more difficult.  

Do note that for selecting, you can just use the values returned from the
selection buffer "as-is".  Conversion is not necessary for a
comparison--only for getting actual OpenGL coordinates.

If you still need to convert to OpenGL units, you can do the following:


mpos = #mouse position--ensure that it is measured in
       #pixels from the *lower right* of the screen!

returned_z_value = #whatever value you want to convert

viewport = glGetIntegerv(GL_VIEWPORT)
modelview = glGetDoublev(GL_MODELVIEW_MATRIX)
projection = glGetDoublev(GL_PROJECTION_MATRIX)

#pos is the actual position of the object in OpenGL coordinates
pos =
gluUnProject(mpos[0],mpos[1],returned_z_value,modelview,projection,viewport)


#tells how far away, in OpenGL units, the object is
distance = length(pos-camerapos)


Other than this possible pitfall, I don't see any problem.

Ian

Re: [PyOpenGL-Users] glGetUniformfv

[Gijs <in...@bs...>]

Glad we cleared that up :)

Anyway, I tried it out, but I couldn't get it to work either. 
glGetUniformfv seemed to be defined as glGetUniformfv(programloc, 
varloc, returnvalues) in PyOpenGL, same as the default C spec. Normal 
PyOpenGL functions aren't defined this way. As you said, the return 
values are normally returned instead of passed along with the function call.

When I tried to call it with three parameters, it did not even touch the 
returnvariable. So I assume there is a bug somewhere. Also, the function 
requires an array to be passed as a returnvariable, but the return value 
is always one value, never an array. You simply cannot ask for the 
values of an entire shader-array. You'd need to call glGetUniformfv for 
each element of the array.

It might work if you pass a ctypes float along with it, however I have 
no experience with ctypes stuff, so I'll leave that to the experts.

Gijs

On 6/6/10 16:06 , Ian Mallett wrote:
> On Sun, Jun 6, 2010 at 1:31 AM, Gijs <in...@bs... 
> <mailto:in...@bs...>> wrote:
>
>     I don't think I've ever had to use it before, but you usually give
>     the program location and the variable location. So it would be
>     something like this:
>     value = glGetUniformfv(programloc, varloc)
>
> Oops!  I actually tried that.  Typo.
> value=glGetUniformfv(programlocation)
> Should have been:
> value=glGetUniformfv(program,location)
> Ian

Re: [PyOpenGL-Users] glGetUniformfv

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

On Sun, Jun 6, 2010 at 1:31 AM, Gijs <in...@bs...> wrote:

>  I don't think I've ever had to use it before, but you usually give the
> program location and the variable location. So it would be something like
> this:
> value = glGetUniformfv(programloc, varloc)
>
Oops!  I actually tried that.  Typo.
value=glGetUniformfv(programlocation)
Should have been:
value=glGetUniformfv(program,location)
Ian

Re: [PyOpenGL-Users] glGetUniformfv

[Gijs <in...@bs...>]

Hi Ian,

I don't think I've ever had to use it before, but you usually give the 
program location and the variable location. So it would be something 
like this:
value = glGetUniformfv(programloc, varloc)

Hope this helps.

Regards,
Gijs

On 6/6/10 7:30 , Ian Mallett wrote:
> Hi,
>
> In trying to debug something, I'm trying to use glGetUniformfv, which 
> I've never used before.  It demands three arguments, and in the 
> documentation a pointer is supposed to be passed.  In Python, such 
> code is typically replaced with a "___ =":
>
> value=glGetUniformfv(programlocation)
>
> This does not work.  What to do?
>
> Ian
>
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
>
>
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>    

[PyOpenGL-Users] glGetUniformfv

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

Hi,

In trying to debug something, I'm trying to use glGetUniformfv, which I've
never used before.  It demands three arguments, and in the documentation a
pointer is supposed to be passed.  In Python, such code is typically
replaced with a "___ =":

value=glGetUniformfv(programlocation)

This does not work.  What to do?

Ian

Re: [PyOpenGL-Users] texture arrays or 3 textures

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

On Fri, Jun 4, 2010 at 10:55 AM, Philip Winston <pwi...@gm...> wrote:

> That's not very encouraging...  so are "texture arrays" even worse?
>
Portability is not really such a huge problem.  It's just not given
functionality.  Newer cards probably support it; it's much older cards that
will difficulty, as is evident here:
http://www.opengl.org/resources/code/samples/sig99/advanced99/notes/node390.html.
Although, if you're writing for cards with programmable shaders, then
chances are 3D texturing will be supported in all its glory.

> That's what we do now and it is a little complex.  The shader needs to know
> the shape/size of the texture and do a bit of math to convert from RGB index
> to UV.  With a 3D texture it seems we can directly use the RGB index as the
> STR coordinates for a 256x256xN texture.  The texture can be only as deep as
> is needed, based on the size of the colormap.
>

> So older cards don't like 3D Textures or does it continue to be a problem
> even for newer hardware?  We have only two dozen users, mostly newish Quadro
> 3800 cards.
>
Then you're probably fine.  A 3D texture is great, especially for new cards
and future cards.

> -Philip

Ian

Re: [PyOpenGL-Users] texture arrays or 3 textures

[Philip W. <pwi...@gm...>]

On Fri, Jun 4, 2010 at 1:14 PM, Ian Mallett <geo...@gm...> wrote:

> What is the context of this problem?


It's a false-color display on top of grayscale images. We have a grayscale
image and a separate image which contains a per-pixel segment index.  Then
we have a colormap which maps segment indexes to RGBA values.  The shader
looks the color up in the colormap then blends it with the grayscale value.

Initially we used LUMINANCE_16 images, so only 16-bit indexes, and a fixed
256x256 colormap.  We moved to RGB  to hold up to 24-bit indexes because
some images are large and have more than 65k segments.


> A 3D texture would certainly work, but these suffer from memory issues,
> complexity, and graphics-cards-generally-not-liking-them.
>

That's not very encouraging...  so are "texture arrays" even worse?


>  You might do better to "unroll" the 3D texture into a 2D texture, although
> again, complexity.
>

That's what we do now and it is a little complex. The shader needs to know
the shape/size of the texture and do a bit of math to convert from RGB index
to UV.  With a 3D texture it seems we can directly use the RGB index as the
STR coordinates for a 256x256xN texture.  The texture can be only as deep as
is needed, based on the size of the colormap.

So older cards don't like 3D Textures or does it continue to be a problem
even for newer hardware?  We have only two dozen users, mostly newish Quadro
3800 cards.

-Philip

Re: [PyOpenGL-Users] Need help about Picking

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

On Thu, Jun 3, 2010 at 2:31 AM, Marco Avellino <mar...@ex...
> wrote:

>  *Challenge:*
>
> Obtain reliable values of min_depth in everywhere I see models in the
> scene. Actually I obtain reliable values of min_depth only in a great level
> of zoom (= Page Down).
>
Seems picking is working . . .

Also, the depth seems to be working fine too.  Do however remember that it's
returning the depth value in z-buffer units.  These measure the part
difference of the fragment from the near plane to the far one.  For example,
in your code, the near and far planes are at 0.1 and 2.0, respectively.  If
a fragment is 1.05 OpenGL units away from the camera, then in Z, your
fragment is 0.5, because it is halfway between the near and far planes.
However, in practice, the Z-buffer is mapped to be non-linear, so the
conversion is more difficult.

Do note that for selecting, you can just use the values returned from the
selection buffer "as-is".  Conversion is not necessary for a
comparison--only for getting actual OpenGL coordinates.

If you still need to convert to OpenGL units, you can do the following:


mpos = #mouse position--ensure that it is measured in
       #pixels from the *lower right* of the screen!

returned_z_value = #whatever value you want to convert

viewport = glGetIntegerv(GL_VIEWPORT)
modelview = glGetDoublev(GL_MODELVIEW_MATRIX)
projection = glGetDoublev(GL_PROJECTION_MATRIX)

#pos is the actual position of the object in OpenGL coordinates
pos =
gluUnProject(mpos[0],mpos[1],returned_z_value,modelview,projection,viewport)


#tells how far away, in OpenGL units, the object is
distance = length(pos-camerapos)


Other than this possible pitfall, I don't see any problem.

Ian

Re: [PyOpenGL-Users] texture arrays or 3 textures

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

On Thu, Jun 3, 2010 at 11:05 AM, Philip Winston <pwi...@gm...> wrote:

> I have a shader which takes a 16-bit index and looks into a 256x256 table
> for an RGBA value, a colormap  I want to extend it to handle larger indexes.
>  I think the best way is create a texture array or a 3D texture with
> multiple 256x256 textures.  Then instead of looking up just U, V I would
> look up R, S, T.
>

> Are texture arrays and 3d textures both supported in PyOpenGL? Is one
> better suited to this problem?
>
3D textures I know are, because I've used them, and texture arrays likely
are too.

What is the context of this problem?  A 3D texture would certainly work, but
these suffer from memory issues, complexity, and
graphics-cards-generally-not-liking-them.  You might do better to "unroll"
the 3D texture into a 2D texture, although again, complexity.

> I want an exact nearest-neighbor lookup, no filtering in X, Y or Z.
>
Use GL_NEAREST when making the texture(s)

> Thanks.
>
> -Philip
>
Ian

Re: [PyOpenGL-Users] embed pyopengl in pygtk. looking for a good starting point

[Duong D. <dan...@gm...>]

I finally used pygtkglext, it worked well.

On Thu, Jun 3, 2010 at 7:17 AM, Duong Dang <dan...@gm...> wrote:

> Hi all,
>
> My application got to a point where I want to embed it into a GUI framework
> (gtk-based, already written by my colleagues). I tried both pyopengl and
> pygtk website but couldn't find any good starting point. Anyone could help
> me on this?
>
> Thanks a lot in advance!
>
> Regards,
>
> D
>
>