12-06-2007 17:30:00

I've come to a barrier in my game. I have just about all the boilerplate code DONE, but I did all of it thinking that OGRE had more elegant collision detection than it really does :P. Nothing against OGRE, it's pretty expected because it's focused on rendering stuff and letting you decide how to handle the objects.

Anywho, I've been searching around for a python binding for OPCODE or even better OgreOPCODE. Google gives me results that have absolutely nothing to do with OPCODE whatsoever. The word "python" has not even been muttered on Conglomerate's forum at all (search turned up no results).

I know ODE uses OPCODE for its collision detection, is there a way I can use its OPCODE without the physics? Everything I've read has said "just use a physics engine" but I don't need a physics engine, I just want collision detection. For one thing, the game is an arcade style space shooter (takes place on planets and in space). Newton and ODE aren't made for aerodynamics, and I don't NEED that much accuracy, because it's just an arcade style shooter. If there's no way around using a full-blown physics engine, is there a way I can turn off all the physics and just make use of its collision detection?


12-06-2007 18:47:09

if its static objects you want to collide with try using an octree, look it up on wikipedia, its not hard to implement in python, I did one a while ago which seems to have been linked around a bit (even though its a bit rubbish :) )

just google 'python octree' and it seems to be the first that comes up, weirdly enough :wink:


12-06-2007 20:56:10

If you dig through the manuals for ODE/Newton you should be able to find a ways to turn off the collision response while still being notified of when they occur. Take a look at the OgreNewt forum for an algorithm that does this.


12-06-2007 22:06:28

Let me know how the ODE/Newton method works out for you if you decide to try it. I was planning on using a physics engine for my collision detection as well.


13-06-2007 01:10:50

It looks like ODE implements it's collision handling as a 'seperate' step from the physics so I would espect you could update objects locations "manually" in the ODE World and just call collision checking..

I believe the same is available from OgreODE, you just have to implement your own stepper (that does collision checking only).

If neither of these work it seems like adding a Python interface to the OPCODE engine is very possible (in looking at the code it seems to be a clean C++ implementation and so is suited to be wrapped) -- let me know what would be easier...



13-06-2007 03:18:01

It would be easier to go with OPCODE honestly, but I don't want to sound too lazy here. I mean, I wouldn't want someone going out of their way for just me or anything, but if you think there's demand for it, I'd be all for a ogre.physics.opcode or something to the like 8). I'm going to look into how hard it'd be to separate the physics some time when I'm bored (good thing about doing this as a hobby and not a career :D)

One of these days I'm going to have to break down and learn how to bind things myself. What do you recommend me to use for doing so (for future reference, etc.)?


13-06-2007 03:30:12

Well you could copy the template for the other wrappers and try to wrap OgreOpcode. It should go rather smoothly.


13-06-2007 05:56:22

The easiest way is probably to wrap OgreOpcode (as mentioned by Game Ender). However the Ogreopcode project looks like it was last updated 3 years ago, and there really isn't much code involved in it.

So, how about I expose OPCODE in the ODE wrapper (it's already in the dll, I just didn't wrap/expose the name space) - this way you get direct access to the collision functions.

Then we simply convert the OgreOpcode wrapper to Python and away you go (or just access the OPCODE functions as you want)



13-06-2007 07:28:28

If it isn't too much trouble. I mean, I mainly made this post to see if there was already something out there so that I didn't reinvent the wheel. I wasn't expecting people to be so helpful :).

This all sounds great, if anybody else is interested in this, please leave a message. I'd feel bad if somebody went through the trouble of doing something just for me.


13-06-2007 14:03:22

So long as it gets used I don't mind creating it :) Also having a simple collision only module makes sense to me.

I've taken an initial look at exposing OPCODE from within ODE and have decided not to do this as it requires compiling ODE with non standard options (to expose the Opcode functions)..

So I've created an initial Opcode wrapper (compiles and loads), however I also need to expose the IceMaths/IceCore namespace which is less nice :) and so will probably take a couple of days..



17-06-2007 03:04:10

