pyopengl-users Mailing List for PyOpenGL (Page 29)
Brought to you by:
mcfletch
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(81) |
Oct
(41) |
Nov
(55) |
Dec
(14) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(34) |
Feb
(3) |
Mar
(16) |
Apr
(5) |
May
(10) |
Jun
(13) |
Jul
(24) |
Aug
(14) |
Sep
(14) |
Oct
(9) |
Nov
(10) |
Dec
(16) |
2003 |
Jan
(25) |
Feb
(59) |
Mar
(9) |
Apr
(21) |
May
(54) |
Jun
(4) |
Jul
(16) |
Aug
(19) |
Sep
(19) |
Oct
(15) |
Nov
(13) |
Dec
(22) |
2004 |
Jan
(19) |
Feb
(8) |
Mar
(20) |
Apr
(16) |
May
(13) |
Jun
(18) |
Jul
(18) |
Aug
(14) |
Sep
(24) |
Oct
(47) |
Nov
(20) |
Dec
(10) |
2005 |
Jan
(23) |
Feb
(31) |
Mar
(11) |
Apr
(29) |
May
(18) |
Jun
(7) |
Jul
(11) |
Aug
(12) |
Sep
(8) |
Oct
(4) |
Nov
(11) |
Dec
(7) |
2006 |
Jan
(7) |
Feb
(8) |
Mar
(15) |
Apr
(3) |
May
(8) |
Jun
(25) |
Jul
(19) |
Aug
(3) |
Sep
(17) |
Oct
(27) |
Nov
(24) |
Dec
(9) |
2007 |
Jan
(6) |
Feb
(43) |
Mar
(33) |
Apr
(8) |
May
(20) |
Jun
(11) |
Jul
(7) |
Aug
(8) |
Sep
(11) |
Oct
(22) |
Nov
(15) |
Dec
(18) |
2008 |
Jan
(14) |
Feb
(6) |
Mar
(6) |
Apr
(37) |
May
(13) |
Jun
(17) |
Jul
(22) |
Aug
(16) |
Sep
(14) |
Oct
(16) |
Nov
(29) |
Dec
(13) |
2009 |
Jan
(7) |
Feb
(25) |
Mar
(38) |
Apr
(57) |
May
(12) |
Jun
(32) |
Jul
(32) |
Aug
(35) |
Sep
(10) |
Oct
(28) |
Nov
(16) |
Dec
(49) |
2010 |
Jan
(57) |
Feb
(37) |
Mar
(22) |
Apr
(15) |
May
(45) |
Jun
(25) |
Jul
(32) |
Aug
(7) |
Sep
(13) |
Oct
(2) |
Nov
(11) |
Dec
(28) |
2011 |
Jan
(35) |
Feb
(39) |
Mar
|
Apr
(25) |
May
(32) |
Jun
(17) |
Jul
(29) |
Aug
(10) |
Sep
(26) |
Oct
(9) |
Nov
(28) |
Dec
(4) |
2012 |
Jan
(24) |
Feb
(47) |
Mar
(4) |
Apr
(8) |
May
(9) |
Jun
(6) |
Jul
(4) |
Aug
(1) |
Sep
(4) |
Oct
(28) |
Nov
(2) |
Dec
(2) |
2013 |
Jan
(11) |
Feb
(3) |
Mar
(4) |
Apr
(38) |
May
(15) |
Jun
(11) |
Jul
(15) |
Aug
(2) |
Sep
(2) |
Oct
(4) |
Nov
(3) |
Dec
(14) |
2014 |
Jan
(24) |
Feb
(31) |
Mar
(28) |
Apr
(16) |
May
(7) |
Jun
(6) |
Jul
(1) |
Aug
(10) |
Sep
(10) |
Oct
(2) |
Nov
|
Dec
|
2015 |
Jan
(6) |
Feb
(5) |
Mar
(2) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(2) |
Oct
(1) |
Nov
(19) |
Dec
|
2016 |
Jan
(6) |
Feb
(1) |
Mar
(7) |
Apr
|
May
(6) |
Jun
|
Jul
(3) |
Aug
(7) |
Sep
|
Oct
(2) |
Nov
(2) |
Dec
|
2017 |
Jan
|
Feb
(6) |
Mar
(8) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(3) |
Oct
(2) |
Nov
|
Dec
|
2018 |
Jan
(9) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
From: Ian M. <geo...@gm...> - 2011-02-23 15:19:58
|
I'd use a vertex shader. |
From: Dirk R. <dir...@gm...> - 2011-02-23 15:18:01
|
Hi Michka, On 02/23/2011 08:34 AM, Michka Popoff wrote: > > Perhaps somebody has a tutorial or some good hints for me ? generally the most generic and efficient way for that is to use glTexGen to turn your height into a texture coordinate and use a 1D texture for the colors to interpolate between. This allows you to fully specify the color that are interpolated and also enables you to do non-linear mappings (e.g. have a bright band at a specific height). Give it a try! Hope it helps Dirk |
From: Michka P. <mic...@gm...> - 2011-02-23 14:34:32
|
Hello I have managed to display a nurb surface. Now I want it to be colored in function of the height (with a color gradient). The documentation doesn't help me a lot, and the tutorials found on the internet are mostly to old or not adapted to my case. (Since most of them are written in C, not adapted to pyOpenGL or not using Nurbs) So here is my code which displays the surface (the controlpoints are random, only here to test if it works) : mat_diffuse = ( 0.7, 0.4, 0.1, 1.0 ) mat_specular = ( 1.0, 1.0, 1.0, 1.0 ) mat_shininess = 100.0 glMaterialfv(GL_FRONT, GL_SPECULAR, mat_specular) glMaterialfv(GL_FRONT, GL_SHININESS, mat_shininess) glEnable(GL_LIGHTING) glEnable(GL_LIGHT0) glEnable(GL_DEPTH_TEST) glEnable(GL_AUTO_NORMAL) glEnable(GL_NORMALIZE) nurb = gluNewNurbsRenderer() gluNurbsProperty(nurb, GLU_SAMPLING_TOLERANCE, 20.0) # Space between polygons gluNurbsProperty(nurb, GLU_DISPLAY_MODE, GLU_FILL) ctrlpts = [] grid_size = 15 for u in range(grid_size): ctrlpts.append([]) for v in range(grid_size): ctrlpts[u].append([u, v, 0.0]) ctrlpts[3][3][2] = 1.0 ctrlpts[4][4][2] = 1.0 ctrlpts[3][4][2] = 1.0 ctrlpts[4][3][2] = 1.0 ctrlpts[2][3][2] = 1.0 ctrlpts[4][2][2] = 1.0 degree=3 knot_num = len(ctrlpts) + degree knots = [ float(i)/(knot_num-1) for i in range( knot_num ) ] # Render glMaterialfv(GL_FRONT, GL_DIFFUSE, mat_diffuse) gluBeginSurface(nurb) gluNurbsSurface(nurb, knots, knots, ctrlpts, GL_MAP2_VERTEX_3) gluEndSurface(nurb) Now, I have read about GL_MAP2_COLOR_4, but I don't know how and where to use it ? Some say I should tessellate my nurb surface, use a callback function and try to change the color of the vertexes. But How ? Perhaps somebody has a tutorial or some good hints for me ? Thank you Michka Popoff |
From: Duong D. <dan...@gm...> - 2011-02-23 13:55:52
|
Hello there, We are having a problem with PyOpenGL on a Ubuntu 10.04 machine with a Intel GMA945 graphics card. The following code works in C++, but its counterpart seg-faults in python. Any idea why that is? Regards, -- Duong Dang |
From: Alejandro S. <as...@gm...> - 2011-02-10 04:14:19
|
Hi Eli, On Wed, Feb 9, 2011 at 3:54 PM, Eli Stevens (Gmail) <wic...@gm...>wrote: > I'm not certain if I've got the absolute latest drivers, but they are > reasonably updated. I see the problem on my Macbook Pro under Parallels, > rebooted into Windows via Boot Camp, and on a dedicated Windows 7 machine > (via py2exe). All exhibit the same behavior (pop up an alert box, then work > fine); though I suspect that's because I'm not using anything provided by > the gle32.dll. > I've never used Parallels myself and I don't know how mature its OpenGL support might be, but personally, I would refrain from doing 3D development on a VM. > > My Boot Camp partition is a fairly recent install, and I purposefully keep > it minimal for testing purposes (ie. no old versions of Python, etc.). That > probably doesn't match most testing environments; I could see a dependency > on an old version of msvcr slipping through. > > What will it take to fix this? Should I start looking into recompiling > PyOpenGL from source? Or will a fixed 3.0.2 come out in the near future? > I am not sure. I would suggest you try to run py2exe on a native Windows (not inside a VM), creating the executable not inside a VM but on the real thing and with the latest video drivers. This may or may not help solve the problem, but it's something I would definitely try. Good luck! Alejandro.- > > On Wed, Feb 9, 2011 at 4:23 AM, Alejandro Segovia <as...@gm...>wrote: > >> Hello Eli, >> >> On Feb 9, 2011, at 7:07 AM, Jonathan Hartley <ta...@ta...> wrote: >> >> Ah, so does that imply that it's not Python2.7 which is using msvcr71, >> it's gle32.dll, which presumably was compiled against that version of the C >> runtime. >> >> >> Okay, the problem seems to be in our OpenGL implementation then. Have you >> installed the latest video drivers for your video card or are you using the >> stock windows version? >> >> If you're on NVIDIA or ATI, upgrading your video drivers might help. >> >> Alejandro.- >> >> Eli Stephens wrote: >> >> Hello, :) >> >> The error can be provoked by "import OpenGL.GL" from the interactive >> prompt in Python, so it seems unlikely to be anything but PyOpenGL. I used >> dependency walker, and see the following tree: >> >> python.exe >> - python27.dll >> - _ctypes.pyd >> - opengl32.dll >> - gle32.dll >> - msvcr71.dll >> >> Obviously there are a ton of other files loaded as well; if any of them >> could be pertinent, let me know and I will search for them. Do other >> people's installs under python 2.7 not try and load msvcr71.dll? >> >> Additionally, after the alert box, dependency walker spat out hundreds of >> error messages like: >> >> GetProcAddress(0x5ED00000 [OPENGL32.DLL], "_FunctionType@108") called >> from "_CTYPES.PYD" at address 0x1D1A39C7 and returned NULL. Error: The >> specified procedure could not be found (127). >> >> I'm not sure if that's related or not. >> >> Thanks for helping me chase this down. :) >> >> Eli >> >> On 09/02/2011 08:43, Jonathan Hartley wrote: >> >> Beware: When downloading the redistributable installer for MSVCR90.dll, it >> is important not to use the SP1 version of the installer. This contains the >> wrong version of MSVCR90.dll. >> >> A similar problem *may* exist with the redistributable installer for >> MSVCR71.dll, linked to below. It may contain a wrong version of MSVCR71.dll, >> which would cause problems. Someone with experience of this feel free to >> contradict me here. >> >> The original version of Microsoft Visual C++ 2005 Redistributable Package >> (x86), as linked to from the py2exe tutorial page: >> >> <http://www.microsoft.com/downloads/en/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee> >> http://www.microsoft.com/downloads/en/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee >> >> ...is known to contain the correct version of MSVCR71.dll for Python 2.5. >> >> All of the above assumes you are using the compiled version of Python >> downloaded from python.org. If you compiled your own (or got it from >> someone else who compiled their own) then I don't know enough about your >> situation for any of my advice to be meaningful. >> >> Best regards, >> >> Jonathan >> >> On 08/02/2011 23:41, Silverstein wrote: >> >> >> >> >> You can also get these dll files by downloading and installing the >> Microsoft Visual C++ redistributable package. It's a free download and will >> spare you (and your users) from having to install Visual Studio. >> >> Please notice there are different redistibutable versions, each one >> corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. >> >> There are also different releases for each of these typically. For >> example, the initial release or a service pack (like an SP1) release. For >> example: >> Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) >> <http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en> >> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. <http://p.sf.net/sfu/intel-dev2devfeb>http://p.sf.net/sfu/intel-dev2devfeb >> >> >> _______________________________________________ >> PyOpenGL Homepage <http://pyopengl.sourceforge.net>http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list <PyO...@li...>PyO...@li... <https://lists.sourceforge.net/lists/listinfo/pyopengl-users>https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> >> -- >> Jonathan Hartley Made of meat. <http://tartley.com>http://tartley.com <ta...@ta...>ta...@ta... +44 7737 062 225 <+447737062225> twitter/skype: tartley >> >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. <http://p.sf.net/sfu/intel-dev2devfeb>http://p.sf.net/sfu/intel-dev2devfeb >> >> >> _______________________________________________ >> PyOpenGL Homepage <http://pyopengl.sourceforge.net>http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list <PyO...@li...>PyO...@li... <https://lists.sourceforge.net/lists/listinfo/pyopengl-users>https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> >> -- >> Jonathan Hartley Made of meat. <http://tartley.com>http://tartley.com <ta...@ta...>ta...@ta... +44 7737 062 225 <+447737062225> twitter/skype: tartley >> >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> > -- Alejandro Segovia Azapian Director, Algorithmia: Visualization & Acceleration http://web.algorithmia.net |
From: Eli S. (Gmail) <wic...@gm...> - 2011-02-09 17:55:01
|
I'm not certain if I've got the absolute latest drivers, but they are reasonably updated. I see the problem on my Macbook Pro under Parallels, rebooted into Windows via Boot Camp, and on a dedicated Windows 7 machine (via py2exe). All exhibit the same behavior (pop up an alert box, then work fine); though I suspect that's because I'm not using anything provided by the gle32.dll. My Boot Camp partition is a fairly recent install, and I purposefully keep it minimal for testing purposes (ie. no old versions of Python, etc.). That probably doesn't match most testing environments; I could see a dependency on an old version of msvcr slipping through. What will it take to fix this? Should I start looking into recompiling PyOpenGL from source? Or will a fixed 3.0.2 come out in the near future? Thanks, Eli On Wed, Feb 9, 2011 at 4:23 AM, Alejandro Segovia <as...@gm...> wrote: > Hello Eli, > > On Feb 9, 2011, at 7:07 AM, Jonathan Hartley <ta...@ta...> wrote: > > Ah, so does that imply that it's not Python2.7 which is using msvcr71, it's > gle32.dll, which presumably was compiled against that version of the C > runtime. > > > Okay, the problem seems to be in our OpenGL implementation then. Have you > installed the latest video drivers for your video card or are you using the > stock windows version? > > If you're on NVIDIA or ATI, upgrading your video drivers might help. > > Alejandro.- > > Eli Stephens wrote: > > Hello, :) > > The error can be provoked by "import OpenGL.GL" from the interactive prompt > in Python, so it seems unlikely to be anything but PyOpenGL. I used > dependency walker, and see the following tree: > > python.exe > - python27.dll > - _ctypes.pyd > - opengl32.dll > - gle32.dll > - msvcr71.dll > > Obviously there are a ton of other files loaded as well; if any of them > could be pertinent, let me know and I will search for them. Do other > people's installs under python 2.7 not try and load msvcr71.dll? > > Additionally, after the alert box, dependency walker spat out hundreds of > error messages like: > > GetProcAddress(0x5ED00000 [OPENGL32.DLL], "_FunctionType@108") called from > "_CTYPES.PYD" at address 0x1D1A39C7 and returned NULL. Error: The specified > procedure could not be found (127). > > I'm not sure if that's related or not. > > Thanks for helping me chase this down. :) > > Eli > > On 09/02/2011 08:43, Jonathan Hartley wrote: > > Beware: When downloading the redistributable installer for MSVCR90.dll, it > is important not to use the SP1 version of the installer. This contains the > wrong version of MSVCR90.dll. > > A similar problem *may* exist with the redistributable installer for > MSVCR71.dll, linked to below. It may contain a wrong version of MSVCR71.dll, > which would cause problems. Someone with experience of this feel free to > contradict me here. > > The original version of Microsoft Visual C++ 2005 Redistributable Package > (x86), as linked to from the py2exe tutorial page: > > <http://www.microsoft.com/downloads/en/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee> > http://www.microsoft.com/downloads/en/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee > > ...is known to contain the correct version of MSVCR71.dll for Python 2.5. > > All of the above assumes you are using the compiled version of Python > downloaded from python.org. If you compiled your own (or got it from > someone else who compiled their own) then I don't know enough about your > situation for any of my advice to be meaningful. > > Best regards, > > Jonathan > > On 08/02/2011 23:41, Silverstein wrote: > > > > > You can also get these dll files by downloading and installing the > Microsoft Visual C++ redistributable package. It's a free download and will > spare you (and your users) from having to install Visual Studio. > > Please notice there are different redistibutable versions, each one > corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. > > There are also different releases for each of these typically. For > example, the initial release or a service pack (like an SP1) release. For > example: > Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) > <http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en> > http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. <http://p.sf.net/sfu/intel-dev2devfeb>http://p.sf.net/sfu/intel-dev2devfeb > > > _______________________________________________ > PyOpenGL Homepage <http://pyopengl.sourceforge.net>http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list <PyO...@li...>PyO...@li... <https://lists.sourceforge.net/lists/listinfo/pyopengl-users>https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > -- > Jonathan Hartley Made of meat. <http://tartley.com>http://tartley.com <ta...@ta...>ta...@ta... +44 7737 062 225 twitter/skype: tartley > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. <http://p.sf.net/sfu/intel-dev2devfeb>http://p.sf.net/sfu/intel-dev2devfeb > > > _______________________________________________ > PyOpenGL Homepage <http://pyopengl.sourceforge.net>http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list <PyO...@li...>PyO...@li... <https://lists.sourceforge.net/lists/listinfo/pyopengl-users>https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > -- > Jonathan Hartley Made of meat. <http://tartley.com>http://tartley.com <ta...@ta...>ta...@ta... +44 7737 062 225 twitter/skype: tartley > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > |
From: Alejandro S. <as...@gm...> - 2011-02-09 12:24:19
|
Hello Eli, On Feb 9, 2011, at 7:07 AM, Jonathan Hartley <ta...@ta...> wrote: > Ah, so does that imply that it's not Python2.7 which is using msvcr71, it's gle32.dll, which presumably was compiled against that version of the C runtime. Okay, the problem seems to be in our OpenGL implementation then. Have you installed the latest video drivers for your video card or are you using the stock windows version? If you're on NVIDIA or ATI, upgrading your video drivers might help. Alejandro.- > Eli Stephens wrote: > > Hello, :) > > The error can be provoked by "import OpenGL.GL" from the interactive prompt in Python, so it seems unlikely to be anything but PyOpenGL. I used dependency walker, and see the following tree: > > python.exe > - python27.dll > - _ctypes.pyd > - opengl32.dll > - gle32.dll > - msvcr71.dll > > Obviously there are a ton of other files loaded as well; if any of them could be pertinent, let me know and I will search for them. Do other people's installs under python 2.7 not try and load msvcr71.dll? > > Additionally, after the alert box, dependency walker spat out hundreds of error messages like: > > GetProcAddress(0x5ED00000 [OPENGL32.DLL], "_FunctionType@108") called from "_CTYPES.PYD" at address 0x1D1A39C7 and returned NULL. Error: The specified procedure could not be found (127). > > I'm not sure if that's related or not. > > Thanks for helping me chase this down. :) > > Eli > > On 09/02/2011 08:43, Jonathan Hartley wrote: >> >> Beware: When downloading the redistributable installer for MSVCR90.dll, it is important not to use the SP1 version of the installer. This contains the wrong version of MSVCR90.dll. >> >> A similar problem *may* exist with the redistributable installer for MSVCR71.dll, linked to below. It may contain a wrong version of MSVCR71.dll, which would cause problems. Someone with experience of this feel free to contradict me here. >> >> The original version of Microsoft Visual C++ 2005 Redistributable Package (x86), as linked to from the py2exe tutorial page: >> >> http://www.microsoft.com/downloads/en/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee >> >> ...is known to contain the correct version of MSVCR71.dll for Python 2.5. >> >> All of the above assumes you are using the compiled version of Python downloaded from python.org. If you compiled your own (or got it from someone else who compiled their own) then I don't know enough about your situation for any of my advice to be meaningful. >> >> Best regards, >> >> Jonathan >> >> On 08/02/2011 23:41, Silverstein wrote: >>> >>> >>> >>>> >>>> You can also get these dll files by downloading and installing the Microsoft Visual C++ redistributable package. It's a free download and will spare you (and your users) from having to install Visual Studio. >>>> >>>> Please notice there are different redistibutable versions, each one corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. >>> There are also different releases for each of these typically. For example, the initial release or a service pack (like an SP1) release. For example: >>> Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) >>> >>> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en >>> >>> >>> ------------------------------------------------------------------------------ >>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>> Pinpoint memory and threading errors before they happen. >>> Find and fix more than 250 security defects in the development cycle. >>> Locate bottlenecks in serial and parallel code that limit performance. >>> http://p.sf.net/sfu/intel-dev2devfeb >>> >>> _______________________________________________ >>> PyOpenGL Homepage >>> http://pyopengl.sourceforge.net >>> _______________________________________________ >>> PyOpenGL-Users mailing list >>> PyO...@li... >>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> -- >> Jonathan Hartley Made of meat. http://tartley.com >> ta...@ta... +44 7737 062 225 twitter/skype: tartley >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > -- > Jonathan Hartley Made of meat. http://tartley.com > ta...@ta... +44 7737 062 225 twitter/skype: tartley > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: Jonathan H. <ta...@ta...> - 2011-02-09 09:07:38
|
Ah, so does that imply that it's not Python2.7 which is using msvcr71, it's gle32.dll, which presumably was compiled against that version of the C runtime. That implies everything I said in my last email, about not using SP1, is barking up the wrong tree and can safely be ignored. You should provide whatever version of msvcr71 was used when gle32 was compiled. I'm not smart enough to help you determine that. Also, I presume that at some point, Python2.7 may also require msvcr90, and that can be provided using the (non SP1) download previously linked to. Cheers, Jonathan Eli Stephens wrote: Hello, :) The error can be provoked by "import OpenGL.GL" from the interactive prompt in Python, so it seems unlikely to be anything but PyOpenGL. I used dependency walker, and see the following tree: python.exe - python27.dll - _ctypes.pyd - opengl32.dll - gle32.dll - msvcr71.dll Obviously there are a ton of other files loaded as well; if any of them could be pertinent, let me know and I will search for them. Do other people's installs under python 2.7 not try and load msvcr71.dll? Additionally, after the alert box, dependency walker spat out hundreds of error messages like: GetProcAddress(0x5ED00000 [OPENGL32.DLL], "_FunctionType@108") called from "_CTYPES.PYD" at address 0x1D1A39C7 and returned NULL. Error: The specified procedure could not be found (127). I'm not sure if that's related or not. Thanks for helping me chase this down. :) Eli On 09/02/2011 08:43, Jonathan Hartley wrote: > Beware: When downloading the redistributable installer for > MSVCR90.dll, it is important not to use the SP1 version of the > installer. This contains the wrong version of MSVCR90.dll. > > A similar problem *may* exist with the redistributable installer for > MSVCR71.dll, linked to below. It may contain a wrong version of > MSVCR71.dll, which would cause problems. Someone with experience of > this feel free to contradict me here. > > The original version of Microsoft Visual C++ 2005 Redistributable > Package (x86), as linked to from the py2exe tutorial page: > > http://www.microsoft.com/downloads/en/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee > > ...is known to contain the correct version of MSVCR71.dll for Python 2.5. > > All of the above assumes you are using the compiled version of Python > downloaded from python.org. If you compiled your own (or got it from > someone else who compiled their own) then I don't know enough about > your situation for any of my advice to be meaningful. > > Best regards, > > Jonathan > > On 08/02/2011 23:41, Silverstein wrote: >> >> >>> >>> You can also get these dll files by downloading and installing the >>> Microsoft Visual C++ redistributable package. It's a free download >>> and will spare you (and your users) from having to install Visual >>> Studio. >>> >>> Please notice there are different redistibutable versions, each one >>> corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. >> There are also different releases for each of these typically. For >> example, the initial release or a service pack (like an SP1) >> release. For example: >> >> >> Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) >> >> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> >> >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > -- > Jonathan Hartley Made of meat.http://tartley.com > ta...@ta... +44 7737 062 225 twitter/skype: tartley > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users -- Jonathan Hartley Made of meat. http://tartley.com ta...@ta... +44 7737 062 225 twitter/skype: tartley |
From: Jonathan H. <ta...@ta...> - 2011-02-09 08:43:38
|
Beware: When downloading the redistributable installer for MSVCR90.dll, it is important not to use the SP1 version of the installer. This contains the wrong version of MSVCR90.dll. A similar problem *may* exist with the redistributable installer for MSVCR71.dll, linked to below. It may contain a wrong version of MSVCR71.dll, which would cause problems. Someone with experience of this feel free to contradict me here. The original version of Microsoft Visual C++ 2005 Redistributable Package (x86), as linked to from the py2exe tutorial page: http://www.microsoft.com/downloads/en/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee ...is known to contain the correct version of MSVCR71.dll for Python 2.5. All of the above assumes you are using the compiled version of Python downloaded from python.org. If you compiled your own (or got it from someone else who compiled their own) then I don't know enough about your situation for any of my advice to be meaningful. Best regards, Jonathan On 08/02/2011 23:41, Silverstein wrote: > > >> >> You can also get these dll files by downloading and installing the >> Microsoft Visual C++ redistributable package. It's a free download >> and will spare you (and your users) from having to install Visual >> Studio. >> >> Please notice there are different redistibutable versions, each one >> corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. > There are also different releases for each of these typically. For > example, the initial release or a service pack (like an SP1) release. > For example: > > > Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) > > http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users -- Jonathan Hartley Made of meat. http://tartley.com ta...@ta... +44 7737 062 225 twitter/skype: tartley |
From: Eli S. (Gmail) <wic...@gm...> - 2011-02-09 07:34:25
|
Hello, :) The error can be provoked by "import OpenGL.GL" from the interactive prompt in Python, so it seems unlikely to be anything but PyOpenGL. I used dependency walker, and see the following tree: python.exe - python27.dll - _ctypes.pyd - opengl32.dll - gle32.dll - msvcr71.dll Obviously there are a ton of other files loaded as well; if any of them could be pertinent, let me know and I will search for them. Do other people's installs under python 2.7 not try and load msvcr71.dll? Additionally, after the alert box, dependency walker spat out hundreds of error messages like: GetProcAddress(0x5ED00000 [OPENGL32.DLL], "_FunctionType@108") called from "_CTYPES.PYD" at address 0x1D1A39C7 and returned NULL. Error: The specified procedure could not be found (127). I'm not sure if that's related or not. Thanks for helping me chase this down. :) Eli On Tue, Feb 8, 2011 at 6:16 PM, Alejandro Segovia <as...@gm...> wrote: > Hi Eli, > > On Feb 8, 2011, at 9:47 PM, "Eli Stevens (Gmail)" <wic...@gm...> > wrote: > > I'm using the standard windows binary installer for python 2.7, which (to > the best of my knowledge) was compiled with VS 2008, and uses the > msvcr90.dll, which I have (I know that I have them due to having to wrangle > py2exe packing for the application). > > Again, my application works just fine, since python 2.7 uses msvcr90.dll. > I don't actually need the msvcr71.dll that the alert box is talking about. > I'm trying to figure out why importing OpenGL.GL is telling me that I need > that file, when I actually don't need it (presenting end users with a > spurious error message on startup isn't acceptable, especially for the > support guys ;). > > > Have you tried using "Dependency Walker" (depends.exe) to trace whether > it's either Python or a dynamically loaded library (and which) is actually > asking for msvcrt71? > > Alejandro.- > > On Tue, Feb 8, 2011 at 2:56 PM, Alejandro Segovia < <as...@gm...> > as...@gm...> wrote: > >> Hello Eli, >> >> On Feb 8, 2011, at 7:26 PM, "Eli Stevens (Gmail)" <<wic...@gm...> >> wic...@gm...> wrote: >> >> According to <http://www.py2exe.org/index.cgi/Tutorial#Step51><http://www.py2exe.org/index.cgi/Tutorial#Step51> >> http://www.py2exe.org/index.cgi/Tutorial#Step51 , msvcr71.dll is from VS >> 2005, while python 2.6 and newer use VS 2008 (and hence msvcr90.dll). Since >> I'm on python 2.7, it should be using msvcr90.dll, not 71. :-/ I guess I >> should have included that in my original email. I guess I'm trying to ask >> "why does PyOpenGL ask for a .dll that's clearly out of date with respect to >> the python version that I'm using?" >> >> >> It might have to do with the compiler version used for compiling >> python.exe. If it was built using VS 2005, it's expectable that it depends >> on msvcrt71. >> >> I guess the question here would be where did you download the Python >> interpreter you are using from? Did you get it from the official website? >> >> You can install the MSVS 2008 Express Edition for free; that's what I've >> done and it works fine (for example, we also use a lot of Cython, and it >> uses VS 2008). >> >> >> You can also get these dll files by downloading and installing the >> Microsoft Visual C++ redistributable package. It's a free download and will >> spare you (and your users) from having to install Visual Studio. >> >> Please notice there are different redistibutable versions, each one >> corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. >> >> Hope this helps. >> >> Alejandro.- >> >> On Tue, Feb 8, 2011 at 12:55 PM, Stephen Hopkins < <sho...@us...><sho...@us...> >> sho...@us...> wrote: >> >>> i think the dll comes from visual studio 2005 or 2008. The newer versions >>> of python do not come with these files I think. It gave me trouble trying to >>> install python on windows 7 so I am stuck using python on my laptop with >>> windows xp since my laptop has visual studio. >>> >>> On Tue, Feb 8, 2011 at 12:00 PM, Eli Stevens (Gmail) <<wic...@gm...><wic...@gm...> >>> wic...@gm...> wrote: >>> >>>> Hello, >>>> >>>> When I import OpenGL.GL like this under windows XP: >>>> >>>> Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit >>>> (Intel)] on win32 >>>> Type "help", "copyright", "credits" or "license" for more information. >>>> >>> import OpenGL.GL >>>> >>>> I get the following error in an alert box: >>>> >>>> python.exe - Unable To Locate Component >>>> This application has failed to start becuase MSVCR71.dll was not >>>> found. Re-installing the application may fix this problem. >>>> >>>> The same behavior occurs when trying to import OpenGL.GL from inside our >>>> application, however, aside from the alert box, the application seems to run >>>> fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). >>>> >>>> PyOpenGL was installed via easy_install: >>>> >>>> >>> OpenGL.GL.__file__ >>>> >>>> 'C:\\Python27\\lib\\site-packages\\pyopengl-3.0.1-py2.7-win32.egg\\OpenGL\\GL\\__init__.pyc' >>>> >>>> Any suggestions on what we need to do to get this (seemingly spurious) >>>> alert to go away? >>>> >>>> Thanks, >>>> Eli >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio >>>> XE: >>>> Pinpoint memory and threading errors before they happen. >>>> Find and fix more than 250 security defects in the development cycle. >>>> Locate bottlenecks in serial and parallel code that limit performance. >>>> <http://p.sf.net/sfu/intel-dev2devfeb><http://p.sf.net/sfu/intel-dev2devfeb> >>>> http://p.sf.net/sfu/intel-dev2devfeb >>>> _______________________________________________ >>>> PyOpenGL Homepage >>>> <http://pyopengl.sourceforge.net> <http://pyopengl.sourceforge.net> >>>> http://pyopengl.sourceforge.net >>>> _______________________________________________ >>>> PyOpenGL-Users mailing list >>>> <PyO...@li...><PyO...@li...> >>>> PyO...@li... >>>> <https://lists.sourceforge.net/lists/listinfo/pyopengl-users><https://lists.sourceforge.net/lists/listinfo/pyopengl-users> >>>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >>>> >>>> >>> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> <http://p.sf.net/sfu/intel-dev2devfeb> >> http://p.sf.net/sfu/intel-dev2devfeb >> >> _______________________________________________ >> PyOpenGL Homepage >> <http://pyopengl.sourceforge.net>http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> <PyO...@li...> >> PyO...@li... >> <https://lists.sourceforge.net/lists/listinfo/pyopengl-users> >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> > |
From: Stephen H. <sho...@us...> - 2011-02-09 03:29:30
|
I have been trying to get a shader debugger to work for pyopengl glsldevil gives me an error saying it only supports up to glsl 1.2 gpu perf studio gives me an error when I attempt to debug, saying that "the opengl frame debugger does not support 3.x contexts which do not use the compatibility profile" Is there some way you can fix this in pyopengl? I never even heard of this compatibility profile until now. my shader will be using floating point textures and frame buffers, but nothing newer than that. |
From: Alejandro S. <as...@gm...> - 2011-02-09 02:17:07
|
Hi Eli, On Feb 8, 2011, at 9:47 PM, "Eli Stevens (Gmail)" <wic...@gm...> wrote: > I'm using the standard windows binary installer for python 2.7, which (to the best of my knowledge) was compiled with VS 2008, and uses the msvcr90.dll, which I have (I know that I have them due to having to wrangle py2exe packing for the application). > > Again, my application works just fine, since python 2.7 uses msvcr90.dll. I don't actually need the msvcr71.dll that the alert box is talking about. I'm trying to figure out why importing OpenGL.GL is telling me that I need that file, when I actually don't need it (presenting end users with a spurious error message on startup isn't acceptable, especially for the support guys ;). Have you tried using "Dependency Walker" (depends.exe) to trace whether it's either Python or a dynamically loaded library (and which) is actually asking for msvcrt71? Alejandro.- > On Tue, Feb 8, 2011 at 2:56 PM, Alejandro Segovia <as...@gm...> wrote: > Hello Eli, > > On Feb 8, 2011, at 7:26 PM, "Eli Stevens (Gmail)" <wic...@gm...> wrote: > >> According to http://www.py2exe.org/index.cgi/Tutorial#Step51 , msvcr71.dll is from VS 2005, while python 2.6 and newer use VS 2008 (and hence msvcr90.dll). Since I'm on python 2.7, it should be using msvcr90.dll, not 71. :-/ I guess I should have included that in my original email. I guess I'm trying to ask "why does PyOpenGL ask for a .dll that's clearly out of date with respect to the python version that I'm using?" > > It might have to do with the compiler version used for compiling python.exe. If it was built using VS 2005, it's expectable that it depends on msvcrt71. > > I guess the question here would be where did you download the Python interpreter you are using from? Did you get it from the official website? > >> You can install the MSVS 2008 Express Edition for free; that's what I've done and it works fine (for example, we also use a lot of Cython, and it uses VS 2008). > > You can also get these dll files by downloading and installing the Microsoft Visual C++ redistributable package. It's a free download and will spare you (and your users) from having to install Visual Studio. > > Please notice there are different redistibutable versions, each one corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. > > Hope this helps. > > Alejandro.- > >> On Tue, Feb 8, 2011 at 12:55 PM, Stephen Hopkins <sho...@us...> wrote: >> i think the dll comes from visual studio 2005 or 2008. The newer versions of python do not come with these files I think. It gave me trouble trying to install python on windows 7 so I am stuck using python on my laptop with windows xp since my laptop has visual studio. >> >> On Tue, Feb 8, 2011 at 12:00 PM, Eli Stevens (Gmail) <wic...@gm...> wrote: >> Hello, >> >> When I import OpenGL.GL like this under windows XP: >> >> Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import OpenGL.GL >> >> I get the following error in an alert box: >> >> python.exe - Unable To Locate Component >> This application has failed to start becuase MSVCR71.dll was not found. Re-installing the application may fix this problem. >> >> The same behavior occurs when trying to import OpenGL.GL from inside our application, however, aside from the alert box, the application seems to run fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). >> >> PyOpenGL was installed via easy_install: >> >> >>> OpenGL.GL.__file__ >> 'C:\\Python27\\lib\\site-packages\\pyopengl-3.0.1-py2.7-win32.egg\\OpenGL\\GL\\__init__.pyc' >> >> Any suggestions on what we need to do to get this (seemingly spurious) alert to go away? >> >> Thanks, >> Eli >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
From: Silverstein <her...@sc...> - 2011-02-09 01:27:31
|
> > You can also get these dll files by downloading and installing the > Microsoft Visual C++ redistributable package. It's a free download and > will spare you (and your users) from having to install Visual Studio. > > Please notice there are different redistibutable versions, each one > corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. There are also different releases for each of these typically. For example, the initial release or a service pack (like an SP1) release. For example: Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) http://www.microsoft.com/downloads/en/details.aspx?FamilyID=200b2fd9-ae1a-4a14-984d-389c36f85647&displaylang=en |
From: Eli S. (Gmail) <wic...@gm...> - 2011-02-08 23:47:56
|
I'm using the standard windows binary installer for python 2.7, which (to the best of my knowledge) was compiled with VS 2008, and uses the msvcr90.dll, which I have (I know that I have them due to having to wrangle py2exe packing for the application). Again, my application works just fine, since python 2.7 uses msvcr90.dll. I don't actually need the msvcr71.dll that the alert box is talking about. I'm trying to figure out why importing OpenGL.GL is telling me that I need that file, when I actually don't need it (presenting end users with a spurious error message on startup isn't acceptable, especially for the support guys ;). Thanks for all the feedback, Eli On Tue, Feb 8, 2011 at 2:56 PM, Alejandro Segovia <as...@gm...> wrote: > Hello Eli, > > On Feb 8, 2011, at 7:26 PM, "Eli Stevens (Gmail)" <wic...@gm...> > wrote: > > According to <http://www.py2exe.org/index.cgi/Tutorial#Step51> > http://www.py2exe.org/index.cgi/Tutorial#Step51 , msvcr71.dll is from VS > 2005, while python 2.6 and newer use VS 2008 (and hence msvcr90.dll). Since > I'm on python 2.7, it should be using msvcr90.dll, not 71. :-/ I guess I > should have included that in my original email. I guess I'm trying to ask > "why does PyOpenGL ask for a .dll that's clearly out of date with respect to > the python version that I'm using?" > > > It might have to do with the compiler version used for compiling > python.exe. If it was built using VS 2005, it's expectable that it depends > on msvcrt71. > > I guess the question here would be where did you download the Python > interpreter you are using from? Did you get it from the official website? > > You can install the MSVS 2008 Express Edition for free; that's what I've > done and it works fine (for example, we also use a lot of Cython, and it > uses VS 2008). > > > You can also get these dll files by downloading and installing the > Microsoft Visual C++ redistributable package. It's a free download and will > spare you (and your users) from having to install Visual Studio. > > Please notice there are different redistibutable versions, each one > corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. > > Hope this helps. > > Alejandro.- > > On Tue, Feb 8, 2011 at 12:55 PM, Stephen Hopkins < <sho...@us...> > sho...@us...> wrote: > >> i think the dll comes from visual studio 2005 or 2008. The newer versions >> of python do not come with these files I think. It gave me trouble trying to >> install python on windows 7 so I am stuck using python on my laptop with >> windows xp since my laptop has visual studio. >> >> On Tue, Feb 8, 2011 at 12:00 PM, Eli Stevens (Gmail) <<wic...@gm...> >> wic...@gm...> wrote: >> >>> Hello, >>> >>> When I import OpenGL.GL like this under windows XP: >>> >>> Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit >>> (Intel)] on win32 >>> Type "help", "copyright", "credits" or "license" for more information. >>> >>> import OpenGL.GL >>> >>> I get the following error in an alert box: >>> >>> python.exe - Unable To Locate Component >>> This application has failed to start becuase MSVCR71.dll was not >>> found. Re-installing the application may fix this problem. >>> >>> The same behavior occurs when trying to import OpenGL.GL from inside our >>> application, however, aside from the alert box, the application seems to run >>> fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). >>> >>> PyOpenGL was installed via easy_install: >>> >>> >>> OpenGL.GL.__file__ >>> >>> 'C:\\Python27\\lib\\site-packages\\pyopengl-3.0.1-py2.7-win32.egg\\OpenGL\\GL\\__init__.pyc' >>> >>> Any suggestions on what we need to do to get this (seemingly spurious) >>> alert to go away? >>> >>> Thanks, >>> Eli >>> >>> >>> ------------------------------------------------------------------------------ >>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >>> Pinpoint memory and threading errors before they happen. >>> Find and fix more than 250 security defects in the development cycle. >>> Locate bottlenecks in serial and parallel code that limit performance. >>> <http://p.sf.net/sfu/intel-dev2devfeb> >>> http://p.sf.net/sfu/intel-dev2devfeb >>> _______________________________________________ >>> PyOpenGL Homepage >>> <http://pyopengl.sourceforge.net>http://pyopengl.sourceforge.net >>> _______________________________________________ >>> PyOpenGL-Users mailing list >>> <PyO...@li...> >>> PyO...@li... >>> <https://lists.sourceforge.net/lists/listinfo/pyopengl-users> >>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >>> >>> >> > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > |
From: Alejandro S. <as...@gm...> - 2011-02-08 22:56:36
|
Hello Eli, On Feb 8, 2011, at 7:26 PM, "Eli Stevens (Gmail)" <wic...@gm...> wrote: > According to http://www.py2exe.org/index.cgi/Tutorial#Step51 , msvcr71.dll is from VS 2005, while python 2.6 and newer use VS 2008 (and hence msvcr90.dll). Since I'm on python 2.7, it should be using msvcr90.dll, not 71. :-/ I guess I should have included that in my original email. I guess I'm trying to ask "why does PyOpenGL ask for a .dll that's clearly out of date with respect to the python version that I'm using?" It might have to do with the compiler version used for compiling python.exe. If it was built using VS 2005, it's expectable that it depends on msvcrt71. I guess the question here would be where did you download the Python interpreter you are using from? Did you get it from the official website? > You can install the MSVS 2008 Express Edition for free; that's what I've done and it works fine (for example, we also use a lot of Cython, and it uses VS 2008). You can also get these dll files by downloading and installing the Microsoft Visual C++ redistributable package. It's a free download and will spare you (and your users) from having to install Visual Studio. Please notice there are different redistibutable versions, each one corresponding to msvcrt 71, 80 and 90 with both x86 and x64 flavors. Hope this helps. Alejandro.- > On Tue, Feb 8, 2011 at 12:55 PM, Stephen Hopkins <sho...@us...> wrote: > i think the dll comes from visual studio 2005 or 2008. The newer versions of python do not come with these files I think. It gave me trouble trying to install python on windows 7 so I am stuck using python on my laptop with windows xp since my laptop has visual studio. > > On Tue, Feb 8, 2011 at 12:00 PM, Eli Stevens (Gmail) <wic...@gm...> wrote: > Hello, > > When I import OpenGL.GL like this under windows XP: > > Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import OpenGL.GL > > I get the following error in an alert box: > > python.exe - Unable To Locate Component > This application has failed to start becuase MSVCR71.dll was not found. Re-installing the application may fix this problem. > > The same behavior occurs when trying to import OpenGL.GL from inside our application, however, aside from the alert box, the application seems to run fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). > > PyOpenGL was installed via easy_install: > > >>> OpenGL.GL.__file__ > 'C:\\Python27\\lib\\site-packages\\pyopengl-3.0.1-py2.7-win32.egg\\OpenGL\\GL\\__init__.pyc' > > Any suggestions on what we need to do to get this (seemingly spurious) alert to go away? > > Thanks, > Eli > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: Eli S. (Gmail) <wic...@gm...> - 2011-02-08 21:26:53
|
According to http://www.py2exe.org/index.cgi/Tutorial#Step51 , msvcr71.dll is from VS 2005, while python 2.6 and newer use VS 2008 (and hence msvcr90.dll). Since I'm on python 2.7, it should be using msvcr90.dll, not 71. :-/ I guess I should have included that in my original email. I guess I'm trying to ask "why does PyOpenGL ask for a .dll that's clearly out of date with respect to the python version that I'm using?" You can install the MSVS 2008 Express Edition for free; that's what I've done and it works fine (for example, we also use a lot of Cython, and it uses VS 2008). Eli On Tue, Feb 8, 2011 at 12:55 PM, Stephen Hopkins <sho...@us...> wrote: > i think the dll comes from visual studio 2005 or 2008. The newer versions > of python do not come with these files I think. It gave me trouble trying to > install python on windows 7 so I am stuck using python on my laptop with > windows xp since my laptop has visual studio. > > On Tue, Feb 8, 2011 at 12:00 PM, Eli Stevens (Gmail) <wic...@gm... > > wrote: > >> Hello, >> >> When I import OpenGL.GL like this under windows XP: >> >> Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit >> (Intel)] on win32 >> Type "help", "copyright", "credits" or "license" for more information. >> >>> import OpenGL.GL >> >> I get the following error in an alert box: >> >> python.exe - Unable To Locate Component >> This application has failed to start becuase MSVCR71.dll was not >> found. Re-installing the application may fix this problem. >> >> The same behavior occurs when trying to import OpenGL.GL from inside our >> application, however, aside from the alert box, the application seems to run >> fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). >> >> PyOpenGL was installed via easy_install: >> >> >>> OpenGL.GL.__file__ >> >> 'C:\\Python27\\lib\\site-packages\\pyopengl-3.0.1-py2.7-win32.egg\\OpenGL\\GL\\__init__.pyc' >> >> Any suggestions on what we need to do to get this (seemingly spurious) >> alert to go away? >> >> Thanks, >> Eli >> >> >> ------------------------------------------------------------------------------ >> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: >> Pinpoint memory and threading errors before they happen. >> Find and fix more than 250 security defects in the development cycle. >> Locate bottlenecks in serial and parallel code that limit performance. >> http://p.sf.net/sfu/intel-dev2devfeb >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> > |
From: Stephen H. <sho...@us...> - 2011-02-08 20:56:22
|
i think the dll comes from visual studio 2005 or 2008. The newer versions of python do not come with these files I think. It gave me trouble trying to install python on windows 7 so I am stuck using python on my laptop with windows xp since my laptop has visual studio. On Tue, Feb 8, 2011 at 12:00 PM, Eli Stevens (Gmail) <wic...@gm...>wrote: > Hello, > > When I import OpenGL.GL like this under windows XP: > > Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit > (Intel)] on win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> import OpenGL.GL > > I get the following error in an alert box: > > python.exe - Unable To Locate Component > This application has failed to start becuase MSVCR71.dll was not > found. Re-installing the application may fix this problem. > > The same behavior occurs when trying to import OpenGL.GL from inside our > application, however, aside from the alert box, the application seems to run > fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). > > PyOpenGL was installed via easy_install: > > >>> OpenGL.GL.__file__ > > 'C:\\Python27\\lib\\site-packages\\pyopengl-3.0.1-py2.7-win32.egg\\OpenGL\\GL\\__init__.pyc' > > Any suggestions on what we need to do to get this (seemingly spurious) > alert to go away? > > Thanks, > Eli > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > |
From: Eli S. (Gmail) <wic...@gm...> - 2011-02-08 20:01:05
|
Hello, When I import OpenGL.GL like this under windows XP: Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import OpenGL.GL I get the following error in an alert box: python.exe - Unable To Locate Component This application has failed to start becuase MSVCR71.dll was not found. Re-installing the application may fix this problem. The same behavior occurs when trying to import OpenGL.GL from inside our application, however, aside from the alert box, the application seems to run fine (we're able to use OpenGL just fine, see 3d stuff, shaders, etc. etc.). PyOpenGL was installed via easy_install: >>> OpenGL.GL.__file__ 'C:\\Python27\\lib\\site-packages\\pyopengl-3.0.1-py2.7-win32.egg\\OpenGL\\GL\\__init__.pyc' Any suggestions on what we need to do to get this (seemingly spurious) alert to go away? Thanks, Eli |
From: Greg E. <gre...@ca...> - 2011-02-04 21:31:53
|
Jonathan Hartley wrote: > It surprised me to hear that a single VBO can't hold different data > types. SuperBible tentatively confirms what Steve says. Page 485 (5th ed.): > > It is also possible to store several different attributes in a > single buffer by interleaving them. To do this, call > glVertexArrayPointer with the stride param set to the distance (in > bytes) between attributes *of the same type.* I think you may be misinterpreting that. By "type" there I don't think it means data type, but rather the "kind" of value, i.e. coordinates, normal, colour, etc. What it's trying to say is that the stride is the distance from one entire record to the next. Not sure about VBOs, but the various predefined formats for interleaved vertex arrays under the old system certainly include some with mixed data types. -- Greg |
From: Jonathan H. <ta...@ta...> - 2011-02-03 22:35:13
|
Thanks for all the responses, they are all extremely helpful. It surprised me to hear that a single VBO can't hold different data types. SuperBible tentatively confirms what Steve says. Page 485 (5th ed.): It is also possible to store several different attributes in a single buffer by interleaving them. To do this, call glVertexArrayPointer with the stride param set to the distance (in bytes) between attributes *of the same type. * (Emphasis mine) All of the subsequent examples use VBOs filled exclusively with floats - although sometimes vec4s of float interleaved with vec3s of float. Is that a confirmation, or am I reading too much into it? If I manage to try it out I'll report back how it goes, but I have more urgent fish to fry for today, because , as Ian suggested early on, it probably doesn't reap the performance gain I was hoping for, so I'll stick with colors as floats for now. * *Thanks all round, especially to Nicolas whose code I'm greedily poring over. Jonathan On 03/02/2011 18:23, Nicolas Rougier wrote: > > Yes you can (see numpy record arrays) > > Z = numpy.zeros(100, > dtype = [('position','f4',3)), ('normal','f4',3), > ('color','uint8',4)] ) > > (see example posted previously). > > Nicolas > > > On Feb 3, 2011, at 6:49 PM, Stephen Hopkins wrote: > >> I dont think its possible to have 2 different data types in the same >> array. IF you've been using Numpy, each array has a type like float32, >> >> zeros(3 * numVertices + 4 * numVertices , dtype=float32) >> >> you could make 2 vbos and bind 2 vertexAttribPointers >> >> colorVBO = zeros(4 * numVertices, dtype="whatever is unsigned byte") >> vertexVBO = zeros(3*numVertices, dtype="float32") >> >> On Thu, Feb 3, 2011 at 3:49 AM, Jonathan Hartley <ta...@ta... >> <mailto:ta...@ta...>> wrote: >> >> Hey, >> >> I am using vbo.VBO, constructed using a single array of (position, >> color, normal) - all floats. This looks like: >> >> self.vbo = vbo.VBO( array( list( >> list(chain(v, c, n)) >> for v, c, n in zip(verts, colors, normals) >> ), >> 'f' >> ), >> usage='GL_STATIC_DRAW' >> ) >> >> where verts, colors, normals are each generator expressions >> containing >> named tuples of (x, y, z) or (r, g, b), etc. >> >> My problem is that I want to try out converting the colors to >> unsigned >> bytes instead of floats. When I was using vertex arrays instead >> of VBOs, >> using unsigned bytes gave me something like 25% better framerates >> on my >> hardware (2004 era laptop with ATI), purely from increased >> rendering speeds. >> >> Does it sound likely that I'll see this sort of improvement on other >> hardware too? Or should I just stick with using colors as floats >> throughout? >> >> If I do go ahead, I'm not certain how to construct the vbo containing >> mixed types like this. Is there anything in OpenGL.arrays that might >> help, or do I need to brush up on my ctypes-fu to construct an >> array of >> structs manually? >> >> I'm happy that I do understand how to assign the vertex attribute >> pointers once the vbo is constructed. >> >> Jonathan >> >> -- >> Jonathan Hartley Made of meat. http://tartley.com >> <http://tartley.com/> >> ta...@ta... <mailto:ta...@ta...> +44 7737 062 >> 225 twitter/skype: tartley >> >> >> >> ------------------------------------------------------------------------------ >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> Finally, a world-class log management solution at an even better >> price-free! >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> February 28th, so secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsight-sfd2d >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net <http://pyopengl.sourceforge.net/> >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> <mailto:PyO...@li...> >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> >> ------------------------------------------------------------------------------ >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> Finally, a world-class log management solution at an even better >> price-free! >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> February 28th, so secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users -- Jonathan Hartley Made of meat. http://tartley.com ta...@ta... +44 7737 062 225 twitter/skype: tartley |
From: Greg E. <gre...@ca...> - 2011-02-03 21:42:35
|
Stephen Hopkins wrote: > I dont think its possible to have 2 different data types in the same > array. Actually, you can -- numpy lets you have arrays of records, where each record can be made up of fields of different types. -- Greg |
From: Stephen H. <sho...@us...> - 2011-02-03 20:47:48
|
hm well I guess theres the stride thing, and the type specifier when you use vertexAttributes. This is off topic, but ts there any way to reply to my own thread. I posted earlier about transformFeedback. I had to update my graphics card drivers from opengl 2.1 to opengl 3.3 and then reinstall pyopengl and it finally worked. Is the documentation for pyopengl going to be updated to include the newer api functons like glBeginTransformFeedback or glGenFrameBuffers? On Thu, Feb 3, 2011 at 12:38 PM, Stephen Hopkins <sho...@us...> wrote: > And the Z array you posted could be passed as a single vertex attrib > pointer? > > > On Thu, Feb 3, 2011 at 10:23 AM, Nicolas Rougier <Nic...@in... > > wrote: > >> >> Yes you can (see numpy record arrays) >> >> Z = numpy.zeros(100, >> dtype = [('position','f4',3)), ('normal','f4',3), >> ('color','uint8',4)] ) >> >> (see example posted previously). >> >> Nicolas >> >> >> On Feb 3, 2011, at 6:49 PM, Stephen Hopkins wrote: >> >> I dont think its possible to have 2 different data types in the same >> array. IF you've been using Numpy, each array has a type like float32, >> >> zeros(3 * numVertices + 4 * numVertices , dtype=float32) >> >> you could make 2 vbos and bind 2 vertexAttribPointers >> >> colorVBO = zeros(4 * numVertices, dtype="whatever is unsigned byte") >> vertexVBO = zeros(3*numVertices, dtype="float32") >> >> On Thu, Feb 3, 2011 at 3:49 AM, Jonathan Hartley <ta...@ta...>wrote: >> >>> Hey, >>> >>> I am using vbo.VBO, constructed using a single array of (position, >>> color, normal) - all floats. This looks like: >>> >>> self.vbo = vbo.VBO( array( list( >>> list(chain(v, c, n)) >>> for v, c, n in zip(verts, colors, normals) >>> ), >>> 'f' >>> ), >>> usage='GL_STATIC_DRAW' >>> ) >>> >>> where verts, colors, normals are each generator expressions containing >>> named tuples of (x, y, z) or (r, g, b), etc. >>> >>> My problem is that I want to try out converting the colors to unsigned >>> bytes instead of floats. When I was using vertex arrays instead of VBOs, >>> using unsigned bytes gave me something like 25% better framerates on my >>> hardware (2004 era laptop with ATI), purely from increased rendering >>> speeds. >>> >>> Does it sound likely that I'll see this sort of improvement on other >>> hardware too? Or should I just stick with using colors as floats >>> throughout? >>> >>> If I do go ahead, I'm not certain how to construct the vbo containing >>> mixed types like this. Is there anything in OpenGL.arrays that might >>> help, or do I need to brush up on my ctypes-fu to construct an array of >>> structs manually? >>> >>> I'm happy that I do understand how to assign the vertex attribute >>> pointers once the vbo is constructed. >>> >>> Jonathan >>> >>> -- >>> Jonathan Hartley Made of meat. http://tartley.com >>> ta...@ta... +44 7737 062 225 twitter/skype: tartley >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >>> Finally, a world-class log management solution at an even better >>> price-free! >>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >>> February 28th, so secure your free ArcSight Logger TODAY! >>> http://p.sf.net/sfu/arcsight-sfd2d >>> _______________________________________________ >>> PyOpenGL Homepage >>> http://pyopengl.sourceforge.net >>> _______________________________________________ >>> PyOpenGL-Users mailing list >>> PyO...@li... >>> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >>> >> >> >> ------------------------------------------------------------------------------ >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> Finally, a world-class log management solution at an even better >> price-free! >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> February 28th, so secure your free ArcSight Logger TODAY! >> >> http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> >> >> >> ------------------------------------------------------------------------------ >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> Finally, a world-class log management solution at an even better >> price-free! >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> February 28th, so secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsight-sfd2d >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> >> > |
From: Stephen H. <sho...@us...> - 2011-02-03 20:38:36
|
And the Z array you posted could be passed as a single vertex attrib pointer? On Thu, Feb 3, 2011 at 10:23 AM, Nicolas Rougier <Nic...@in...>wrote: > > Yes you can (see numpy record arrays) > > Z = numpy.zeros(100, > dtype = [('position','f4',3)), ('normal','f4',3), > ('color','uint8',4)] ) > > (see example posted previously). > > Nicolas > > > On Feb 3, 2011, at 6:49 PM, Stephen Hopkins wrote: > > I dont think its possible to have 2 different data types in the same array. > IF you've been using Numpy, each array has a type like float32, > > zeros(3 * numVertices + 4 * numVertices , dtype=float32) > > you could make 2 vbos and bind 2 vertexAttribPointers > > colorVBO = zeros(4 * numVertices, dtype="whatever is unsigned byte") > vertexVBO = zeros(3*numVertices, dtype="float32") > > On Thu, Feb 3, 2011 at 3:49 AM, Jonathan Hartley <ta...@ta...>wrote: > >> Hey, >> >> I am using vbo.VBO, constructed using a single array of (position, >> color, normal) - all floats. This looks like: >> >> self.vbo = vbo.VBO( array( list( >> list(chain(v, c, n)) >> for v, c, n in zip(verts, colors, normals) >> ), >> 'f' >> ), >> usage='GL_STATIC_DRAW' >> ) >> >> where verts, colors, normals are each generator expressions containing >> named tuples of (x, y, z) or (r, g, b), etc. >> >> My problem is that I want to try out converting the colors to unsigned >> bytes instead of floats. When I was using vertex arrays instead of VBOs, >> using unsigned bytes gave me something like 25% better framerates on my >> hardware (2004 era laptop with ATI), purely from increased rendering >> speeds. >> >> Does it sound likely that I'll see this sort of improvement on other >> hardware too? Or should I just stick with using colors as floats >> throughout? >> >> If I do go ahead, I'm not certain how to construct the vbo containing >> mixed types like this. Is there anything in OpenGL.arrays that might >> help, or do I need to brush up on my ctypes-fu to construct an array of >> structs manually? >> >> I'm happy that I do understand how to assign the vertex attribute >> pointers once the vbo is constructed. >> >> Jonathan >> >> -- >> Jonathan Hartley Made of meat. http://tartley.com >> ta...@ta... +44 7737 062 225 twitter/skype: tartley >> >> >> >> >> ------------------------------------------------------------------------------ >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> Finally, a world-class log management solution at an even better >> price-free! >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> February 28th, so secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsight-sfd2d >> _______________________________________________ >> PyOpenGL Homepage >> http://pyopengl.sourceforge.net >> _______________________________________________ >> PyOpenGL-Users mailing list >> PyO...@li... >> https://lists.sourceforge.net/lists/listinfo/pyopengl-users >> > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > > http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > |
From: Nicolas R. <Nic...@in...> - 2011-02-03 18:23:09
|
Yes you can (see numpy record arrays) Z = numpy.zeros(100, dtype = [('position','f4',3)), ('normal','f4',3), ('color','uint8',4)] ) (see example posted previously). Nicolas On Feb 3, 2011, at 6:49 PM, Stephen Hopkins wrote: > I dont think its possible to have 2 different data types in the same array. IF you've been using Numpy, each array has a type like float32, > > zeros(3 * numVertices + 4 * numVertices , dtype=float32) > > you could make 2 vbos and bind 2 vertexAttribPointers > > colorVBO = zeros(4 * numVertices, dtype="whatever is unsigned byte") > vertexVBO = zeros(3*numVertices, dtype="float32") > > On Thu, Feb 3, 2011 at 3:49 AM, Jonathan Hartley <ta...@ta...> wrote: > Hey, > > I am using vbo.VBO, constructed using a single array of (position, > color, normal) - all floats. This looks like: > > self.vbo = vbo.VBO( array( list( > list(chain(v, c, n)) > for v, c, n in zip(verts, colors, normals) > ), > 'f' > ), > usage='GL_STATIC_DRAW' > ) > > where verts, colors, normals are each generator expressions containing > named tuples of (x, y, z) or (r, g, b), etc. > > My problem is that I want to try out converting the colors to unsigned > bytes instead of floats. When I was using vertex arrays instead of VBOs, > using unsigned bytes gave me something like 25% better framerates on my > hardware (2004 era laptop with ATI), purely from increased rendering speeds. > > Does it sound likely that I'll see this sort of improvement on other > hardware too? Or should I just stick with using colors as floats throughout? > > If I do go ahead, I'm not certain how to construct the vbo containing > mixed types like this. Is there anything in OpenGL.arrays that might > help, or do I need to brush up on my ctypes-fu to construct an array of > structs manually? > > I'm happy that I do understand how to assign the vertex attribute > pointers once the vbo is constructed. > > Jonathan > > -- > Jonathan Hartley Made of meat. http://tartley.com > ta...@ta... +44 7737 062 225 twitter/skype: tartley > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users |
From: Stephen H. <sho...@us...> - 2011-02-03 17:49:37
|
I dont think its possible to have 2 different data types in the same array. IF you've been using Numpy, each array has a type like float32, zeros(3 * numVertices + 4 * numVertices , dtype=float32) you could make 2 vbos and bind 2 vertexAttribPointers colorVBO = zeros(4 * numVertices, dtype="whatever is unsigned byte") vertexVBO = zeros(3*numVertices, dtype="float32") On Thu, Feb 3, 2011 at 3:49 AM, Jonathan Hartley <ta...@ta...>wrote: > Hey, > > I am using vbo.VBO, constructed using a single array of (position, > color, normal) - all floats. This looks like: > > self.vbo = vbo.VBO( array( list( > list(chain(v, c, n)) > for v, c, n in zip(verts, colors, normals) > ), > 'f' > ), > usage='GL_STATIC_DRAW' > ) > > where verts, colors, normals are each generator expressions containing > named tuples of (x, y, z) or (r, g, b), etc. > > My problem is that I want to try out converting the colors to unsigned > bytes instead of floats. When I was using vertex arrays instead of VBOs, > using unsigned bytes gave me something like 25% better framerates on my > hardware (2004 era laptop with ATI), purely from increased rendering > speeds. > > Does it sound likely that I'll see this sort of improvement on other > hardware too? Or should I just stick with using colors as floats > throughout? > > If I do go ahead, I'm not certain how to construct the vbo containing > mixed types like this. Is there anything in OpenGL.arrays that might > help, or do I need to brush up on my ctypes-fu to construct an array of > structs manually? > > I'm happy that I do understand how to assign the vertex attribute > pointers once the vbo is constructed. > > Jonathan > > -- > Jonathan Hartley Made of meat. http://tartley.com > ta...@ta... +44 7737 062 225 twitter/skype: tartley > > > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |