Blender 2.8 : une beta pour le SIGGRAPH, comme prévu

GO TO ADMIN PANEL > ADD-ONS AND INSTALL VERTIFORO SIDEBAR TO SEE FORUMS AND SIDEBAR
#81
Turtle j'ai l'impression que tu cherches absolument à trouver des arguments pour indiquer qu'Eevee n'a aucune utilisation possible, d'abord en citant son utilisation dans Maya impossible (encore si Blender était payant et Maya gratuit je comprendrais), puis que tu fais des rendues en 20 secondes par frame contre le dixième ou centième de seconde dans Eevee (même vitesse en intérieur grâce aux light probes bakés, donc on devrait arriver à un écart de >x1000 en vitesse par frame dans certaines scènes sans compter le volumetric et post-processing), donc je serais curieux de voir en combien de temps tu sorts une série TV de 20 minutes par épisode en 4k 60 FPS avec des scènes en intérieur sur un PC moyen. Puis tu nous parles des jeux vidéo et VR chose impossible à faire non plus avec Maya et Redshift donc je ne vois pas où est le problème.

Donc pour faire des jeux vidéo multi-support et VR en attendant le mode intéractif, tu peux utiliser Godot. Tous les deux utilisent le glTF 2.0 et le principled shader, tu peux faire du multi-export en un seul clic avec toutes les actions, blend shapes, matériaux et textures et tout se plug automatiquement dans Godot et inversement plus tard tu pourras faire du blockout de level design en CSG puis exporter des meshes en glTF pour chaque CSG container (donc possibilité d'avoir du modulaire) vers Blender pour finaliser les assets. Ils vont améliorer leur compatibilité entre eux, Godot va restaurer et réécrire le Visual Shader Editor dans la 3.1 qui était dans la 2.x avant l'arrivé du PBR et permettra d'exporter les mêmes nodes vers Blender et inversement.

Le glTF 2.0 fonctionne déjà très bien, même si pour l'instant j'utilise le "Better Collada" car il n'est pas encore compatible avec le Principled Shader de Blender, il faut importer un node group créé par le Khronos Group:


PS: ne dénigre pas Godot si tu le cites.
 
Dernière édition:

TURTLE

Membre très actif
#82
Godot a aussi bien amélioré son rendu. Et depuis le début, il ya l'idée de créer un pont pour que les shaders passent bien de Blender à Godot.
En théorie, l'utilisateur Blender devrait avoir un interactive mode pour prototyper son jeu dans Blender (comme il pouvait le faire dans les versions précédentes avec le game engine) ; puis, il pourrait continuer le travail dans godot sans trop de problème d'export.

Et puis, bon, si c'est juste pour créer des matériaux et textures pour asset, EEVEE n'est pas d'une complexité folle. Il reprend les mêmes nodes que sous Cycles, en plus limité.
C'est dans la gestion des lights et des effets screenspace qu'il demande un approndissement des connaissances.

Grosso modo, c'est apprendre Blender tout court qui va prendre du temps.

La nouveauté, c'est Blender qui passe à une nouvelle série 2.8. EEVEE est une grosse partie du changement.
Je suis d'accord sur le fait que ce n'est pas une raison suffisante à elle seule pour migrer sur Blender.
Mais il est évident que les utilisateurs de Blender ne vont pas bouder EEVEE et vont produire avec.


Ouais enfin entre Godot et Unreal 4, j'ai vite fait le choix.
Godot n'est pas vraiment un argument de poids dans le domaine de la 3D temps réel.
 

TURTLE

Membre très actif
#83
Turtle j'ai l'impression que tu cherches absolument à trouver des arguments pour indiquer qu'Eevee n'a aucune utilisation possible, d'abord en citant son utilisation dans Maya impossible (encore si Blender était payant et Maya gratuit je comprendrais), puis que tu fais des rendues en 20 secondes par frame contre le dixième ou centième de seconde dans Eevee (même vitesse en intérieur grâce aux light probes bakés, donc on devrait arriver à un écart de >x1000 en vitesse par frame dans certaines scènes sans compter le volumetric et post-processing), donc je serais curieux de voir en combien de temps tu sorts une série TV de 20 minutes par épisode en 4k 60 FPS avec des scènes en intérieur sur un PC moyen. Puis tu nous parles des jeux vidéo et VR chose impossible à faire non plus avec Maya et Redshift donc je ne vois pas où est le problème.

Donc pour faire des jeux vidéo multi-support et VR en attendant le mode intéractif, tu peux utiliser Godot. Tous les deux utilisent le glTF 2.0 et le principled shader, tu peux faire du multi-export en un seul clic avec toutes les actions, blend shapes, matériaux et textures et tout se plug automatiquement dans Godot et inversement plus tard tu pourras faire du blockout de level design en CSG puis exporter des meshes en glTF pour chaque CSG container (donc possibilité d'avoir du modulaire) vers Blender pour finaliser les assets. Ils vont améliorer leur compatibilité entre eux, Godot va restaurer et réécrire le Visual Shader Editor dans la 3.1 qui était dans la 2.x avant l'arrivé du PBR et permettra d'exporter les mêmes nodes vers Blender et inversement.

Le glTF 2.0 fonctionne déjà très bien, même si pour l'instant j'utilise le "Better Collada" car il n'est pas encore compatible avec le Principled Shader de Blender, il faut importer un node group créé par le Khronos Group:


PS: ne dénigre pas Godot si tu le cites.
Pour moi calculer une image de qualité finale de l'ordre de la seconde avec EEVEE n'est pas vraiment un argument, quand tu peux faire beaucoup mieux en 2min sous Redshift, soit dejà 300 en une nuit. Ce rapport qualité temps calcul est tout à fait acceptable pour moi. Aprés pour quelqu'un qui a besoin de sortir une video en 2h pourquoi pas, mais il y a pas si longtemps il fallait 1h pour sortir 1 image, donc j'ai du mal à comprendre que maintenant 2min ce soit trop d'attente.
Quand à Godot je le considère pas comme un argument de poids dans le domaine de la 3D temps réel, qui donne envie de passer à blender.
 
#84
Le truc c'est que tu pense pour toi, et tout le monde ne pense pas pareil que toi.

Là c'est comme avec les gars sur BA, tu présente un truc pour améliorer la vie de 99% des utilisateurs et eux refusent par peur que ça change leur workflow.
Là c'est pareil, parce que tu n'en voit pas l'intérêt, tu descend le truc, même si tu n'es même pas utilisateur blender.
C'est con non ;)

C'est d'autant plus con car des projets tempts réel il y en a de plus en plus, tu vas aller leur dire que c'est con car tu préfères utiliser Redshift ? J'en doute.
Donc, pose toi la question, pourquoi est ce que tu commente un truc sur un soft sur lequel tu ne bosse pas et surement ne bossera jamais dessus.

Sinon, un truc sympa avec le temps réel.

J'espère que les devs redshift pour l'addon blender vont faire en sorte que ce soit compatible avec eevee.
Même si redshift est mega rapide, j'avoue que je surkiff bosser mes shaders en temps réel.
 
Dernière édition:

Gam

Membre très actif
#85
donc je serais curieux de voir en combien de temps tu sorts une série TV de 20 minutes par épisode en 4k 60 FPS avec des scènes en intérieur sur un PC moyen. Puis tu nous parles des jeux vidéo et VR chose impossible à faire non plus avec Maya et Redshift donc je ne vois pas où est le problème.
c'est quoi l'interet d'une serie en 4k 60i/s ? On es en 25 i/s en europe.
Vous avez des carnets de commandes remplis de series 4k ? Le 4k a l'air d'en titiler quelqu'uns alors qu'on y est meme pas en film.
Je cherche a comprendre quelque chose qui m'echappe. Ca revient souvent sur le tapis.

Turtle ton raisonement ne tient pas, il est propre a tes besoins. Je pourrais en dire de meme avec Redshift et ses aleas, mais a quoi bon ?
 
Dernière édition:
#86
Redshift est pourrri pour du scatter, et pas hybride, mais rapide en raytacer, et pour etre honnete, ses jours sont compte avec l'arrive du hyride chez Solid Angle et xpu chez Pixar.
C'est sur, mais autant le XPU arrive bientôt chez Rman, autant l'hybride d'Arnold on l'attend toujours... S'il tarde trop beaucoup de petites boites qui auront un pipe Redshift ou Octane bien en place ne se casseront pas le cul à changer pour Arnold, et les grosses n'ont que faire du GPU (à la limite pour le graphiste quand il bosse mais le calcul final sera toujours en CPU). Donc ils se seront cassé le cul pour pas grand chose... Mais je me trompe peut être et ce sera tellement ouffissime que tout le monde quittera Octane et Redshift pour Arnold (et en vrai pas mal de features d'Arnold me manque dans Redshift). Mais bon ça va faire quoi, 1 an et demi qu'on attend la solution GPU dArnold ? Plus ? Je sais que je suis pas très patient mais quand même... ^^
 

Gam

Membre très actif
#87
C'est sur, mais autant le XPU arrive bientôt chez Rman, autant l'hybride d'Arnold on l'attend toujours... S'il tarde trop beaucoup de petites boites qui auront un pipe Redshift ou Octane bien en place ne se casseront pas le cul à changer pour Arnold, et les grosses n'ont que faire du GPU (à la limite pour le graphiste quand il bosse mais le calcul final sera toujours en CPU). Donc ils se seront cassé le cul pour pas grand chose... Mais je me trompe peut être et ce sera tellement ouffissime que tout le monde quittera Octane et Redshift pour Arnold (et en vrai pas mal de features d'Arnold me manque dans Redshift). Mais bon ça va faire quoi, 1 an et demi qu'on attend la solution GPU dArnold ? Plus ? Je sais que je suis pas très patient mais quand même... ^^
j'ai vu la 1er demo du xpu il y a plus de 3 ans donc ca va. Ce n'est pas la priorite de Solid Angle pas plus que celle de Pixar.
Il faut garder en tete que Redshift bias a mort, Pixar un peu, Arnold brute force a fond, il est donc bien plus compliquer a adapter un core sur du GPU.
En sachant que Marcos, ne veut strictement aucune difference entre cpu/gpu.

Mais tu pointe bien le truc, j'y vois plus un avantage en lookdev et poser le lighting, le reste en cpu sur une farm cpu interne.
 
Dernière édition:
Haut