[not solved] Python-Ogre problems

jacmoe

13-04-2007 23:36:17

I decided to learn Python - and I couldn't think of a better way than using Python-Ogre! :)

Or so I thought ... :(

I've tried to get O-P for both Python 2.4 and 2.5 - no dice.

Then I realised that the downloads listed on the O-P wiki is out-of-date, and got the latest OP-RC.

My drivers are up-to-date - everything works flawlessly in my main Ogre environment.
I've got 2 GBs of RAM, and a AMD x62 x2 processor.
My graphics card is an ATI Radion X1650.

The problem is:

PO starts up, parses the configuration files, fills up RAM rapidly (over 4 GB worth), and then dies.
The death is slightly different, depending on which rendersystem I choose: OpenGL dies with an unknown C++ expection error, while Direct3D dies from a memory error condition.

Strange.

Am I the only one experiencing this? :o

I am not really keen on going through the process of building everything from scratch ...

If everything else fails: where can I get the latest pyOgre?

Let me know if I should post more information. :wink:

griminventions

14-04-2007 03:21:17

Weird! I've never had a problem like that.

Did you get the 0.9 release from http://www.python-ogre.org/wiki/DownloadsPage?

Game_Ender

14-04-2007 15:23:30

Python-Ogre dev here, I do mostly the linux side but have been doing some testing on windows lately. Sorry the download page was a little slow to be updated but it is now up to date. The installer can't make it any simpler and it has worked on both windows machines I have tried it on. I wish you luck and report any more error you have here.

jacmoe

14-04-2007 16:06:40

The installation was dead simple, thanks! :)

But it does not work.

I will try and fire up a python debugger to see exactly where it barfs ..

If everything else fails, I'll build it from source.

Any AMD64x2 issues with Python, Boost?

Game_Ender

14-04-2007 16:52:17

Boost.Python is not thread safe, but none of the demos use multithreading. Do you have any Ogre libraries on your system path? Can you post the Ogre.log output? Did you run the demos from the console so you can see the output before it disappears?

jacmoe

14-04-2007 17:35:12

I get three Python warnings firstly:
C:\Python25\lib\site-packages\ogre\renderer\OGRE\__init__.py:6: RuntimeWarning: to-Python converter for struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > already registered; second conversion method ignored.
from _ogre_ import *
C:\Python25\lib\site-packages\ogre\io\OIS\__init__.py:1: RuntimeWarning: to-Python converter for class std::multimap<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >,struct std::less<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > >,class std::allocator<struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > > > already registered; second conversion method ignored.
from _ois_ import *
C:\Python25\lib\site-packages\ogre\io\OIS\__init__.py:1: RuntimeWarning: to-Python converter for struct std::pair<class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const ,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > > already registered; second conversion method ignored.
from _ois_ import *


They can probably be ignored?

Then later on:
Parsing script Examples.program
High-level program Ogre/HardwareSkinningTwoWeightsCg encountered an error during loading and is thus not supported.
Parsing script StdQuad_vp.program

That can probably be ignored as well ...

Then, it dies differently depending on which rendersystem I choose.

This is the death message when running it through Direct3D:
Finished parsing scripts for resource group Internal

1

1

22

23
Traceback (most recent call last):
File "D:/PythonOgre/demos/ogre/Demo_Bezier.py", line 247, in <module>
application.go()
File "C:\Python25\lib\site-packages\ogre\renderer\OGRE\sf_OIS.py", line 60, in go
if not self._setUp():
File "C:\Python25\lib\site-packages\ogre\renderer\OGRE\sf_OIS.py", line 87, in _setUp
self._createScene()
File "D:/PythonOgre/demos/ogre/Demo_Bezier.py", line 212, in _createScene
ogre.ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME)
MemoryError
Unregistering ResourceManager for type BspLevel
*-*-* OGRE Shutdown


This is when using the OpenGL rendersystem:
GLSL compiling: InstancingShadowCasterGLSL
GLSL compiled : InstancingShadowCasterGLSL
GLSL compiling: CrowdGLSL
Traceback (most recent call last):
File "D:/PythonOgre/demos/ogre/Demo_Bezier.py", line 247, in <module>
application.go()
File "C:\Python25\lib\site-packages\ogre\renderer\OGRE\sf_OIS.py", line 60, in go
if not self._setUp():
File "C:\Python25\lib\site-packages\ogre\renderer\OGRE\sf_OIS.py", line 85, in _setUp
self._loadResources()
File "C:\Python25\lib\site-packages\ogre\renderer\OGRE\sf_OIS.py", line 117, in _loadResources
ogre.ResourceGroupManager.getSingleton().initialiseAllResourceGroups()
RuntimeError: unidentifiable C++ exception
Exception exceptions.NameError: "global name 'pVert' is not defined" in <bound method BezierApplication.__del__ of <__main__.BezierApplication object at 0x01627F50>> ignored