I was just wondering what the status of opcode is. I did a checkout of python-ogre's svn and noticed an opcode directory, which made me happy :). I've been keeping myself busy trying to bind HexiDave's simplepaginglandscape :D. It's turned out to be rather frustrating, but I'm getting a little closer to finishing it (well, the really hacky "AHA! Now I can do it correctly!" version :P)


17-06-2007 07:16:04

Well, apart from callbacks (which may not be needed) Opcode is wrapped (not tested though)...

However I haven't had time to write the Python code that will integrate it into Ogre as I need to learn how Opcode actually works :)

Unfortunately the OgreOpcode project was based upon an older version of Opcode (1.2) and the current (1.3) API has changed.. I downloaded a demo program that uses Opcode and am going through that now..

Great to hear you are working on the landscape scene manager -- let me know if you need any help and if you are interested in adding it to the Python-Ogre project (happy to have it in the SVN etc)



17-06-2007 14:47:49

I just thought I would point you towards my signature.. You might have an easier time. :)


17-06-2007 14:58:43

I'm part way through writing test code for the Opcode wrapper and in the process implemented a test for the internal Ogre collision handling..

It seems to work fairly well so it might also be an option for your game (here's the interesting bit)
class OpcodeBoxesQueryListener(ogre.IntersectionSceneQueryListener):
def __init__ ( self ):
ogre.IntersectionSceneQueryListener.__init__ ( self )

def queryResult ( self, first, second ):
# Lets change the material so I can see the intersecting objects
return True

class OpcodeBoxesListener(sf.FrameListener):
def __init__(self, renderWindow, camera, sm, num):
sf.FrameListener.__init__(self, renderWindow, camera)
# Create an intersection query
self.intersectSceneQuery = sm.createIntersectionQuery()
# and a listener to receive the results
self.querylistener = OpcodeBoxesQueryListener()

# I then create a range of crates and barrels to test with
self.numBoxes = num
self.sceneManager = sm
self.CreateBoxes ( num )

def frameStarted(self, frameEvent):
self.intersectSceneQuery.execute( self.querylistener )
return sf.FrameListener.frameStarted(self, frameEvent)

I can send a complete test program if you are interested and will test it against the Opcode wrapper once I get done..


17-06-2007 16:45:36


Did I read that you're trying to wrap the paging geometry sceneManager? If so I'd be very interested to see what you've accomplished. Having seen it on the showcase forum I'm very excited about using it, it looks awesome


18-06-2007 08:11:00

@bharling: You probably wouldn't be too interested in what I have right now just yet :(. I'm still teaching myself this binding stuff as I go along, and right now I'm stuck with py++ generating code that has a comment in it saying that it won't compile because some class (I'd look it up, but I'm tired right now, this is all on page 11 of Simple Paged Terrain's thread IIRC) doesn't contain an == operator if I remember right. I was hacking away and reading documentation for quite a few hours already and got to the point where I said "I need a break!" Everytime I'd appease py++ and boost.python with one thing, they'd complain about something else. It's like dealing with an ungrateful child, only I'm still reading what I can find online in example code and mailing list archives to make sure it is in fact a child after all :lol:

If anybody wants to take a crack at telling me what's wrong with my code (besides the stupidness of the thing in its very hacky frustrated programmer fashion. I got to the point where I was trying anything and everything and the code shows it :(), I posted all of the py++ code in the Simple Paged Terrain thread on page 11 IIRC. I'm tired so I don't feel like working on it right now, but when I get a chance I'll try to get it to work. I really want to do this, even if I never use it (which I WILL use it), just as thanks for all the things the Ogre community has given me. I always feel bad when it comes to OSS because I never feel like I give back anything.

@andy: Sounds good, and I'm very interested in seeing what you have. I'm personally not a framelistener user, is there a way to use OPCODE without framelisteners (that you've exposed)? I was meaning to try them out, but at the moment I haven't really convinced myself that I needed framelisteners. I just use the old-school "while(1) {}" method ATM. I notice everybody in the Ogre community seems to just love listeners and incorporate them into everything :lol:. I can see their usefulness, but I've always been fine without them.


19-06-2007 05:04:19

A VERY rough collision example can be found [b]here[/b]

More to come



21-06-2007 04:00:00

VERY nice, looks perfect for my game. Thank you so much! The glorious andy has earned a spot in my credits :D