Autre - Divers Scènes 3DS Lourdes, utilisation de la Ram et bonnes pratiques

GO TO ADMIN PANEL > ADD-ONS AND INSTALL VERTIFORO SIDEBAR TO SEE FORUMS AND SIDEBAR
#1
Bonjour à tous

Je m’interroge sur les bonnes pratiques permettant de gérer et maîtriser le poids des scènes et l’utilisation de la Ram.
Je cherche à comprendre qui pèse dans un fichier et l’incidence sur les ressources.

Je fais de l’archviz sur 3DS & corona depuis moins un an. Mes scènes pèsent entre 250 Mo et 1,20 Go. Je me suis formé en autodidacte, j’ai p-e loupé un basique

-Selon vous quel est le poids d’un projet moyen?
J’observe une moyenne (intérieur & extérieur) autour de 450 Mo. J’ai l’impression que c’est trop pour l’envergure des projets réalisés.
-Est-il possible de voir la répartition du poids d’un fichier ?
Lorsque j’utilise les Stats Xview de 3DS je ne vois pas de corrélations entre Polys, Verts, FPS et le poids du fichier.
-Quels sont les points importants pour maîtriser le poids?

Mon Workflow
Modélisation sketchup, import après nettoyage par Cleanup.
Il y a souvent des ajouts et des modifications en cours de projet et donc des ré-imports.
Je merge les objets et les place dans des Proxys. (Est-ce que dupliquer 30 fois un proxy alourdie la scène? )
Utilisation de textures PBR.
Moteur rendu Corona. Plugin : Forest pack.

J’ai utilisé le script cleaner sur 3DS qui réduit de 1 ou 2Mo. (pas bézef)
Voilà pour le poids du fichier.

Concernant la mémoire vive comment optimiser la scène pour minimiser son utilisation ?
Qui utilise la Ram? Les Displaces, le bump, textures et l’affichage ? Forest Pack ?
Pour l’instant ma station de travail tourne relativement bien avec 64Go de ram. (exception d’une vue aérienne + forest pack = crash, crash et re crash). J'ai peur d'arriver bientôt à la limite.

Parfois redémarrer mon ordi (et purger la ram?) me permet de lancer le rendu plus rapidement.


Peut-être une piste de discussion :
En lançant un rendu partagé avec un poste de 32Go de Ram. Celui-ci virtualise les 16Go manquant, le rendu se lance bien et m’affiche çà :
35,8 GB of virtualized* RAM used by Corona + 3ds Max
40,2 GB of virtualized* RAM used by all running applications
31,9 GB of physical RAM installed on system
51,4 GB of virtualized* RAM provided by OS

virtualized RAM means physical RAM + swap file on HDD/SSD

Corona RAM usage breakdown:
3,7 GB used by render elements
10,6 GB used by geometry
15,3 GB used by textures (CoronaBitmap only)


Merci pour votre aide.
 

phicata

