Ah mais je suis tout à fait d'accord, c'est du 100% egoïsme ! Ouais je me sens grave volé ! :-p mais mon avis importe peu, et on verra ce que ça amène.

Mon côté professionnel me dis que ça amènera des artistes d'autres moteurs de rendus, qui viendront apporter un avis ultra constructif. Mais c'est tout ce que je peux lâcher là tout de suite en positif

Cycles n'est pas vraiment le centre du monde.

Les autres moteurs OSL n'ont pas beaucoup de choses à lui envier.
Dans le monde du propriétaire, les prod hollywoodiennes sont réalisées avec Arnold.
Et octane semble toujours plus connu chez les designers/archi que le couple Blender/Cycles.
Dans le monde du libre, Coraline Mescaline a été rendu avec Appleseed et beaucoup de démos techniques pour siggraph ont été rendu avec Mitsuba ( il n'est pas OSL).

Au moment de l'annonce du changement de licence, un type a dit qu'il ferait un export pour Maya. Mais depuis pas de nouvelles. Tout le monde a l'air de s'en foutre. Comme si l'info n'était pas passé.

V-Ray 3 va être compatible avec OSL 1.3 alors que Cycles est déjà à la spécification suivante.

En gros, Cycles fait partie des moteurs à essuyer les plâtres d'OSL. Le risque est qu'on lui colle une étiquette d'instabilité non méritée.

En fait, les moteurs de rendu, il y en a vraiment une floppée. On dirait que faire son moteur est un des exercice préféré des devs 3D.
Donc Blender a permis d'apporter un éclairage et une protection sur Cycles en le sortant de la masse.
Mais il y a des gens qui sont totalement réfractaire à blender et qui fuient la gpL comme la peste.
Il ne faudrait pas que Blender devienne un boulet pour Cycles.

M'enfin, quoiqu'il en soit, l'avenir semble radieux au moins pour le partage des shaders.

Sinon, personne n'a l'air de pleurer les stars du BI virées de la 2.70 ?

Citation :
Sais-tu pourquoi ils les suppriment ? Je ne voit pas de raison, à part le fait qu'elles ne sont pas ou peu utilisées (perso je les ai utilisées 1 seules fois).

Bien que ce soit beaucoup plus lourd à mettre en place; ils estiment qu'on peut arriver au même résultat avec des particules et qu'ils peuvent les supprimer sans problème.

C'est simplement pour faire de la place.

Plus il y a de features dans Blender, plus la tâche devient lourde pour les développeurs.
Si personne ne les utilise; à quoi bon perdre son temps à lancer des .blend tests pour vérifier que ça fonctionne toujours ? à quoi bon perdre de l'espace disque en maintenant leur code dans chaque révision ?

Sans compter que ça libère un peu l'interface qui deviens de plus en plus chargé au fil des features rajoutés sur les nouvelles versions. J'avais d'ailleurs pensé a creer un topic sur les features qu'il serai temps de supprimer de par leur inutilité.

Citation :

Généralement, ce genre de thread est contre-productif.
Une perte de temps pour tout le monde.

Les néophytes ne connaissant pas le soft approuvent en masse la suppression des features qu'ils ne comprennent pas.

Des pros les utilisant n'ont pas le temps de laisser de commentaires pour dire qu'elles sont indispensables parce qu'ils bossent.

Des jeunes devs zélés les suppriment.

Les devs mentors ne se souviennent plus à quoi ça sert et laissent passer parce qu'ils sont pris par autre chose.

Alors les pros se plaignent et les devs les remettent.

Je ne compte plus les fois où j'ai dû défendre des trucs.
La dernière en date était la simplification du cast shadows qui confondait les buffershadow et les rayshadow.

Personnellement pour les stars, j'aurais préférer qu'ils les gardent. Sans Freestyle, le BI serait vraiment en train de mourrir. Alors que là, il a eu droit à des améliorations dans la 2.70

C'est quand même beaucoup moins compliqué de faire un starfield que de gérer et compositer des particules.
Et parfois, c'est suffisant.
Je pense aux débutants qui se précipitent sur les particules et n'arrivent à rien pour au final cracher dessus. Des mecs comme le blender guru.

Citation :

Tu es sur de ton coup pour Coraline ? C'est du stop motion ce film...

Citation :

Ca c'est sur que ce n'est pas vrai. OSL est développé par Sony ImageWorks et ils l'utilisent pour leur prod, donc il n'y a pas de platres à essuyer du tout. Le fait que Cycles supporte l'OSL est un énorme avantage et permet justement à Cycles d'être pris au sérieux par l'industrie.

L'instabilité de Cycles n'a d'ailleurs pas grand chose à voir avec OSL. Les killers features commes les volumétriques ou les SSS (qui ne sont pas méga stables) n'ont rien à voir avec l'OSL.

Citation :

C'est le cas ! :D La création d'un moteur de rendu est vraiment très gratifiant, super intéressant,et comporte pas mal d'aspects qui plaisent aux développeurs, donc c'est normal d'en voir fleurir ici et là.

Et pour revenir sur la libération de Cycles, il faut voir que Blender utilise des librairies fournie par l'industrie (OSL, open subdiv), il est normal, et dans l'esprit du libre, de redonner en échange du savoir faire de la fondation...

Citation :

Je le confonds toujours avec leur court Fetch (Mescaline).
Je suis persuadé d'avoir lu que les gars de Coraline avait testé un truc pour leurs rendus 3D. Je n'arrive pas à remettre la main sur l'article que j'avais lu. Mais c'était très sûrement autre chose qu'Appleseed.

Citation :
Depuis que je suis ici, j'essuie.

J'ai bien mis un pluriel. Il y a probablement plus de retour pertinent qui vient des utilisateurs d'Arnold.

Ce n'est pas parce qu'ils l'utilisent, le testent et le modifient en un second temps que tout était déjà parfait d'emblée.

Si les devs de Cycles ne voyaient jamais rien à redire à OSL, il faudra m'expliquer pourquoi ils se retrouvent nommer comme contributeurs dans la dernière spécification.

OSL, c'est aussi du libre. Il ne s'impose pas comme un langage venant d'une boîte se croyant omnisciente, omnipotente, infaillible et propriétaire.

Ca reviendrait à dire que le retour des testeurs de la RC de blender n'a pas d'importance puisque d'autres ont testé le master.


Citation :

Il est pris au sérieux par les gens qui s'intéressent à la tambouille. Mais ce n'est pas la majorité des graphistes.

Citation :

Ben quelque part, si. Ca a à voir avec le fait qu'il ne les gère pas pour de bonnes raisons ou que Cycles n'exploite pas OSL pour ça.
Pour l'instant, OSL est tout jeune et tout beau. Il va grossir.

Tout comme on demande à Cycles de grossir en features.

Mais c'est bien dans la façon d'utiliser judicieusement le language pour certains trucs et de la même manière OpenSubdiv ou OpenVDB pour d'autres; et dans la façon d'articuler tout ça que se trouvent les difficultés et différences entre les moteurs.

Yeah La 2.70RC est là.

Salut la compagnie,
J'ai eu le problème dans la 2.69, et je vois que ça persiste dans la 2.70 RC.

Lorsqu'une Curve est utilisée avec des Modifiers Hook, l'inversion du sens de la Curve
change la position des points de contrôle qui sont "hookés".
Un essai est plus parlant qu'une description :
http://www.pasteall.org/blend/27421

Il y a une liste des manipulations à faire dans la zone de texte au-dessus de la vue 3D.
Ça ne prend pas plus d'une minute à tester.

Est-ce un bug ? Est-ce connu ? Faut-il le signaler ?
Merci d'avance.