TexturePointer in Python-Ogre

[Mike Handverger]

Hi guys,

PyOgre had a handy class called TexturePointer. You could use it to
convert a Resource as returned by
Ogre.TextureManager.getSingleton().getByName() to a Texture class that
you could actually work with. There was a similar thing for materials.
Is there anything in Python-Ogre that can do this now?

Here's some example code I'd like to get working somehow:

im=Ogre.TextureManager.getSingleton().getByName("Texture.jpg")
sz=(im.getWidth(),im.getHeight())

and

mat=ogre.MaterialManager.getSingleton().getByName(nm)
mat.getTechnique(0).getPass(0).getTextureUnitState(0).setTextureName("Texture.jpg")

Thanks,

Mike

[Andy Miller]

OK I've done some testing and here's my understanding of the problem... 

 

Basically when a resource is retrieved from 'Ogre' using getByName (or via a number of other functions) it's always returned as a Resource Object..

 

And it's up to the programmer to decide what type of Object it 'really' is, and cast it to that object type - at which point everything it cool..

 

Does anyone know if it's possible to tell from the Resource Object what type of object it really is??  I looked at some of the sub classes source and don't see anywhere where they set a flag etc to indicate this...

 

I'll chat with Roman as to whether we can make Boost etc handle this automatically (I don't really see how) and if not I'll add a couple of helper functions (or add constructor methods to the subclasses to take a resource object)
 

 

[Roman Yakovenko]

On 2/19/07, Andy Miller <nzmi...@gmail.com> wrote:

OK I've done some testing and here's my understanding of the problem... 

 

Basically when a resource is retrieved from 'Ogre' using getByName (or via a number of other functions) it's always returned as a Resource Object..

 

And it's up to the programmer to decide what type of Object it 'really' is, and cast it to that object type - at which point everything it cool..

 

Does anyone know if it's possible to tell from the Resource Object what type of object it really is??  I looked at some of the sub classes source and don't see anywhere where they set a flag etc to indicate this...

 

I'll chat with Roman as to whether we can make Boost etc handle this automatically (I don't really see how) and if not I'll add a couple of helper functions (or add constructor methods to the subclasses to take a resource object)
 

 

Can you tell me what are the errors? The functionality you ask for, should work.

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[Andy Miller]

It isn't that you get errors as such, it just that non of the (in this
case) texture methods etc are available as python only knows that the
object is a "resource"

The trouble is we need to turn what is a base class into a subclass -
the reverse of normal operations I guess..

Cheers
Andy

[Roman Yakovenko]

On 2/19/07, Roman Yakovenko <roman.y...@gmail.com> wrote:

Okey, here is my solution, after some thought. PyOgre provided "less than optimal" interface for factory classes. Casting it is not something that could be
easily explained to a Python user. The better interface is to return the right class.

Solution. We need to wrap every factory and every create method within it.

boost::python::object TextureManager_getByName(const std::string& name){
    ResourcePtr r = TextureManager.getSingleton().getByName( name );
    if( dynamic_cast< Texture* >( r.get() ) ){
        return boost::python::object( TexturePtr( r ) );
    }
    if( dynamic_cast< Material* >( r.get() ) ){
        return boost::python::object( MaterialPtr( r ) );
    }
    ....
    return boost::python::object( r ); //unknown type
}

Than we should expose this function, instead of the original one. This will give
our users intuitive behavior.

Of course, this task could be automated. I mean we can create a class, which will
generate a code like this for every factory. But I suggest we will try it first on
Resource derived classes and factory manually.

What do you think?

--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/

[Mike Handverger]

That sounds good. If you want to check in the manual fix, I can give
it a try on Linux. I've been meaning to test the new stuff on Linux as
Andy asked and should probably have the time in the next day or so. In
any case, this would be a great way of handling this issue.

Thanks,

Mike

On Feb 19, 5:10 am, "Roman Yakovenko" <roman.yakove...@gmail.com>
wrote:

[Andy Miller]

I won't get the texture pointer stuff done until tomorrow - a full compile is underway with a lot of other fixes etc..

 

I'll update the SVN now with what I have, but if you have any issues just go back a version :)

 

Cheers

 

Andy

 

On 19/02/07, Mike Handverger <mike.ha...@gmail.com> wrote: