pyopengl-users Mailing List for PyOpenGL (Page 38)
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: Greg E. <gre...@ca...> - 2010-04-21 10:06:18
|
> On Tue, 2010-04-20 at 10:46 -0700, Ian Mallett wrote: > >>I'm not sure, but as I recall, a proper pygame/OpenGL context also >>requires a pygame.DOUBLEBUF flag. I was playing with that recently, and if I remember correctly, you can use it with or without DOUBLEBUF. But if you're not double buffering, you have to remember to call glFlush before anything will appear on the screen. -- Greg |
From: Nicolas R. <Nic...@lo...> - 2010-04-21 08:16:54
|
In fact, the code I sent was kind of a shortcut and I'm actually creating a proper context using glut (full sources are available at http://code.google.com/p/glumpy/). Currently, I'm only able to run my demo-teapot.py example, all other examples use shaders and do not work anymore. Nicolas On Tue, 2010-04-20 at 10:46 -0700, Ian Mallett wrote: > Yes, a context is necessary for many functions to work properly. > > > I'm not sure, but as I recall, a proper pygame/OpenGL context also > requires a pygame.DOUBLEBUF flag. That probably doesn't influence > whether the context exists or not, but it should influence whether you > can use it later. > > > Ian |
From: Ian M. <geo...@gm...> - 2010-04-20 17:46:26
|
Yes, a context is necessary for many functions to work properly. I'm not sure, but as I recall, a proper pygame/OpenGL context also requires a pygame.DOUBLEBUF flag. That probably doesn't influence whether the context exists or not, but it should influence whether you can use it later. Ian |
From: Alejandro S. <as...@gm...> - 2010-04-20 14:53:51
|
Hello Nicolas, On Tue, Apr 20, 2010 at 8:27 AM, Nicolas Rougier <Nic...@lo...>wrote: > > Hello, > > I've been testing the upcoming Ubuntu Lucid Lynx version (beta 2) on an > imac and I got problem accessing a lot of functions from PyOpenGL. I > would say that most OpenGL 2.0 (or above) functions are not accessible > anymore (compared to previous installed Karmic Koala that was fully > functional). I suspect PyOpenGL to somehow get the wrong version of the > library (GL_VENDOR and GL_VERSION are empty) but I do not know how to > debug it, any idea ? > > > Here are some informations: > > ~ > sudo dmidecode -s system-product-name > iMac7,1 > > ~ > uname -a > Linux sulfur 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC > 2010 x86_64 GNU/Linux > > ~ > fglrxinfo (long version at the end of this post) > display: :0.0 screen: 0 > OpenGL vendor string: ATI Technologies Inc. > OpenGL renderer string: ATI Mobility Radeon HD 2600 XT > OpenGL version string: 3.2.9756 Compatibility Profile Context > > ~ > python > >>> import OpenGL > >>> print OpenGL.__version__ > 3.0.1 > >>> import OpenGL.GL as gl > >>> print gl.glGetString(gl.GL_VENDOR) > None > >>> print gl.glGetString(gl.GL_VERSION) > None > >>> print bool(gl.glCreateProgram) > False > This might sound trivial, but have you tried creating an OpenGL Context before testing whether this functions exist? Adding something like pygame.display.set_mode((200,200), pygame.OPENGL) at the beginning should do. > > > ~ > fglrxinfo -n > display: :0.0 screen:0 > OpenGL vendor string: ATI Technologies Inc. > OpenGL renderer string: ATI Mobility Radeon HD 2600 XT > OpenGL version string: 3.2.9756 Compatibility Profile Context > OpenGL extensions: > GL_AMDX_name_gen_delete, GL_AMDX_vertex_shader_tessellator, > GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, > GL_AMD_performance_monitor, GL_AMD_shader_stencil_export, > GL_AMD_vertex_shader_tessellator, GL_ARB_color_buffer_float, > GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, > GL_ARB_depth_texture, GL_ARB_draw_buffers, > GL_ARB_draw_buffers_blend, > GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, > GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program, > GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, > GL_ARB_framebuffer_object, GL_ARB_framebuffer_sRGB, > GL_ARB_geometry_shader4, GL_ARB_half_float_pixel, > GL_ARB_half_float_vertex, GL_ARB_imaging, GL_ARB_instanced_arrays, > GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, > GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, > GL_ARB_point_parameters, GL_ARB_point_sprite, > GL_ARB_provoking_vertex, > GL_ARB_seamless_cube_map, GL_ARB_shader_objects, > GL_ARB_shader_texture_lod, GL_ARB_shading_language_100, > GL_ARB_shadow, > GL_ARB_shadow_ambient, GL_ARB_sync, GL_ARB_texture_border_clamp, > GL_ARB_texture_buffer_object, GL_ARB_texture_compression, > GL_ARB_texture_compression_rgtc, GL_ARB_texture_cube_map, > GL_ARB_texture_env_add, GL_ARB_texture_env_combine, > GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, > GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat, > GL_ARB_texture_multisample, GL_ARB_texture_non_power_of_two, > GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_snorm, > GL_ARB_transpose_matrix, GL_ARB_uniform_buffer_object, > GL_ARB_vertex_array_bgra, GL_ARB_vertex_array_object, > GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, > GL_ARB_vertex_shader, > GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_envmap_bumpmap, > GL_ATI_fragment_shader, GL_ATI_meminfo, GL_ATI_separate_stencil, > GL_ATI_texture_compression_3dc, GL_ATI_texture_env_combine3, > GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_EXT_abgr, > GL_EXT_bgra, GL_EXT_bindable_uniform, GL_EXT_blend_color, > GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, > GL_EXT_blend_minmax, GL_EXT_blend_subtract, > GL_EXT_compiled_vertex_array, > GL_EXT_copy_buffer, GL_EXT_copy_texture, GL_EXT_draw_buffers2, > GL_EXT_draw_instanced, GL_EXT_draw_range_elements, > GL_EXT_fog_coord, > GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, > GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, > GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters, > GL_EXT_gpu_shader4, GL_EXT_histogram, GL_EXT_multi_draw_arrays, > GL_EXT_packed_depth_stencil, GL_EXT_packed_float, > GL_EXT_packed_pixels, > GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, > GL_EXT_provoking_vertex, GL_EXT_rescale_normal, > GL_EXT_secondary_color, > GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, > GL_EXT_stencil_wrap, > GL_EXT_subtexture, GL_EXT_texgen_reflection, GL_EXT_texture3D, > GL_EXT_texture_array, GL_EXT_texture_buffer_object, > GL_EXT_texture_buffer_object_rgb32, > GL_EXT_texture_compression_latc, > GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_s3tc, > GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, > GL_EXT_texture_env_add, GL_EXT_texture_env_combine, > GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, > GL_EXT_texture_integer, GL_EXT_texture_lod, > GL_EXT_texture_lod_bias, > GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, > GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, > GL_EXT_texture_shared_exponent, GL_EXT_texture_snorm, > GL_EXT_texture_swizzle, GL_EXT_timer_query, > GL_EXT_transform_feedback, > GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, > GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, > GL_NV_blend_square, > GL_NV_conditional_render, GL_NV_copy_depth_to_color, > GL_NV_explicit_multisample, GL_NV_primitive_restart, > GL_NV_texgen_reflection, GL_SGIS_generate_mipmap, > GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, > GL_SUN_multi_draw_arrays, > GL_WIN_swap_hint, WGL_EXT_swap_control > glx server vendor string: ATI > glx server version string: 1.4 > glx server extensions: > GLX_ARB_multisample, GLX_EXT_import_context, > GLX_EXT_texture_from_pixmap, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, > GLX_SGI_make_current_read, GLX_SGI_swap_control, > GLX_SGIS_multisample, > GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group > glx client version: 1.4 > glx client extensions: > GLX_ARB_create_context, GLX_ARB_create_context_profile, > GLX_ARB_get_proc_address, GLX_ARB_multisample, > GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, > GLX_MESA_allocate_memory, > GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, > GLX_NV_swap_group, > GLX_OML_swap_method, GLX_SGI_make_current_read, > GLX_SGI_swap_control, > GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, > GLX_SGIX_pbuffer, GLX_SGIX_swap_barrier, GLX_SGIX_swap_group, > GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, > GLX_EXT_framebuffer_sRGB, GLX_ARB_fbconfig_float > glx extensions: > GLX_ARB_create_context, GLX_ARB_create_context_profile, > GLX_ARB_get_proc_address, GLX_ARB_multisample, > GLX_EXT_import_context, > GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, > GLX_NV_swap_group, GLX_OML_swap_method, GLX_SGI_make_current_read, > GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, > GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_swap_barrier, > GLX_SGIX_swap_group, GLX_SGIX_visual_select_group, > GLX_EXT_texture_from_pixmap > > visual x bf lv rg d st r g b a ax dp st accum buffs ms > id dep cl sp sz l ci b ro sz sz sz sz bf th cl r g b a ns b > ----------------------------------------------------------------- > 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 > 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 > 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 > 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 > 0x2b 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x2c 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x2d 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x2e 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x2f 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 2 1 > 0x30 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 2 1 > 0x31 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 2 1 > 0x32 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 2 1 > 0x33 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x34 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x35 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x36 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x37 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 4 1 > 0x38 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 4 1 > 0x39 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 4 1 > 0x3a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 4 1 > 0x3b 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x3c 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x3d 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x3e 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x3f 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 6 1 > 0x40 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 6 1 > 0x41 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 6 1 > 0x42 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 6 1 > 0x43 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x44 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x45 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x46 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x47 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 8 1 > 0x48 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 8 1 > 0x49 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 8 1 > 0x4a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 8 1 > 0x4b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x4c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x4d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x4e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x4f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 > 0x50 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 > 0x51 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 > 0x52 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 > 0x53 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x54 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x55 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x56 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x57 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 2 1 > 0x58 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 2 1 > 0x59 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 2 1 > 0x5a 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 2 1 > 0x5b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x5c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x5d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x5e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x5f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 4 1 > 0x60 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 4 1 > 0x61 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 4 1 > 0x62 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 4 1 > 0x63 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x64 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x65 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x66 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x67 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 6 1 > 0x68 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 6 1 > 0x69 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 6 1 > 0x6a 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 6 1 > 0x6b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x6c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 > 0x6d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x6e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 > 0x6f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 8 1 > 0x70 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 8 1 > 0x71 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 8 1 > 0x72 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 8 1 > 0xa3 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 4 1 > > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > 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: Nicolas R. <Nic...@lo...> - 2010-04-20 11:27:40
|
Hello, I've been testing the upcoming Ubuntu Lucid Lynx version (beta 2) on an imac and I got problem accessing a lot of functions from PyOpenGL. I would say that most OpenGL 2.0 (or above) functions are not accessible anymore (compared to previous installed Karmic Koala that was fully functional). I suspect PyOpenGL to somehow get the wrong version of the library (GL_VENDOR and GL_VERSION are empty) but I do not know how to debug it, any idea ? Here are some informations: ~ > sudo dmidecode -s system-product-name iMac7,1 ~ > uname -a Linux sulfur 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux ~ > fglrxinfo (long version at the end of this post) display: :0.0 screen: 0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Mobility Radeon HD 2600 XT OpenGL version string: 3.2.9756 Compatibility Profile Context ~ > python >>> import OpenGL >>> print OpenGL.__version__ 3.0.1 >>> import OpenGL.GL as gl >>> print gl.glGetString(gl.GL_VENDOR) None >>> print gl.glGetString(gl.GL_VERSION) None >>> print bool(gl.glCreateProgram) False ~ > fglrxinfo -n display: :0.0 screen:0 OpenGL vendor string: ATI Technologies Inc. OpenGL renderer string: ATI Mobility Radeon HD 2600 XT OpenGL version string: 3.2.9756 Compatibility Profile Context OpenGL extensions: GL_AMDX_name_gen_delete, GL_AMDX_vertex_shader_tessellator, GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, GL_AMD_performance_monitor, GL_AMD_shader_stencil_export, GL_AMD_vertex_shader_tessellator, GL_ARB_color_buffer_float, GL_ARB_copy_buffer, GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex, GL_ARB_draw_instanced, GL_ARB_fragment_coord_conventions, GL_ARB_fragment_program, GL_ARB_fragment_program_shadow, GL_ARB_fragment_shader, GL_ARB_framebuffer_object, GL_ARB_framebuffer_sRGB, GL_ARB_geometry_shader4, GL_ARB_half_float_pixel, GL_ARB_half_float_vertex, GL_ARB_imaging, GL_ARB_instanced_arrays, GL_ARB_map_buffer_range, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_provoking_vertex, GL_ARB_seamless_cube_map, GL_ARB_shader_objects, GL_ARB_shader_texture_lod, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_sync, GL_ARB_texture_border_clamp, GL_ARB_texture_buffer_object, GL_ARB_texture_compression, GL_ARB_texture_compression_rgtc, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_multisample, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_ARB_texture_rg, GL_ARB_texture_snorm, GL_ARB_transpose_matrix, GL_ARB_uniform_buffer_object, GL_ARB_vertex_array_bgra, GL_ARB_vertex_array_object, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_ATI_draw_buffers, GL_ATI_envmap_bumpmap, GL_ATI_fragment_shader, GL_ATI_meminfo, GL_ATI_separate_stencil, GL_ATI_texture_compression_3dc, GL_ATI_texture_env_combine3, GL_ATI_texture_float, GL_ATI_texture_mirror_once, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_bindable_uniform, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_copy_buffer, GL_EXT_copy_texture, GL_EXT_draw_buffers2, GL_EXT_draw_instanced, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_blit, GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_object, GL_EXT_framebuffer_sRGB, GL_EXT_geometry_shader4, GL_EXT_gpu_program_parameters, GL_EXT_gpu_shader4, GL_EXT_histogram, GL_EXT_multi_draw_arrays, GL_EXT_packed_depth_stencil, GL_EXT_packed_float, GL_EXT_packed_pixels, GL_EXT_pixel_buffer_object, GL_EXT_point_parameters, GL_EXT_provoking_vertex, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_wrap, GL_EXT_subtexture, GL_EXT_texgen_reflection, GL_EXT_texture3D, GL_EXT_texture_array, GL_EXT_texture_buffer_object, GL_EXT_texture_buffer_object_rgb32, GL_EXT_texture_compression_latc, GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_integer, GL_EXT_texture_lod, GL_EXT_texture_lod_bias, GL_EXT_texture_mirror_clamp, GL_EXT_texture_object, GL_EXT_texture_rectangle, GL_EXT_texture_sRGB, GL_EXT_texture_shared_exponent, GL_EXT_texture_snorm, GL_EXT_texture_swizzle, GL_EXT_timer_query, GL_EXT_transform_feedback, GL_EXT_vertex_array, GL_EXT_vertex_array_bgra, GL_IBM_texture_mirrored_repeat, GL_KTX_buffer_region, GL_NV_blend_square, GL_NV_conditional_render, GL_NV_copy_depth_to_color, GL_NV_explicit_multisample, GL_NV_primitive_restart, GL_NV_texgen_reflection, GL_SGIS_generate_mipmap, GL_SGIS_texture_edge_clamp, GL_SGIS_texture_lod, GL_SUN_multi_draw_arrays, GL_WIN_swap_hint, WGL_EXT_swap_control glx server vendor string: ATI glx server version string: 1.4 glx server extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group glx client version: 1.4 glx client extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_NV_swap_group, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_swap_barrier, GLX_SGIX_swap_group, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_EXT_framebuffer_sRGB, GLX_ARB_fbconfig_float glx extensions: GLX_ARB_create_context, GLX_ARB_create_context_profile, GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_swap_control, GLX_NV_swap_group, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_swap_barrier, GLX_SGIX_swap_group, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap visual x bf lv rg d st r g b a ax dp st accum buffs ms id dep cl sp sz l ci b ro sz sz sz sz bf th cl r g b a ns b ----------------------------------------------------------------- 0x23 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x24 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x25 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x26 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x27 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 0x28 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 0x29 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 0x2a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 0x2b 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x2c 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x2d 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x2e 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x2f 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 2 1 0x30 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 2 1 0x31 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 2 1 0x32 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 2 1 0x33 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x34 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x35 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x36 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x37 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 4 1 0x38 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 4 1 0x39 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 4 1 0x3a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 4 1 0x3b 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x3c 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x3d 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x3e 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x3f 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 6 1 0x40 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 6 1 0x41 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 6 1 0x42 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 6 1 0x43 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x44 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x45 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x46 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x47 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 8 1 0x48 24 tc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 8 1 0x49 24 tc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 8 1 0x4a 24 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 8 1 0x4b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x4c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x4d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x4e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x4f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 0x50 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 0 0 0x51 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 0 0 0x52 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 0 0 0x53 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x54 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x55 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x56 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x57 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 2 1 0x58 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 2 1 0x59 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 2 1 0x5a 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 2 1 0x5b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x5c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x5d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x5e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x5f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 4 1 0x60 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 4 1 0x61 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 4 1 0x62 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 4 1 0x63 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x64 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x65 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x66 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x67 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 6 1 0x68 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 6 1 0x69 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 6 1 0x6a 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 6 1 0x6b 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x6c 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 16 16 16 16 0 0 0x6d 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x6e 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 16 16 16 16 0 0 0x6f 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 8 1 0x70 24 dc 0 32 0 r . . 8 8 8 8 0 24 8 0 0 0 0 8 1 0x71 24 dc 0 32 0 r y . 8 8 8 8 0 24 0 0 0 0 0 8 1 0x72 24 dc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 8 1 0xa3 32 tc 0 32 0 r . . 8 8 8 8 0 24 0 0 0 0 0 4 1 |
From: Punyashloka B. <pun...@gm...> - 2010-04-19 19:38:12
|
Hi PyOpenGL people, I'm using a computer whose graphics card has decent DirectX 9 support but very outdated GL drivers, and I've had some success writing OpenGL programs using Google Angle library (which translates GL into DX, including GLSL -> HLSL) from C++. I'd like to work on adding Angle support to PyOpenGL, but I have no clue where to begin. Would anybody be willing to give me some guidance? Thanks! Punya |
From: Mike C. F. <mcf...@vr...> - 2010-04-17 22:13:02
|
Lionel Data wrote: > There's actually a problem with the way the extensions are retrieved. > The hasGLExtension() function returns always 'False'. > This is due to the fact that glGetStringi returns a GLubyteArray > object, and the AVAILABLE_GL_EXTENSIONS list is full of instances of > GLuByteArray, instead of strings. > > I'm quite new to PyOpenGL and the open source community, so I'm not > too good with the collaborative work stuff. Should I report these bugs > somewhere more visible or patch it myself and commit it somehow ? bzr is a distributed source control system, and LaunchPad lets you publicly expose your branches with a (free) account. If your patches are small, you can simply commit them to your local bzr branch and do a: bzr send which will create a merge-capable patch I can use to pull in your changes. If you want to do more involved changes, branching on LaunchPad and doing a merge-request there is likely more appropriate (I'll accept bzr-send patches even if they're large, it's just that we may wind up with some back-and-forth as we revise it, and a public repository makes that easier). Particularly for this kind of hardware-specific stuff, I'd really appreciate any contributions. Have fun, Mike > > 2010/4/16 Lionel Data <lio...@gm... > <mailto:lio...@gm...>> > > Hum sorry I skipped the part with the bzr head :) > Forget about the glGetInteger, it works fine with the head version. > > So I just tested, and I still get unexpected error 1280 after > import OpenGL.GL.ARB.vertex_array_object. > What actually happens is that I import this module at a function > level (so that the context is already created) and the next OpenGL > call I try to make raises the 1280 error. > > My guess is it does not work because there is still glGetString( > GL_EXTENSIONS ).split(), even if it is in a try. Since the error > is not reported with an actual exception right away, but with the > glCheckError function. > > It works fine after commenting the 'try' statement. > > Cheers, > > Lionel > > > 2010/4/16 Lionel Data <lio...@gm... > <mailto:lio...@gm...>> > > Ok, so apparently there is a problem with glGetInteger()as > well and I can't really understand it. > Here is what I get. > > print glGetInteger(GL_NUM_EXTENSIONS) > File > "/home/lionel/work/ets/python26/lib/python2.6/site-packages/PyOpenGL-3.0.1-py2.6.egg/OpenGL/latebind.py", > line 45, in __call__ > return self._finalCall( *args, **named ) > File > "/home/lionel/work/ets/python26/lib/python2.6/site-packages/PyOpenGL-3.0.1-py2.6.egg/OpenGL/wrapper.py", > line 570, in wrapperCall > cArgs = tuple(calculate_cArgs( pyArgs )) > File > "/home/lionel/work/ets/python26/lib/python2.6/site-packages/PyOpenGL-3.0.1-py2.6.egg/OpenGL/wrapper.py", > line 373, in calculate_cArgs > yield converter( pyArgs, index, self ) > File > "/home/lionel/work/ets/python26/lib/python2.6/site-packages/PyOpenGL-3.0.1-py2.6.egg/OpenGL/converters.py", > line 194, in __call__ > return self.arrayType.zeros( self.getSize(pyArgs) ) > File > "/home/lionel/work/ets/python26/lib/python2.6/site-packages/PyOpenGL-3.0.1-py2.6.egg/OpenGL/converters.py", > line 233, in getSize > raise KeyError( """Unknown specifier %s"""%( specifier )) > KeyError: ('Unknown specifier GL_NUM_EXTENSIONS (33309)', > 'Failure in cConverter <OpenGL.converters.SizedOutput object > at 0xb5a8186c>', (GL_NUM_EXTENSIONS,), 1, > <OpenGL.wrapper.glGetIntegerv object at 0xb5a0356c>) > > This looks a bit too deep for me. > > Lionel > > 2010/4/16 Lionel Data <lio...@gm... > <mailto:lio...@gm...>> > > Hi, > Shall I modify the code of the hasGLExtension and submit > you the patch ? > I was thinking about checking for the flag > FORWARD_COMPATIBLE_ONLY, and, if set, > change the glGetString(GL_EXTENSIONS) to : > extensions_count = glGetInteger(GL_NUM_EXTENSIONS) > for i in range(extensions_count): > > AVAILABLE_GL_EXTENSIONS.append(glGetStringi(GL_EXTENSIONS, i)) > > Does that sound good ? > > 2010/4/16 Mike C. Fletcher <mcf...@vr... > <mailto:mcf...@vr...>> > > Lionel Data wrote: > > Hi, > > > > this is my first post to this mailing list. I'm > currently struggling > > quite hard to have a fresh OpenGL 3.2 compliant > mini-engine using > > PyOpenGL. > > > > I wanted to use the vertex array objects provided by > the core profile. > > As far as I know, it shouldn't be an extension > anymore, but I may be > > mistaken. > > Anyway, I found the actual functions in the > > OpenGL.GL.ARB.vertex_array_object module. However, > it seems that, > > somewhere in PyOpenGL, the function > glGetString(GL_EXTENSIONS) is > > called. Since I created an OpenGL3.2 core context, > and that the > > GL_EXTENSIONS enum is now deprecated, I get an > unexpected error 1280 > > (bad enum), and my engine crashes. > > > > Is there something I am missing ? > Just that the utility code that checks for extensions > wasn't tested with > a machine that can do legacy free. I've attempted to > update the > extension-checking functionality to provide a legacy-free > implementation, but I don't have any machine with > glGetStringi available > (i.e. I don't have a 3.x capable card), so I can't > actually test that it > works. If you can test with bzr head, it would be > helpful. > > HTH, > Mike > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > > > -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2010-04-16 04:08:43
|
Lionel Data wrote: > Hi, > > this is my first post to this mailing list. I'm currently struggling > quite hard to have a fresh OpenGL 3.2 compliant mini-engine using > PyOpenGL. > > I wanted to use the vertex array objects provided by the core profile. > As far as I know, it shouldn't be an extension anymore, but I may be > mistaken. > Anyway, I found the actual functions in the > OpenGL.GL.ARB.vertex_array_object module. However, it seems that, > somewhere in PyOpenGL, the function glGetString(GL_EXTENSIONS) is > called. Since I created an OpenGL3.2 core context, and that the > GL_EXTENSIONS enum is now deprecated, I get an unexpected error 1280 > (bad enum), and my engine crashes. > > Is there something I am missing ? Just that the utility code that checks for extensions wasn't tested with a machine that can do legacy free. I've attempted to update the extension-checking functionality to provide a legacy-free implementation, but I don't have any machine with glGetStringi available (i.e. I don't have a 3.x capable card), so I can't actually test that it works. If you can test with bzr head, it would be helpful. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Lionel D. <lio...@gm...> - 2010-04-15 15:42:21
|
Hi, this is my first post to this mailing list. I'm currently struggling quite hard to have a fresh OpenGL 3.2 compliant mini-engine using PyOpenGL. I wanted to use the vertex array objects provided by the core profile. As far as I know, it shouldn't be an extension anymore, but I may be mistaken. Anyway, I found the actual functions in the OpenGL.GL.ARB.vertex_array_object module. However, it seems that, somewhere in PyOpenGL, the function glGetString(GL_EXTENSIONS) is called. Since I created an OpenGL3.2 core context, and that the GL_EXTENSIONS enum is now deprecated, I get an unexpected error 1280 (bad enum), and my engine crashes. Is there something I am missing ? Thanks Lionel |
From: Gary H. <gh...@di...> - 2010-04-14 16:47:54
|
Eleftherios Garyfallidis wrote: > Hello, > > Thank you again for your response. > > - Show quoted text - > On Tue, Apr 13, 2010 at 11:20 AM, Greg Ewing > <gre...@ca... <mailto:gre...@ca...>> wrote: > > Eleftherios Garyfallidis wrote: > > to get > > the near plane I believe you need to gluUnProject with z=0. > and to get the far plane you need to gluUnProject with z=1 > > > You're quite right, I was misremembering, sorry. > > > Surprisingly, when I do glu.gluUnProject(x,viewport[3]-y,0.) > and glu.gluUnProject(x,viewport[3]-y,1.) in PyOpenGL it seems > it works fine but when I am feeding the transformation > matrices by myself I am getting this error "Projection Failed". > > > That sounds like there is something wrong with your matrices. > How are you getting them? Are you getting them directly from > OpenGL, or calculating them yourself? If you're calculating them > yourself, you might be making a mistake somewhere. > > > What happens if you retrieve the relevant matrices from OpenGL > and feed them to gluUnProject? If that works, compare them with > your own matrices to see if there is a difference. > > > Yes this is what I am doing just calculating these matrices using > the following PyOpenGL functions > > import OpenGL.GL as gl > > modelviewmatrix=gl.glGetDoublev(gl.GL_MODELVIEW_MATRIX) > > projectionmatrix=gl.glGetDoublev(gl.GL_PROJECTION_MATRIX) > > viewport=gl.glGetDoublev(gl.GL_VIEWPORT) I have not followed this thread at all -- so I don't know the history. Nevertheless, I see a potential problem. The call to gluUnProject expects the viewport to be passed in as integers (GLint*) so you should be using glGetIntegerv not glGetDoublev to get the viewport as an array of integers. Here's gluUnProject's spec: GLint gluUnProject( GLdouble winX, GLdouble winY, GLdouble winZ, const GLdouble * model, const GLdouble * proj, const GLint * view, // !!!!! GLdouble* objX, GLdouble* objY, GLdouble* objZ); Using glGetDoublev for the two matricies and glGetIntegerv for the viewport as input to gluUnProject has always worked well for me. > > These matrices are numpy arrays do you think that it might be a > problem when we put these as input in gluUnProject? Should I transform > them into something else perhaps? > > By the way I do confirm that when using gluUnProject without feeding > in the transformation matrices as in glu.gluUnProject(x,viewport[3] > -y,0.) does work correctly :-) I made some tests with picking planes > and the accuracy of picking was excellent!!! The tests involved > checking if the segment AB (where A is near and B is far) intersects > with planes. For my application I need to check against many planes so > I made a function for this in cython. The link for the code is here > > http://github.com/Garyfallidis/Fos/blob/master/fos/core/collision.pyx > > Best wishes, > Eleftherios > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > ------------------------------------------------------------------------ > > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > -- Gary Herron, PhD. Department of Computer Science DigiPen Institute of Technology (425) 895-4418 |
From: Eleftherios G. <gar...@gm...> - 2010-04-14 09:59:29
|
Hello, Thank you again for your response. - Show quoted text - On Tue, Apr 13, 2010 at 11:20 AM, Greg Ewing <gre...@ca...>wrote: > Eleftherios Garyfallidis wrote: > > to get > >> the near plane I believe you need to gluUnProject with z=0. and to get the >> far plane you need to gluUnProject with z=1 >> > > You're quite right, I was misremembering, sorry. > > > Surprisingly, when I do glu.gluUnProject(x,viewport[3]-y,0.) and >> glu.gluUnProject(x,viewport[3]-y,1.) in PyOpenGL it seems it works fine but >> when I am feeding the transformation matrices by myself I am getting this >> error "Projection Failed". >> > > That sounds like there is something wrong with your matrices. > How are you getting them? Are you getting them directly from > OpenGL, or calculating them yourself? If you're calculating them > yourself, you might be making a mistake somewhere. > > What happens if you retrieve the relevant matrices from OpenGL > and feed them to gluUnProject? If that works, compare them with > your own matrices to see if there is a difference. > Yes this is what I am doing just calculating these matrices using the following PyOpenGL functions import OpenGL.GL as gl modelviewmatrix=gl.glGetDoublev(gl.GL_MODELVIEW_MATRIX) projectionmatrix=gl.glGetDoublev(gl.GL_PROJECTION_MATRIX) viewport=gl.glGetDoublev(gl.GL_VIEWPORT) These matrices are numpy arrays do you think that it might be a problem when we put these as input in gluUnProject? Should I transform them into something else perhaps? By the way I do confirm that when using gluUnProject without feeding in the transformation matrices as in glu.gluUnProject(x,viewport[3] -y,0.) does work correctly :-) I made some tests with picking planes and the accuracy of picking was excellent!!! The tests involved checking if the segment AB (where A is near and B is far) intersects with planes. For my application I need to check against many planes so I made a function for this in cython. The link for the code is here http://github.com/Garyfallidis/Fos/blob/master/fos/core/collision.pyx Best wishes, Eleftherios |
From: Greg E. <gre...@ca...> - 2010-04-13 10:30:13
|
Eleftherios Garyfallidis wrote: > wx,wy,wz= glu.gluUnProject(float(x),viewport[3]-float(y),0., > modelviewmatrix, > projectionmatrix, > viewport) I don't think that 0 is a valid value for the z coordinate when you're unprojecting in a perspective projection. Also, to get a ray, you need to know *two* points in the scene. The way I do it is to call gluUnProject twice, once with z = the near plane, and once with z = the far plane. A line between the two resulting points gives you your pick ray. -- Greg |
From: Eleftherios G. <gar...@gm...> - 2010-04-12 17:57:13
|
Hello, I am using the pyopengl version 3.0.0 in Ubuntu 9.10 and I am trying to get a pick ray when I press 'p' in the keyboard. To do that I found that is well suggested to use gluUnProject. if key == 'p': modelviewmatrix=gl.glGetDoublev(gl.GL_MODELVIEW_MATRIX) print 'ModelViewMatrix' print modelviewmatrix projectionmatrix=gl.glGetDoublev(gl.GL_PROJECTION_MATRIX) print 'ProjectionMatrix' print projectionmatrix viewport=gl.glGetDoublev(gl.GL_VIEWPORT) print 'Viewport' print viewport print float(x), viewport[3]-float(y) wx,wy,wz= glu.gluUnProject(float(x),viewport[3]-float(y),0., modelviewmatrix, projectionmatrix, viewport) print 'World Coordinate' print wx,wy,wz And the output is giving me a value error projection failed as you can see below ModelViewMatrix [[ 1. 0. 0. 0.] [ 0. 1. 0. 0.] [ 0. 0. 1. 0.] [ 0. 0. -150. 1.]] ProjectionMatrix [[ 1.28300059 0. 0. 0. ] [ 0. 1.73205078 0. 0. ] [ 0. 0. -1.00010002 -1. ] [ 0. 0. -0.20001 0. ]] Viewport [ 0. 0. 1080. 800.] 693.0 489.0 Traceback (most recent call last): File "_ctypes/callbacks.c", line 295, in 'calling callback function' File "scene.py", line 294, in keystroke viewport) File "/usr/lib/pymodules/python2.6/OpenGL/lazywrapper.py", line 9, in __call__ return wrapper( baseFunction, *args, **named ) File "/usr/lib/pymodules/python2.6/OpenGL/GLU/projection.py", line 60, in gluUnProject raise ValueError( """Projection failed!""" ) ValueError: Projection failed! Any ideas? Best wishes, Eleftherios |
From: Claudio <cla...@ya...> - 2010-04-01 18:34:01
|
In windows xp sp3, python 2.6.3, pyOpenGL 3.0.1, installed from the .exe in sourceforge 1. For glut32.dll the dll lookup order seems to be i) %windows%\system32 ii) site-packages\OpenGL\DLLS iii) the CWD (current working dir) is irrelevant I'm unsure if this was intended, but seems weird: in worst case you should touch %windows%\system32 and site-packages to ensure the desired glut flavor is loaded (see 3. , concrete case) 2. freeglut.dll is a replacement for glut32.dll that have some extra functions, like glutBitmapString. The glut32.dll provided by PyOpenGL-3.0.1.win32.exe dont have the extra functions, thus you can get a traceback like: [snipped] OpenGL.error.NullFunctionError: Attempt to call an undefined function glutBitmapString, check for bool(glutBitmapString) before calling Should the NullFuncionError handler check if the name belongs to the freeglut exclusive functions and inform 'you need to use freeglut...' ? Wouldn't be better functionality to load a specific glut flavor, like: import OpenGl OpenGL.glut_desired = 'freeglut' ... Then in site-packages\OpenGL\DLLS you can include both flavors: glut32.dll and freeglut.dll, and at run time you bind according to .glut_desired 3. concrete case: a pyweek10 entry, look at this thread if you want the code http://www.pyweek.org/d/3222/#comment-7145 I will reproduce my comment there: """ At first it crashed, made some adjustments and then succeed in windows xp, pyOpenGL 3.0.1 (the latest released in sourceforge), at the start crashes with: D:\tmp\_pyweek10_previa\teetering-towers-2\teetering-tower-2>run_game.py Traceback (most recent call last): File "D:\tmp\_pyweek10_previa\teetering-towers-2\teetering-tower-2\run_game.py ", line 268, in <module> tower.render() File "D:\tmp\_pyweek10_previa\teetering-towers-2\teetering-tower-2\run_game.py ", line 116, in render glutBitmapString(GLUT_BITMAP_HELVETICA_18, "%.1f" % r) File "C:\Python26\lib\site-packages\OpenGL\platform\baseplatform.py", line 336 , in __call__ self.__name__, self.__name__, OpenGL.error.NullFunctionError: Attempt to call an undefined function glutBitmap String, check for bool(glutBitmapString) before calling Workaround: seems that glutBitmapString is not available in the standard glut32.dll shipped in the win binaries for pyOpenGL greping the pyOpenGL sources with the func name suggested that freeglut was needed got freeglut (I choosed the MSVC version) from http://www.transmissionzero.co.uk/software/freeglut-devel/ copied freeglut.dll to site-packages\OpenGL\DLLS renamed to glut32.dll in %windir%\system32 rename glut32.dll to something else Done, it runs (and the text shows) """ Comments: Stashing the freeglut.dll (renamed or not to glut32.dll) at the script directory (thus in the CWD) dont work. If you happen to have glut32.dll in %windows%\system32, it will hide the glut32.dll in site-packages\OpenGL\DLLS So a python app needs to modify system-wide and python-wide settings in order to specify the desired glut variant (!). And if packaging with py2exe or similar, surely my expectation would be that the dlls will come from the narrower environment: CWD, site-packages\pyOpenGL\DLLS, system32. Should at least pyOpenGL try to load the dll first from the CWD ? -- claxo Yahoo! Cocina Encontra las mejores recetas con Yahoo! Cocina. http://ar.mujer.yahoo.com/cocina/ |
From: Łukasz R. <lr...@st...> - 2010-03-26 21:52:01
|
2010/3/26 Mike C. Fletcher <mcf...@vr...>: > ... > If you have some example/test code that uses it, I can look at making it > part of the PyOpenGL distribution (unlikely) or distributing it as a > separate module (more likely). > ... There are some examples shipped with MesaDemos package, located at progs/osdemos. I attached them. Thanks for response and let me know if I can do something to help. Łukasz |
From: Alejandro S. <as...@gm...> - 2010-03-26 18:33:08
|
On Fri, Mar 26, 2010 at 3:24 PM, Mike C. Fletcher <mcf...@vr...>wrote: > > Is there another way to achieve off screen hardware accelerated > > rendering with OpenGL? > IIRC these are the currently-available methods for off-screen rendering > (note, some may require a primary context, I don't do headless rendering > myself): > > * Pixel Buffers (pbuffers) > * Win32 has render-to-device-independent bitmaps and GLX has > render-to-GLX-pixmaps (likely OSX has something similar) > * Aux buffers (have to confirm they don't require a visible primary > context) > * FBOs (have to confirm that these don't require a visible primary > context) > I remember I used to do offscreen rendering (without having to open a window) using Qt 4.3 from C++. What I would do was to create a PixelBuffer instance (iirc) and set that as the current context. Once set up, I would create the QApplication and have it loop forever, with a timer going off every few seconds, calling the rendering code. Hope this helps. Alejandro.- -- Alejandro Segovia Azapian Director Algorithmia http://web.algorithmia.net > > -- > ________________________________________________ > Mike C. Fletcher > Designer, VR Plumber, Coder > http://www.vrplumber.com > http://blog.vrplumber.com > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > PyOpenGL Homepage > http://pyopengl.sourceforge.net > _______________________________________________ > PyOpenGL-Users mailing list > PyO...@li... > https://lists.sourceforge.net/lists/listinfo/pyopengl-users > |
From: Mike C. F. <mcf...@vr...> - 2010-03-26 18:24:17
|
Giuliano Vilela wrote: ... > > Attached is an auto-generated wrapper for the module. I don't > have any > test-code to exercise it, so expect that it is going to break :) . If > you have some example/test code that uses it, I can look at making it > part of the PyOpenGL distribution (unlikely) or distributing it as a > separate module (more likely). The mechanism doesn't allow for > hardware-accelerated rendering, so I don't expect that there will > be all > that many users. > > > Is there another way to achieve off screen hardware accelerated > rendering with OpenGL? IIRC these are the currently-available methods for off-screen rendering (note, some may require a primary context, I don't do headless rendering myself): * Pixel Buffers (pbuffers) * Win32 has render-to-device-independent bitmaps and GLX has render-to-GLX-pixmaps (likely OSX has something similar) * Aux buffers (have to confirm they don't require a visible primary context) * FBOs (have to confirm that these don't require a visible primary context) The OSMesa code definitely has a role, particularly where you don't want to deal with hardware/platform issues, but the trade-off is that it can't access the hardware/platform mechanisms. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Mike C. F. <mcf...@vr...> - 2010-03-26 15:22:07
|
Łukasz Różycki wrote: > Dear list, > > My goal is to render OpenGL scene to image file, without a need to > initiate window. Mesa 3d provide such functionality through OSMesa API > (http://www.mesa3d.org/osmesa.html). However, I would like to do this > using Python. As far as I can tell after reading documentation and > looking into PyOpenGL source code, this extension is not available. > > How difficult would it be to add OSMesa bindings to PyopenGL? I could > try to do it myself, just need some tips what steps are necessary. Is > adding a wrapper as simple as describing function and pointing where > it is? > Attached is an auto-generated wrapper for the module. I don't have any test-code to exercise it, so expect that it is going to break :) . If you have some example/test code that uses it, I can look at making it part of the PyOpenGL distribution (unlikely) or distributing it as a separate module (more likely). The mechanism doesn't allow for hardware-accelerated rendering, so I don't expect that there will be all that many users. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Łukasz R. <lr...@st...> - 2010-03-25 20:57:39
|
Dear list, My goal is to render OpenGL scene to image file, without a need to initiate window. Mesa 3d provide such functionality through OSMesa API (http://www.mesa3d.org/osmesa.html). However, I would like to do this using Python. As far as I can tell after reading documentation and looking into PyOpenGL source code, this extension is not available. How difficult would it be to add OSMesa bindings to PyopenGL? I could try to do it myself, just need some tips what steps are necessary. Is adding a wrapper as simple as describing function and pointing where it is? |
From: Jason H. <Jas...@vo...> - 2010-03-22 18:23:59
|
FWIW, I've used PyOpenGL on Win64 without issue. -Jason -----Original Message----- From: Mike C. Fletcher [mailto:mcf...@vr...] Sent: Sunday, March 21, 2010 4:28 PM To: Derek Escontrias Cc: pyo...@li... Subject: Re: [PyOpenGL-Users] Getting Started With PyOpenGL and OpenGL 3.2 Derek Escontrias wrote: > > > Hello, this is my first message to the mailing list. I am using > Python 2.6, PyOpenGL 3.0.1, Windows Vista 64, > and a NVIDIA GeForce 9800 GTX+ graphics card with the latest > drivers. > Just as a note, I don't have a Win64 box on which to test, so PyOpenGL isn't tested on Win64 at all. It is possible it just doesn't work at all due to some bug or another. > > > I am trying to use PyOpenGL in a forward compatible mode. I am > new to OpenGL 3.x and I am finding > it very difficult to locate information about getting started. I > have been piecemealing information > from the OpenGL specifications; However, I do not believe my > PyOpenGL is setup correctly to be used > in this way. > > My current problem is that I am receiving a NullFunctionError > when attempting to call > glGenBuffers. The documentation states that this method is not > available if the OpenGL version is > less than 1.5. > I don't really use Windows. I believe the NVidia drivers will advertise 2.x level functionality at least, but I know there are some Win32 drivers that advertise 1.x and have everything beyond that as extensions. > > > I am not sure how to hook-up PyOpenGL for use with OpenGL 3.2. > Do I need to compile > PyOpenGL myself? > PyOpenGL isn't compiled. There are a few binary plug-ins that can be compiled to optimize it, but the core is pure-python + ctypes. > > > Is there a flag I can set to indicate which library files to use? > Nope, it will use your platform's OpenGL implementation. > > > Is this a result of an > inappropriate context? > Possible, but extremely unlikely unless you're going out-of-your-way to do something exotic. Default contexts generally have the driver's primary features available. > > > What is the appropriate way to setup a forward compatible > context in PyOpenGL? > I haven't tried recently. There are now entry points that allow you to specify it, but when I was doing it they weren't yet available. You can do: import OpenGL OpenGL.FORWARD_COMPATIBLE_ONLY at the top of your application, but that doesn't change the context, only prevents legacy entry-points from being loaded. > > > I am using wxPython and its GLCanvas that implements a GL > context. I am under the impression that > I need to create my own; However, I was having some difficulty > following guides on using WGL as I found > some of the functionality not present in PyOpenGL. This is in > reference to an AMD whitepaper > <http://developer.amd.com/gpu_assets/GL3_WhitePaper.pdf> in which > I could not locate the ARB create context extension or the PFN > for creating context attributes, where > I think the specification mentioned one would set a forward > compatibility mode if desired. > wxPython has its own mechanism for specifying flags, but I don't see any legacy-free constant when I import it here. You shouldn't *need* a forward-compatible context, generally speaking. That is, the forward-compatible context is just not loading the legacy functions, it doesn't change the behavior of the context itself. The ARB entry points for the various OpenGL 3.x features are all available, so you *should* be able to use those if your card is able to provide them. You can see which extensions are available by calling glGetString(GL_EXTENSIONS). You can see what version of OpenGL is advertised by doing glGetString( GL_VERSION ), note that both of those need to be done with a GL context (window) created. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ PyOpenGL Homepage http://pyopengl.sourceforge.net _______________________________________________ PyOpenGL-Users mailing list PyO...@li... https://lists.sourceforge.net/lists/listinfo/pyopengl-users This message, including any attachments, may contain privileged and/or confidential information. Any distribution or use of this email by anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies. Thank you. |
From: Mike C. F. <mcf...@vr...> - 2010-03-21 21:45:12
|
Derek Escontrias wrote: > > > Hello, this is my first message to the mailing list. I am using > Python 2.6, PyOpenGL 3.0.1, Windows Vista 64, > and a NVIDIA GeForce 9800 GTX+ graphics card with the latest > drivers. > Just as a note, I don't have a Win64 box on which to test, so PyOpenGL isn't tested on Win64 at all. It is possible it just doesn't work at all due to some bug or another. > > > I am trying to use PyOpenGL in a forward compatible mode. I am > new to OpenGL 3.x and I am finding > it very difficult to locate information about getting started. I > have been piecemealing information > from the OpenGL specifications; However, I do not believe my > PyOpenGL is setup correctly to be used > in this way. > > My current problem is that I am receiving a NullFunctionError > when attempting to call > glGenBuffers. The documentation states that this method is not > available if the OpenGL version is > less than 1.5. > I don't really use Windows. I believe the NVidia drivers will advertise 2.x level functionality at least, but I know there are some Win32 drivers that advertise 1.x and have everything beyond that as extensions. > > > I am not sure how to hook-up PyOpenGL for use with OpenGL 3.2. > Do I need to compile > PyOpenGL myself? > PyOpenGL isn't compiled. There are a few binary plug-ins that can be compiled to optimize it, but the core is pure-python + ctypes. > > > Is there a flag I can set to indicate which library files to use? > Nope, it will use your platform's OpenGL implementation. > > > Is this a result of an > inappropriate context? > Possible, but extremely unlikely unless you're going out-of-your-way to do something exotic. Default contexts generally have the driver's primary features available. > > > What is the appropriate way to setup a forward compatible > context in PyOpenGL? > I haven't tried recently. There are now entry points that allow you to specify it, but when I was doing it they weren't yet available. You can do: import OpenGL OpenGL.FORWARD_COMPATIBLE_ONLY at the top of your application, but that doesn't change the context, only prevents legacy entry-points from being loaded. > > > I am using wxPython and its GLCanvas that implements a GL > context. I am under the impression that > I need to create my own; However, I was having some difficulty > following guides on using WGL as I found > some of the functionality not present in PyOpenGL. This is in > reference to an AMD whitepaper > <http://developer.amd.com/gpu_assets/GL3_WhitePaper.pdf> in which > I could not locate the ARB create context extension or the PFN > for creating context attributes, where > I think the specification mentioned one would set a forward > compatibility mode if desired. > wxPython has its own mechanism for specifying flags, but I don't see any legacy-free constant when I import it here. You shouldn't *need* a forward-compatible context, generally speaking. That is, the forward-compatible context is just not loading the legacy functions, it doesn't change the behavior of the context itself. The ARB entry points for the various OpenGL 3.x features are all available, so you *should* be able to use those if your card is able to provide them. You can see which extensions are available by calling glGetString(GL_EXTENSIONS). You can see what version of OpenGL is advertised by doing glGetString( GL_VERSION ), note that both of those need to be done with a GL context (window) created. HTH, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com |
From: Derek E. <d.e...@gm...> - 2010-03-17 23:23:43
|
Hello, this is my first message to the mailing list. I am using Python 2.6, PyOpenGL 3.0.1, Windows Vista 64, and a NVIDIA GeForce 9800 GTX+ graphics card with the latest drivers. I am trying to use PyOpenGL in a forward compatible mode. I am new to OpenGL 3.x and I am finding it very difficult to locate information about getting started. I have been piecemealing information from the OpenGL specifications; However, I do not believe my PyOpenGL is setup correctly to be used in this way. My current problem is that I am receiving a NullFunctionError when attempting to call glGenBuffers. The documentation states that this method is not available if the OpenGL version is less than 1.5. I am not sure how to hook-up PyOpenGL for use with OpenGL 3.2. Do I need to compile PyOpenGL myself? Is there a flag I can set to indicate which library files to use? Is this a result of an inappropriate context? What is the appropriate way to setup a forward compatible context in PyOpenGL? I am using wxPython and its GLCanvas that implements a GL context. I am under the impression that I need to create my own; However, I was having some difficulty following guides on using WGL as I found some of the functionality not present in PyOpenGL. This is in reference to an AMD whitepaper <http://developer.amd.com/gpu_assets/GL3_WhitePaper.pdf> in which I could not locate the ARB create context extension or the PFN for creating context attributes, where I think the specification mentioned one would set a forward compatibility mode if desired. Thanks for any help regarding these issues. Derek |
From: Ian M. <geo...@gm...> - 2010-03-17 18:48:45
|
Doesn't seem to be working though. I tried: mencoder "mf://*.jpg" -mf fps=25 -o output.avi -ovc lavc -lavcopts vcodec=mpeg4:mbd=2:trell on a directory of (valid) .jpgs and the resultant file does not play. |
From: Ian M. <geo...@gm...> - 2010-03-17 18:42:41
|
Hey I figured out mencoder. Just need to add the location of the .exe to the system path environment variable. |
From: Larry C. <cu...@we...> - 2010-03-12 22:42:45
|
Nicolas, Miriam, and Ian, Thanks for your responses. Here's where I am so far... At 04:15 PM 3/10/2010, Ian Mallett wrote: >I've been trying to install mencoder for a while--for some reason, the command line doesn't recognize "mencoder" as a program. I thought I installed it properly. Ideas? >Thanks, >Ian I didn't try mencoder, so i have no info on that. ImageMagick appeared to be primarily oriented toward still manipulation with limited movie file creation features. ffmpeg is very powerful with lots of parameters. i was able to create mpeg files with the standard compression artifacts. but i really need an uncompressed movie. the ones i created with ffmpeg wouldn't play on windows media player or real player. could have been a codec problem or any number of incorrectly set parameters. didn't debug that any further. went back to <http://gromada.com/videomach/videomach.php>VideoMach. contacted their tech support who said my problem was a known bug they were working on. in the meantime, they gave me a workaround and i was able to create uncompressed .avi files totally under python control with this code: arglist = ["slug", "/openfile = c:/images/*.bmp", "/savevideo = c:/movie.avi", "/start", "/exit"] os.spawnv(os.P_WAIT, c:/Program Files/VideoMach/videomach.exe, arglist) assumes all the input .bmp files are in the directory c:/images and are successively numbered like: "any_filename_0001.bmp" hope this may be of help to someone... Larry Cuba |