A:M v16 beta

[Fabrice]

Salut!

Je mets le lien pour la téléchargée : http://www.hash.com/forums/index.php?showtopic=38522

J'e l'ai testé durant quelques heures et ce que je constate de suite c'est une légère amélioration des temps de rendu en général mais sur la version 64 bits l'écart doit être plus important.
Le traitement des weights cps est meilleur, la fenêtre peut s'agrandir.
On peut sauvegarder et charger des presets de rendu, c'est une bonne chose car cela évite de refaire les réglages à chaque nouveau projet.
Autre point positif, AM RenderServer est maintenant inclus mais je ne connais rien sur son utilisation donc il faut aussi chercher de ce côté là.
La majorité des plugins de Steffen Gross sont directement installés.

Voilà pour l'instant, j'attends les prochaines versions betas pour me faire une idée plus précise de cette nouvelle v16.

[LUDO_SI]

c'est bien ce que j'avais compris aussi )

[Fabrice]

Le point positif dans cette nouvelle version c'est que des efforts sont faits pour améliorer et optimiser la vitesse de calcul. On aurait pu avoir des nouvelles fonctions peu abouties voir inutiles pour l'animation de personnage. Comme on l'a souvent dit à de nombreuses reprises, A:M est un excellent logiciel d'animation mais il lui manque des améliorations dans ses outils actuels. La vitesse de son moteur de rendu méritait d'être revue, on peu imaginer que pour la version finale il y ait encore des améliorations à ce niveau.
Quelques plus dans l'éditeur d'UV seraient aussi les bienvenues avec un dépliage LSCM...

[LUDO_SI]

je fais pas mal de tests de rendu avec AM et blender. À partir d'un objet modélisé (une boule) que j'ai exporté en obj (16 poly per patch) vers blender je fais ces tests. j'ai créé une texture de displacement pour pousser le rendu polygone à être aussi semblable que celui d' AM. Là, j'ai été assez surpris. L'objet de départ pour être aussi détaillé avec le displacement mapping doit être subdivisé au moins par 5, voir 6 (6 blender plante même avec 8 go de ram). Donc ma simple boule qui n'a que quelques patch dans AM doit avoir plus d'un million de polygones pour être identique à AM.
plus d'un million c'est subdivisé par 5, subdivisé par 6 c'est plus de 6 millions de faces

Pour compliquer le tout un peu, j'ai dupliqué toutes la boule 18 fois dans chacun des softs.
À mon rendu, j'y ajoute la lumière de l'environement (ibl dans AM) et l'AO. Et je lance mon rendu.

J'ai jamais su lancer le rendu en subdivisant par 6. J'ai donc diminué la résolution du maillage.

Le résultat est que blender à rendu l'image en 12 minutes avec l'utilisation des 4 cores car il est multithread et AM en 10 minutes avec un seul core.

Dans le cadre d'un rendu d'animation, il faut donc compter le temps de rendu divisé par le nombre de cores disponibleS



Bien sur sans AO, le temps de rendu est divisé par 4 sans problème mais c'est un peu moins joli ou demande de chipoter avec les lampes et les textures.
[img][/img][img][/img]

[LUDO_SI]

AM ao+ ibl (10 minutes)
[img][/img]

Et le rendu blender en 12 minutes
[img][/img]

[LUDO_SI]

pour terminer voici un rendu AM mais radiosité en plus. ( je ne maitrise pas bien du tout la radiosité sous AM) Le temps de rendu est multiplié par 4

[img][/img]

Dans cettes scène, on remarque que chaque brique ressort du mur. Sans le displacement mapping, c'est impossible à rendre comme cela. Ce sont des millions de faces qu'il faut dans un software 3d ordinaire pour rendre cette scène. AM, il y a un patch par face de mur. 5 minutes avec ibl + ao

[img][/img]

Comment trouvez vous la qualité de ce dernier rendu?

[Fabrice]

Salut Ludo,

