Looking for Bugs in 1.2 Release

It's nearly time for an official 1.2 release and hence I want to ensure that the release is a bug free as possible

If you are aware of any bugs/issues can you please create a ticket [b]here[/b] on sourceforge.

Many Thanks

Andy

Found one!

An issue with some D3D shaders, I made a ticket for it.

glad we're finally using a bug tracker

Finally??

It's been there for over a year and I've been requesting that people use it since the 1.1 release in October 2007 (and via messages on the google list)....

I can only lead the horse to water...................

Andy

I reported the bug and also putting it here for reference:

I believe node.getWorldPosition() is missing, correct me if im wrong, i am very new to ogre. I tried to run the following example article:
http://wiki.python-ogre.org/index.php/3rd_Person_Camera_System_Tutorial
and failed with the missing function

It's an API change in Ogre and has been replaced by _getDerivedPosition..

Have a look at the demos/ogre directory for examples on how this is used..

Andy

I think this is not a bug, maybe API change in caelum module.
I get an error:

self.caelumSystem.getSun ().getSunDirection ()
AttributeError: 'SphereSun' object has no attribute 'getSunDirection'

on Demo_Caelum01.py

I think this is not a bug, maybe API change in caelum module.
I get an error:

self.caelumSystem.getSun ().getSunDirection ()
AttributeError: 'SphereSun' object has no attribute 'getSunDirection'

on Demo_Caelum01.py

Yes, there is an API change.

From what I understood:

Old way:
self.caelumSystem.getSun ().getSunDirection ()

New way:
self.caelumSystem.getSolarSystemModel().getSunDirection(self.caelumSystem.getUniversalClock().getJulianSecond()))


But there is still something weird, as the demo still exits before starting to render.

Hmmn, thanks EvanPMeth, I've put a note about the API change into the tutorial will properly update it when 1.2 becomes current stable.

@andy: is there a complete list of the API changes between 1.1 and 1.2 available somewhere?

Thanks.

Thanks andy. For the short time ive been here, you have sure put a lot of work into python-ogre and helping noobs like myself.

Thanks for the help and dedication to making python-ogre what it is today.

entity.setNormaliseNormals and entity.getNormaliseNormals are both missing (but existed in previous python-ogre versions)

entity.setNormaliseNormals and entity.getNormaliseNormals are both missing (but existed in previous python-ogre versions)

that would seem to be an ogre1.7 thing. setNormaliseNormals works fine with ogre1.4.9 wrapped.

Yes the normalise call has been removed from Ogre.. While it's in Ogre 1.4.x it's not in the SVN and won't be in the 1.6 release which is 'very' close..

Have a look about half way down the announcment post [b]here[/b]

regards
Andy

In ogre 1.7, entities automatically normalizeNormals. I can't currently recall how to get the old functionality, but normalized normals seems to be the more common case than not.

I am curious if the api problem with CEGUI has been fixed? Namely the missing ability to set a name with loadWindowLayout. That was the only bug I found.

Yes on the CEGUI fix - it's in the SVN

Andy

Ahh. Good to know about the normalise call. I guess the change-log explains why the node class is also missing getWorldPosition and getWorldOrientation now. Perhaps I should stop relying on the on-site API document for the most up-to-date interface.

Just to point out, for anyone who hasn't seen it, here is the changelog for 1.6:

http://www.ogre3d.org/wiki/index.php/ShoggothNotes

I realize this is dead simple to work-around at this point by just manually retrieving values by logical index and that it's not relative to 1.2, so I'm not sure if I'd call this a bug as much as a quirk of the existing setup, but...

simple = ogre.Vector3(2,5,6)
print simple[0]
print simple[1]
print simple[2]
# As you'd expect so far, however you don't have to stop there strangely.
print simple[3]
print simple[4]
...
print simple[78]
...
print simple[12893]
Is the jargon generated beyond the vector's three values intended?

Additionally, iterating the vector as a list will give you a nigh endless stream of results due to the above. Attempting to typecast the vector to a list/tuple will crash the program (at least on my simple setup). Lack of methods also prevents you from doing simple[0:2] to get just the first 3 values.

Well Vector3 is a class not a list so while we try and make it as 'pythonic' as possible you do get the exceptions you are seeing..

For example the fact you can access the variables as an array (insead of v.x, v.y, v.z) is because the underlying C++ library has implemented the [] operator. However if you look at the code you'll see:
Real x, y, z;
inline Real& operator [] ( const size_t i )
{
return *(&x+i);
}
So even in C++ you can do a v[2323] and get a value, however only the first 3 are valid.

I may look to implement a __len__ function for the Vector wrappers just to make it behave 'better'

regards
Andy

Glad to hear, Andy.

That's why I wanted to bring it up more as a "quirk" than anything else. It was merely to address that a bit of extra work could be done to bring python-ogre up that extra smidgen (apparently in a more "logical" standing than the original ogre setup)

I've had another look at this and it's not a quick fix as the [] operator implementation is handled within Boost and there isn't an obvious way for it to generically know the size of the 'array' (which in this case is simply 3 'reals' that are defined "together")

This is simply one of those areas that I need to ensure the base Python-Ogre wrapper is as thin as possible, mainly to ensure the long term maintainability of the wrapper etc..

Of course the beauty of Python means you can always do something like (untested, imperfect implementation )
import exceptions as e
import ogre.renderer.OGRE as ogre

class NewVector3 ( ogre.Vector3 ):

