Blender 2.69, 2.70 etc

[Ethan Aeris]

c'est bien beau tout ça, mais il est où l'undo illimité même avec 1 Mo de ram que même photoshop ne sait pas faire
Blague à part, j'ai l'impression que c'est la guerre dans les forums de Blenderartist, avec les pleurs du départ du game engine (que j'aimais bien) ,alors qu'il a été clair qu'il aurait un successeur amélioré.

Mais le pompon de la foire d'empoigne, c'est dès qu'il s'agit de la nouvelle UI.
entre ceux qui font juste des propositions, et qui se prennent des rafales pour rien, et ceux qui veulent imposer leurs vues en mode "nobrain", ça m'a un peu éloigné des forums.

ça m'a aussi surpris le résultat du sondage sur le click gauche/droit, ça a remis beaucoup d'idées préconçues en cause.
mais bon, le sondage ne prend pas en compte tous ceux qui ont essayé Blender et qui l'ont rage-quitté au bout de x minutes (je m'inclus , jusqu'à la version qui permettait de choisir le clic)

Pour le vertex painting, c'est cool qu'une partie des travaux de Darshan aient été intégrés par Campbell.
ce que tu dis sur la branche grease pencil fait penser à une gestion plus pratique des couleurs/materiaux.
mais j'ai l'impression qu'il manque toujours ce feeling crayon.

en croisant les doigts pour que la branche mantaflow atterrisse enfin un jour dans la master ,
niveau qualité, peut on espérer que cela soit au niveau de l'addon flip fluids ?

et même si il y a encore beaucoup de choses à définir, je l'aime bien la nouvelle UI, surtout qu'elle réussit le tour de force de garder la rapidité des anciens raccourcis claviers avec une nouvelle interface plus aisée à comprendre.
on peut la redimensionner, il y a moins de de scrolling dans les menus.
je viens de voir que les pop over de la top bar peuvent être ouverts au survol de la souris sans cliquer comme les menus.
La sélection peut se faire enfin sans bloquer la navigation.
c'est que du bonheur.

[cedric]

Même si je me suis bien fait descendre, le sondage a montré que le click droit est en fait plus utilisé que le clic gauche, c'est donc bien à savoir.

Par contre pour le choix par defaut c'est le clic gauche qui l'emporte.
En gros, les gens ont apris blender avec et souvent la 3D en même temps et s'y sont fait et si il y a plus de monde qui l'utilise c'est à cause de ça mais ce n'est pas le choix préféré.
Perso gauche ou droite je m'en fout, ce que j'aimerait c'est avoir le choix sur le splash screen.

[zeauro]

[cedric]

On verra bien.

Il y a des choix bizarre comme ce redo.

[Ethan Aeris]

Les streams de Pablo sont cools, à la décontract bière à la main
Les vidéos faites pour les codequest permettent aussi de mettre des visages sur tous ces super développeurs, il y a l'air d'avoir une bonne ambiance.

d'habitude , je regarde les streams x jours après et j'avance rapide les vidéos streams en m'aidant des miniatures , mais je me suis fait avoir par le dernier titre qui disait un truc genre"on the ashes of the game engine".
je croyais qu'il allait aborder le sujet de l'interactive mode.
résultat, j'ai regardé le stream en entier. bon ,c'était pas pour rien, il y avait des trucs intéressants mais rien au sujet du bge next.

en regardant developer.blender.org , j'ai vu qu'ils comptaient aussi refaire enfin le curseur 3D, et il y avait des bonnes propositions de Cedric pour les raccourcis clavier.
un vrai snap d'origine et des facilités pour en faire un point de pivot plus pratique.

la création des primitives à la q_p addon, ou en tout cas par widgets semble aussi à l'étude.

