Segfault on creating billboard


07-12-2005 10:46:51

Just trying pyOgre out, and I get a segfault on creating a billboard.

It looks like this at the moment:

self.lightBbs = self.sceneManager.createBillboardSet('Only create one lightBbs', 0)
self.lightBbs.materialName = 'Light'


# create some dummy lights
print dir(self.lightBbs)
leftLight = self.lightBbs.createBillboard(ogre.Vector3.ZERO)
rightLight = self.lightBbs.createBillboard((1.0, 0.0, 0.0))

Everything is fine until I try to create the first billboard. It fails whatever method I use to specify the position.

Is there a good way to switch pyOgre over to debug Ogre dlls? I think this might be the best way to find what is causing this issue.


07-12-2005 10:52:35

BBS are auto-growing, but there is obviously something going wrong there. If I preallocate 2 billboards in my BBS constructor above, there are no problems.



07-12-2005 11:12:34

Couple of other things. My billboards seem to default to a veeery large size. Without resizing them I need to move the camera out to around 500 down the zAxis to see anything other than the billboard filling the entire screen.

Further, attribute usage like this:
billboard.dimensions = (0.5, 0.5)
doesn't seem to work at all, though thankfully setDimensions does work.


07-12-2005 12:27:06

Hmm. I'll add billboards to my todo list. I'm about to start my finals week at my university, so this week and next week are very busy.

The easiest way to build a debug version of pyogre is probably to download the Ogre VC++ 8 SDK, download the PyOgre source + SWIG and build using the debug version of Ogre. (They accidently left RTTI on for Ogre VC++ 8.)

The only tricky part is linking against the debug version of Python dlls seems to cause problems, though for the life of me I can't figure out why. I generally have to force it to link against a release build of python and debug for everything else.

Any help is greatly appreciated but if you are busy I'll get to work on this as soon as I'm done with finals.

Edit: I opened a bug for this.


07-12-2005 20:07:11

Clay: best of luck for your finals!

At this stage I am really just evaluating PyOgre for a special set of projects I have coming up. Despite the small setbacks, things are looking pretty awesome so far. I am really enjoying getting back to some lovely Python. :)

If I get into using PyOgre hardcore, I'll likely want to become familiar with the PyOgre build process so I can help out. Also, I'll probably take the time to build a debug version as I've certainly found the Ogre assertions useful sometimes when developing with C++.

So, for now I have to let this rest.


07-12-2005 22:30:17

Clay: best of luck for your finals!
Thanks. =)

At this stage I am really just evaluating PyOgre for a special set of projects I have coming up. Despite the small setbacks, things are looking pretty awesome so far. I am really enjoying getting back to some lovely Python.
I'm also working on a project which allows boost style embedding using swig instead of Boost.Python. The project is not yet at an alpha stage (I have not had time to finish what I was working on with it yet). I plan on having an alpha release by early january. The project page is here but in its current state it does not do much other than wrap the basic Python classes in C++.

In my working copy I have code which imports a SWIG generated library and implements a boost style extract<type>(const Object &) for SWIG based python objects (though it will be a few weeks before I commit this to the repos). I'm not quite sure what type of project you are working on but you might find this of interest.

So, for now I have to let this rest.
No worries. If you decide you want to play with pyogre some let me know. I'll give you SVN access if you want it. It's a standing invitation to all previous pyogre maintainers. =)

Nice catch on this billboard thing. It's simply a part of the library I never use, so some problems might have slipped through.


08-12-2005 00:47:32

Clay your embedding project sounds pretty good. I'm looking forward to seeing what you come up with early next year.

Hey I just got pyogre from svn, as I am going to get into building this. There seems to be a file missing: pyogre\ogre\ogre_wrap.cxx

Then again, I really have no idea about building pyogre -- is ogre_wrap.cxx be a swig generated file or something?

Edit: ignore me, I'm actually using swig now. :)


08-12-2005 06:16:41

I've had similiar problems using c++. Maybe I'm missing something here but would not setting the poolSize to 1 (instead of 0) in the BBS constructor resolve the segfault on creating a billboard.

The following code works for me.

skelBBS = self.sceneManager.createBillboardSet('Flare Set', 1)
skelBBS.defaultWidth,skelBBS.defaultHeight=10,10 #default 100,100
skelBBS.materialName = 'Examples/Flare'
for j in range(10):
b = skelBBS.createBillboard((j*spacing,0.0,0.0))


08-12-2005 21:25:32

Dermont: interesting. The Ogre docs do say that the default when growing a BBS is to double the size of the set. Perhaps initial size 0 is a problem for this?

Clay: I've run into some problems and I'm wondering if you have any advice or hints.

I am building a C++ framework for some small Python Ogre apps, and I need 2-way communication between framework and Python. Python needs to get Ogre stuff from C++ (fine), but I am also using my task scheduler in C++, and I need to add Python functions/callbacks to be managed in C++.

With boost, I'd simply have a C++ function that takes a boost::object, and everything would be fine. Do you have any hints or good ideas as to the best way to do this in the SWIG world? I guess this is what your new project above is all about?


08-12-2005 23:24:45

This is one of the things my library set out to solve, yes.

For now, if you need to add Python functions/callbacks there are two things you can do:

Swig's director methods: Subclassing a C++ object in python and calling the C++ method, such as how Ogre/PyOgre handles FrameEvent::frameStarted or FrameEvent::frameEnded.

A python function callback. To do this the "nice" way (such as what I describe here) you will need to dig into the Python/C api. Instead of adding a function with a boost Object class you will need to define the function with a PyObject *, and do all of the incref/decref/etc stuff on it. SWIG understands functions which take in a raw PyObject * (it'll just pass the object in there).

It's all a mess and a pain. This is why I'm working on a library that exposes this functionality with Boost style classes (though without some of the template magic).

Edit: I'm happy to help with any specific questions you run into. I'll post up some example code later, as I'm working on doing Python/C callbacks right now.


09-12-2005 07:00:13

alphageek wrote:

The Ogre docs do say that the default when growing a BBS is to double the size of the set.

Yep, the autoextend=True in the previous code is superfluous.

Perhaps initial size 0 is a problem for this?

Again Yes, I always put this down to setting an initial pool size of 0 meant that the freeBillboards queue was empty and doubling the poolsize(2*0 is always 0) had no effect. Subsequently retrieving and accessing a billboard from the queue caused a crash. I'm probably wrong on this so you probaly want to check on this yourself.