Yopiyo !

Bon j'ai pas taffé dessus hier soir donc rien de neuf, ce dont je suis pratiquement absolument sûr c'est que ce n'est absolument pas dû à un problème hardware, pour moi c'est soit blender, soit windows, soit les 2...
Comme je l'ai déjà dit, même quand on sature la ram, il y a la swap, et elle fonctionne très bien sur seven. Ce qui me fait plutot me tourner coté software (et/ou mauvaise gestions des ressources par blender et/ou windows) c'est, comme je l'ai déjà dit, le fait que rien qu'au chargement de la tex dans blender ca fermait... Et ensuite en compressant l'image ca chargeait mais plantait au rendu...

J'ai déjà eu des tas et des tas de plantages de blender (j'adore les scènes gigantiques) pour diverses raisons, scènes trop lourdes, trop de polys, trop de shaders poussés ou tout simplement instabilité de blender etc etc...
Quand la ram devient insuffisante, windows sort un message d'erreur pour le dire, par ailleurs j'ai essayé de charger la texture avec le moniteur de perf, la charge de ram n'était même pas à 75%, quand blender plante suite à une limitation (trop de polys par exemple) il donnait un message d'erreur avant de planter... Là c'est une fermeture intempestive, ce qui me fait plus penser à une limitation du logiciel, genre un dépassement bien gore d'une allocation, une division par zero, un calcul improbable et imprévisible un truc dans le style quoi...

Citation :

Oui et d'ailleurs il me semble que le topic émanait de moi mais je ne me souviens plus de l'issue et je ne l'ai pas retrouvé en faisant une recherche avant de créer ce topic...

@ plouche
Nx.

Bon, suite à une batterie de tests, je vous confirme que ce n'est pas un probleme de poids mais bien de dimensions... Meme en compressant le jpeg au max pour finir avec une image de 5Mo ca plante quand même...
J'ai ensuite réduit progressivement les dimensions de la texture... au delà de 10800px de long, ca plante obligatoirement... Mais à 10800, plus de problemes, quelque soit la géometrie sur laquelle on applique la texture (j'ai esayé sur un plan et une sphere).

Si ceux qui sont sous windows peuvent faire de tests avec des textures de très grandes dimensions ce serait cool. Comme ca on déterminerait définitivement si c'et un probleme de config/hard ou bien d'une limitation de la version windows de blender (ou bien un pb sous win).

Merci.
@ plouche
Nx.

je peux juste te dire qu'il m'est une fois arrivé de lancer une image de 14 000*14 000 en texture sous blender sous windows 64 (malheureusement la le pc est mort donc jpeux pas faire de tests ...). Après si c'est un problème au niveau du calcul le problème pourrait changer selon les config donc je sais pas trop :-s

Citation :

Ça me semble pas pertinent comme raisonnement. En interne, peux importe le format d'entrée, blender va décompresser l'image, donc peux importe que le jpeg fasse 5 ou 500mo, ça sera pareil.

Ici, rien que pour ta texture, si elle est gérée avec un canal alpha (=24 bits), elle va prendre en ram (21600*10800*4)/(1024^2) = 890 Mo. Après, je sais pas ce que tu as dans ta scène, mais faut faire attention à la limite de 2Go par processus des systèmes 32 bits.

Sur linux, je sais que blender crash avec un message dans la console du genre "problème d'allocation".

Si tu trouve pas de solution, je te suggère un rapport de bug. Il doit pas y avoir grand monde qui utilise des textures aussi grosse, tu pourrai bien avoir trouvé un bug. Au pire, t'aura surement une réponse pertinente.

Pour ceux qui souhaitent tester par eux-même ; Ici Les images sont téléchargeables en 500m/pixel.

Selon moi, j'aurais testé un découpage de la texture. Cela aurait éclairci l'affaire avant de trouver une solution plus propre, afin de connaître le fond du problème.

Bon courage!

Bonjour le BC et tout d'abord tous mes vœux pour 2010. Bon alors je viens de tester avec la texture du lien de Gaspard,(21600x10800) avec une normal map,rendu en 4m21s format 1980x1080,blender 2.49b, sur un plan d'environ 200000 vertice,avec l'AO à 1 et sans OSA,si je monte l'AO pas de problème,mais si j'enclenche l'OSA même à 5 plantage immédiat!Ma config est:Win7 32bits,core quad q8200,4Go de ram,Nvidia gtx260,voilà si ça peut faire avancer le "schmilblick" papy Mouseau serra content,amicalement,Pierro

edit: Même résultat avec la 2.48,quand à la 2.5 A0 elle ne veut même pas en entendre parler,plantage direct après ouverture.

re-édit: pour tester,même fichier sous Ubuntu 9.10 64bits,il me le rend tranquille,AO10 Osa11 toujours en HD,mon CPU n'est solicité qu'à 75%.

salut, j'ai fait le test avec des textures en (22000x11000) fois 7(7 objets différents avec cette texture); plus de 1 millions de verticles, osa 16, AOE raytrace 10 samples. J'ai surchargé le système, pour l'obliger à utiliser toutes la ram 2.9GO et à créer 3 GO de ram virtuelle. ça rame un max mais ça ne plante pas, 51mn plus tard j'ai un rendu en 800X800.

Ubuntu 64 bits
3Go de ram
AMD64 3400(truc préhistorique)
blender 2.49(64bits)

Je suis entrain de faire un rendu avec la 2.5 pour le moment pas de plantage, rendu en cours (2/16).

J'ai tester avec une texture en 40000X11000 plantage direct au téléchargement de la texture. En espérant que celle puisse t'aider.

Hey j'avais pas répondu à ton post. En fait c'est pas une question de charge de ram ou quoi que ce soit, je pense : les modules de mémoire, pour les images, autorisent une taille max (à vérifier) : c'est en tout cas valable pour les cartes graphiques, comme l'a montré je ne sais plus quelle boite sur je ne sais plus quel jeu (c'est précis hein ! promis dès que je retrouve je post le lien), qui gère des maps de 32000². Pour réussir à afficher ça, ils ont dû bidouiller pour que la carte graphique puisse afficher la map entière (les CG ont x puces de mémoire qui forme la mémoire totale), étant donné qu'on ne peut pas diviser les fichiers entre les différents partitions. P-a que le problème vient de là (et qu'au moment de recoller les différentes parties de la même map dispatchée entre les différentes barrettes, ça merde).

Je dis ça en tant que gros noob d'hardware

Citation :

Cette limitation est uniquement valable dans du temps réel (jeux, affichage du viewport de blender, ...), Si chez Nx, ça plante au rendu, ça peut pas être ça. Néanmoins, il me semble avoir lu quelque part que la limite en taille des textures dans blender était de 8000². Visiblement cette limite a du évoluer, mais il y en a peut-être encore une.

Par contre, si ça marche sans problème sur un linux 64 bits, c'est probablement un problème dû au 32 bits (pour éviter le troll sur windows ).

d'où l'intérêt d'acquérir windows7 ultimate