pyopengl-users — Discussion of all PyOpenGL matters.

Re: [PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes

[Joshua R. D. <jd...@ca...>]

----- Original Message -----
From: "Mike C. Fletcher" <mcf...@vr...>
To: "Joshua R. Davis" <jd...@ca...>
Cc: pyo...@li...
Sent: Saturday, February 14, 2009 5:10:59 PM GMT -06:00 US/Canada Central
Subject: Re: [PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes

Joshua R. Davis wrote:
> > I am trying to cast shadows from multiple lights using shaders. I use one framebuffer object per light. When I have just one light, it works. When I try two lights, the program survives the first call to glGenFramebuffersEXT() but crashes ("Bus error") upon the second call to it.

[snip]

> If you can run the script above instead of directly accessing the 
functions from the DLL we may be able to track down the problem further.

Thanks a lot, Mike. I no longer crash when making multiple calls to glGenFramebuffersEXT(). However, I now crash on the first call to glBindFramebufferEXT(). This demo...

#! /usr/bin/env python
from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *
from OpenGL.GL.EXT.framebuffer_object import *
def main():
    glutInit(0)
    glutInitDisplayMode(GLUT_RGB|GLUT_DOUBLE|GLUT_DEPTH)
    glutCreateWindow('test')
    framebuffer = glGenFramebuffersEXT(1)
    print framebuffer
    glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, framebuffer)
if __name__ == "__main__":
    main()

...produces this error:

> python fbotest.py
1
Traceback (most recent call last):
  File "fbotest.py", line 14, in <module>
    main()
  File "fbotest.py", line 12, in main
    glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, framebuffer)
  File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/PyOpenGL-3.0.0b6-py2.5.egg/OpenGL/platform/baseplatform.py", line 275, in __call__
    return self( *args, **named )
ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: wrong type

This kind of code used to work, when I was using the DLL. Can anyone help?

Joshua Davis

[PyOpenGL-Users] bug in glDrawBuffers?

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

Hello List,

I am trying to use glDrawBuffers to render to multiple textures using 
shaders. However, I'm running into a problem (otherwise I wouldn't be 
posting here ofcourse :) ). When I call glDrawBuffers with *any* 
buffer-type, it fails with the following error:

  File 
"/Library/Python/2.5/site-packages/OpenGL/platform/baseplatform.py", 
line 275, in __call__
    return self( *args, **named )
  File "/Library/Python/2.5/site-packages/OpenGL/error.py", line 194, in 
glCheckError
    baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
    err = 1280,
    description = 'invalid enumerant',
    baseOperation = glDrawBuffers,
    cArguments = (
        1,
        [
        GL_COLOR_ATTACHMENT0_EXT
    ],
    )
)

This is ofcourse just an example but I want to use it to enable 8 
buffers (the maximum that is supported by my card). When I call 
glDrawBuffer with GL_COLOR_ATTACHMENT0_EXT it does work so I know it 
*should* work. I am using python 2.5.1 and Mac OS X 10.5. Below is part 
of my test-render code for 3 buffers:

glUseProgram(p_multiple_output)
 
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, b_multiple_output)

glActiveTexture(GL_TEXTURE0)
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, int(input_images[0]))
glActiveTexture(GL_TEXTURE1)
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, int(input_images[1]))
glActiveTexture(GL_TEXTURE2)
glBindTexture(GL_TEXTURE_RECTANGLE_ARB, int(input_images[2]))
 
glActiveTexture(GL_TEXTURE0)

drawingBuffers = list([GL_COLOR_ATTACHMENT0_EXT, 
GL_COLOR_ATTACHMENT1_EXT, GL_COLOR_ATTACHMENT2_EXT])
glDrawBuffers(3, drawingBuffers)
 
glCallList(quadid)


Hope someone knows what's going on under the hood.

Regards

[PyOpenGL-Users] Please test PyOpenGL 3.0.0c1

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

Hi all,

