BillboardSet::getTextureCoords() returning const * ?

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

BillboardSet::getTextureCoords() returning const * ?

Post by tuan kuranes »

Is there any reason that BillboardSet::getTextureCoords() returns a "const *", so we cannot edit it outside of BillboardSet ?

In my case Texture Coordset parts may move each frame.
In my "UniqueImpostorSet", each impostor representing a unique MovableObject, that can be represented by a bigger or lesser texture part of the billboardset material, meaning different texture coordinates.

If "const *" that means, having to allocate a huge coordset FloatRect clone, fill it each frame, call BillboardSet::setTextureCoords each frame, which will copy over BillboardSet own coordset, resulting on very costly copy calls, not speaking of the memory cost, as it doubles memory necessary for texture coordinates.

Ideally :

Code: Select all

virtual Ogre::FloatRect const * getTextureCoords( uint16 * oNumCoords );
should to be :

Code: Select all

virtual Ogre::FloatRect * const getTextureCoords( uint16 * oNumCoords );
(perhaps it's just a typo, "const *" and "* const" being rather syntax near, and it's Dagon related)
genva
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 1603
Joined: Wed Oct 20, 2004 7:54 am
Location: Beijing, China
x 1

Post by genva »

tuan kuranes wrote:Is there any reason that BillboardSet::getTextureCoords() returns a "const *", so we cannot edit it outside of BillboardSet ?
For the reason of good C++ programming theory, some variables store in a class aren't supposed to modify outside directly.

If you really want to modify them directly, you can cast to Ogre::FloatRect*. Be sure you know what you are doing.

But, because you are modify the texcoord every frame, and the billbordset will re-fill vertex buffer every frame, therefore, why not write your own Renderable, so all compute can take place in one step, with slight performance boost bonus.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

Fair enough.

So actual per billboard implementation is really a once for all " texcoord load " implementation, and perhaps comments should state that more clearly or main billboarset class be patched to handle texcoord like other per billboard properties.

Which would be more C++ theory oriented than the actual special case "texcoord addition" to Billboardset, as I found it hard to understand, as it's not consistent at all with color and position handling.

For my needs, I'll go for making a new class a "BillboardUniqueTextureCoord" handled by a "BillboardSetUniqueTextureCoordPerBillboard" where texcoord will be per Billboard, as "color" and "position" is managed now...

Unless you'll accept a patch that add per billboard texcoordset in a much more cleaner way ?
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

genva
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 1603
Joined: Wed Oct 20, 2004 7:54 am
Location: Beijing, China
x 1

Post by genva »

Looks good. Thanks contribution :).
Post Reply