Effet de bord sur texture atlas.

[Cpl.Bator]

J'ai un soucis lors de l'affichage de mes couches tilemap uniquement quand j'utilise une texture atlas ( commune à tout les tiles ) généré via cette méthode :

void tileManager::generateAtlasTexture(sf::Int32 edgeSize)
{

        int x  = 0;
        int y  = 0;
        int nl = int(((sqrt( mTileArray.size() )*.5f)*2))+1;
        sf::Int32 atlasSquare = nl * edgeSize;
        mAtlasTexture.create(atlasSquare,atlasSquare);

        std::vector<tile*>::iterator it;
       
        for(it=mTileArray.begin(); it<mTileArray.end(); ++it)
        {
                // retrieve tile
                tile * t = *it;
                // get pixel
            const sf::Uint8 * pixels = t->getTexture().copyToImage().getPixelsPtr();
                // update them into atlas texture
                mAtlasTexture.update (pixels,edgeSize,edgeSize,x,y);
                               

                t->mAtlasCoordinate.left        = x;
                t->mAtlasCoordinate.top         = y;
                t->mAtlasCoordinate.width       = edgeSize;
                t->mAtlasCoordinate.height      = edgeSize;
                               
                t->mSprite.setTexture(mAtlasTexture);
                t->mSprite.setTextureRect(t->mAtlasCoordinate);
               
                x += edgeSize;
                if (x>=atlasSquare)
                {
                        x = 0;
                        y+=edgeSize;
                }
        }
       
        // control
        //mAtlasTexture.copyToImage().saveToFile("ctrl.png");
}

mAtlasCoordinate est un sf::IntRect , l'effet obtenu est le suivant :



je voudrais obtenir :



pour le résultat qui fonctionne , je découpe chaque tuile dans une image que je copie et que j'ajoute dans un sf::Texture , chaque tuile a donc un sf::Texture & sf::Image propre , mais en vue d'optimisé le tout
je dois passé par une texture atlas pour faire ensuite l'optimisation avec un vertex array.

j'ai fait le tour de la question , setSmooth() n'est pas activé , ce n'est pas un problème de positionnement des tuilles puisque sinon cela apparaîtrait avec la méthode de base , une texture & une image par tile.
je pense plus à un soucis d'uv au niveau sfml , clamp de texture ?
merci de m'apporté un oeil neuf sur ce problème.

[Cpl.Bator]

j'ai résolu le problème en passant de

mSprite.setPosition(sf::Vector2f(position.x, position.y));

a

mSprite.setPosition((int)position.x, (int)position.y);

Edit :

Quand je change la vue , le problème reviens...

[Hiura]

Comme tu l'as remarqué, le problème arrive quand une image est affichée à des coordonnées non entière. Le problème peut revenir si ta vue induit un décalage d'un nombre non entier de pixels.

[Cpl.Bator]

le problème arrive dans les cas suivants :

- Coordonnées flottante & texture commune à tout les sprites ( découpage a l'aide de setTextureRect() )
- Coordonnées entière & changement de vue ( zoom ) & texture commune aussi.
- Coordonnées flottante & changement de vue ( zoom ) & texture commune aussi.

ca marche uniquement si chaque sprite possède sa propre texture & image. ( que je découpe aussi au passage )

le point commun du problème , c'est la texture commune a tout les sprites , j'ai vérifier les sources de la sfml , il "clampe" correctement , je suis bloqué à réfléchir la dessus... :/
je me demande si lui passer les coordonnées de texture (int) que sfml convertit en UV (float) induit un décalage lors des zooms , je vais trafiqué en ce sens...

[Laurent]

C'est un problème insoluble, ne vous cassez pas trop la tête dessus. C'est même une "fonctionnalité" : dans certains cas on a besoin que ça bave un peu (pour des sprites en mouvement ou en rotation, ça évite un effet saccadé).

[Cpl.Bator]

c'est bien ce que je me disait. je me tate à essayer le vertexArray pour voir si cela change quelque chose.
je pense que le soucis pourrais être régler si on pouvais passer des floats pour les uv.

setTextureRect( sf::IntRect() ) // coordonnées en pixels
setTextureRect( sf::IntFloat() ) // coordonnées entre 0-1

le problème interne a sfml serais de connaitre la taille de la texture , car l'update interne se base sur ces valeurs (intrect).

[Laurent]

je me tate à essayer le vertexArray pour voir si cela change quelque chose.

Ca ne changerait rien, tout est déjà basé sur des vertex arrays.

je pense que le soucis pourrais être régler si on pouvais passer des floats pour les uv.

OpenGL prend des floats pour les UVs, je dois donc déjà faire cette conversion en interne.

[kimci86]

Salut,
Tu pourrais faire le rendu sur une RenderTexture avec des coordonnées entières, puis appliquer les transformations.

[Cpl.Bator]

le rtt résoud le problème , effectivement , mais c'est du bricolage & les perfs en prenne un coup.
je pense que le soucis viens de la SFML , il ne prend pas en compte la taille des texels lors d'un redim de texture.
je fouille de ce coté http://gamedev.stackexchange.com/questions/46963/how-to-avoid-texture-bleeding-in-a-texture-atlas

[Cpl.Bator]

Résolu ! 3 jours que je suis dessus ! c'est à cause de l'antialiasing dans le contexte.
merci de m'avoir aidé

[Laurent]

Au fait, ton code est incorrect (comportement indéterminé). Tu prends trop de raccourcis là :

const sf::Uint8 * pixels = t->getTexture().copyToImage().getPixelsPtr();

Tu gardes un pointeur sur les pixels d'une image que tu ne stockes même pas, et qui est du coup détruite dès la fin de l'exécution de cette ligne de code. Sois tu stockes l'image, soit tu ne stockes rien et passes tout le bazar directement à texture.update.

[Cpl.Bator]

l'image est déjà stocké dans t. la copie de pixel part sur ma texture atlas qui possède sa propre image.
quand *pixels est détruit à la fin de la méthode , il ne représentait qu'une copie, pas une référence.

[Laurent]

Non, t stocke un sf::Texture. Les pixels vers lesquels tu pointes sont stockés dans le sf::Image éphémère qui est créé par l'appel copyToImage().

[Cpl.Bator]

oui , mais update fait une copie de l’éphémère ?

[Laurent]

Mais il n'existe déjà plus à ce moment. Tu ne l'as pas stocké, il a été détruit dès la fin de la ligne de code sur laquelle il a été créé.