I'm intending to release approximately the current trunk of PyOpenGL in 
bzr as 3.0.0 final, barring any show-stopping bug reports.  So, if you 
have show-stoppers that haven't been addressed, let me know.  The 
3.0.0c1 release is basically the same as the b8 release with a few bug 
fixes and binary versions of GLUT and GLE32 for Win32 users.  Going 
forward, I'm thinking I may focus much of my energy on getting developer 
documentation and the like written so that more contributors can work on 
the package.  At some point I'd also like to revisit the idea of 
unifying the Pyglet and PyOpenGL generators so that we're able to avoid 
duplication of effort somewhat.

Downloads are available from:

https://sourceforge.net/project/showfiles.php?group_id=5988&package_id=6035

Enjoy yourselves,
Mike

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

Re: [PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes

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

Joshua R. Davis wrote:
> I am trying to cast shadows from multiple lights using shaders. I use one framebuffer object per light. When I have just one light, it works. When I try two lights, the program survives the first call to glGenFramebuffersEXT() but crashes ("Bus error") upon the second call to it.
>
> What follows is a minimal demo. If I run it as-is, then it prints out the two FBO identifiers and terminates normally. If I switch the "cow = ..." and "print framebuffer" lines, then it prints out the first FBO identifier and then crashes ("Bus error"). Why would the location of the print statement matter?
>   
Here's what I'm running to test:

#! /usr/bin/env python
"""Test for glGenFramebuffersEXT multiple-call failure reported by 
Joshua Davis"""
from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *
# adapted from http://www.pygame.org/wiki/GLSLExample
from OpenGL.GL.EXT.framebuffer_object import *
def main():
    glutInit(0)
    glutInitDisplayMode(GLUT_RGB|GLUT_DOUBLE|GLUT_DEPTH)
    glutCreateWindow('test')
    framebuffer = glGenFramebuffersEXT(1)
    print framebuffer
    cow = glGenFramebuffersEXT(1)
    print cow

if __name__ == "__main__":
    main()

which prints the two identifiers on a Linux AMD64 (Kubuntu Intrepid) 
machine using driver "2.1.8087 FireGL Release" for an "ATI Mobility 
Radeon HD 3650" using BZR trunk of PyOpenGL.  No change if I swap the 
framebuffer = and print framebuffer lines.
> Other questions:
> 1. Why do I not need to call glInitFramebufferObjectEXT()?
>   
That function just checks for the presence of the extension, PyOpenGL 
will check for the extension the first time you try to call a function 
or check its boolean truth value, so the explicit check isn't needed any 
more.
> 2. Does glGenFramebuffersEXT(1) return a framebuffer identifier or a list of them? (When I try glGenFramebuffersEXT(1)[0], I get "TypeError: 'int' object is unsubscriptable".)
>   
This is, in retrospect, probably a poor choice.  I retained 
compatibility with PyOpenGL 1.x and 2.x scripts at the expense of the 
consistency of the interface.  The behaviour with all previous PyOpenGL 
releases (and PyOpenGL 3.x now) is to return a single-value rather than 
a list if you ask for a single item.

If you can run the script above instead of directly accessing the 
functions from the DLL we may be able to track down the problem further.

Good luck,
Mike

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

Re: [PyOpenGL-Users] OpenGL array-type problem

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

vwf wrote:
> Hello,
>
>
> For drawing large text/characters I use a stripped down version of 
> Michael C. Fletcher's OpenGLContext, pygamefont.py 
> I cut it down to the bare essentials, one file that does all the work.
>
> By upgrading from Debian Stable to Testing I ran into a problem.
> After the upgrade, during initialisation, I get:
>   
...
> "/usr/lib/python2.4/site-packages/OpenGL/arrays/arraydatatype.py", line
> 39, in getHandler
>     raise TypeError(
> TypeError: No array-type handler for type <type 'array'> (value:
> array([[[200,   0],
>         [200,   0],
>         [2) registered
>   
Looks like Debian testing is using one of the earlier betas which used 
setuptools for registering plugins, but has not run setuptools to 
register the plugins.
> Anyone an idea what the cause of this error can be?
>   
It's a failure to lookup a format-handler plugin from the old code that 
handled the plugin lookups.

HTH,
Mike

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

[PyOpenGL-Users] OpenGL array-type problem

[vwf <vw...@vu...>]

Hello,


For drawing large text/characters I use a stripped down version of 
Michael C. Fletcher's OpenGLContext, pygamefont.py 
I cut it down to the bare essentials, one file that does all the work.

By upgrading from Debian Stable to Testing I ran into a problem.
After the upgrade, during initialisation, I get:

Traceback (most recent call last):
[...]
  File "/home/.../fppu/manavnew/pyfont.py", line 187, in textureToList
    array, 
  File "/usr/lib/python2.4/site-packages/OpenGL/wrapper.py", line 1631,
in __call__
    return self.finalise()( *args, **named )
  File "/usr/lib/python2.4/site-packages/OpenGL/wrapper.py", line 502,
in wrapperCall
    pyArgs.append( converter(arg, self, args) )
  File "/usr/lib/python2.4/site-packages/OpenGL/GL/images.py", line 422,
in __call__
    return self.arrayType.asArray( arg )
  File
"/usr/lib/python2.4/site-packages/OpenGL/arrays/arraydatatype.py", line
70, in asArray
    return cls.getHandler(value).asArray( value, typeCode or
cls.typeConstant )
  File
"/usr/lib/python2.4/site-packages/OpenGL/arrays/arraydatatype.py", line
39, in getHandler
    raise TypeError(
TypeError: No array-type handler for type <type 'array'> (value:
array([[[200,   0],
        [200,   0],
        [2) registered

The calling line is line 68 of 
OpenGLContext-2.1.0a2/scenegraph/text/pygamefont.py

  glDrawPixelsub( 
          mode, 
          array, 
  )


Anyone an idea what the cause of this error can be?

Thank you!
Frits

Re: [PyOpenGL-Users] No stencil buffer?

[Jordan S. <jso...@MI...>]

Yep, that was it- I wasn't allocating a stencil buffer when I 
initialized GLUT.  Thanks a ton for your help!  I appreciate it.
Thanks,
-Jordan

Dirk Reiners wrote:
>
>     Hi Jordan,
>
> Jordan Sorensen wrote:
>> I've been developing a simple application using PyOpenGL for a few 
>> weeks now, and trying to add a feature that requires use of the 
>> stencil buffer.  However, the stencil buffer doesn't seem to be 
>> working- all pixels pass the test, even when the test is GL_NEVER.  
>> glGetInteger(GL_STENCIL_BITS) returns 0, but running glxinfo on my 
>> machine shows that my graphics card supports an 8 bit stencil 
>> buffer.  I'm running Ubuntu and my graphics card is an nVidia GeForce 
>> Go 7300.  Anyone have any ideas?
>
> The stencil buffer needs to be allocated when the window is created, 
> as it takes resources that not all applications need. How do you 
> create the window? If it's GLUT, the glutInitDisplayMode function 
> takes an option that allows you to specify it.
>
> Hope it helps
>
>     Dirk
>
>

Re: [PyOpenGL-Users] No stencil buffer?

[Lorenzo M. <lma...@de...>]

Jordan Sorensen wrote:
> I've been developing a simple application using PyOpenGL for a few weeks 
> now, and trying to add a feature that requires use of the stencil 
> buffer.  However, the stencil buffer doesn't seem to be working- all 
> pixels pass the test, even when the test is GL_NEVER.  
> glGetInteger(GL_STENCIL_BITS) returns 0, but running glxinfo on my 
> machine shows that my graphics card supports an 8 bit stencil buffer.  
> I'm running Ubuntu and my graphics card is an nVidia GeForce Go 7300.  
> Anyone have any ideas?

IIRC the stencil buffer shares the available bits of the depth buffer; 
thus, the choice is between having a 24 bit depth buffer with no stencil 
buffer and a 16 bit depth buffer with 8 bit stencil buffer.

-- 
Lorenzo Mancini

Re: [PyOpenGL-Users] No stencil buffer?

[Gary H. <gh...@is...>]

Jordan Sorensen wrote:
> I've been developing a simple application using PyOpenGL for a few weeks 
> now, and trying to add a feature that requires use of the stencil 
> buffer.  However, the stencil buffer doesn't seem to be working- all 
> pixels pass the test, even when the test is GL_NEVER.  
> glGetInteger(GL_STENCIL_BITS) returns 0, but running glxinfo on my 
> machine shows that my graphics card supports an 8 bit stencil buffer.  
> I'm running Ubuntu and my graphics card is an nVidia GeForce Go 7300.  
> Anyone have any ideas?
> Thanks a ton,
> -JS
>   

How are you creating your window?    The  window, and any
depth/stencil/aux buffers associated with it, are not created by OpenGL,
but are part of the context created with the window via what ever method
you use to create the window.  So I repeat -- what method do you use to
create a window, and can you find a way to specify a stencil buffer at
that time?

Gary Herron

> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> PyOpenGL Homepage
> http://pyopengl.sourceforge.net
> _______________________________________________
> PyOpenGL-Users mailing list
> PyO...@li...
> https://lists.sourceforge.net/lists/listinfo/pyopengl-users
>   

[PyOpenGL-Users] No stencil buffer?

[Jordan S. <jso...@MI...>]

I've been developing a simple application using PyOpenGL for a few weeks 
now, and trying to add a feature that requires use of the stencil 
buffer.  However, the stencil buffer doesn't seem to be working- all 
pixels pass the test, even when the test is GL_NEVER.  
glGetInteger(GL_STENCIL_BITS) returns 0, but running glxinfo on my 
machine shows that my graphics card supports an 8 bit stencil buffer.  
I'm running Ubuntu and my graphics card is an nVidia GeForce Go 7300.  
Anyone have any ideas?
Thanks a ton,
-JS

[PyOpenGL-Users] second call to glGenFramebuffersEXT() crashes

[Joshua R. D. <jd...@ca...>]

I am trying to cast shadows from multiple lights using shaders. I use one framebuffer object per light. When I have just one light, it works. When I try two lights, the program survives the first call to glGenFramebuffersEXT() but crashes ("Bus error") upon the second call to it.

What follows is a minimal demo. If I run it as-is, then it prints out the two FBO identifiers and terminates normally. If I switch the "cow = ..." and "print framebuffer" lines, then it prints out the first FBO identifier and then crashes ("Bus error"). Why would the location of the print statement matter?

from OpenGL.GL import *
from OpenGL.GLU import *
from OpenGL.GLUT import *
# adapted from http://www.pygame.org/wiki/GLSLExample
try:
    from OpenGL import platform
    gl = platform.OpenGL
except ImportError:
    try:
        gl = cdll.LoadLibrary('libGL.so')
    except OSError:
        from ctypes.util import find_library
        path = find_library('OpenGL')
        gl = cdll.LoadLibrary(path)
glutInit(0)
glutInitDisplayMode(GLUT_RGB|GLUT_DOUBLE|GLUT_DEPTH)
glutCreateWindow('test')
framebuffer = gl.glGenFramebuffersEXT(1)
cow = gl.glGenFramebuffersEXT(1)
print framebuffer
print cow

Other questions:
1. Why do I not need to call glInitFramebufferObjectEXT()?
2. Does glGenFramebuffersEXT(1) return a framebuffer identifier or a list of them? (When I try glGenFramebuffersEXT(1)[0], I get "TypeError: 'int' object is unsubscriptable".)

I'm new to both Python and framebuffer objects, so I may have fundamental misconceptions. My setup is Mac OS 10.4.11, ATI Radeon 9600, Python 2.5, PyOpenGL 3.0.0b6.

-- Josh

Re: [PyOpenGL-Users] OpenGL_accelerate

[Lorenzo M. <lma...@de...>]

Mike C. Fletcher wrote:

> [...] I forgot to add the .pyx and .c files to the MANIFEST.in, 
> so the package didn't include the source files or even the generated 
> versions.

It seems that the files are not present at all; I checked the 
OpenGL-ctypes repository and can't find them.


> I'll hopefully get a new release out today to fix this.  I'm just 
> testing that the current code-base runs now.

Any news about this?

Thanks!

-- 
Lorenzo Mancini

Re: [PyOpenGL-Users] OpenGL_accelerate

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

Lorenzo Mancini wrote:
> Hi all,
>
> I'd like to try the optional OpenGL_accelerate wrapper module written in 
> cython; I read about it a recent blog post from PyOpenGL's author [1] 
> but couldn't find it in the 3.0.0b8 source package, even if it's 
> referenced in the imports of some modules.
>
> It doesn't seem to be present in the windows binary package either.  Am 
> I missing something obvious?
>   
Nope, I was.  I forgot to add the .pyx and .c files to the MANIFEST.in, 
so the package didn't include the source files or even the generated 
versions.

I'll hopefully get a new release out today to fix this.  I'm just 
testing that the current code-base runs now.

HTH,
Mike

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

[PyOpenGL-Users] OpenGL_accelerate

[Lorenzo M. <lma...@de...>]

Hi all,

I'd like to try the optional OpenGL_accelerate wrapper module written in 
cython; I read about it a recent blog post from PyOpenGL's author [1] 
but couldn't find it in the 3.0.0b8 source package, even if it's 
referenced in the imports of some modules.

It doesn't seem to be present in the windows binary package either.  Am 
I missing something obvious?

TIA,

[1] 
http://blog.vrplumber.com/index.php?/archives/2233-Have-to-do-another-beta-for-PyOpenGL.html

-- 
Lorenzo Mancini

Re: [PyOpenGL-Users] gluNurbsCurve ?

[<vma...@am...>]

Prashant,

If N is the number of control points for a spline curve
and D is the degree (D = p+1, where p is the order of the polynomials  
that define the spline functions),
and K is the number of knots (knot values, defining the range of the  
parameter over which the spline is defined), then

K = N+D

Note that this is differs from the relation given in the ISO/IEC FDIS  
19775-1:2008 standard, Sec 27.2.3 (see
http://www.web3d.org/x3d/specifications/ISO-IEC-FDIS-19775-1.2-X3D- 
AbstractSpecification/Part01/components/ 
nurbs.html#CommonGeometryFieldsAndCorrectness)
By my calculations, the relation I have given above is correct* and  
moreover it works with OpenGL.

For most applications, the first D knots are equal to the lowest value  
of the parameter, and the last D values are equal to
the highest value of the parameter, the interior knots (if any) may or  
may not be equally spaced, but do need to be ordered. For your case,
with D=3 and N=5 we need K=8 knot values, for the parameter u from 0 to  
1 a valid, equally spaced set of knots is:
knots = [0.0,0.0,0.0,   0.33, 0.66,  1.0,1.0,1.0]

*If you look at the calculations to evaluate the splines you will find  
that the first and last knot values are
extraneous. However, every API or standard I have examined for NURBS   
(OpenGL, ISO 10303, "The NURBS Book"...) requires that
they be included in the knots vector, and the relation I give above is  
the one required by the software I have used.

Regards,

Vince Marchetti

Re: [PyOpenGL-Users] gluNurbsCurve ?

[Prashant S. <ani...@ya...>]

Thanks,

Yes, after explicitly specifying "knot" attribute the curve is drawn properly.
Could you please tell me how to calculate knots using degree and 
number of points?

Prashant



Your raw code specified a Nurbs curve of order 3 (so polynomial degree 
2, a quadratic curve), and set 5 control points. Since the 'knot' 
attribute was not specified, I assume you relied on the default.

Does the code get the behavior you expect if you explicitly specify a 
"knot" attribute ? ( for example:

knot = [0.0,0.0,0.0, 0.33, 0.67, 1.0, 1.0, 1.0]  # note: length - 8 list

)

Vince Marchetti






      Download prohibited? No problem. CHAT from any browser, without download. Go to http://in.webmessenger.yahoo.com/

Re: [PyOpenGL-Users] gluNurbsCurve ?

[<vma...@am...>]

Prashant asked:
> I am creating a "gluNurbsCurve" and ripped code is here:
>
> ...

> Using above I am getting a curve which is missing both start and end 
> points.. (Image1.jpg>Curve 1)
>
>

Your raw code specified a Nurbs curve of order 3 (so polynomial degree 
2, a quadratic curve), and set 5 control points. Since the 'knot' 
attribute was not specified, I assume you relied on the default.

Does the code get the behavior you expect if you explicitly specify a 
"knot" attribute ? ( for example:

knot = [0.0,0.0,0.0, 0.33, 0.67, 1.0, 1.0, 1.0]  # note: length - 8 list

)

Vince Marchetti

Re: [PyOpenGL-Users] volume rendering

[Andrew W. <and...@al...>]

Hey Dirk

There was a paper a few years ago that did this for shadow mapping, but I
> can't find it right now. The main idea is to think of the pixel/voxel as a
> cube that is split into two parts, one inside, one outside (in your case, of
> the ROI). When you render a pixel that belongs to the cube, you figure out
> where it is in the cube (fractional texcoords should be fine), and use that
> to decide whether it's in or out, and act accordingly. So for you you could
> save a plane equation that says for example that the area left of the x=.75
> point in your cube is inside the ROI, the rest is outside, and you would get
> super-voxel resolution ROIs. You could also go beyond planes to higher-order
>

Got it, sounds a lot like generating an isosurface using marching cubes or
something similar.



> I guess the question is how often you need to update the ROI, and how high
> the ROI resolution really needs to be.
>

You've hit the nail on the head, I like the idea of using shaders as it
won't require much editing of existing opengl code and would provide the
best looking results.
  Thanks for the help, much appreciated.
  Andrew

Re: [PyOpenGL-Users] volume rendering

[Dirk R. <di...@li...>]

	Hi Andrew,

Andrew Wilson wrote:
> 
> I'm simply doing texture slicing for volume rendering.

OK.

> I am running with low resolution textures (10x8x8 to 20x16x16 or so).  

Ouch! That is low. ;)

> I'm
> not sure I understand the full implementation of storing a plane equation in
> the voxel, can you elaborate a bit more?

There was a paper a few years ago that did this for shadow mapping, but I can't 
find it right now. The main idea is to think of the pixel/voxel as a cube that 
is split into two parts, one inside, one outside (in your case, of the ROI). 
When you render a pixel that belongs to the cube, you figure out where it is in 
the cube (fractional texcoords should be fine), and use that to decide whether 
it's in or out, and act accordingly. So for you you could save a plane equation 
that says for example that the area left of the x=.75 point in your cube is 
inside the ROI, the rest is outside, and you would get super-voxel resolution 
ROIs. You could also go beyond planes to higher-order

> I'm expecting on the order of 4-6 ROI's per dataset and may have 2-4
> datasets up at the same time.

OK. For those numbers you should be able to make it real simple and just run the 
inside/outside test inside the fragment shader for each fragment. That would 
given you pretty much zero-cost changes to the ROI, if needed.

> I've pinged the opengl groups too, they recommended using using the
> multitexture extension with an alpha texture with higher resolution than the
> dataset to minimize the voxelation.  I think this is pretty interesting too.

Interesting idea, too.

I guess the question is how often you need to update the ROI, and how high the 
ROI resolution really needs to be.

Yours

	Dirk

Re: [PyOpenGL-Users] volume rendering

[Andrew W. <and...@al...>]

Hey Dirk,
  See the response below:

On Mon, Dec 8, 2008 at 9:44 AM, Dirk Reiners <di...@li...> wrote:

>
> Basic question: how are you doing the volume rendering? Texture slicing or
> shader-based ray marching?
>

I'm simply doing texture slicing for volume rendering.


> You can avoid the voxelisation by not storing a bit but a plane equation in
> the voxel. That would allow fairly high precision clipping, even for an 4x8
> bit texture. But it really is only necessary if your volumes are small, so
> that a voxel is blown to many pixels. Is that the case?


I am running with low resolution textures (10x8x8 to 20x16x16 or so).  I'm
not sure I understand the full implementation of storing a plane equation in
the voxel, can you elaborate a bit more?



>    3. Use a shader to clip the ROI's
>>
>
> That sounds like the best idea, IMHO, as long as you have a relatively
> small number of ROIs. How many are you expecting?
>

I'm expecting on the order of 4-6 ROI's per dataset and may have 2-4
datasets up at the same time.

I've pinged the opengl groups too, they recommended using using the
multitexture extension with an alpha texture with higher resolution than the
dataset to minimize the voxelation.  I think this is pretty interesting too.


Thanks
  Andrew

Re: [PyOpenGL-Users] volume rendering

[Dirk R. <di...@li...>]

	Hi Andrew,

I'm not really an expert in volume rendering, but an interesting problem 
nonetheless...

Andrew Wilson wrote:
> Hello,
>   I've got an opengl question, figured there are a few experts on this
> list.  I'm generating a 3D volume render using 3d textures and would like to
> setup multiple regions of interest (ROIs) where only the volume data within
> the ROI is displayed (everything else is transparent).  This is rather easy
> using the clipping planes for rectangular shaped ROI's and can be faked for
> ellipsoidal ROIs with the stenil buffer.  The tricky part is to render
> multiple ROI's simultaneously without much performance hit.  I'm having a
> hardtime doing this elegantly.  Some ideas are:

Basic question: how are you doing the volume rendering? Texture slicing or 
shader-based ray marching?

>    1. Clip the actual 3d texture to the different ROI's using a binary mask
>    and reload the texture to the GPU.  This becomes problematic for
>    non-rectangular ROIs as the ROIs will look "voxelated" but is nice because
>    it is a single pass for all rendering all ROIs.

You can avoid the voxelisation by not storing a bit but a plane equation in the 
voxel. That would allow fairly high precision clipping, even for an 4x8 bit 
texture. But it really is only necessary if your volumes are small, so that a 
voxel is blown to many pixels. Is that the case?

>    2. For each ROI, render the 3d texture clipped with that ROI's bounds.
>    This require multiple renderings and would slow down quite a bit for many
>    ROI's, this will look the best but is not all that elegant.

Nope, and pretty slow to boot, and I'm not sure if you can make it work for 
overlapping ROIs. You'd have to do some solid model operations to make it clean.

>    3. Use a shader to clip the ROI's

That sounds like the best idea, IMHO, as long as you have a relatively small 
number of ROIs. How many are you expecting?

> Any other obvious solutions or ticks that would do this?  Any help is much
> appreciated.

Nothing obvious, sorry. :(

Yours

	Dirk

[PyOpenGL-Users] gluNurbsCurve ?

[Prashant S. <ani...@ya...>]

http://img372.imageshack.us/my.php?image=image1lp7.jpg


I am creating a "gluNurbsCurve" and ripped code is here:

x1 = y1 = 25
x2 = y2 = 450
scale = abs(x2-x1)/3.0
midx, midy = (abs(x2+x1)/2.0), abs(y2+y1)/2.0   
degree = 3

    
ctrlpoints=[[x1, y1, 0],
    [x1+scale, y1, 0],
    [midx, midy, 0],
    [x2-scale, y2, 0],
    [x2, y2, 0]]   

Using above I am getting a curve which is missing both start and end points.. (Image1.jpg>Curve 1)

Instead If I use:

ctrlpoints=[[x1, y1, 0],
                [x1, y1, 0],
    [x1+scale, y1, 0],
    [midx, midy, 0],
    [x2-scale, y2, 0],
    [x2, y2, 0],
    [x2, y2, 0]]    

by repeating first and last points I am getting a curve from points to points but I am loosing the smoothness which I am getting from first "ctrlpoints". (Image1.jpg>Curve 2)

Any solution?

Prashant




      Add more friends to your messenger and enjoy! Go to http://messenger.yahoo.com/invite/

Re: [PyOpenGL-Users] pyopengl on the OpenMoko FreeRunner

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

Gunnar Aastrand Grimnes wrote:
> Hi all,
>
> I am trying to get pyopengl to work on the openmoko FreeRunner [1]
> Building the package and installing was fairly straight forward, but
> running my fairly simple example gives me:
>   
...
>     model = GL.glGetDoublev( GL.GL_MODELVIEW_MATRIX )
>   File "/usr/lib/python2.5/site-packages/OpenGL/wrapper.py", line 1631,
> in __call__
>     return self.finalise()( *args, **named )
>   File "/usr/lib/python2.5/site-packages/OpenGL/wrapper.py", line 683,
> in wrapperCall
>     converter( pyArgs, index, self )
>   File "/usr/lib/python2.5/site-packages/OpenGL/converters.py", line
> 195, in __call__
>     return self.arrayType.zeros( self.getSize(pyArgs) )
>   File
> "/usr/lib/python2.5/site-packages/OpenGL/arrays/arraydatatype.py", line
> 98, in zeros
>     return cls.returnHandler().zeros( dims, typeCode or cls.typeConstant )
>   File "/usr/lib/python2.5/site-packages/OpenGL/arrays/nones.py", line
> 32, in zeros
>     raise TypeError( """Can't create NULL pointer filled with values""" )
> TypeError: ("Can't create NULL pointer filled with values", 'Failure in
> cConverter <OpenGL.converters.SizedOutput object at 0x40ffcfb0>',
> [GL_MODELVIEW_MATRIX], 1, <OpenGL.wrapper.glGetDoublev object at
> 0x4100a698>)
>   
That's strange, it's trying to create an array with a NULL format-type 
handler.  That should never be the registered output handler (regardless 
of platform).
> Now, before I dive in and debug this - let me ask: Has anyone else had
> any success with pyopengl on the ARM architecture?
>   
Not to my knowledge.  I didn't even know ctypes worked on ARM.  I'll see 
if I can borrow a FreeRunner to test with it.
> Some of the tests from the pyopengl run successfully, but most GLUT ones
> fail with because of some missing font - and test_loadglut fails with :
> AttributeError: python: undefined symbol: glutSolidTeapot
>
> The FreeRunner has libGL, libGLU from MESA version 6.5, is this too old?
>   
You'd need FreeGLUT or GLUT installed to use that function, as it's not 
defined in core Mesa.
> Please reply also to me offlist as I am not subscribed.
>   
HTH,
Mike

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

Re: [PyOpenGL-Users] problem registering FormatHandler class on installation

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

vmarchetti@ameritech wrote:
> I have installed PyOpenGL-3.0.0b6 onto a Linux (Fedora 7) running 
> Python 2.5, using the
> easy_install PyOpenGL
> command. I note that I have Numeric installed, but not numpy.
>   
This is a code-path that hasn't really had much testing, mostly because 
I haven't had such a setup myself for a long time.
> On trying to invoke gluNurbsSurface with a Numeric.array value as 
> control points, I get a thrown exception with the message:
> TypeError: No array-type handler for type <type 'array'> (value: 
> array([[[ 0.,  0.,  0.,  1.],[ 1.,  0.,  ) registered
>   
The b6 iteration was using pkg_resources to do that registration.  b7 
(which never got out the door) and b8 (just released) use a custom 
plugin system that registers in regular Python code.
> Looking through source code, it seems that at some point the class 
> OpenGL.arrays.numeric.NumericHandler needs to be registered as a source 
> of data conversion methods; and that this should have been configured 
> as part of the easy_install process.
>
> So, my questions are:
>
> -- Is there some clue I can look for in the logging from the 
> easy_install as to whether there was a problem configuring the plugins
>   
If the install completed the handler *should* have been registered...
> --- do I need to set some configuration before installing
>   
Shouldn't need to.
> --- or, can (and how) can I manually register the NumericHandler class
>   
You can with the new system, and would have to in order to get Numeric 
support (not provided by default):

Add:

    from OpenGL.plugins import FormatHandler
    FormatHandler( 'numeric', 'OpenGL.arrays.numeric.NumericHandler', )

to your applications that want to use Numeric arrays.  If we can get the 
handler tested reliably I'd imagine we can enable the support by default 
again.

HTH,
Mike

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

[PyOpenGL-Users] volume rendering

[Andrew W. <and...@al...>]

Hello,
  I've got an opengl question, figured there are a few experts on this
list.  I'm generating a 3D volume render using 3d textures and would like to
setup multiple regions of interest (ROIs) where only the volume data within
the ROI is displayed (everything else is transparent).  This is rather easy
using the clipping planes for rectangular shaped ROI's and can be faked for
ellipsoidal ROIs with the stenil buffer.  The tricky part is to render
multiple ROI's simultaneously without much performance hit.  I'm having a
hardtime doing this elegantly.  Some ideas are:

   1. Clip the actual 3d texture to the different ROI's using a binary mask
   and reload the texture to the GPU.  This becomes problematic for
   non-rectangular ROIs as the ROIs will look "voxelated" but is nice because
   it is a single pass for all rendering all ROIs.
   2. For each ROI, render the 3d texture clipped with that ROI's bounds.
   This require multiple renderings and would slow down quite a bit for many
   ROI's, this will look the best but is not all that elegant.
   3. Use a shader to clip the ROI's

Any other obvious solutions or ticks that would do this?  Any help is much
appreciated.
  Andrew