Voilà de très bons tests de rendu qui prouvent encore une fois l'efficacité du displacement mapping d'A:M. Par contre tu ne le sais peut être pas, le displacement est différent dans A:M et dans Blender. La technique utilisée dans A:M est basé sur les pixels et non sur les polygones résultants des patches. Cette méthode est appelée Sub-Pixel Displacement. Martin Hash l'avait expliqué sur son forum mais je ne sais plus ou ce trouve cette discution. Blender doit subdiviser énormément le maillage des objets pour gagner en qualité et du coup le temps de rendu grimpe. En dehors de Blender, il me semble que Modo utilise aussi la technique de displacement d'A:M mais je n'en suis pas certain.
Bref ce qui compte c'est le résultat avec un temps de rendu aussi court. L'image du mur de brique est impressionnante quand on pense que le mur est composé de simplement quelques patches.
J'imagine que si A:M était multi-core, les temps de rendu seraient sérieusement divisés !!!

[Fabrice]

Je me suis amusé à faire le test sur Houdini et il semble que la technique de displacement d'A:M soit aussi utilisé. Voici les différences en images. Sur A:M j'ai appliqué une map sur un patche à 4cps et sur Houdini c'est un polygone de 4 côtés non subdivisé.
Temps de rendu:
A:M = 29 s
Houdini = 57 s
Concernant le rendu, j'ai une préférence pour celui d'A:M qui gère mieux le displacement sur une image 8 bits. En 16 bits, les effets d'escalier devraient disparaitrent, il faudrait que je fasse le test pour en être sûr.

A:M

Houdini

[LUDO_SI]

effectivement le résultat est impressionnant. C'est assez amusant à dire mais plus on en demande au rendu plus AM devient intéressant. lol

Les images 16 bits donne encore un meilleure résultat, je les convertis dans toshop

[malo]

Salut à vous deux!
Très intéressant vos rendus et vos comparaisons !
Merci
Ludo, ton images montre bien à quel points ont peut rajouter du détail, sans ce casser la tête dans la topologie de la modélisation.
Oui c'est du Sub-Pixel Displacement, dommage que l'on ne puisses pas le peindre en temps réel dans AM
Fabrice, ton diplacemement est le même sur les deux modèles? Car on ne dirait pas.

[Fabrice]

Salut Malo,

Fabrice, ton diplacemement est le même sur les deux modèles? Car on ne dirait pas.

Oui j'ai utilisé la même image bitmap et je ne comprends pas non plus pourquoi il y a cette différence. Je pense que l'orientation des 2 surfaces ou que le point de vue de la caméra sont différents dans les 2 logiciels mais il n'y a pas que ça. A:M marque plus de différence d'élévation entre chaque couleur de pixel.

[malo]

Salut Fabrice,

Oui étrange,

Un petit test rapide sur le diplacement d'AM avant d'aller au boulot.

Remarques:
l'enfoncement est legerement moins marqué que l'elevation.
à un gris de 50%, il n'y a pas de surface lisse

Mais autrement sur des pas de 10% de gris les élévations sont réguliere entre elle.
C'est effectivement étrange cette difference entre le deux softs.
ci-joint le gris, si tu veux faire un essai sur Hodini : image tga

[Fabrice]

Salut Malo,

J'ai un problème avec ton image, elle doit être encodée dans un format différent de celui que j'utilise. Si je l'affiche dans l'aperçu de windows, elle n'apparait pas et Houdini refuse de la charger en m'indiquant qu'il y a une erreur. Par contre A:M et Gimp la charge sans problème.

[Fabrice]

Bon j'ai trouvé le pourquoi de la chose. Ton image est en mode "niveau de gris" alors que j'ai pour habitude de les sauvegarder en mode RVB. Dans ce 2ème cas, Houdini la prend sans problème. Je fais l'essai et je le poste.

[Fabrice]

Voici mon essai sur Houdini:



J'ai l'impression qu'il y a aussi une petite différence entre la partie la plus haute et la partie la plus basse. C'est bizarre, peut être une illusion d'optique.

[malo]

Salut Fabrice!

Merci pour ton exemple sur Houdini.
Si tu as pris la même image, il y a quelques chose qui me saute au yeux. Le gris 50% est irrégulier sur AM, et pas sur Houdini.
Je me suis dit qu'AM avait un défaut, et puis en examinant l'image utilisé pour le diplacement, j'ai constaté qu'il y avait également des variation sur l'image, en jouant sur les contrastes. Du coup AM est très très sensible aux variations de pixels. Il faut éviter les images compréssés et bien inspecté les dégradés et les aplats.
voici l'ancien aplat avec le filtre contraste pour faire ressortir l'irrégularité.

