J'ai réalisé que je ne savais pas réellement quelles opération étaient les opérations les plus couteuses dans irrlicht,
En gros qu'est ce qui est le plus susceptible de faire ramer les applis ?

L'idée, (sans vouloir lancer un benchmark comparatif exhaustif ) c'est donc qu'elles sont selon vous, les grosses opérations ?

par exemple, en irrlicht:
faut il éviter les collisions response animator ?  les fonctions d'acces aux données membres (getheight, getposition ..) ?
les animators en général ? l'ajout dynamique de nodes ?

Je résume ce que j'ai appris jusqu'ici :

au niveau du rendu tout dépends directement du nombre de polygones,
Les lumières sont a proscrire a moins de ne pas vouloir faire du rendu temps réel

les waterscene node et les grassscene node sont potentiellement tres gourmands fonction des options qu'on utilise (field of vision, qualité du rendu etc ..)

le terrain avec du relief sont tres couteux si le field of vision est grand

l'utilisation des shaders améliorent la vitesse de rendu si ils sont bien supportés par le hardware

les effets de fake glow de Copland sont tres rapides

Dernière modification par Jerry Kan (01-01-2007 13:35:16)

Hello,

Je pense qu'il est très difficile de déterminer ce qui peut être utilisé et ce qui ne peut pas l'être ou que très modérément.
Il faut juste savoir que dans tout ce que l'on programme, il est normal d'avoir dès les premières lignes de code des chutes brutale de fps.
Genre un écran vide te donnera 5000 Fps, tu vas mettre un cube et il t'affichera plus que 2500 Fps (je n'écris ça qu'à titre d'exemple).

Pour les terrains, ceux d'irrlicht sont assez lent, je t'invite à regarder du côté de IrrSpintz et de lancer l'exemple du terrain Irrlicht, tu verras que Spintz à fait une optimisation assez importante dans les terrains basique (Je suis d'ailleurs en train de me demander si je vais pas modifier Irrlicht pour utiliser son système).

Pour les waterSceneNode, oui il est très dur d'avoir un beau rendu rapide, mais je pense que le plus expérimenté pour répondre à ça c'est DeusXL.

Ensuite il faut savoir que pour tout se qui est rendu Alpha, tout les moteurs souffrent quand on leur demande des rendus massif d'alpha pour des feuillages d'arbres ou d'herbe.

Pour les shaders, ça dépend la façon dont ils sont implémenté dans le moteur aussi.

Quand à mes effets de Fake Glow, je ne sais pas si ils sont plus rapide qu'un shader, il faudra pour ça que j'essai d'intégrer un BlurX,BlurY et un tone mapping par shader pour voir si on y gagne ou l'on y perd. Mais pour l'instant c'est une technique parmis tant d'autre qui permet d'avoir un peu de doux glow dans se monde de polygones bruts .

Les méthodes réputés gourmandes dans tout les moteurs sont les racines carrés "SQRT" pour les calculs de distance par exemple.Il vaut mieux préférer un calcul par vecteur si l'on a la possibilité de le coder de cette manière.

Enfin bref, sujet interressant mais malheureusement très vaste...
@+

Les méthodes réputés gourmandes dans tout les moteurs sont les racines carrés "SQRT" pour les calculs de distance par exemple.Il vaut mieux préférer un calcul par vecteur si l'on a la possibilité de le coder de cette manière.

D'ailleurs petits conseils :

Dans les calculs de distance entre deux points, on utilise souvent pythagore et la racine carré intervient. Or il est plus rapide de comparer les carrés que de s'encombrer d'une racine.

Ou alors faire appel à Carmack :

float SquareRootFloat(float number)
{
    long i;
    float x, y;
    const float f = 1.5F;
    
    x = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;
    i  = 0x5f3759df - ( i >> 1 );
    y  = * ( float * ) &i;
    y  = y * ( f - ( x * y * y ) );
    y  = y * ( f - ( x * y * y ) );
    return number * y;
}

(code en licence GPL, attention !)

Cette fonction tirée de quake3 est réputée très rapide