lors d'une conversation, on avait abordé avec Dairin0d (l'auteur du géniallisime Mouselook Navigation addon ) de se mettre en rapport avec les devs, pour se mettre à jour de l'api et leur suggérer un support plus avancé des touches+ souris enfoncés puis lachés 'le fameux alt+clic gauche qui sert à tout pour naviguer dans brush).
en effet, le concept (touche clic-laché suivant contexte peut être étendu à certains modifiers ou pour contraindre certains axes ou modifier à la volée certaines propriétés).
cela désengorgerait la keymap puisque la même touche peut être attribué "deux fois" ... je sais pas si je suis clair

EDIT : le document de référence "Industry Standard Keymap" de William Reynish propose enfin d'accéder directement aux modes édit vertex/edge/face avec les touches 1,2,3 , puisque celles ci ne sont plus réservées aux layers.

les autres touches numérotées permettront d'accéder aux différents modes sculpt, paint, etc.
le tout en étant plus en adéquation avec les standards de l'industrie.

[Nicolas R]

Salut, j'avais pas vu ça mais c'est vraiment super : circular array modifier, tip top, mais à ceque je comprends il vas être viré?
https://www.youtube.com/watch?v=vzKFHubAFzQ

[zeauro]

C'est un patch qui a été fait par un développeur qui ne fait pas partie de l'équipe de la codequest.

Il s'est pointé sur la mailing-list, y a demandé comment on faisait des modifiers pour la 2.8.
Les gars lui ont répondu. Il a fait ses modifiers de son côté et a immédiatement proposé de les intégrer.

Ce à quoi, campbell a répondu que la façon dont il s'y était pris n'était pas la plus efficace, qu'il vaudrait mieux passer par des duplis et a rejeté son patch.

Thomas Beck et moi, on a répondu sur la mailing qu'on a toujours eu des moyens de s'en passer. On peut modéliser la même chose avec l'array de base et un empty, un screw modifier sur un cercle ou une Curve avec un Bezier circle en bevel object ou utilisant des dupliframes. Voire passer par les animation nodes pour des animations.

J'ai continué sur Blenderartists en disant que le dev des animation nodes devrait participer à la codequest, fin juin.
A ce moment-là, il dessinera peut-être ce que seront les modifiers nodes, repoussés à après la codequest mais qui devraient quand même advenir lors de la série 2.8x.

Donc avoir le soft le plus efficace possible, ne consiste pas à intégrer immédiatement le premier outil avec démo sans se poser de questions.
On pourrait se poser la question de rendre plus intuitif l'array existant au lieu de lui garder un fonctionnement pas terrible et d'en rajouter un autre avec plein de méthodes pas forcément utiles.
Il y a déjà eu d'autres modifiers proposés des années auparavant tout aussi intéressant qui n'ont pas été retenus à cause de la perspective de modifier nodes.

Maintenant, il y a aucun souci avec le créateur de ce patch.
Il a décidé d'aider les développeurs de la codequest en s'occupant de mettre à jour dans la 2.8, le code de modifiers déjà présents comme le Triangulate.

L'équipe de Spring va arriver en Juin. La priorité pour l'instant est d'avoir le maximum d'opérateurs supportant le multi-object editing et de modifiers supportant le nouveau depsgraph et le copy-on-write.
C'est pas de se rajouter du boulot avec des nouveaux outils de mod, tout de suite.
Quand ils auront des utilisateurs sous la main, à l'étage en dessous, ils pourront aller plus loin que juste tester les bases de la 2.8.

[zeauro]

Une vidéo à ne pas manquer.

[zeauro]

Aujourd'hui, c'est la fin des groupes. Brecht vient de les remplacer par les collections.

Dans l'outliner, il n'y a plus que des collections.
Les instances de groupes deviennent des instances de collections. Collection Instance
Pour l'instant, la différence est qu'on peut les créer à partir de l'outliner.
Mais une instance de collection est un empty utilisant l'option duplicollection; comme une instance de groupe est un empty utilisant l'option dupligroup.
Tous les champs de l'interface n'ont pas encore été réécrits. Mais ce que vous allez trouver dans un champ vous demandant un groupe est une collection.