En utilisant un gris unis, et un dégradé correct voici ce que j'ai :



Peut être qu'Houdini n'est pas aussi sensible (ou alors tu as recréer l'image?), et cela pourrait expliqué cette différence entres les deux rendus.

[Fabrice]

En fait j'ai chargé ton image dans Gimp, changé le mode niveau de gris en RGB et je l'ai sauvegardé. C'était la seule solution pour que Houdini accepte de lire l'image.
Dans Houdini, pour chaque image importée est appliqué un filtre qui lisse l'image. Par défaut ce filtre est actif à un faible niveau mais c'est peut être suffisant pour atténuer l'effet irrégulier visible sur A:M.
Ensuite il y a d'autres paramètres qui peuvent jouer sur l'aspect de l'image. On peut forcer sur la qualité du shading d'un objet ainsi que sur la qualité du raytracing qui va être projeté sur ce même objet. Là aussi, il y a des valeurs appliquées par défaut. Je peux tout mettre à zéro mais du coup la comparaison avec A:M risque d'être faussée.

[LUDO_SI]

avez vous aussi autant de plantage avec la V16?
Je me demande comment cela se fait il qu'il soit pratiquement impossible de travailler une heure sans avoir un crash du soft

[Fabrice]

Salut Ludo,

Je n'ai pas beaucoup testé cette version 16. J'avais remarqué quelques bugs qui plantaient A:M mais je ne pensais pas qu'il y en avait autant. Pour l'instant ce n'est qu'une version beta, il faut attendre un peu. D'après ce que j'ai lu sur le forum Hash, l'amélioration des temps de rendu est très appréciable.

[Fabrice]

Ludo, as-tu essayé la v16 64 bits ? D'après le forum hash les temps de rendus sont vraiment plus rapides que ceux obtenus avec le version 32 bits.

[LUDO_SI]

oui, je l'ai essayée. le problème chez moi, ce sont les plantages récurant. surtout avec les textures dont notamment le displacement mapping.
Je réfléchit à l'idée de construire ma scène dans la V15 et de la rendre dans la V16
Effectivement les temps de rendu sont plus intéressant. C'est même envisageable d'utiliser l'AO.

[LUDO_SI]

toujours à propos du displacement mapping dans AM, je suis tombé sur un problème au rendu.
La différence entre le rendu fast préview et le rendu final est important.
En fait le fast preview est correct et l'autre pas du tout.

Voici un lien vidéo qui montre la différence entre les deux

[Fabrice]

En effet la différence est flagrante. Je suppose que c'est un bug et que ce sera vite réglé dans les prochaines versions. Il y a aussi un bug au niveau des decals et j'ai vu sur A:M Reports qu'il avait été résolu. Il y a peut être un lien entre ces 2 bugs. On sera vite fixé puisque Stephen Gross travaille déjà sur la beta 4.

[LUDO_SI]

dans la v15, le problème se posait déjà. J'espère qu'ils vont le régler. C'est pour moi une des fonctions les plus intéressantes :-)

La V15 est au final une très mauvaise version, j'ai jamais bien compris ce qui avait eu comme amélioration. (peut être le départ de Martin Hash, mais je pense pas que c'est une amélioration lol)

La 14 tournait mieux mais malheureusement j'ai bien griffé mon cd. Ce qui fait que j'ai pris une websubscription.

j'ai reposté un exemple sur le forum de hash, on ne sait jamais lol
C'est dommage que ce ne soit pas le preview qui serve au rendu final dans AM, j'ai tjs eu l'impression que c'était plus évident

preview

rendu final

[LUDO_SI]

j'ai eu une réponse du forum. c'est bel et bien un bug du au uv créé en faisant un auto baking de texture.En fait il faut utiliser le mapping par projection, cylindrique ou sphérique. Avec un peu de chance, ce sera corrigé bientot

[Contenu sponsorisé]