def __init__( self, value ):
ogre.Vector3.__init__( self, *value )

def __getitem__ ( self, index ):
if not type ( index ) == type ( 1 ):
raise e.TypeError
if index < 0 or index > 3:
raise e.IndexError
return ogre.Vector3.__getitem__( self, index )

def __getslice__ ( self, start, end ):
if not type ( start ) == type ( end ) == type ( 1 ) :
raise e.TypeError
if (start < 0 or start > 3) or ( end < 0 ):
raise e.IndexError
if end > 3: end = 3
retValues=[]
for x in range ( end - start ):
retValues.append ( ogre.Vector3.__getitem__( self, start + x ) )
return retValues

TestValues=[1.223,5.676,98.43]

v = NewVector3( TestValues )
print v
print v.x, v.y, v.z
print v[0], v[1], v[2]
print v[0:1]
print v[1:2]
print v[1:1]
print v[:]
print v[0:3]
Regards
Andy

Just making sure Navi is going to be in the 1.2 official release.

At the moment it will NOT be in the release -- there isn't anything wrong with the wrapper etc, issue is that I build with MSVC 2008 and the runtimes that are in the Navi SVN are built with MSVC 2005 (specifically nspr4.dll which is the underlying mozilla libraries)..

I can't even get the C++ demos to work (let along Python-Ogre) as I get a "MSVCR80.DLL was not found" error message. And I have the MSVC 2005 runtimes installed correctly so I think the issue is a Micrsoft one in that you can't run multiple MSVC runtimes..

I've looked at building all the support libraries from source and simply dont have the time (it looks like a multiple hour project on it's own)..

If you could build the Navi C++ project with MSVC 8 (express) and supply me the underlying lirbaries then I'm happy to create the Python-Ogre wrapper -- perhaps you could talk to the Navi development team and see if they could help

Regards
Andy

Well, I don't know if there is a possible way to solve this problem as it is a general C++/Python Wrap problem.
The problem that paramters of class methods, that get passed as reference or pointer in c++, act like immutable objects, when overriding the method in python.
It's no actual problem with Ogre itself, but it's a problem with other libraries, that aren't written so OO as Ogre, e.g. Bullet.

paramters of class methods, that get passed as reference or pointer in c++, act like immutable objects
Not sure that's always the case The wrapper generation auto-magically looks for cases where references are passed and "handles" these..

Now it's more than possible that I've missed some in the bullet library. Could you send through an example where you see this behaviour and I'll take a further look..

Andy

class OgreMotionState(bullet.btMotionState):
def __init__(self, initalPosition):
bullet.btMotionState.__init__(self)
self.Pos=initalPosition
self.Position=Vector3()
self.Quaternion=Quaternion()
def getWorldTransform(self, WorldTrans):
WorldTrans=self.Pos
def setWorldTransform(self, WorldTrans):
self.Position=Vector3(WorldTrans.getOrigin().x(),WorldTrans.getOrigin().y(),WorldTrans.getOrigin().z())
self.Quaternion=Quaternion(WorldTrans.getRotation().w(),WorldTrans.getRotation().x(),WorldTrans.getRotation().y(),WorldTrans.getRotation().z())
Well, the problem is in getWorldTransform(self, WorldTrans).
WorldTrans is handeld as an immutable object, so WorldTrans is still an identity btTransform after calling getWorldTransform, even though you passed a nonidentity transform in the constructor.
There is an workaround by deriving from btDefaultMotionState, but that's not the way it is ought to be done.
If I stumble over more of those today, I'll post them here.

OK so things are working properly, just not necessarly in an obvious way... Your code needs to be something like:
def getWorldTransform(self, WorldTrans):
WorldTrans.setOrigin(self.Pos.getOrigin())
WorldTrans.setBasis(self.Pos.getBasis())

Python-Ogre is in fact passing you WorldTrans as a reference, and hence changes to it do work correctly -- however if you do the following:
WorldTrans = self.Pos
you are telling Python to create a brand new 'variable' that points to self.Pos. Where as what you "really" want is to modify the internal value of WorldTrans you were passed, hence you need to do the setOrigin and setBasis..

Hope this makes sense

regards
Andy

Ok, I understand. Glad to here.

Just want to make sure, that bullet.btCollisionDispatcher.setNearCallback gets wrapped in next release. It should be in 2.69, but is not wrapped if I'm not completley mistaken.
I'm not sure about this, but could it be the case that btHeightFieldTerrainShape isn't wrapped either?

If you could build the Navi C++ project with MSVC 8 (express) and supply me the underlying lirbaries then I'm happy to create the Python-Ogre wrapper -- perhaps you could talk to the Navi development team and see if they could help


It appears the Navi folks are using MSVC 8, at least according to http://navi.agelessanime.com/wiki/index.php/Get_NaviLibrary! (note that the ! at the end is part of the URL).

I think he meant 2008 not 8 navi is compiled under msvc 8 and python-ogre works with msvc 9

I think he meant 2008 not 8 navi is compiled under msvc 8 and python-ogre works with msvc 9

Ah, that makes sense.

In any case, I've heard that the person working on Navi is going to be moving from the Gecko engine (used in Firefox) to the Webkit engine (used in Safari, iPhone, Android, Chrome, Adobe AIR etc). So down the road it might make sense to take a fresh look at wrapping Navi.

Thats the first i've heard of that. Thats good to know i just hope someday it makes it to python-ogre, so i can incorporate it in my program