Membre très actif
#2
-le fait de réduire les objets en "edit mesh" plutôt qu'édit poly réduit pas mal le poids.
-Les arbres sont souvent les éléments très lourds des scènes archis, les importer en tant qu'Xref object est une bonne solution (mais j’imagine que c'est ce que tu entend par proxy).
-Il m'est souvent arriver de voir le poids de mes scènes max quadruplées sans aucune raisons valables, je n'avais alors pour seule alternative que de créer une nouvelle scène et d'y merger l'ancienne.
-On est d'accord qu'on duplique tjs en Instance ou en Reference (si l'objet peut rester le même).
-J'ai déjà eu à traiter des scènes de 1 giga, la solution était de faire une scène avec les fondamentaux (éclairage, caméra, voir le sol) et de ramener tout le reste en Xref Object, ainsi ma scène ne pesait qu'un petit méga, facilitant grandement le travail.
-forest pack = crash ........:rolleyes: c'est aussi le souvenir que j'en ai, mais ct il y à longtemps.
 

malikarn

Membre très actif
#4
Salut.
Dans l'agence dans laquelle je bosse, on se sert aussi beaucoup de corona est je ne pense pas qu'il y ait une seule scène qui pèse moins de 2Go (en considérant les containers et xref scene/object).
On va pas se mentir, corona est un bon outil vraiment users friendly, mais c'est aussi une grosse cochonne en termes de ram usage comparé à vray ou arnold. C'est sans doute le prix de la simplicité. ^^
Cela dit le point crucial avec corona concernant la mémoire, c'est le displace et la taille des textures. Après tu peux faire passer sans soucis 6 à 10 milliards de tris (oui milliards) en tenant compte des instancer tels que le corona scatter et forestpack.
Meme si la majorité de notre parc matériel a au moins 64Go, certaines machines ont 32 et sans faire d'optimisations violentes et time consuming, tu peux facilement tenir dans le budget mémoire.
1 - Essaie de te passer des displaces. Si tu peux pas, limite la superficie des surfaces concernées et clampe les blancs et noirs autant que possible.
2 - si tu as beaucoup de lights sources, utilise le new light solver. C'est un système comparable au stochastic lights de vray. C'est utile
3 - tu peux sacrifier un peu de temps de calcul et desactiver l'uhd cache (donc brute force/path tracer en primary et secondary) qui comme son nom l'indique est un système de caching qui prend par conséquent de la mémoire. En particulier sur les vues aériennes ou d'extérieur plus généralement car la source principale de lumière est simple a identifier, c'est le soleil.
4 - et enfin surtout surtout, check la taille de tes bitmaps. Oublie les maps en 12k si ce n'est pas nécessaire (sur les props et tout le bordel) identifie les matériaux qui ont besoin de défintion. Les arbres genre evermotion (on la bib fpack) ont parfois des textures en 4k pour une simple feuille qui sera résumée a quoi ? 20pixels sur ton rendu. En plus il y a une map pour la diffuse, le cutout, le glossiness, la normale etc.
5 - mets toutes les map d'opacity en clip sauf là ou ce n'est pas nécessaire. Et pas le contraire.
6 - n'utilise que des coronabitmap, pas de bitmap natifs de max sauf si tu dois charger un ifl.
7 - rationnalise l'usage des matériaux. Si tu as 1000 fenetres, utilise 1 seul matériau de vitrage (sauf indication contraire) et pas 1000 matériaux de verre. J'exagère mais c'est l'idée.
8 - si tu sais faire, utilise des tiled-exr pour la mapping de l'orthophoto et l'environnent qui sont mécaniquement assez grosses.

Tu peux créer des droplets photoshop qui vont redimensionner pour toi les textures des props. Bien souvent, une map en 256/512 pour le glossiness d'une cafetière au fond a droite, c'est déjà bien plus qu'il n'en faut !
Passe toutes tes textures scalaires en mono plutot que rgb ca va diviser par 3 leur encombrement mémoire. La encore un droplet peut t'aider.
Bref, la taille des textures, c'est la clé. Utilise ce qu'il faut, là où il le faut. Avec corona plus qu'avec n'importe quel autre renderer.

++
 

malikarn

Membre très actif
#5
edit :
et du coup en complément et pour rebondir sur la remarque de phicata, je ne suis pas certain que l'edit mesh/poly ait vraiment un impact sur l'usage mémoire.
Effectivement tous les renderer passent par une phase de traduction (translation) où finalement ils émettent une description de la scène qui leur est propre. D'ailleurs si tu exportes la scène corona pour corona standalone (encore un moyen d'épargner de la mémoire) tu verras que toute ta scène tient dans un unique .cgeo (l'equivalent d'un .vrmesh ou .ass). De ce point vue, la distinction poly/mesh ne se fait plus.
Cela dit oui, au moins pour la réactivé dans le viewport, celle de la timeline et le poids du fichier bien sur, je te rejoints il est préférable de passer les polys en mesh.
A ce propos les .cgeo ne permettront pas de diminuer l'empreinte mémoire mais par contre ca peut significativement accélérer le temps de scene translation.
++
 

malikarn

Membre très actif
#7
Re
Il s'agit de se servir de l'output curve pour neutraliser une partie des valeurs de la map :
Par exemple ca c'est le bitmap admettons en png16 mono (ce qui n'est pas le cas ici car les images sont issues de la faq corona)

Sur l'image seule la partie entre 0.8 et 1 et clampee car finalement il y a peu de zones noires absolues.
Sans clamper le résultat est celui-ci :

Oui a gauche c'est le maillage.
Une fois clampée le résultat est un peu différent :
 
Haut