Problems using DataStreamPtr


28-01-2009 08:50:33

Has something changed with the code generation and usage of SharedPtrs?. For example using the latest svn version of python ogre running

File "", line 60, in _createScene
ogre.MaterialManager.getSingleton().parseScript( dataptr, "General" )
Boost.Python.ArgumentError: Python argument types in
MaterialManager.parseScript(MaterialManager, MemoryDataStream, str)
did not match C++ signature:
parseScript(struct MaterialManager_wrapper {lvalue}, class Ogre::SharedPtr<c
lass Ogre::DataStream> {lvalue} stream, class std::basic_string<char,struct std:
:char_traits<char>,class std::allocator<char> > groupName)
parseScript(class Ogre::MaterialManager {lvalue}, class Ogre::SharedPtr<clas
s Ogre::DataStream> {lvalue} stream, class std::basic_string<char,struct std::ch
ar_traits<char>,class std::allocator<char> > groupName)


28-01-2009 13:42:42

Are you seeing the problem show up anywhere else? Looks like 1.6.0 has the same behavior so I'm not certain if the problem is actually with Python-Ogre or Ogre??

I'm assuming that the test did once work (:)) so i'll look into it further -- however don't believe that sharedptr's are implicitly broken..



28-01-2009 15:30:21

Wasn't suggesting sharedptr's were implicitly broken. It appears to be a problem with *DataStreamPtrs. Pretty sure this worked for 1.4.*, maybe not.

The following works fine:

m = ogre.MaterialSerializer()
mat = ogre.MaterialManager.getSingleton().getByName('Examples/RustySteel')
m.exportMaterial(mat, "TEST.MAT")

The following nonsense code doesn't:

d = ogre.DataStream()
mesh = ogre.Mesh(ogre.MeshManager.getSingletonPtr(), "Nonsense", 0, ogre.ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME)
mesh = meshSerializer.importMesh(d, mesh)

I don't think this is a problem with ogre you can check the xmlconverter source. Anyway this is an example of the problem using the meshSerializer( without a DataStreamPtr which obviously doesn't exist in python ogre).

import sys
import os
import PythonOgreConfig

import ogre.renderer.OGRE as ogre
import SampleFramework as sf
import ctypes, math, random

def testLoadMesh(meshSerializer, mesh_name):
f = file(os.path.join("../media/models", mesh_name), 'rb')
fileString =
memBuffer = ctypes.create_string_buffer( fileString )
memstream = ogre.MemoryDataStream ( ogre.CastVoidPtr(ctypes.addressof (memBuffer )), len (fileString) + 1 ) ##+1??

print dir(memstream)
print len (memBuffer)
print type(memstream)

mesh = ogre.Mesh(ogre.MeshManager.getSingletonPtr(), mesh_name, 0, ogre.ResourceGroupManager.DEFAULT_RESOURCE_GROUP_NAME)
mesh = meshSerializer.importMesh(memstream, mesh)
print "Load Mesh Num Sub Meshes %d", mesh.numSubMeshes
del mesh

##--------- Main Content -----------------------------

logMgr = ogre.LogManager()
logMgr.createLog('Test', False)
rgm = ogre.ResourceGroupManager()
mth = ogre.Math()
meshMgr = ogre.MeshManager()
matMgr = ogre.MaterialManager()
skelMgr = ogre.SkeletonManager()
meshSerializer = ogre.MeshSerializer()
skeletonSerializer = ogre.SkeletonSerializer()
bufferManager = ogre.DefaultHardwareBufferManager()# needed because we don't have a rendersystem

## import mesh
testLoadMesh(meshSerializer, 'ogreHead.mesh')

##--------- cleanup -----------------------------
del skeletonSerializer
del meshSerializer
del skelMgr
del matMgr
del meshMgr
del bufferManager
del mth
del rgm
del logMgr


01-02-2009 05:48:36

Found the problem -- I'd was returning from Fix_Ref_Not_Const in without actually doing anything !! Looks like I introduced the problem :oops: back in October when I was working on functional transformation stuff for renderQueueListener etc.. Guess it's time to convert my 'tests' directory to unittests......

The problem is that in the Ogre code none of the 'DataStream' references are defined as 'const'. All (I believe) other functions that use SharedPtrs are specifying them as const.

When Python-Ogre looks to do an implicit conversion to a sharedptr the 'return' pointer is a const and it does a signature check looking for const (which it doesn't find on the DataStream functions such as 'parseScript')

I'm not sure if Boost had it's signature detection 'improved' and/or gccxml changed however now that I understand the problem I'll see what I can do about it....