It gets much farther than D3D, but eventually dies.
The error message here is a bit more *enlightening* - I think.. :)

D3D collects memory, OpenGL does not.
Weird. :wink:

jacmoe

14-04-2007 17:39:25

D3D shuts down cleanly, OpenGL does not (it triggers a JIT debug prompt, then exits).

jacmoe

14-04-2007 22:07:56

Bugger.. Python 2.5 is built with VC7.1, which basically means that I need to build Python from source .. :?
:evil:

andy

15-04-2007 00:48:31

Do you have these problems with all the demos (some implement very different functionality - try Demo_Smoke)? Do some fail in different ways or is it fairly consistant.

Does it make a difference if you run it from the command line instead of from the windows start menu (can't imagine why - just a thought)

What about selecting non-windowed mode vs windowed-mode in the renderer?

Currently Python-Ogre under windows only compiles with MSVC 7.1 -- It 'should' be ok with VS2005, however there are currently some limitations with GCC_XML that may cause an issue etc (it's on my todo list to convert to VC2005...)

Cheers
Andy

Game_Ender

15-04-2007 00:55:42

Were you trying to use Python-Ogre with your own VC8 Ogre binaries? I don't think Python builds out of the box with VC8 which is why its built for VC7.1. So you are going to have some difficulty with that, leave a post of the google group, I think some users have had success.

jacmoe

15-04-2007 01:28:20

My main Ogre environment works OK, in all rendersystems and all modes.

I downloaded the Python-Ogre distribution and ran the bezier demo, for both rendersystems - only in windowed mode (pretty difficult to debug in full screen mode :P ).

I managed to build Python with VC8 (after a small patch), and could probably have carried on with the extensions which does not build out of the box, but gave up.
And installed VC7.1 - so now I've got two Visual Studios.

I am pretty sure I am not mixing Ogre dlls or Python's.

Ran the demos both by double-clicking and opening a cmd shell - didn't try the Start - Run option.

My VC8 Ogre binaries are safely tucked away in my ogrenew/samples/common/bin folders, so don't worry. :wink:

Pretty strange.. :roll:

Game_Ender

15-04-2007 01:35:18

Do you have the DLL dependency checking tool? You should check all the Python-Ogre dll in the python site packages directory to make sure they are pulling in the right libraries.

EDIT: Dependency Walker its called

jacmoe

15-04-2007 02:31:41

Only the OpenGL rendersystem allows me to get an actual error message.
It's a classic: The instruction at "0x7c910f29" referenced the memory at "0x00000000". The memory could not be read.
Smells like an unitialised pointer.
But why?

And it's pretty strange that D3D piles up memory, and then dies gracefully, without any exceptions thrown..

Is my system cursed? :)

Anyway: I'll run the dependency tool against the dlls in the site-packages folder.

jacmoe

15-04-2007 03:04:15

You won't believe this ... :)

I ran the Ogre_Python OgreNewt demos - and they all ran flawlessly, in both OpenGL and D3D.
Pretty impressive framerates! :D

Now I just have to figure out what the difference is between those demos and the rest.
I tried each and every demo: ogre, cegui, ode, ogreode, ogreal, ..
Each one featuring a crash no matter what I do.

Well.. One step closer to Ogre_Python happiness for me. :wink:

jacmoe

15-04-2007 03:11:47

OK. So I commented out FileSystem=../media/materials/programs in resources.cfg and the ogre demos runs! :)

Pretty strange, considering that my system doesn't die when using stock c++-powered Ogre.. :?

But, I can finally do some Ogre_Python programming! :twisted:

jacmoe

15-04-2007 03:25:41

I solved the problem!! :D :lol: :D

Turned out to be an ATI issue, which is fixed in the main Ogre branch.

Replacing the contents of python_ogre/demos/media/materials/programs with the Ogre equivalent did the trick! :)

Looks like you need to update your media likewise to prevent those issues from happening.

andy

15-04-2007 05:54:21

Thanks for the work in finding the problem -- glad it wasn't a Python-Ogre bug, sorry for the disconnect on the media files :oops:

Turns out I'd copied across the media from the Ogre 1.4 release but hadn't completly deleted the old files first - fixed in the SVN and will be fixed in the next binary release.

Cheers

Andy

jacmoe

22-04-2007 12:48:42

Looks like the problem arose again when I upgraded to Vista ... :?

Odd thing.. The regular Ogre is running fine, using the same set of media, still Python-Ogre barfs if I do not comment out the materials/programs section in resources.cfg .. :o

Will investigate further ..

jacmoe

22-04-2007 15:16:23

I think it might have something to do with CG, but I am not sure.
Will dig into it when I get the time to do so.. :wink: