ZBrush France

La section Pixologic France, pour tous savoir des logiciels de Pixo => Vos questions sur ZBrush => Discussion démarrée par: Stéph. le 27 novembre 2007 à 00:20:41

Titre: ZB3 Performance test
Posté par: Stéph. le 27 novembre 2007 à 00:20:41
Bon je ne sais pas pour vous, mais moi j'arrive à afficher avec ma machine un nombre hallucinant de polygones de manière fluide assemblés en Subtool  :shock:

Je suis toujours sur le cul de voir ZB3 capable d'afficher autans de polygones sans ralentissement, avec les brosses en temps réel et tous. À croire qu'il OC le CPU par x10 quand on bouge :lol: parce que je n'ai qu'un X2 4400+, et je peux déjà tous faire, ou presque...  :twisted:

Oui, car il y a un truc super frustrant qui vient gâcher la fête, parfois avec les objets lourds, et notamment quand je fais un Undo, ou que je masque un objet, parfois même comme ça quand ça lui toque avec le temps, ben ZB écrit souvant « Compacting Men » en haut à gauche avec le disque qui mouline, et je dois attendre plusieurs longues et pénibles secondes avant que ZB réagisse.

J'ai donc assemblé rapidement un objet basic en Subtool pour faire des tests publics que vous pouvez télécharger ici http://www.zbrush.fr/TutsSteph3D/ZB3Test.rar

Un truc bien lourd pour bien stresser la machine. Ben ce machin sans queue ni tete, mon X2 l'affiche fluide sans problème. Mais si je fais des undo, que j'essaye de masquer des parties, ou au bou d'un certain temps, ça commence à ramer dans la choucroute au niveau du RAM disque :(

Bon j'ai peut-être pas assez de ram pour ça, mais je sais pas si c'est pas aussi mon windobe qui se fait vieux, si j'ai un logiciel résident qui fou la merde, si je devrais pas passer à une version 64bits, etc... perso j'ai 2Go de RAM sur XP 32.

Voilà, sinon c'est aussi un bon test pour savoir quel matos il faut pour ZB. Chez qui ça marche bien sans soucis ? Chez qui ça ne marche pas du tout ? etc...
Titre: Re : ZB3 Performance teste
Posté par: Frenchy Pilou le 27 novembre 2007 à 00:25:13
il fait combien ton fichier en poids au chargement?
78 mégas : j'aurais dû me méfier!
j'ai réussi à le charger mais après bonjour l'angoisse, seul Alt+Ctrl+SUp m'a permis de sortir de ce traquenard!!!
Mais bon je ne sais si mon matos est encore dans la course  :mrgreen:
Titre: Re : ZB3 Performance test
Posté par: Stéph. le 27 novembre 2007 à 00:45:30
103 Mo une fois décompacté en subdivision maxi, j'ai déjà eu bien pire.

Mais je doute qu'avec 1 Go tu puisses bien l'afficher :?
Titre: Re : ZB3 Performance test
Posté par: Frenchy Pilou le 27 novembre 2007 à 00:47:42
Bien vue la marmotte tu m'as eu ! Voir au-dessus!
AMD Athlon 2600 1.9 ghz 1 Giga ram, 128 mega video ati radeon 9200  :roll:
Les mégas volumes de la mort qui tuent en milliards de polys pas pour moi  :wink:
Titre: Re : ZB3 Performance test
Posté par: Ldoppea le 27 novembre 2007 à 08:41:03
Idem pour moi. Dès le démarrage il compacte la mémoire, puis tout devient fluide après quelques sec. Puis dès qu'il faut annuler ou masquer une partie, il re-compacte tout çà.

Ma config' (pc portable) :
- Core-2-duo T7500 (2,2GHz)
- 2Go de rame
- Geforce 8600MGS (256Mo de mémoire dédiée)
Titre: Re : ZB3 Performance test
Posté par: derkomai le 27 novembre 2007 à 10:11:25
??? :o
c'est dingue ca! idem que pour Ldoppea mais l'annulation est super rapide et le masquage pas trop lent!

ma config:
-Core 2 duo E6600 (2,4Ghz)
-2Go de RAM
-Geforce N7600GS (256Mo)
-winXP 32

ouai, en même temps on a une config que se ressemble...

chui impressionée parce que mon dragon de 4million de polys fait ramer ma machine!
il faut croire que les subtools se gèrent mieux qu'un seul tool.
Titre: Re : ZB3 Performance test
Posté par: Stéph. le 27 novembre 2007 à 20:38:04
Ouais, en tout cas, c'est clair et net, en faisant un objet composé en SubTool, on peut afficher 10x plus de polygones en même temps de manière fluide sur un double coeur d'entrée de gamme. Pas besoin de CPU de la NASA, ni d'une grosse carte graphique, et à ce niveau ZBrush 3 est vraiment très très surprenant  :o

Le point sensible de ZB est donc clairement la RAM

Perso j'ai pas mal de résidents en mémoire, faut que je vire tout, puis mon XP est très vieux, installé depuis fort longtemps.

Les problèmes de lenteur du au compactage de la ram et assez variable, parfois l'undo est rapide, parfois pas...

Reste à voir si ça tourne mieux sur un XP plus récemment installé sans programme parasite. Faudrait voir aussi si c'est plus confortable sur un wndows 64 qui est sensé mieux gérer la RAM ?
Titre: Re : ZB3 Performance test
Posté par: PrayingMantis le 28 novembre 2007 à 18:22:12
Tenez:
Citer
Le nombre maximum de polygones avec lequel Zbrush vous permet de travailler,selon votre configuration matérielle, s'applique sur une base par subtool (et non par objet), donc avoir un objet avec plusieurs subtools vous permet de travailler avec un très, très grand nombre de polygones.

Ca vient de la doc, la limitation de polygone ne se fait pas par objet mais par subtool, je suppose que les subtools sont tous compacté lorsque l'on ne travaille pas dessus et on peut donc avoir X subtools.
Ce qui compte c'est le subtool sur lequel on travaille.
Et pour Xp64, c'est sur que c'est plus efficace car il gere plus de ram, avec 32bits il se limite a 2Go par application.
Et puis c'est pas non plus nécessaire d'afficher tout les polygones des subtools non actif, ca aide a améliorer la fluidité.

La ram est bien le point principal de Zbrush, comme celui de Mudbox.
Sinon ca aide en effet d'etre en 64bits, j'etais en 32bits avec 3GB de ram et lors des undo sur des gros objets ca mettais assez de temps. Ici avec ton objet ca me fait toujours compact memory mais je n'ai qu'une attente de 1seconde, tandis qu'en 32bits c'etait beaucoup plus long.
Maintenant c'est moins contraignant.
Titre: Re : ZB3 Performance test
Posté par: Stéph. le 28 novembre 2007 à 20:03:58
Ouais, beaucoup plus long même, variable entre 4 et 20 secondes, je dirais, selon les cas et ce que windaube à en mémoire.

Le message de la doc n'est pas vraiment clair ;-) La limitation est bien le nombre de polys par objet, mais composées en subtools, on peu en mettre 10x plus, et bouger le tout en même temps.
Après, quand ça commence à ramer, malheureusement ça le fait pareil que je n'affiche qu'un seul subtool, voir même qu'une partie, le reste est toujours en mémoire, et ça compact. Parfois ça se stabilise un peu avec le temps, mais c'est très variable, parfois ça fini même par ramer un peu avec le projection master. Attendre 5, voir 10 secondes à chaque annulation ou diverse manipes, il y a de quoi devenir fou ( je parle pas pour mon objet de test, j'ai des objets plus complexe que ça :roll: )
Titre: Re : ZB3 Performance test
Posté par: Lecaramel le 08 décembre 2007 à 16:14:43
Je vais peut être dire une connerie, mais j'ai augmenté mon seuil de Compact memory en préférence, pour que ca ne soit pas a 256 par défaut (si mes souvenirs sont bons..) mais à 1 Go. j'ai déjà beaucoup moins de soucis. Mais c'est clair que c'est embettant sur les gros meshs et les undos..
Titre: Re : ZB3 Performance test
Posté par: Alexis Flamand le 08 décembre 2007 à 16:59:46
C'est pas du tout une connerie, il vaut même mieux placer la barre juste un peu en-dessous de ta quantité de mémoire vive ( c'est à dire à 12 si tu as la même quantité de mémoire que Pilou ).
On peut même paraît-il la mettre au-dessus, mais pas à plus de deux fois la valeur de RAM, sinon ZB aspire toute la RAM dispo et Windoz aime pas trop...

Alexis
Titre: Re : ZB3 Performance test
Posté par: Frenchy Pilou le 09 décembre 2007 à 01:06:10
je vais peut-être une betise, mais plus il y a de mémoire, plus il de gros objets, plus il y a de calculs, plus la machine turbine, plus la machine chauffe?
Titre: Nombre de poly et UV
Posté par: HappyMantis le 14 juillet 2008 à 13:07:16
Je me pose une petite question:

J'ai un object d'actuellement 8 millions et des brouettes de polygones, en système un Q6600 et 8 giga de ram sous xp pro 64.

Même en boostant la mémoire à fond (donc 4096 alloués à zbrush), je ne peux pas subdiviser mon objet (j'arriverais à quelques 34 millions), apparemment d'ailleurs, la subdivision s'arrête de suite avec 4096 mais tente d'aller jusqu'au bout avec 256 (et à la fin Zbrush plante et me dit que mon système ne pourrait supporter un tel niveau de détails).

Alors je vais peut être dire une connerie moi aussi, mais une map UV de 4096/4096 contient un peu plus de 16 millions de pixel, il me faudrait donc un objet de 16 millions de poly pour la remplir complètement? Je me demande donc si sortir des maps de 4096 à partir d'un objet de 8 millions de poly ne reviens pas tout simplement au même que d'agrandir la taille de la map sous photoshop, et s'il ne faut pas mieux préparer son objet de base (au niveau 1), pour qu'après subdivision, l'on tombe sur un objet qui fasse à peu prêt 16 millions de polys?
Titre: Re : ZB3 Performance test
Posté par: Alexis Flamand le 14 juillet 2008 à 14:59:15
Si, c'est exactement ça :)

Alexis
Titre: Re : ZB3 Performance test
Posté par: ginko le 22 juillet 2008 à 20:46:18
J'en profite pour pauser une petite question sur quelque chose qui me turlupine. Pourquoi tout le monde semble s'accorder sur le fait qu'une texture ayant un nombre de pixel étant une puissance de 2 serait plus optimisée ??
Par exemple mon objet fait 5 millions de poly, j'en conclue donc qu'il me faut une texture de 2500x2500. Pourquoi la map serait-elle moins optimisée que du 4096x4096 ?
Je comprend ce genre de chose au niveau du nombre de bits par pixel étant donné que c'est fixe. Mais là je nage un peu, pouvais vous m'éclairer ?
Titre: Re : ZB3 Performance test
Posté par: Néo Créa le 22 juillet 2008 à 21:28:11
En fait, tu as par ex un mesh de 6 250 000 de poly.

Et une texture de 2500².

Par conséquent pour chaque poly du mesh tu as en correspondance chaque pixel de la texture.

Alors pour une performance en TEMPS REEL, et en voulant garder les mêmes détails que le high poly sur ton low poly, tout en gardant la vitesse d'affichage, ben le 2500 ² est par conséquent le plus adapté.

Tu peux évidemment faire une texture en 4096² mais pas pour du temps réel. Où là tu auras plus de pixels de texture que de pixel mesh. Et là c'est un atout pour le calcul, car tu auras du détail sans avoir un mesh à plusieurs milliards de poly ^^.

Donc ben l'optimisation dépendra de ton objectif d'image.

 :mrgreen:
Titre: Re : ZB3 Performance test
Posté par: ginko le 22 juillet 2008 à 21:57:17
Ouai mais quelle sera la différence entre une map 4095 (ou 4097) et 4096 ? :)
Titre: Re : ZB3 Performance test
Posté par: Frenchy Pilou le 22 juillet 2008 à 22:25:38
4096 est une puissance de 2 et les programmes adorent travailler avec les puissances de 2 !
çà tombe pile quand il faut diviser une image par 2 par exemple  :wink:
Et de toute manière la texture avec Zbrush n'accepte que les puissances de 2  :D
Sinon le résultat sera un peu n'importe quoi  :mrgreen:

On devrait les savoir par coeur   :roll:
2 4 8 16 32 64 128 256 512 1024 2048 4096....à l'infini  :lol:
Titre: Re : ZB3 Performance test
Posté par: Néo Créa le 22 juillet 2008 à 22:27:31
 :roll:

Euh..

Si tu veux savoir pourquoi il faut utiliser une texture carrée, ben un polygone, ben c'est un carré...

Par conséquent, pour une concordance parfaite du rapport largeur x longeur, ben par conséquent ta texture sera carrée.

