The PyOgre wiki portal

I've been doing some design work on the PyOgre wiki portal: http://www.ogre3d.org/wiki/index.php/PyOgre

I tried to structure it similiarly to the main portal, and I think it looks better than it used to. So what are your opinions on it? Is there anything that is missing, at first glance? Of course there can always be more tutorials, but is there anything else?

And what to do about the 3D OS Pipeline headline? Put in a new article or just link to the image or something?

excellent work !!!

Bernd

Thanks.
Except for the logo (do you like it?), it was mostly a job of looking at other wiki pages and copying stuff. But whatever gets the job done.

Wow. Nice job.

Just read your Introduction to PyOgre guide, Clay. Interesting read.

Especially

SWIG also creates a Ptr class for each C++ class. So the class Entity will have a corresponding EntityPtr, the Node class has a NodePtr class. These are for internal SWIG mechanics, and you should just ignore them. They should never actually be returned from any function or needed as a parameter for any function.

since I've tried using them for doing things (and failed, I think).

I've got a question about the Speeding up PyOgre section. We've written a normalize(a) function that just returns a normalized. Ogre::Vector3 has this built in, be we've guessed that it's faster to have 3-tuples and do stuff on them, than using Vector3s and calling the Ogre methods. For example, we have this function in actors (that move):


def move(self, fTime):

### Update the position of the actor
### according to its speed and the time since
### the last frame
self.position = ( self.position[X] + self.direction[X] * fTime * self.speed,
self.position[Y] + self.direction[Y] * fTime * self.speed,
self.position[Z] + self.direction[Z] * fTime * self.speed)
self.ogreNode.position = ogre.Vector3(self.position)



As you can see, actors have both a self.position, and a reference to it's ogre SceneNode that also has a position. Lately we have been thinking if it might be faster to just use the ogrenode's position directly. So, what I'm asking is basically, is it faster to do something like

self.normalize(self.position)
or this
self.ogreNode.position.Normalize()

After looking this over and running some tests, I realized you are correct...which is highly dissapointing, to say the least. Ogre's normalise function is faster than a Python version, but the slowdown due to calling an ogre function (IE the swig overhead for converting python objects to C++ objects then calling them) is not insignificant. I wrote a quick test:

iterations = 100000

def normal(x):
x, y, z = x[0], x[1], x[2]
length = math.sqrt(x*x + y*y + z*z)
if length > 0:
x /= length
y /= length
z /= length
return x, y, z

def norm_python():
v = (14, 15, 16)
for x in range(iterations):
normal(v)

def norm_ogre():
v = ogre.Vector3(14, 15, 16)
for x in range(iterations):
ogre.Vector3(v).normalise()

Now, timing each function I get:
norm_ogre (regular): 2.52s
norm_ogre (psyco): 2.34s
norm_python (regular): 0.20s
norm_python (psyco): 0.05s

Needless to say that's a huge difference.

One other thing, you should change this line:
# from this
self.ogreNode.position = ogre.Vector3(self.position)

# to this
self.ogreNode.position = self.position

That's because all tuples are converted into Vector3 objects automatically:
# this code:
t = (1, 2, 3)
self.ogreNode.position = ogre.Vector3(t)

# is exactly equivalent to this:
self.ogreNode.position = ogre.Vector3(ogre.Vector3(1, 2, 3))

I'll change the wiki.

I tried changing your norm_ogre to this:


def norm_ogre():
v = ogre.Vector3(14, 15, 16)
for x in range(iterations):
v.normalise()

Which actually seemed to make it faster than norm_python, but I wasn't able to time it so I might be wrong. Why did you choose to write "ogre.Vector3(v)"?

Hmmm yes, if I make that change it is faster:

norm_ogre (regular): 0.06
norm_ogre (psyco): 0.06

I was making it functionally equivalent to your code... After the first .normalise call the code v is no longer equal to ogre.Vector3(1, 2, 3).

This test does a better job of describing what I was getting at:
def python_position():
position = (1, 2, 3)
direction = (3, 2, 1)

for x in range(iterations):
value = position[0] + direction[0] * 0.123 * 50,
position[1] + direction[1] * 0.123 * 50,
position[2] + direction[2] * 0.123 * 50

def ogre_position():
position = ogre.Vector3(1, 2, 3)
direction = ogre.Vector3(3, 2, 1)

for x in range(iterations):
value = position * direction * 0.123 * 50

def ogre_position_2():
position = ogre.Vector3(1, 2, 3)
direction = ogre.Vector3(3, 2, 1)

for x in range(iterations):
value = position * direction * (0.123 * 50)

50,000 iterations
python_position: 0.09
python_position(psyco): 0.02
ogre_position: 1.92
ogre_position (psyco): 1.83
ogre_position_2: 1.22
ogre_position_2 (psyco): 1.16

Big difference there, and it's because of the overhead related to calling swig functions.