BillboardSet::getTextureCoords() returning const * ?

[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]

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.

[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 ?

[tuan kuranes]

The patch :
http://sourceforge.net/tracker/index.ph ... tid=302997

[genva]

Looks good. Thanks contribution .