Pour résumer, il n'y a pas de changement énorme de comportement.
Vous auriez déplacé un objet sur un autre layer. Vous le mettez dans une autre collection en appuyant sur M.
Vous auriez créé un nouveau groupe avec la sélection. Vous créez une nouvelle collection en faisant Ctrl G.

Bizarrement, la vue collecions de l'outliner a été renommée View Layers.
Mais, du coup-là, pour l'instant, on a perdu ce qu'apportait la première mouture des collections.
Tous les view layers qu'on peut créer sont identiques.
Là, il y a un problème de logique. Ca ne peut pas rester comme ça.
L'intéret d'avoir des view layers : c'est qu'ils affichent et rendent des collections différentes.
Mais là, en masquer une ou en supprimer une dans l'outliner, la masque ou la supprime pour tous les views layers.

[cedric]

Comme pour l'UI on se demande si ils savent où ils vont.
Il y a bien un plan de base mais on dirait que plus ils avancent plus ils se rendent compte que ça ne marche pas super et qu'ils essaient de trouver une solution.
Bon, c'est comme ça pour tout mais là c'est assez flagrant.

Qu'en est il de la possibilité de cacher un objet ? Va falloir créer une collection et la cacher ?

[zeauro]

D'un autre côté, pendant que j'écrivais mon commentaire, brecht a ouvert plusieurs tâches sur d.b.o disant qu'il restait du travail à faire du côté de l'outliner.

Donc,c'est peut-être transitoire. Mais grosso modo, pour l'instant, c'est comme-ci on avait qu'un layer pour le rendu.

Pour l'instant, il faut toujours créer une collection si on veut cacher un objet.
Mais ça fait un moment que ça ne marche pas ça.
Ils ont répondu sur BA et ont pondu des tâches sur d.b.o. où masquer les objets sans création de collection ou restaurer la vue d'isolation sont des objectifs.

Il y a un moment où ça devrait réapparaître.
Ce serait exagéré de dire qu'ils ne savent pas où ils vont.
Mais il y a une différence entre connaître le chemin et arpenter le chemin. Donc, quand ça ne vas pas, ils décident de changer de parcours.
C'est pour que prendre la décision soit plus facile à faire qu'on les a enfermé à 12 dans la même pièce.
C'est le principe de la codequest.

Après tout, ça peut très bien fonctionner quand le système d'overrides sera là.
Ca dépend si la visibilité peut y devenir sensible dans l'outliner ou les properties.
Il faut peut-être juste les laisser travailler un peu plus.
Mais ce qui est sûr : c'est que tel quel ; ça ne fonctionne pas encore.
Même, si on fait 2 scènes différentes et on y lie la même collection. A partir du moment où une collection est masquée dans un renderlayer d'une scène, elle l'est pour tous les renderlayers de toutes les scènes.

[lapineige]

La vidéo sur le NPR mets l'eau à la bouche.

Mélanger les shaders "classiques" et du NPR, ça peut être vraiment sympa.

Pis bon en temps réel, c'est toujours aussi cool

[Ethan Aeris]

c'est super intéressant et flexible, mais la mise en place du shader toon est encore un peu lourde.
Il faut encore mixer des nodes, sans compter qu'il faut rajouter par dessus Freestyle si on veut des contours.
Il faudrait vraiment un "principled" toon qui comprendrait au moins le nombre d'aplats de couleurs que l'on veut, l'épaisseur des contours(0 si on n'en veut pas) qui pourraient être couplés à une texture par un slot.
Une option pourrait permettre à cette texture de "suivre un sens" des contours, horaire ou anti horaire par exemple.
plus pleins d'options auxquelles je n'ai sûrement pas pensé

[lapineige]

C'est peut-être quelque chose qui viendra avec l'add-on évoqué dans la vidéo. Un groupe intégré de base par exemple.

[cedric]

Oui ils ont l'air de vouloir faire un principled par typde de shader.
Il y aura celui pour les hair si je ne me trompe pas.