[SOLVED] 1.0 RC2 renderOneFrame() issue

Brad

10-06-2007 17:08:59

I updated to 1.0 RC2 of python-ogre this morning after doing a clean swipe of my files. I was thrilled that getVertices() methods had been added since I'd actually been working on implementing edge extrusion techniques and needed such methods available -- my python-ogre implementation of the getMeshInformation() function had sadly hit a brick wall.

Appreciative as I was of the new additions, I found that all of my personal sandbox files seemed to break after the upgrade. After some tracing, I located the problem to the root.renderOneFrame(), which seems to be causing a segmentation fault.

I'll go ahead and submit a ticket now just in the event this is a severe issue.

andy

11-06-2007 05:11:38

This doesn't appear to be an obvious rednerOneFrame issue as adding :
def go(self):
"Starts the rendering loop."
if not self._setUp():
return
while self.root.renderOneFrame():
pass
To any of the demos works OK..

Let's move this to the Ticket system and resolve it there

Cheers
Andy

Brad

11-06-2007 17:55:30

Ticket response. Posted here for archival and solution purposes.

Alright. I stripped down one my working examples to bare essentials for ease of testing. No renderWindow, sceneManager, camera, viewport, etc. are created thus you will get memory artifacts, but the code below does illustrate my point. The code below works properly in 1.0 RC1c, yet crashes in 1.0 RC2b.

After your establishment that you had renderOneFrame() working properly in with your sampleFramework, I had assumed it might be my SDL windowHandler creation process (even though it worked before). After testing and breaking down the core of my demo and subsequent engine module for ogre, it would seem that the issue does persist with an ogre generated window also.

Have a test.
import ogre.renderer.OGRE as ogre
class program:
def __init__(self):
self.root = ogre.Root("ogre/plugin.cfg","ogre/config.cfg","ogre.txt")
self.root.showConfigDialog()
self.root.initialise(True)
main = program()
while True:
main.root.renderOneFrame()

Be careful of course as there is no input, timer, or otherwise hindering mechanism. This example is just a brute way of showing that renderOneFrame() or my creation scheme (which has worked fine before in pyOgre and earlier python-Ogre version) seems to be at fault.

Here's where the 1.0 RC2b log breaks :

11:36:05: *** Starting Win32GL Subsystem ***
11:36:05: GLRenderSystem::createRenderWindow "OGRE Render Window", 800x600 windowed miscParams: FSAA=0 colourDepth=32 vsync=false


While older revisions continue properly :

11:18:46: *** Starting Win32GL Subsystem ***
11:18:46: GLRenderSystem::createRenderWindow "OGRE Render Window", 800x600 windowed miscParams: FSAA=0 colourDepth=32 vsync=false
11:18:46: Created Win32Window 'OGRE Render Window' : 800x600, 32bpp


Again, of course, the crashing issue is present whether or not I establish my own render Window and complete Ogre environment or not.

andy

12-06-2007 00:21:11

The sample code you sent me works fine, however as you are using your own "sandbox" I suspect you didn't copy the RC2 plugins across to your sandbox plugins directory..

In any release of Python-Ogre the plugins are specifically linked to the release..

Cheers
Andy

Brad

12-06-2007 01:50:01

How careless of me. I'm still adjusting to the differences between pyOgre and python-Ogre -- one being that the plugins for Ogre remain in the package folder nested within Python's lib folder on pyOgre while they must be duplicated on a per-project basis for python-ogre. Perhaps centralizing this could be an option.

Anyhow. Clearly my own mistake. Sorry for the hassle with the ticket and thread and I thank for the quick response.

andy

12-06-2007 03:51:20

Great to hear it's fixed..

I'm not sure if there is a clean way to resolve the plugins issue - we had discussed some form of checking upon load but didn't come up with a working solution (ie if it's a wrong "enough" version that the DLL doesn't load then what do you do - and do you force this in the ogre module load, or perhaps as an overload on creating root?)

Cheers

Andy

saladin

12-06-2007 12:05:27

How careless of me. I'm still adjusting to the differences between pyOgre and python-Ogre -- one being that the plugins for Ogre remain in the package folder nested within Python's lib folder on pyOgre while they must be duplicated on a per-project basis for python-ogre. Perhaps centralizing this could be an option.

Anyhow. Clearly my own mistake. Sorry for the hassle with the ticket and thread and I thank for the quick response.


That makes the two of us... I made the same mistake and thought my project just 'big red bussed' on RC2. duhh~~~