Je viens de tester des rendus avec les images de la nasa. J'ai pris la première texture à 2km/pixel. J'ai fait plusieurs essais : sur un plan, sur des spheres dépliées... dans tous les cas, ça n'a pas planté. Aucun problème (juste un petit temps d'import de la texture).

Et pourtant, ma config n'est pas tip top :

Ubuntu Linux 9.10 32 bits
Blender 2.50 (dernière révision)
3Go Ram
Intel Pentium Dual-Core 2.16Ghz

Aucun soucis.

Je pencherait plus pour une mauvaise gestion de windows 7... qu'en est-il sous Windows XP (plus vieux, donc peut être plus stable avec tous ses correctifs).

j'ai testé avec un pc avec un pentium IV et 2 go de ram
- mandriva 2008 : ça plante (avec ou sans OSA)
- windows XP : ça plante (avec ou sans OSA)

super ...

edit : systèmes en 32bits

Citation :

Tu voulais sûrement dire "integral"... Ultimate étant la version hackz

Batmur
Citation :

Alors attention à ne pas se méprendre je le répète une Nième fois : IL N'Y A PAS DE DECOMPRESSION. Il y a une nuance et j'y viens en dessous.

Citation :

Bon ya pas de canal alpha, c'est un simple jpeg, ensuite ton calcul bien que proche de la réalité est faux, ensuite il n'y a pas de limitation de 2Go en Ram par processus sinon je ne pourrait pas faire la moitié de mon taf sous toshop.
Alors oui on applique pixel par pixel une texture, mais non ca ne prend pas autant que ca dans la ram, c'est précisément pour celà qu'on a inventé des algorythmes de compression d'image, il faut arreter de croire que chaque pixel d'une texture va peser son kilo dans la ram, même en temps réel ce n'est pas le cas. Et en plus de ca, si blender / opengl / le moteur de rendu de blender, sont bien codés ils utiliseront un processus d'octree qui fait que toute la map elle même ne sera pas prise en compte, lors de l'affichage viewport ET lors du rendu. Ce qui me laisse penser que c'est bien un probleme de codage dans blender. Et le fait que ca marche sur Nux et pas sur win (ou bien sur 64b et pas sur 32b) me laisse penser que c'est précisément une routine de calcul qui n'est pas bornée et qui fait tout foirer quand l'unité d'allocation est dépassée...
Un exemple pourri (mais qui pourrait vous aider à piger si vous avez pas compris là où je veux en venir), une variable déclarée integer a une limite et si on essaye d'y rentrer un trop grand chiffre, beh ca foire, c'est pourquoi on teste la longueur du chiffre pour savoir si on va le mettre en int, en double etc etc... Et ca expliquerai pourquoi c'est nickel en 64 bits et pas en 32...
Moi je mettrai presque ma main à couper que le problème se situe là...

@ plouche
Nx.

je suis pas informaticien mais je pense que tu as tout à fait raison wizard

N'empeche que savoir que le problème vient de la ou la ne suffit pas pour le résoudre, aussi je voudrais savoir si t'as tenté de découper ? parce que si c'est un pb de blender le temps qu'ils le corrigent ton boulot sera en retard xD

Citation :

Pour l'instant ma légendaire et épique flemme fait que je n'ai pas encore découpé l'image non... huhu hum...
lol

Mais je vais le faire vui :)

Mais comme je disais par MP à un blendy qui m'a gentiement proposé de faire tourner les rendus sur sa machine, ca ne pose problème que sur les machine de travail qui sont sur win7 pour les rendus tests, notre render farm tournant sur nunux devrait pas yavoir de souci... Enfin si on en croit therebirthed puisque j'ai pas encore balancé ca dans la renderfarm...

@ plouche
Nx.

Note : j'ai testé sur un ordi portable 32 bits linux effectivement... Donc je te rejoint en pensant c'est plus un problème lié au système utilisé qu'un problème matériel ou de 32/64 bits... Après, est ce que c'est un problème propre à windows ou un problème de Blender sous windows... les deux cas me semble plausible (si t'a un Maya sous la main, tu le met en mode OpenGL (normalement, c'est le mode par défaut de Maya), et tu importe ta texture. Si ça plante, c'est windows. Sinon, c'est un problème de Blender sous windows (car sous linux, ça ne semble pas poser problème).

Quoi qu'il en soit, bonne chance, Ô grand malade des texture gigantesques .

je ferais bien le test sous windows 64 mais ma carte mère du pc en questoin est en réparation depuis désormais 5 semaines (bande d'enfoirés ils prennent leur temps chez asus ...)

Haha, ça sort les grands mots. Je reconnais le troll corse :p

Citation :

Il faut bien faire la différence entre la taille et le format du fichier de la texture, et son la taille et le format de la texture en interne à blender, c'est a dire dans la RAM.

Autrement dit, peut importe que la texture soit en jpeg sans canal alpha, en ram, ça sera identique.

Citation :

Perdu, les octree s'occupent uniquement de la géométrie (vertices, edges, ..).

en tout cas je sais pas comment fonctionne blender pour ça mais je peux vous assurer que tous les moteurs de rendus ne chargent pas les textures en brut dans la mémoire vive (faudrait que je teste sur blender)

Et si c'est le cas c'est franchement une drole d'idée

Citation :

Et pourquoi pas ? T'as des sources ? C'est pas pour troller, mais j'ai une formation en informatique, j'ai pas mal étudié l'infographie, j'ai en partie codé un moteur 3d, ... Je vois pas comment on peut faire autrement que charger les textures complètement. M'enfin, je suis près à apprendre, pas de soucis =)