De même faire des textures non carrées risque de faire déformer ta texture sur le poly. Comme étendre une image 4/3 sur un 16/9.

Et aussi pourquoi il vaut mieux respecter les rapports en puissance du chiffre 2 ( je veux dire 2 puissance n ).

Ben, le proc va utiliser autant de puissance, si ce n'est plus si tu utilises une texture 4000x4000 qu'une texture 4096x4096... Vu que lui va te calculer par pair.

2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096.... sont les textures à privilégier.

De même je crois qu'il y a l'histoire des virgules flottantes, et des entiers, le proc va mettre plus de temps à te calculer des  "" virgules flottantes '', qui ne soient pas dans la suite de 2 puissance n, que des entiers faisant partie de cette suite.

Je m'avance un peu sur le fonctionnement de calcul d'un proc, mais en gros ça doit sûrement correspondre à ça...

 :mrgreen:
Titre: Re : ZB3 Performance test
Posté par: Frenchy Pilou le 22 juillet 2008 à 22:29:11
comme quoi les grands esprits se rencontrent  :mrgreen:
Néo aussi l'a appris par coeur  :D

Et vous savez pas la meilleure?  :roll:
cette suite de chiffres 248163264128256512102420484096
peut se retrouver dans les décimales de PI, sisi, c'est un nombre univers ce brave Pi   :shock:
(enfin preque parce qu'il parait que ce n'est pas démontrer mais bon...il doit pas en être loin  :mrgreen:
Bon faut la chercher un peu, mais elle y est :mrgreen:
Ah on est peut de chose dans ce bas monde!  :lol:
Titre: Re : ZB3 Performance test
Posté par: bibouik le 22 juillet 2008 à 22:29:55
peut étre que z brush calcul mieux des packets 32 ou 64 pixel ... comme un os 32 ou 64 qui en faite calcul des packet de 32 ou 64 bits
enfin j imagine car quand on fait des normal on voit qui travaille en packet

edit tous c est reponse en mémé temps waouuuuuuuu
Titre: Re : Re : ZB3 Performance test
Posté par: Néo Créa le 22 juillet 2008 à 22:39:26
comme quoi les grands esprits se rencontrent  :mrgreen:
Néo aussi l'a appris par coeur  :D

Et vous savez pas la meilleure?  :roll:
cette suite de chiffres 248163264128256512102420484096
peut se retrouver dans les décimales de PI,


Pi m'en bouche un coin, j'ignorais cette précision.

Quoi que quand j'y pense... j'avais vu ça en Terminale S il me semble. En cours de math (même pas spé ). Dans un exemple ou exercice...

Mais bon, le souvenirs me font peut être mentir.

 :mrgreen:

En tout cas puissance n de 2 ya rien de mieux...

 :mrgreen: ça rime en plus...
Titre: Re : ZB3 Performance test
Posté par: Ldoppea le 22 juillet 2008 à 22:44:18
En même temps, Pi est tellement grand et infini qu'on doit bien pouvoir trouver le mot Pilou codé en octal dedans :lol:
Titre: Re : ZB3 Performance test
Posté par: Ldoppea le 22 juillet 2008 à 22:46:12
Tiens Pilou, va apprendre çà : http://www.col-camus-soufflenheim.ac-strasbourg.fr/Page.php?IDP=244&IDD=0 :twisted:

(j'avais trouvé plus long à l'époque, mais trouve plus)
Titre: Re : ZB3 Performance test
Posté par: Frenchy Pilou le 22 juillet 2008 à 23:00:17
oui le plus rigolo c'est qu'on peut trouver dans Pi toutes images codées sur un écran  :roll:

pour l'octal pas besoin de gros mots :)
p = 16
i  = 9
l = 12
o =15
u = 20
169121520 de l'enfantillage  :mrgreen:
enfin un peu retord quand même d'après eux (http://www.medusesetlicornes.com/html_java/suis10m.html) je ne suis pas dans les premières 10 000 000 décimales !  :roll:

Ce film il délirait grave!  8)
(http://blogs.sfweekly.com/shookdown/Pi%20movie%20poster.jpg)
Titre: Re : ZB3 Performance test
Posté par: Ldoppea le 22 juillet 2008 à 23:12:08
C'est pas de l'octal çà, c'est du 26al (je connais pas le terme :oops:)
Titre: Re : ZB3 Performance test
Posté par: Frenchy Pilou le 22 juillet 2008 à 23:16:25
Citer
je connais pas le terme
Du codage alpha numérique simplexe  :mrgreen:

ni d'après eux (http://pi.nersc.gov/cgi-bin/pi.cgi?word=169121520&format=hex) dans les 4 000 000 000 premières décimales  :roll:

D'un autre côté dans Pilou il y a pi  :mrgreen:
Titre: Re : ZB3 Performance test
Posté par: Stéph. le 22 juillet 2008 à 23:57:10
J'ai pas le temps de tout suivre, pilou t'arrêtes de trop parler,  :RED:
mais je signale qu'un polygone n'a jamais été un quad, un polygone est une figure géométrique constituée de n segment qui forme un contour fermé. Les triangles, les quads et les n-gon sont tous des polygones. Un polygone à 3 vecteurs s'appelle un trigone, 4 vecteurs un tétragone, 5 pentagones, 6 hexagones, etc... 

En 3D nos vecteurs nommés vertex ou point qui forme les polygones contiennent 2 types de coordonnées, XYZ qui représentent leurs emplacements dans l'espace tridimensionnel, et UV pour les textures, qui est un vecteur 2D (on peut mettre plusieurs attributs UV par vertex pour faire du multitexturing). l’abscisse U et l' ordonnée V donne donc une cordonnée qui est ici la positon relative de notre vecteur de polygone sur notre map 2D. Et ici c'est nous qui plaçons nos vecteurs 2D sur la map en fonction de nos images, c'est ce qu'on appelle, le dépliage UV en infographie, et ça dépend de ce qu'on fait, de là les UV peuvent être plus ou moins étirés, donc essayer après de dire que 4096 corresponds exactement à tant de polygones est une interprétation assez triviale de la chose.

Et les maps n'ont rien à voir, comme dit pilou, les machines aiment bien les multiples de 2 pour une question de gestion de la mémoire. D'ailleurs si vous balancez à la Cg un rectangle, ben elle va l'étirer en quad via le moteur 3d, ou ne pas fonctionner à part quelques cartes assez récentes. Pour le temps réel, on va jusqu'à 2048 sinon ça mouline, sauf pour les nouvelle Cg qui acceptent enfin bien plus.

Titre: Re : ZB3 Performance test
Posté par: Resh le 23 juillet 2008 à 00:46:00
Enfin simplement les puissances de 2 correspondent au binaire, et c'est avec ca que nos procos fonctionnent il me semble.
Et en hexadecimal pour la mémoire, ca simplifie d'autant plus, puisqu'en 1 symbole on compte jusqu'à 16, en 2 symboles jusqu'à 256, et en 3 symboles jusqu'à 4096

Mais surtout, je crois que c'est à cause des techniques comme le mip-mapping qui ont besoin de réduire la resolution de la texture rapidement... en la divisant par deux donc. Si ils avaient à gérer avec des nombre impairs ca ralentirais inutilement les choses.
Titre: Re : ZB3 Performance test
Posté par: Stéph. le 23 juillet 2008 à 01:24:13
Je te conseil plutôt de visiter le meilleur site fr sur la prog, tu trouvera beaucoup de réponse très technique
http://jeux.developpez.com/faq/3d/?page=techniques#TECHNIQUES_textures_puissance_2
Titre: Re : ZB3 Performance test
Posté par: ginko le 23 juillet 2008 à 06:23:54
Yes on y arrive! Merci beaucoup je commence à comprendre enfin.

Beaucoup de gens pensent comme Néo Créa :
Citer
Ben, le proc va utiliser autant de puissance, si ce n'est plus si tu utilises une texture 4000x4000 qu'une texture 4096x4096... Vu que lui va te calculer par pair.
Malheureusement c'est faux, et c'est pourquoi j'ai posé ma question. Les cas pour lesquels on peut appliquer ce genre d'analyses sont à un tout autre niveau d'abstraction. Par exemple pour une image RVB dans laquelle on va mettre que du niveau de gris. On va quand même remplir 3 cannaux alors qu'on en a en fait besoin que d'un.
Par contre quand on parle du nombre de pixels on monte d'un niveau d'abstraction et là on va mettre dans la mémoire le nombre exact de pixels dont on se sert, il n'est pas question de puissance de 2.

C'est ici que j'étais perdu, je me demandais pourquoi même mon ami zbrush me conseillait les maps en puissance de 2, alors que ma map 2500*2500 prendrait beaucoup moins de place en mémoire que du 4096x4096.

Et hop la bonne réponse arrive avec Resh :
Citer
Mais surtout, je crois que c'est à cause des techniques comme le mip-mapping qui ont besoin de réduire la resolution de la texture rapidement... en la divisant par deux donc. Si ils avaient à gérer avec des nombre impairs ca ralentirais inutilement les choses.

Ce qui est dit également par LeGreg dans le lien de Steph :
Citer
Certaines opérations comme la division et les modulos sont beaucoup plus rapides en puissance de deux, et quasiment gratuites quand elles sont précablées sous forme de transistors.

Lors du mip-mapping par contre le calcul n'est fait qu'une seule fois, à la création de la map afin de créer une texture pyramidale. Et là boum! On charge grave la mémoire avec plusieurs fois la même texture mais à des tailles différentes (justement de façon à ce que la division soit faite à l'avance et non en temps réel).
Je pense que notre problème se pose tout simplement, tout le temps, lors du calcul de la taille que fera la texture à l'écran.

Ca serait peut-être pas mal de comparer le temps que mettent 2 rendus, un avec des textures plus grandes mais puissance de 2, et un autre avec des tailles batardes.

ce qui me dérangerait, c'est qu'on s'embête à surcharger la mémoire alors qu'elle reste précieuse même aujourd'hui, pour avoir un gain de temps relativement ridicule lors du rendu.

Après pour aller plus loin, faudrait comparer le temps que met le proc pour faire une division sur un nombre qui n'est pas une puissance de 2, et le temps que met l'adressage mémoire de n pixels...

Bon ok il va falloir que j'aille dormir ;)

PS: pour le film Pi, il reste sympa à voir mais un peu trop barré à mon goût :p j'ai préféré A Beautiful Mind puis la BO elle arrache ;)
Titre: Re : ZB3 Performance test
Posté par: Resh le 23 juillet 2008 à 14:11:19
Woh c'est vrai qu'on se sent moins con avec une réponse précise come ca  :mrgreen:
Sinon il me semble bien que certains moteurs 3D utilisent des rectangles, mais on reste dans la puissance de deux...
C'est en tout cas une des voies de recherches pour l'optimisation, concentrer au maximum les textures dans un minimum de fichier, pour mieux pouvoir le compresser... C'est ce que veux faire ID dans sont prochain moteu, les NMap et diffuse de tout le jeu sont fusionnées et compressées à mort dans un seul fichier de 500mo, à partir duquel des tiles de 128x128 sont générée à la volée. Tout ca bien optimisé entre RAM mémoire vidéo et mémoire virtuel est censé être revolutionnaire, et il parait qu'en gros on aura même plus besoin de faire boucler nos textures ou de limiter la résolution  :shock:
Pour ceux qui ont un stock d'aspirine et du temps devant eux: http://www.presence-pc.com/tests/moteur-3D-Carmack-22702/6/
Titre: Re : ZB3 Performance test
Posté par: Stéph. le 23 juillet 2008 à 14:53:38
Oui, mais attention, tout cela ne concerne que le temps réel ! et la perde de puissance perdue lors des calculs se limite à quelques nano secondes par map, ce qui peu être très importants sur des calculs temps réels qui doivent au moins pouvoir générer 60 images pas secondes.

Non seulement tout ceci ne peu se sentir sur un rendu classique, mais en plus, le moteur de rendu de Max et compagnie ne calcul pas du tout pareil, et n'utilise même pas la carte vidéo pour calculer l'image, tout se fait par le CPU, c'est aussi pourquoi on pourrais aussi imaginé très prochainement des moteurs de rendus (et non-temps réel) beaucoup plus rapide en exploitant le GPU de la carte avec les libs CUDA.

Utiliser une map de 4096 dans 3DS Max au lieu de 2046 ne fera pas gagner en performance, mais en perte, car le moteur de rendu vas avoir beaucoup plus d'informations à faire passé à la mémoire vive, et risque même de faire du swap. De plus, si on utilise trop de grosses map, on peut très vite saturer la ram sur un OS 32bits avec risque de plantage.
Les algorithmes de lissage son aussi différent en rendu fixe et le temps réel, c'est deux mondes différents, je vous parle même pas du fonctionnement du raytracing, rendu par lancé de rayon qui est très différent du rendu par rasterisation de nos Cg.

Après, pas mal de choses risque de changer à l'avenir, mais pour le moment, un infographiste temps réel se doit de faire face à certaine contrainte technique, et aussi savoir économisé au maximum les données à fournir à la carte, mais un infographiste normal ne devrait pas avoir à se préoccuper de tout ça. Quand je fais du rendu fixe, je me fiche de savoir la taille et la forme de mes textures. Quand je fais du temps réel, j'essaye de dépliés mes maps sur du 1024 ou 2048 pour les objets assez importants, et les autres des maps de 512, et même 128 ou 64 pour les petits objets, et après on export ça en DDS qui est un format d'image qui stock les mipmaps et compresse les map en DXTC pour les Cg

Carmack, c'est le dieux geek  :king:
Titre: Re : ZB3 Performance test
Posté par: ginko le 23 juillet 2008 à 17:58:55
Merci pour ces précisions. Un monde bien différent qu'est celui du jeu vidéo! Un monde que je ne connais vraiment pas mais qui est super intéressant.
Sans Carmack j'aurais pas envie de sortir mon BFG à caque planton de zbrush  :twisted:
Titre: Re : ZB3 Performance test
Posté par: Frenchy Pilou le 23 juillet 2008 à 18:23:15
John Carmack (http://fr.wikipedia.org/wiki/John_Carmack)

(http://farm1.static.flickr.com/43/123855223_5b9a992f83.jpg?v=0)
L'inverse d'une racine carrée c'est lui :mrgreen:
Citer
float Q_rsqrt( float number ){
    long i;
    float x2, y;
    const float threehalfs = 1.5F;
 
    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y;  // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 ); // what the fuck?
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) ); // 1st iteration
    // y  = y * ( threehalfs - ( x2 * y * y ) ); // 2nd iteration, this can be removed
 
    #ifndef Q3_VM
    #ifdef __linux__
      assert( !isnan(y) ); // bk010122 - FPE?
    #endif
    #endif
    return y;
}
Titre: Re : ZB3 Performance test
Posté par: logan le 31 décembre 2008 à 09:09:02
salut tout le monde
j'ai pris le fichier et franchement ...aucuns soucis pour rien du tout............je tourne avec un WinLSD et mon pc est pas une bête de course plus que ça.........(17kl.........c'est le poids de ma tour  :twisted:)

en parlant de ça, quelqu'un pourrait me dire ou je peux trouver des systèmes de refroidissement a l'eau pas trop chère?marre de mon ventilo
Titre: Re : ZB3 Performance test
Posté par: geburah123 le 31 décembre 2008 à 14:04:43
refroidissement liquide c'est des contraintes malgré tout, il faut changer le liquide régulièrement... :(
Titre: Re : ZB3 Performance test
Posté par: BijoB le 20 avril 2009 à 17:20:43
bon ben moi je trouve que c'est pas très stable en fait

au delà de 7M de pixels ça se ferme sans prévenir et pourtant je fais des subtools et je masque caches des parties quand je bosse

pourtant j'ai une bonne carte graphique ( 640 Mo ) et 2Go de ram ( faut il passer à 4 Go ? )

le nombre de fois ou je hurle devant mon ordi parceque 'il me ferme Zbrush sans que j'ai eut le temps de sauver mon Ztools ça


des fois je ferais voler ma tablette ^^
Titre: Re : ZB3 Performance test
Posté par: Mind Symbion le 20 avril 2009 à 20:20:03
Salut Bijob,

La puissance de ta carte graphique ne jouera pas vraiment avec ZBrush...
C'est plutôt une bon processeur qu'il te faudrait! Et pour la RAM, oui plus tu en as et mieux c'est.
Mais pour 4Go, faut passer au 64bit!
Titre: Re : ZB3 Performance test
Posté par: dess le 20 avril 2009 à 23:05:09
tu fais un truc, tu sauvegarde, un autre truc tu sauvegarde sous un nom de fichier different & ainsi de suite...
sinon tu peux configurer ta ram dans preference/mem


ps : John Carmack !! Quake !!!! mon heros !
Titre: Re : ZB3 Performance test
Posté par: BijoB le 21 avril 2009 à 10:15:32
c'est ce que je fais déjà je fais une sauvegarde toutes les 5 min environ mais ça rends fou :)


sinon je vais passer en 64bit mais j'attends d'avoir une version de Win 7 qui me le permette ( je tournerai sur 3 Go en attendant ^^ )

peut être me fendre d'un nouveau proc aussi car ça fais trois an que j'en ai un provisoire  ( 1.8Ghz @2.6Ghz soit près de 50% d'overclocking )
Titre: Re : ZB3 Performance test
Posté par: gook le 22 avril 2009 à 17:32:18
Salut,


Sur ma bécane aucun compact mémoire pendant les undo ou masquage de poly, non il faut que je duplique tout les subtools pour qu'il commence à compacter sérieusement  :) 

ne pas perdre de vue non plus, que la vitesse et le cache disponible sur votre hd  influes directement sur la vitesse du compactage     
Titre: Re : ZB3 Performance test
Posté par: kilik le 27 juin 2009 à 14:23:48
Bonjour j'ai un nouvelle i7 avec 6 gigas de ram et un disque dur 5500 t/m sur un vista 64

je monte en polygones pas de souci mais je trouve çà encore un peu mou çà viendrait de la ram ou du disque dur?
Titre: Re : ZB3 Performance test
Posté par: geburah123 le 27 juin 2009 à 16:08:08
hm 5500 t'es sûr ça serait pas plutôt 5400 ou 7500 ..., si c'est 5400 tu peux changer ton disque dur ça fera toujours du bien
Titre: Re : ZB3 Performance test
Posté par: kilik le 28 juin 2009 à 15:15:29
oui 5400 ok je vais test avec un autre
Titre: Re : ZB3 Performance test
Posté par: sansan le 26 octobre 2009 à 21:20:21
Bonjour à tous. Je profite de ce sujet pour éviter d'ouvrir un énième topic. Je suis pas trés calé pour ce qui est des capacités de mémoire de la machine et j'ai donc du mal à configurer les préférences mém de zbrush. Donc si quelqu'un peut m"éclairer ce serait génial.
Voilà
avec une machine comme celle là :
pentium(R)4 CPU 3.00GHz
2.99GHz, 3.00 Go de RAM
carte NVIDIA Geforce 8500 GT
Comment je peux optimiser les préférences ?
Titre: Re : ZB3 Performance test
Posté par: Frenchy Pilou le 26 octobre 2009 à 21:33:56
Et bien regarde la superbe vidéo de Lecaramel Questions et réponses Ateliers N°3 (http://www.polysculpt.com/fr/ateliers-zbrush/videos-ateliers)
Ta question est solutionnée  8)
(Et au début de la vidéo en plus, ce qui ne t'empèche pas de voir la suite bien sûr!
Ni les autres ateliers d'ailleurs  :mrgreen:
Titre: Re : ZB3 Performance test
Posté par: sansan le 27 octobre 2009 à 09:49:34
merci beaucoup !  :D
Titre: Re : ZB3 Performance test
Posté par: Le Mitch le 06 janvier 2010 à 17:41:24
moi aussi je profite de ce sujet pour poser une question à propos de l'installation de la version R3.
Qu'elle que soit sa machine, la mémoire plafonne à 4096 ?
Quand j'ai installé la première fois Zbrush j'avais 6 Go, aujourd'hui j'en ai 12.
J'ai souvent des messages concernant le manque de mémoire, ce qui m'etonne un peu.
Le nb maxi de polygone tournait autour de 8 millions ?!
étrange n'est il pas ?

 :shock:
Titre: Re : ZB3 Performance test
Posté par: nephentes le 31 août 2010 à 15:29:57
bonjour  Le Mitch  ! et bien nous avons le meme probleme dans ce cas ! as tu trouver une solution ?
Titre: Re : ZB3 Performance test
Posté par: marabounta le 31 janvier 2012 à 15:16:40
Bonjour a tous,

Moi j'aimerai bien qu'il ya un GOZ pour passsage direct vers Vue.
Titre: Re : ZB3 Performance test
Posté par: michel fontaine le 03 février 2012 à 21:01:18
avec plus que du retard, je réponds : non rien de nouveau vu que Zbrush est limité en gestion de mémoire.
Depuis j'ai fait plein d'autres con....  qui font qu'avec l'expérience je les évite  :mrgreen: :mrgreen: :mrgreen: :mrgreen:....jusqu'à la prochaine  :o