Are you running Ubuntu Hardy? - python-ogre debs away!
Tim Ansell
I have finally gotten around to doing some more work on the
debian/ubuntu packages.
Now I need testers! Currently I only have packages for ubuntu hardy
i386, but I hope to add support for gusty and debian unstable (both i386
and amd64!). I will also soon push code to the svn repository which lets
you easily build your own debs too.
Add the following repository to your source list,
deb http://packages.thousandparsec.net/ubuntu hardy universe
Then just do an
apt-get install python-ogre
Life has never been this easy before!
The following modules are supported,
ois, cegui, ogre (core modules)
noise, betagui, cadunetree, caelum, et, plib, ogreforests, ogreal,
watermesh (extra modules)
I have no idea what most of these modules do, so I'm not sure they all
work. I will add the demo modules sometime in the near future.
Tim 'Mithro' Ansell
Lakin Wecker
I'm installing them right now.
Lakin
Tim Ansell
> Right on! Thanks for doing this. I'm sure it will really be appreciated.
>
> I'm installing them right now.
I appreciate any feedback, bug reports, etc.
Tim 'Mithro' Ansell
> Lakin
>
<snip>
Jimjamjahaa
plugin path in plugins.cfg to /usr/lib/OGRE/ and it manages to load a
bit but then there appears to be a missing one
[code]Loading library /usr/lib/OGRE/Plugin_CgProgramManager.so
OGRE EXCEPTION(7:): Could not load dynamic library /usr/lib/OGRE/
Plugin_CgProgramManager.so. System Error: /usr/lib/OGRE/
Plugin_CgProgramManager.so: cannot open shared object file: No such
file or directory in DynLib::load at OgreDynLib.cpp (line 80)[/code]
is it me doing something wrong or is there something not right with
the .deb?
Ivan Vucica
Does the file:
/usr/lib/OGRE/Plugin_CgProgramManager.so
exist?
@Tim:
Thanks for this packaging! I intended to do Debian packaging at some
point, but it never got around. I hope you'll port it to Debian
Lenny/Sid soon. In the meantime, when I get hold of an Ubuntu machine
I'll try it.
--
Regards,
Ivan Vučica
OBJECT Networks :: www.objectnetworks.net
Cateia Games :: www.cateia.com
Krešimir Špes
Ivan Vucica
I don't know how to debug this, so here's just the installation log.
Note, the possible conflict may ONLY come from previous attempted
installation of Python-Ogre from source, although I doubt this (unless
the Wiki instructions install system wide binaries? :P)
ivucica@riki:~/development/pygccxml$ sudo apt-get install python-ogre
[sudo] password for ivucica:
Reading package lists... Done
Building dependency tree
Reading state information... Done
python-ogre is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded.
1 not fully installed or removed.
After this operation, 0B of additional disk space will be used.
Setting up python-ogre (0.0.0-1) ...
pycentral: pycentral pkginstall: not overwriting local files
pycentral pkginstall: not overwriting local files
dpkg: error processing python-ogre (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
python-ogre
E: Sub-process /usr/bin/dpkg returned an error code (1)
--
Tim Ansell
> Thanks for this packaging! I intended to do Debian packaging at some
> point, but it never got around. I hope you'll port it to Debian
> Lenny/Sid soon. In the meantime, when I get hold of an Ubuntu machine
> I'll try it.
>
I don't have a lenny/sid machine available to build on. I have however
pushed the code which I used to generate these debs into the Python-ogre
repository (thank Andy for giving me access).
You should be able to produce debs for Lenny/Sid by doing the following,
1. Checking out python-ogre "svn co
https://python-ogre.svn.sourceforge.net/svnroot/python-ogre/trunk/python-ogre"
2. Running the prereq script "./python-ogre/scripts/00-PreReqs.sh"
3. Running the buildeb script "./python-ogre/scripts/build-deb.sh"
*WARNING*: The scripts are very fragile, do not attempt this unless you
know what you are doing!!!!!! I am working on making this easier for the
general user.
Hope this helps,
Tim 'Mithro' Ansell
Tim Ansell
> Hi,
>
> I don't know how to debug this, so here's just the installation log.
> Note, the possible conflict may ONLY come from previous attempted
> installation of Python-Ogre from source, although I doubt this (unless
> the Wiki instructions install system wide binaries? :P)
>
> ivucica@riki:~/development/pygccxml$ sudo apt-get install python-ogre
> [sudo] password for ivucica:
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> python-ogre is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 59 not upgraded.
> 1 not fully installed or removed.
> After this operation, 0B of additional disk space will be used.
> Setting up python-ogre (0.0.0-1) ...
> pycentral: pycentral pkginstall: not overwriting local files
> pycentral pkginstall: not overwriting local files
> dpkg: error processing python-ogre (--configure):
> subprocess post-installation script returned error exit status 1
> Errors were encountered while processing:
> python-ogre
> E: Sub-process /usr/bin/dpkg returned an error code (1)
>
Do you have a previous version of python-ogre installed (IE from
building the development version yourself)? If so you will need to
remove it by hand.
Pycentral is complaining that it will overwrite files which already
exist.
Are you installing these on Ubuntu Hardy (or trying to install on
debian)? There are differences in pycentral that will make it
impossible.
Tim 'Mithro' Ansell
Tim Ansell
> which ogre version is used? 1.4.x or 1.7?
I am currently only building the "stable" version of python-ogre (IE the
one built against 1.4.x).
I will look into the "unstable" version once I get some more time.
Tim 'Mithro' Ansell
Tim Ansell
> i just installed it, tryin to get some demos working. i replaced the
> plugin path in plugins.cfg to /usr/lib/OGRE/ and it manages to load a
> bit but then there appears to be a missing one
You should remove plugins.cfg and link /etc/OGRE/plugins.cfg to the
local directory (IE the command you need to run is "ln
-s /etc/OGRE/plugins.cfg plugins.cfg").
> [code]Loading library /usr/lib/OGRE/Plugin_CgProgramManager.so
> OGRE EXCEPTION(7:): Could not load dynamic library /usr/lib/OGRE/
> Plugin_CgProgramManager.so. System Error: /usr/lib/OGRE/
> Plugin_CgProgramManager.so: cannot open shared object file: No such
> file or directory in DynLib::load at OgreDynLib.cpp (line 80)[/code]
The CgProgramManager is not part of the ogre3d Ubuntu ships. See what
you have to do above. I hope to create a python-ogre-demos package in
the near future.
> is it me doing something wrong or is there something not right with
> the .deb?
Nope the deb works fine.
>
<snip>
Tim 'Mithro' Ansell
Ivan Vucica
> Do you have a previous version of python-ogre installed (IE from
> building the development version yourself)? If so you will need to
> remove it by hand.
>
> Pycentral is complaining that it will overwrite files which already
> exist.
>
> Are you installing these on Ubuntu Hardy (or trying to install on
> debian)? There are differences in pycentral that will make it
> impossible.
It's on Ubuntu Hardy on company's PC :)
Is it possible to make Pycentral print out exactly WHICH file is it
attempting to overwrite? DPKG usually prints that out when it hits a
file replacement error, so can you make Pycentral do the same in this
postinstall config step?
Tim Ansell
> It's on Ubuntu Hardy on company's PC :)
Has this machine had python ogre installed at any time in the past?
> Is it possible to make Pycentral print out exactly WHICH file is it
> attempting to overwrite? DPKG usually prints that out when it hits a
> file replacement error, so can you make Pycentral do the same in this
> postinstall config step?
I have no idea :/ An strace or ltrace might give us an idea.
I'm assuming it is one of the files under
/usr/lib/python2.5/site-packages/ogre/
That directory should not exist until after you install the python-ogre.
Tim 'Mithro' Ansell
Ivan Vucica
> Has this machine had python ogre installed at any time in the past?
Only as described on the wiki.
I don't _think_ it was globally installed, but I can't remember what
kind of junk I did over a month ago.
> I have no idea :/ An strace or ltrace might give us an idea.
No pycentral --help? (I'm currently under Evil OS)
>
> I'm assuming it is one of the files under
> /usr/lib/python2.5/site-packages/ogre/
>
> That directory should not exist until after you install the python-ogre.
Hm; I'll check it out.
Jimjamjahaa
set to "FBO". when that happens i get the following
Registering ResourceManager for type GpuProgram
GLSL support detected
GL: Using GL_EXT_framebuffer_object for rendering to textures (best)
FBO PF_UNKNOWN depth/stencil support: D16S0 D24S0 D32S0
FBO PF_R5G6B5 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_B5G6R5 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_R8G8B8 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_B8G8R8 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_A8R8G8B8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-
D24S8
FBO PF_B8G8R8A8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-
D24S8
FBO PF_A2R10G10B10 depth/stencil support: D0S0 D16S0 D24S0 D32S0
Packed-D24S8
FBO PF_A2B10G10R10 depth/stencil support: D0S0 D16S0 D24S0 D32S0
Packed-D24S8
FBO PF_FLOAT16_RGB depth/stencil support: D0S0 D16S0 D24S0 D32S0
sorry for the mass of text... is there any formatting controls on
google groups?
Tim Ansell
> On Tue, Jul 15, 2008 at 15:35, Tim Ansell <mit...@gmail.com> wrote:
> > Has this machine had python ogre installed at any time in the past?
>
> Only as described on the wiki.
>
> I don't _think_ it was globally installed, but I can't remember what
> kind of junk I did over a month ago.
It is likely that you did and hence python central is refusing to
overwrite these unknown files.
> > I have no idea :/ An strace or ltrace might give us an idea.
>
> No pycentral --help? (I'm currently under Evil OS)
Nothing in there gives any useful information about this problem.
> > I'm assuming it is one of the files under
> > /usr/lib/python2.5/site-packages/ogre/
> >
> > That directory should not exist until after you install the python-ogre.
>
> Hm; I'll check it out.
Tim 'Mithro' Ansell
Tim Ansell
> hi thanks for the tip. it works, but not when "RTT Preferred Mode" is
> set to "FBO". when that happens i get the following
I have no idea what you are saying above. Can you send some code which
produces the problem (or which demo is failing?).
<snip>
Tim 'Mithro' Ansell
dermont
this is a well known bug. There is a workaround in svn and Ogre1.4.9
which rectifies this for nvidia 169.x. I'm not sure what version of
Ogre is in the debian/ubuntu package or if it contains the above
patch.
http://www.ogre3d.org/phpBB2/viewtopic.php?t=38037&postdays=0&postorder=asc&start=0&sid=39235f864d735cd1de8c589b131babdb
Jimjamjahaa
there newer debs available?
On Jul 16, 8:54 am, dermont <dermontg...@gmail.com> wrote:
> >>> I have no idea what you are saying above.
>
> If he is running nvidia 169.x drivers and an older version of Ogre,
> this is a well known bug. There is a workaround in svn and Ogre1.4.9
> which rectifies this for nvidia 169.x. I'm not sure what version of
> Ogre is in the debian/ubuntu package or if it contains the above
> patch.
>
Ivan Vucica
distro, be it debian or ubuntu :)
Ivan Vucica
I have no idea :/ An strace or ltrace might give us an idea.
I'm assuming it is one of the files under
/usr/lib/python2.5/site-packages/ogre/
That directory should not exist until after you install the python-ogre.
Ivan Vucica
finally I have tested this (continuing from what I have posted in the previous mail).
First, here's the output log from company's "big project" developed under Windows:
ivucica@riki:/mnt/winxp/LOCV SVN/trunk$ python main.py
data/texts: loaded 214 texts from 7 files
Traceback (most recent call last):
File "main.py", line 1, in <module>
from src import init, logger
File "/mnt/winxp/SVN/trunk/src/init.py", line 1, in <module>
from project import *
File "/mnt/winxp/SVN/trunk/src/project.py", line 23, in <module>
from src import app, camera, session, localisation, audio, character, jobs, path, ui, actions, dialog
File "/mnt/winxp/SVN/trunk/src/audio.py", line 2, in <module>
import ogre.sound.OgreAL as OgreAL
File "/usr/lib/python2.5/site-packages/ogre/sound/OgreAL/__init__.py", line 6, in <module>
from _ogreal_ import *
ImportError: /usr/lib/python2.5/site-packages/ogre/sound/OgreAL/_ogreal_.so: undefined symbol: _ZN5boost6python8indexing15python_iteratorC1ENS0_3api6objectE
Obviously, OgreAL is not built correctly.
Also I have tried demo smoke and demo onefish from PythonOgre SVN:
ivucica@riki:~/development/python-ogre/demos/ogre$ python ./Demo_OneFish.py
Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
SceneManagerFactory for type 'DefaultSceneManager' registered.
Registering ResourceManager for type Material
Registering ResourceManager for type Mesh
Registering ResourceManager for type Skeleton
MovableObjectFactory for type 'ParticleSystem' registered.
OverlayElementFactory for type Panel registered.
OverlayElementFactory for type BorderPanel registered.
OverlayElementFactory for type TextArea registered.
Registering ResourceManager for type Font
ArchiveFactory for archive type FileSystem registered.
ArchiveFactory for archive type Zip registered.
FreeImage version: 3.9.3
This program uses FreeImage, a free, open source image library supporting all common bitmap formats. See http://freeimage.sourceforge.net for details
Supported formats: bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi
DDS codec registering
Registering ResourceManager for type HighLevelGpuProgram
Registering ResourceManager for type Compositor
MovableObjectFactory for type 'Entity' registered.
MovableObjectFactory for type 'Light' registered.
MovableObjectFactory for type 'BillboardSet' registered.
MovableObjectFactory for type 'ManualObject' registered.
MovableObjectFactory for type 'BillboardChain' registered.
MovableObjectFactory for type 'RibbonTrail' registered.
Loading library /usr/lib/OGRE/RenderSystem_GL.so
Installing plugin: GL RenderSystem
OpenGL Rendering Subsystem created.
Plugin successfully installed
Loading library /usr/lib/OGRE/Plugin_ParticleFX.so
Installing plugin: ParticleFX
Particle Emitter Type 'Point' registered
Particle Emitter Type 'Box' registered
Particle Emitter Type 'Ellipsoid' registered
Particle Emitter Type 'Cylinder' registered
Particle Emitter Type 'Ring' registered
Particle Emitter Type 'HollowEllipsoid' registered
Particle Affector Type 'LinearForce' registered
Particle Affector Type 'ColourFader' registered
Particle Affector Type 'ColourFader2' registered
Particle Affector Type 'ColourImage' registered
Particle Affector Type 'ColourInterpolator' registered
Particle Affector Type 'Scaler' registered
Particle Affector Type 'Rotator' registered
Particle Affector Type 'DirectionRandomiser' registered
Particle Affector Type 'DeflectorPlane' registered
Plugin successfully installed
Loading library /usr/lib/OGRE/Plugin_BSPSceneManager.so
Installing plugin: BSP Scene Manager
Plugin successfully installed
Loading library /usr/lib/OGRE/Plugin_OctreeSceneManager.so
Installing plugin: Octree & Terrain Scene Manager
Plugin successfully installed
Loading library /usr/lib/OGRE/Plugin_EXRCodec.so
EXRCodec initialised
*-*-* OGRE Initialising
*-*-* Version 1.4.5 (Eihort)
Creating resource group Bootstrap
Added resource location '../media/packs/OgreCore.zip' of type 'Zip' to resource group 'Bootstrap'
Added resource location '../media' of type 'FileSystem' to resource group 'General'
Added resource location '../media/fonts' of type 'FileSystem' to resource group 'General'
Added resource location '../media/sounds' of type 'FileSystem' to resource group 'General'
Added resource location '../media/Audio' of type 'FileSystem' to resource group 'General'
Added resource location '../media/materials/programs' of type 'FileSystem' to resource group 'General'
Added resource location '../media/materials/scripts' of type 'FileSystem' to resource group 'General'
Added resource location '../media/materials/textures' of type 'FileSystem' to resource group 'General'
Added resource location '../media/models' of type 'FileSystem' to resource group 'General'
Added resource location '../media/overlays' of type 'FileSystem' to resource group 'General'
Added resource location '../media/particle' of type 'FileSystem' to resource group 'General'
Added resource location '../media/gui' of type 'FileSystem' to resource group 'General'
Added resource location '../media/packs/cubemap.zip' of type 'Zip' to resource group 'General'
Added resource location '../media/packs/cubemapsJS.zip' of type 'Zip' to resource group 'General'
Added resource location '../media/packs/dragon.zip' of type 'Zip' to resource group 'General'
Added resource location '../media/packs/fresneldemo.zip' of type 'Zip' to resource group 'General'
Added resource location '../media/packs/ogretestmap.zip' of type 'Zip' to resource group 'General'
Added resource location '../media/packs/skybox.zip' of type 'Zip' to resource group 'General'
CPU Identifier & Features
-------------------------
* CPU ID: GenuineIntel: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz
* SSE: yes
* SSE2: yes
* SSE3: yes
* MMX: yes
* MMXEXT: yes
* 3DNOW: no
* 3DNOWEXT: no
* CMOV: yes
* TSC: yes
* FPU: yes
* PRO: yes
* HT: no
-------------------------
******************************
*** Starting GLX Subsystem ***
******************************
GLRenderSystem::createRenderWindow "OGRE Render Window", 800x600 windowed miscParams: FSAA=0 title=OGRE Render Window
GLXWindow::create
Parsing miscParams
GLXWindow::create -- Best visual is 36
Error: API mismatch: the NVIDIA kernel module has version 173.14.05,
but this NVIDIA driver component has version 173.14.09. Please make
sure that the kernel module and all NVIDIA driver components
have the same version.
NVIDIA: Direct rendering failed; attempting indirect rendering.
GL_VERSION = 2.1.2 NVIDIA 173.14.05
GL_VENDOR = NVIDIA Corporation
GL_RENDERER = GeForce 9600 GT/PCI/SSE2
GL_EXTENSIONS = GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_vertex_program GL_ARB_window_pos GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_object GL_EXTX_framebuffer_mixed_formats GL_EXT_framebuffer_sRGB 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_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_array 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_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_geometry_shader4 GL_NV_light_max_exponent GL_NV_multisample_coverage GL_NV_multisample_filter_hint GL_NV_packed_depth_stencil GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum
***************************
*** GL Renderer Started ***
***************************
Registering ResourceManager for type GpuProgram
GLSL support detected
GL: Using GL_EXT_framebuffer_object for rendering to textures (best)
FBO PF_UNKNOWN depth/stencil support: D16S0 D24S0 D32S0
FBO PF_A8 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_A4L4 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_BYTE_LA depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_B5G6R5 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_B8G8R8 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_A8R8G8B8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
FBO PF_B8G8R8A8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
FBO PF_A2R10G10B10 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
FBO PF_A2B10G10R10 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
FBO PF_FLOAT16_RGB depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_FLOAT32_RGB depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_FLOAT32_RGBA depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_X8R8G8B8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
FBO PF_X8B8G8R8 depth/stencil support: D0S0 D16S0 D24S0 D32S0 Packed-D24S8
FBO PF_SHORT_RGBA depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_R3G3B2 depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_FLOAT16_R depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_FLOAT32_R depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_FLOAT16_GR depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_FLOAT32_GR depth/stencil support: D0S0 D16S0 D24S0 D32S0
FBO PF_SHORT_RGB depth/stencil support: D0S0 D16S0 D24S0 D32S0
[GL] : Valid FBO targets PF_UNKNOWN PF_L8 PF_A8 PF_A4L4 PF_BYTE_LA PF_R5G6B5 PF_B5G6R5 PF_A1R5G5B5 PF_R8G8B8 PF_B8G8R8 PF_A8R8G8B8 PF_B8G8R8A8 PF_A2R10G10B10 PF_A2B10G10R10 PF_FLOAT16_RGB PF_FLOAT16_RGBA PF_FLOAT32_RGB PF_FLOAT32_RGBA PF_X8R8G8B8 PF_X8B8G8R8 PF_SHORT_RGBA PF_R3G3B2 PF_FLOAT16_R PF_FLOAT32_R PF_FLOAT16_GR PF_FLOAT32_GR PF_SHORT_RGB
RenderSystem capabilities
-------------------------
* Hardware generation of mipmaps: yes
* Texture blending: yes
* Anisotropic texture filtering: yes
* Dot product texture operation: yes
* Cube mapping: yes
* Hardware stencil buffer: yes
- Stencil depth: 8
- Two sided stencil support: yes
- Wrap stencil values: yes
* Hardware vertex / index buffers: yes
* Vertex programs: yes
- Max vertex program version: vp40
* Fragment programs: yes
- Max fragment program version: fp40
* Texture Compression: yes
- DXT: yes
- VTC: yes
* Scissor Rectangle: yes
* Hardware Occlusion Query: yes
* User clip planes: yes
* VET_UBYTE4 vertex element type: yes
* Infinite far plane projection: yes
* Hardware render-to-texture: yes
* Floating point textures: yes
* Non-power-of-two textures: yes
* Volume textures: yes
* Multiple Render Targets: 8
* Point Sprites: yes
* Extended point parameters: yes
* Max Point Size: 63.375
* Vertex texture fetch: yes
- Max vertex textures: 47144
- Vertex textures shared: yes
Registering ResourceManager for type Texture
ResourceBackgroundQueue - threading disabled
Particle Renderer Type 'billboard' registered
OGRE EXCEPTION(7:): Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock at OgreGLHardwareVertexBuffer.cpp (line 126)
*-*-* OGRE Shutdown
Unregistering ResourceManager for type Compositor
Unregistering ResourceManager for type Font
Unregistering ResourceManager for type Skeleton
Unregistering ResourceManager for type Mesh
Unregistering ResourceManager for type HighLevelGpuProgram
EXRCodec deinitialised
Unloading library /usr/lib/OGRE/Plugin_EXRCodec.so
Uninstalling plugin: Octree & Terrain Scene Manager
Plugin successfully uninstalled
Unloading library /usr/lib/OGRE/Plugin_OctreeSceneManager.so
Uninstalling plugin: BSP Scene Manager
Plugin successfully uninstalled
Unloading library /usr/lib/OGRE/Plugin_BSPSceneManager.so
Uninstalling plugin: ParticleFX
Plugin successfully uninstalled
Unloading library /usr/lib/OGRE/Plugin_ParticleFX.so
Uninstalling plugin: GL RenderSystem
Render Target 'OGRE Render Window' Average FPS: 0 Best FPS: 0 Worst FPS: 999
Unregistering ResourceManager for type GpuProgram
******************************
*** Stopping GLX Subsystem ***
******************************
Unregistering ResourceManager for type Texture
Plugin successfully uninstalled
Unloading library /usr/lib/OGRE/RenderSystem_GL.so
Unregistering ResourceManager for type Material
Ok, to help you out, the problem is here:
....
ResourceBackgroundQueue - threading disabled
Particle Renderer Type 'billboard' registered
OGRE EXCEPTION(7:): Vertex Buffer: Out of memory in GLHardwareVertexBuffer::lock at OgreGLHardwareVertexBuffer.cpp (line 126)
*-*-* OGRE Shutdown
Unregistering ResourceManager for type Compositor
Graphics card should be ok, it's an nVidia GeForce 9600 GT:
01:00.0 VGA compatible controller: nVidia Corporation Geforce 9600 GT 512mb (rev a1)
If there's any other test or info I can provide, just tell me. I'm also trying to build PyhonOGRE from SVN, we'll see how it comes out.
dermont
...
but this NVIDIA driver component has version 173.14.09. Please make
sure that the kernel module and all NVIDIA driver components
have the same version.
>
> Graphics card should be ok, it's an nVidia GeForce 9600 GT:
> 01:00.0 VGA compatible controller: nVidia Corporation Geforce 9600 GT 512mb
> (rev a1)
>
> If there's any other test or info I can provide, just tell me. I'm also
> trying to build PyhonOGRE from SVN, we'll see how it comes out.
>
> On Mon, Jul 14, 2008 at 04:01, Tim Ansell <mit...@gmail.com> wrote:
>
> > Hey guys,
>
> > I have finally gotten around to doing some more work on the
> > debian/ubuntu packages.
>
> > Now I need testers! Currently I only have packages for ubuntu hardy
> > i386, but I hope to add support for gusty and debian unstable (both i386
> > and amd64!). I will also soon push code to the svn repository which lets
> > you easily build your own debs too.
>
> > Add the following repository to your source list,
Ivan Vucica
From your log this may be your problem:
...
Error: API mismatch: the NVIDIA kernel module has version 173.14.05,..
but this NVIDIA driver component has version 173.14.09. Please make
sure that the kernel module and all NVIDIA driver components
have the same version.
Tim Ansell
> ivucica@riki:/mnt/winxp/LOCV SVN/trunk$ python main.py
> data/texts: loaded 214 texts from 7 files
> Traceback (most recent call last):
> File "main.py", line 1, in <module>
> from src import init, logger
> File "/mnt/winxp/SVN/trunk/src/init.py", line 1, in <module>
> from project import *
> File "/mnt/winxp/SVN/trunk/src/project.py", line 23, in <module>
> from src import app, camera, session, localisation, audio,
> character, jobs, path, ui, actions, dialog
> File "/mnt/winxp/SVN/trunk/src/audio.py", line 2, in <module>
> import ogre.sound.OgreAL as OgreAL
> File
> "/usr/lib/python2.5/site-packages/ogre/sound/OgreAL/__init__.py", line
> 6, in <module>
> from _ogreal_ import *
> ImportError: /usr/lib/python2.5/site-packages/ogre/sound/OgreAL/_ogreal_.so: undefined symbol: _ZN5boost6python8indexing15python_iteratorC1ENS0_3api6objectE
<snip>
This error is now fixed but I have yet to upload the new debs. I'm still
working on fixing a bunch of other build errors.
Tim 'Mithro' Ansell
>
Stefan Stammberger
I've installed the debs today and they are working great!
Will Ogrenewt ever be part of that package? Or can't they be included
like
the CG package?
Stefan Stammberger
Tim Ansell
> Hi,
>
> I've installed the debs today and they are working great!
> Will Ogrenewt ever be part of that package? Or can't they be included
> like
> the CG package?
Anything which has a "non-free" license (what type of license is
OgreNEWT under) or "non-free" dependency will probably never be included
in the default build of the debs.
You may however be able to build your own package which adds support for
that once I have finished the packaging stuff.
Tim 'Mithro' Ansell
> Stefan Stammberger
<snip>
oranda
pretty well. I had to hack at a few of the demo files to get them to
run, but the actual bindings themselves seemed to be okay. The lack of
the Cg plugin in the default hardy build of OGRE is kind of annoying,
though.
That said, there is one game-stopper issue I found. I can't get the
wxOgreWindow sample to work. It appears that GetHandle() is returning
0. I remember reading that a fix had been made for this on Linux some
time ago, although now I can't find the forum post. Is that fix still
in there?
Also, I was thinking it might be easier to break the python-ogre
package up into a bunch of smaller packages to make them a little
easier to maintain and work with. For example, a python-ogre-core,
python-ogre-ois, python-ogre-theora package, etc. And then a python-
ogre-all super package that is simply dependent on all of the other
packages, for people who really want the whole shebang in one shot.
Most of the other packages in Ubuntu seem to be factored out like
this.
I really appreciate the work you're putting into these packages :).
oranda
The first line from my previous message should read:
Hi, I tried out the ogre portion of these bindings on my hardy box and
they worked
pretty well.
Sorry about that.
Ivan Vucica
Gah, there isn't an edit button on these boards.
That's because Google Groups are actually a mailing list + Usenet hybrid ;)
And neither of those actually support message editing -- Google-hosted boards are just an extension of the Usenet Google Groups :)
I opened the web interface just to sign up, I do all other messaging via my mail client (be it Gmail or any other)
Just my totally off-topic 10 Croatian lipas
(~2 US cents)
TackyParker
on amd64 and got the following message when I tried to reload
repository information:
Failed to fetch http://packages.thousandparsec.net/ubuntu/dists/hardy/universe/binary-amd64/Packages.gz
404 Not Found
I'll resume building from scratch: I found my way past the Boost
1_35_0 problems last night, then ran into some FreeImage compilation
problems before throwing up my hands and going to bed. I'm going to
start again from scratch and take close notes so that I can share my
solutions and have enough info to ask for help also.
Thanks,
Scott
PS first post, hi all!
TackyParker
- I see that my problem looks like the one that Ivan Vucica reported
earlier.
Tim Ansell
Step 1 - Remove everything you have
Step 2 - Create a fresh checkout
cd ~
mkdir development
cd development
svn co https://python-ogre.svn.sourceforge.net/svnroot/python-ogre/trunk/python-ogre python-ogre
Step 3 - Create an empty file in the "python-ogre" directory called
"STABLE"
cd python-ogre
touch STABLE
Step 4 - Continue from Step 2 on the wiki.
I have AMD64 debian/ubuntu packages but they just segfault when running
anything and I've yet to figure out why. It occurs somewhere in Boost
and I have yet to convince boost to build with debug symbols.
Tim
Ivan Vucica
> I have AMD64 debian/ubuntu packages but they just segfault when running
> anything and I've yet to figure out why. It occurs somewhere in Boost
> and I have yet to convince boost to build with debug symbols.
Debug symbols?
If I want full debug information, I remove all references to -strip
and I replace any reference to -g0, -g1, and -g2 with -g3 in the
makefiles. If that's not enough I can catch some bugs in the way I use
STL by breaking binary compatibility with -D_GLIBCXX_DEBUG ; breaking
binary compatibility means that all other C++ libraries and all other
C++ code, in general, has to be built with this option. This turns on
some safeguards which noticeably slow down the code, but helps in
debugging some crashes (helped me on a number of occasions). I'm not
sure how feasible this is since you would need to rebuild a lot of
code, and having debugging information slows down the build process
too (noticeably for some projects, in my case).
Hope at least some of this information helps.
TackyParker
> As a quick suggestion to try the following,
I'll give it a shot. Thanks for the tip.
-
Scott
Andy Miller
TackyParker
Good point. I'm mainly using the forum as a place to store and share
my notes, but if and when I get it working, I'll be happy to post it
to the wiki.
Yesterday evening I was very optimistic as the ogre wrapper compiled
and compiled and compiled, but after installation I got unspecified
exceptions and crashes whenever running the python-ogre demos.
Thanks and regards,
Scott
On Aug 15, 11:42 pm, "Andy Miller" <nzmill...@gmail.com> wrote:
> Scott
>
> Perhaps you should look to create a Wiki article (along with this mailing
> list) on your 64bit experiences instead of using the forums 'messages'.
>
> The forum articles will eventually get old and people don't search them (as
> much as they should) whereas a wiki article is more permanent and could
> serve as a single point of information for Linux 64 bit work...
>
> Regards
>
> Andy
>
Tim Ansell
> Hi Andy,
>
> Good point. I'm mainly using the forum as a place to store and share
> my notes, but if and when I get it working, I'll be happy to post it
> to the wiki.
>
> Yesterday evening I was very optimistic as the ogre wrapper compiled
> and compiled and compiled, but after installation I got unspecified
> exceptions and crashes whenever running the python-ogre demos.
That is the same problem I am having with AMD64 platforms here.
Tim
<snip>
Tim Ansell
> package up into a bunch of smaller packages to make them a little
> easier to maintain and work with. For example, a python-ogre-core,
> python-ogre-ois, python-ogre-theora package, etc. And then a python-
> ogre-all super package that is simply dependent on all of the other
> packages, for people who really want the whole shebang in one shot.
> Most of the other packages in Ubuntu seem to be factored out like
> this.
That is on the todo list, but it's not likely to happen any time soon.
> I really appreciate the work you're putting into these packages :).
I appreciate any support in the form of,
* Hacking on Thousand Parsec - http://www.thousandparsec.net/
* Creating cool Python Ogre games
* Sending something Andy Miller's way.
Tim
dermont
What has this to do with Python Ogre other than the current Linux
build is crippled to support this.
>> Sending something Andy Miller's way.
current windows release is based on the svn version of Ogre. The
current Linux build is pretty much a shambles and based on the above
with so many obvious bugs/memory leaks.
If you expect people to people to contribute you should at least have
some consistency in the STABLE/UNSTABLE builds and allow people to
submit patches via the sourceforge tracker.
On Aug 17, 11:14 pm, Tim Ansell <mit...@gmail.com> wrote:
> > Also, I was thinking it might be easier to break the python-ogre
> > package up into a bunch of smaller packages to make them a little
> > easier to maintain and work with. For example, a python-ogre-core,
> > python-ogre-ois, python-ogre-theora package, etc. And then a python-
> > ogre-all super package that is simply dependent on all of the other
> > packages, for people who really want the whole shebang in one shot.
> > Most of the other packages in Ubuntu seem to be factored out like
> > this.
>
> That is on the todo list, but it's not likely to happen any time soon.
>
> > I really appreciate the work you're putting into these packages :).
>
> I appreciate any support in the form of,
Andy Miller
Did I miss something along the way with the Linux binary build and it being related to 'Thousand Parsec' ?????
Last time I ran the build process on Ubuntu Linux it worked well and created what seem like reliable code. Has the build process changed in a way that I'm not aware of ?
All the patches that have been submitted via the source forge tracker are in the SVN (unless I've screwed up along the way and missed one) and while the current "release candidate" for Windows is indeed built against the Ogre SVN (in anticipation of the 1.6 release) I haven't had any bugs reported against it that would be caused by the underlying Ogre code...
Regards
Andy
Tim Ansell
> >> Hacking on Thousand Parsec
>
> What has this to do with Python Ogre other than the current Linux
> build is crippled to support this.
Thousand Parsec has nothing to do with Python Ogre, hacking on Thousand
Parsec will give me more time to spend working on Python Ogre however.
How is it Python Ogre crippled to support Thousand Parsec?
You welcome to go back to r631 and live there the rest of your life.
> >> Sending something Andy Miller's way.
> Yep, it's not exactly as if others haven't done this already. The
> current windows release is based on the svn version of Ogre.
You can still build Python Ogre on Linux with the latest and greatest
Ogre, Boost and everything. Infact, that is the default option!
There is still the outstanding Boost problem but I have been
concentrating on AMD64 support at the moment.
I have however been working on the older version as it introduces less
complexity when packaging. Once the basics of packaging are done, then
we can more forward to the latest and greatest.
> The
> current Linux build is pretty much a shambles and based on the above
> with so many obvious bugs/memory leaks.
Please report the issues, I have yet to see any obvious bugs or memory
leaks in my testing (but then I only use a small part of Python Ogre and
have a crappy video card).
> If you expect people to people to contribute you should at least have
> some consistency in the STABLE/UNSTABLE builds and allow people to
> submit patches via the sourceforge tracker.
We are working towards that, I only have limited time and a lot of other
responsibilities. In fact, as far as I can see we have applyed all your
patches from the SF tracker as soon as they come in.
Tim 'Mithro' Ansell
<snip>
dermont
and greatest' refer to:
Linux STABLE - 1.4
Linux UNSTABLE - hardwired to version 1.4
Windows STABLE - 1.4
Windows UNSTABLE - 1.7
Windows Binary 1.2RC1 - Ogre 1.7
Windows Binary 1.2RC2 - Ogre 1.6
For at me at least the current UNSTABLE build script on Linux fails
since the multithread version of boost 1.3.5 is built by default. The
build seems to assume that the single threaded version of boost is
being used. The boost-indexing Makefile builds against 1_34_1. Someone
has already supplied a patch on this mailing list.
>> You welcome to go back to r631 and live there the rest of your life.
any changes that Andy may make in code generation. However, since on
Linux, the build script's latest and greatest version of Ogre is
1.4.9 it would be nice to test any patches against that before
submitting.
>>I have however been working on the older version as it introduces less
>> complexity when packaging. Once the basics of packaging are done, then
>> we can more forward to the latest and greatest.
greatest.
>>Please report the issues, I have yet to see any obvious bugs or memory
>> leaks in my testing (but then I only use a small part of Python Ogre and
>> have a crappy video card).
do. Do you have a copy of your unit tests used in testing. Have you
tried running some of the demos with Valgrind?
Tim Ansell
> >> You can still build Python Ogre on Linux with the latest and greatest Ogre, Boost >> and everything. Infact, that is the default option!
>
> Ok, I'll take your word for it. What version of Ogre does the 'latest
> and greatest' refer to:
>
> Linux STABLE - 1.4
This is correct, this is where I'm spending my time at the moment. (As
Ogre 1.4.x is the only "released" and commonly available version.)
> Linux UNSTABLE - hardwired to version 1.4
As far as I know, Linux unstable should be using the same version as
Windows. As I am not currently working on UNSTABLE I'm not sure why this
is incorrect.
> Windows STABLE - 1.4
> Windows UNSTABLE - 1.7
> Windows Binary 1.2RC1 - Ogre 1.7
> Windows Binary 1.2RC2 - Ogre 1.6
I thought Andy was working against Ogre 1.7?
> For at me at least the current UNSTABLE build script on Linux fails
> since the multithread version of boost 1.3.5 is built by default. The
> build seems to assume that the single threaded version of boost is
> being used. The boost-indexing Makefile builds against 1_34_1. Someone
> has already supplied a patch on this mailing list.
I somehow missed this patch. (I got distracted by trying to auto-detect
the boost version). It (well a version) is now committed,
boost_python_index should now build against both boost 1.35 and 1.34
(and possibly even 1.36). It also defaults to the MT version.
> >> You welcome to go back to r631 and live there the rest of your life.
>
> Since I'm building against trunk Ogre1.7 I'm only really interested in
> any changes that Andy may make in code generation. However, since on
> Linux, the build script's latest and greatest version of Ogre is
> 1.4.9 it would be nice to test any patches against that before
> submitting.
Agreed. I would love to be able to run a test suite after each change to
make sure I have not broken anything.
> >>I have however been working on the older version as it introduces less
> >> complexity when packaging. Once the basics of packaging are done, then
> >> we can more forward to the latest and greatest.
>
> Confused, I thought the default option was already the latest and
> greatest.
The default option for Python Ogre is the latest and greatest.
What I was meaning was that when I have finished getting STABLE working
in packages I can then work on doing packages for UNSTABLE.
> >>Please report the issues, I have yet to see any obvious bugs or memory
> >> leaks in my testing (but then I only use a small part of Python Ogre and
> >> have a crappy video card).
>
> Once there is some consistency in the STABLE/UNSTABLE builds I will
> do. Do you have a copy of your unit tests used in testing. Have you
> tried running some of the demos with Valgrind?
Nope, not yet.
It would be very cool to have a test suite which one could run which
after compiling to make sure everything works. I see that Andy and you
have been working on Demos which should be a good start for this!
Tim 'Mithro' Ansell
Nathan Williams
I want to start by saying thanks for the binary, I have been having
trouble building from source (some issues with boost_index & others).
I tried following this:
http://www.ogre3d.org/phpBB2addons/viewtopic.php?p=45858
Which got me further, but I still had issues lastnight (one being my
little eeepc was struggling with only 1/2 a gig of ram!).
I tried this on a small game framework I built under windows, and once
I commented out my OgreNewt code, the game worked fine (minus physics
that is!)
So what I was wondering, is there a simple way for me to build the
missing libraries (ode, ogrenewt etc) by themselves and make a deb, or
at least a local copy of the required .so files etc in the game's
directory?
I'm hoping to make some small games based on python-ogre and I need to
make sure others on linux will be able to simply install python-ogre
from a deb / apt (and extras if needed) so they can play.
dermont
when it has the same functionality as the Windows Binary. One bug that
springs to mind (sorry can't remember how I resolved it) is the
FileInfoList / DataStreamList code doesn't seem to generated,
subsequently:
r =
ogre.ResourceGroupManager.getSingleton().findResourceFileInfo('General','*',
False )
TypeError: No to_python (by-value) converter found for C++ type:
Ogre::SharedPtr<std::vector<Ogre::FileInfo,
std::allocator<Ogre::FileInfo> > >
Anyway I'm all python ogre users appreciate the work that both you and
Andy are undertaking with python ogre. Good luck with the future of
the project.
Tim Ansell
> On Fri, Aug 15, 2008 at 09:22, Tim Ansell <mit...@gmail.com> wrote:
> > I have AMD64 debian/ubuntu packages but they just segfault when running
> > anything and I've yet to figure out why. It occurs somewhere in Boost
> > and I have yet to convince boost to build with debug symbols.
>
> Debug symbols?
Just FYI,
The magic incarnation I wanted was to run bjam with "debug-symbols=on".
This will then build debug symbols in the release binary.
I have submitted patches to Debian and Ubuntu so the next releases of
their libboost-dbg packages should actually include proper debug
symbols!
Tim 'Mithro' Ansell
<snip>