Blender 2.69, 2.70 etc

[Ethan Aeris]

Merci de ton retour sur le grease pencil.
N'ayant pas compilé cette branche, je devais me contenter des annonces et images diffusées.

Pour les strokes, de début/fin, dans la mesure où l’implémentation de bouts arrondis avait commencé, cela peut revenir sur la table.
Pour le reste (uv,motif) , oui, ça calme

concernant Freestyle ,j'ai cru voir un commit pour Eevee en offline, qui a été annulé dans la foulée, aka ascenseur émotionnel.

Sinon, l'univers m'a envoyé un signe/foutage de gueule :
au moment ou le support des cartes Fermi est enlevé de cycles, ma 1060 pascal rend l'âme, et je me retrouve
avec ma vieille 460 . ça fait tout drôle dans les dernières builds, de plus rien voir apparaître dans les préférences en Cuda.

[zeauro]

Pour le reste (uv,motif) , oui, ça calme

D'un autre côté, les bugs et problèmes évidents comme ça, ne font pas long feu.
Les types d'Hero ont du s'en rendre compte aussi.
L'UVfactor ne part plus en vrille à chaque update d'un paramètre.

Il y a toujours un petit glitch au moment où on trace et un UVfactor incohérent sur la première stroke dessinée.
Mais désormais, on peut bosser avec les strokes texturées.
Antonio a aussi réglé la suzanne 2D et il a aussi permis la variation de la strength.
Il a fixé les couleurs de l'onion skinning que je n'avais pas testé.
Il a ajouté un bouton UV rotation sur les modifiers Noïse et Smooth. Par contre ,le subdivide fout encore en l'air le mapping.

Evidemment que quand il se lance dans un truc : tout n'est pas opérationnel, tout de suite. Mais ça avance assez vite.

concernant Freestyle ,j'ai cru voir un commit pour Eevee en offline, qui a été annulé dans la foulée, aka ascenseur émotionnel.

Oui, le dev de Freestyle s'est un peu emballé. Mais Dalai a annoncé au dev meeting d'hier que le rendu des layers multiples serait supporté par EEVEE aujourd'hui.
Et effectivement, c'est le cas depuis une demi-heure.

Sinon, l'univers m'a envoyé un signe/foutage de gueule :
au moment ou le support des cartes Fermi est enlevé de cycles, ma 1060 pascal rend l'âme, et je me retrouve
avec ma vieille 460 . ça fait tout drôle dans les dernières builds, de plus rien voir apparaître dans les préférences en Cuda.

T'es pas le seul. Dans son dernier rapport, Campbell a expliqué que c'était son disque dur qui l'avait lâché, lui.

[zeauro]

L'optimisation du rendu Cycles des smokes par Kevin Dietrich est dans le master, depuis ce matin.

Lorsque l'on fait une simulation de fumée, le domaine est une bounding box qui va forcément contenir du vide autour de la fumée. Dans la 2.79, ce vide au rendu est analysé comme une partie du volume du domaine. Et donc, un tile qui ne contient que du vide à rendre peut être calculé très lentement.
Le principe de cette optimisation est donc de générer automatiquement un mesh de référence aux limites de la fumée pour que le vide du domaine n'engendre plus des calculs inutiles.

Pour une scène avec juste un panache de fumée, ça peut donc diviser par 2 ou plus, le temps de rendu.
Mais dans le cas extrême où vous remplissez tout le cadre de fumée; théoriquement, il ne faut pas s'attendre à un gain.
Pour ce genre de scène, il y aura peut-être une légère amélioration lorsque le step size pourra être réglé par objet et non pour toute la scène comme actuellement.

Il est possible de voir le mesh généré au rendu, en mettant un shader Diffuse dans l'output surface tout en conservant le shader des smokes dans l'output Volume.

Tout ça est automatique. Le seul réglage disponible en plus est l'Empty Space Clipping par rapport à la 2.79.
Il est à 0.001 par défaut et vous avez intérêt à le laisser bas, si vous voulez de la qualité.
Car l'augmenter veut dire supprimer les voxels les moins denses de la fumée du cache. Et sur toute la durée de la simulation, ça peut donner une animation incohérente avec de la fumée qui vient dont ne sait où ou des trous où la fumée disparaît avant pour réapparaître plus loin.
Mais si vous l'augmentez en y allant mollo, vous pouvez quand même gagner quelques dizaines de mégaoctets sur la taille du cache de la simulation. Cette valeur était masquée à l'utilisateur avant.
Je ne sais pas si ça sert vraiment à quelquechose de la révéler.
Parce généralement, si on a un cache lourd ; c'est qu'on a un cache avec détails. Et donc, on n'a pas envie de les virer.
M'enfin, elle va commander la tronche du mesh automatiquement généré.
Donc de façon pas du tout sécure, on peut quand même faire un Free Cache, la changer et faire un Bake Current Cache pour virer les détails sans recalculer la simu afin d'accélérer le rendu.

[zeauro]

La branche grease pencil a maintenant 3 gommes parmi les brushes.
Une qui efface l'entièreté de la stroke dès qu'elle la touche.
Une soft qui réduit la thickness avant de supprimer les points de la stroke comme celle de la 2.79.
Et enfin une hard qui supprime les points sans toucher à la thickness de la stroke.

[zeauro]

Depuis que Sergey a changé le motion blur, on avait un nombre de steps foireux trop limité.
Brecht vient de changer ça.
https://developer.blender.org/rBdb333d9 ... 4dafb27cc0

[zeauro]

Il n'y a pas grand chose d'autre qu'un travail de la tambouille interne de nettoyage et d'optimisation du code, en ce moment.

Mais Brecht a fait passer dans le master un patch de Matt Heimlich.
Cycles peut désormais baker une map de roughness.

Et Dalai a restoré le "M" (move to layer dans la 2.79b) en tant que Move to Collection dans la 2.8.
En faisant un simple clic, on change l'objet de collection.
En faisant un ctrl clic, on l'ajoute à une autre collection mais il reste compris dans sa précédente collection.

[Ethan Aeris]

c'est un ensemble de petits détails qui améliorent l'expérience.
Conjugué au nouveau système de undo, ça devient presque indispensable.
Je prends l'exemple d'un tracé de grease pencil.
Si on se trompe de gomme (totale au lieu de segment), suivant le mode, le undo serait passé à la trappe dans l'ancien système.
Le Redo n'a pas encore l'air totalement fonctionnel à l'heure actuelle.

Paraît qu'il y aurait peut être un système d'historique, ça veut dire qu'on pourrait remonter directement à n'importe quelle étape, ou c'est moi qui extrapole ?

trouvé une petite astuce (sûrement déjà connue des vétérans ) dans la dernière build grease pencil.
En ajoutant un modifier array, et en mettant juste +1 dans un axe en count.
Si on fait un scale en -1 sur ce même axe, on fait un dessin en symétrie.
L'actualisation ne se fait pas en temps réel et faut jouer avec l'offset pour éviter les chevauchements, mais c'est déjà un pas.

[zeauro]

Mouais. Enfin dans la 2.79b, le grease pencil n'est pas un objet. Il n'a pas de mode Draw.

Donc il n'y a que les gens qui ont déjà fait mumuse avec le grease pencil de la 2.8 qui voient la différence.

Par contre ce qui va parler à tout le monde, c'est l'édition d'un mesh.
Dans la 2.79b, il y a un undo global pour le mode Object et et un autre temporaire en mode Edit.
Si bien qu'après avoir fait 15 manips en mode edit, faire un undo juste après en mode object les efface toutes.
Mais pas dans la 2.8, il n'y a plus qu'un seul undo. Dans ce cas-là, faire un undo nous repasse en mode edit.

Pour ce qui est de l'historique, de toute façon, tu exagères. Pas n'importe quelle étape. Il y aura forcément une limite du nombre d'étapes en mémoire ou même si il est enregistré dans le fichier .blend, tu seras obligé de l'écraser à un moment.
Maintenant, il n'y a rien de concret sur une façon de présenter l'historique.
Mais ça serait pas mal effectivement, dans la mesure où maintenant on se retrouve obligatoirement à annuler les étapes une à une qu'on puisse en éliminer plusieurs d'un coup.

C'est un truc de tordus : cet array du grease pencil !
Franchement, ils ne pouvaient pas reprendre le même que pour les mesh et faire un mirror.

[cedric]

C'est cool d'avoir un meilleur undo, mais j'avoue que c'était pratique de pouvoir supprimer toute une partie de modif d'un coup.

[zeauro]

Vous êtes déjà probablement tous au courant qu'Hero est sorti.
Mais il faut au moins le mentionner dans un thread comme celui-ci.
https://cloud.blender.org/p/hero/

L'équipe de la codequest a défini un plan d'attaque, la semaine dernière.
Et cette semaine, on sent qu'ils crochent dedans.
Le nombre de commits par jour double ou triple dans la branche de la 2.8 (passant de 10-20, la semaine dernière à 30-40-50, cette semaine). A côté, 2 branches temporaires (une sur les modifiers et une autre sur le drag'n drop) ont été crées.
Il n'y a pas grand chose à montrer ou à tester.
C'est de la mise en place de logique interne, de bases solides pour la suite.
Sergey résoud des bugs de particules pour Spring. Campbell a mis dans la 2.8 de base du multi-object editing.
Clément améliore l'outline en object mode.
Tout ça, c'est du taff qui ne se ressent pas forcément mais il y a du taff.

Et je finis par ce qui est nouveau : le Workbench.
C'est l'engine de base qui va grouper tous les draw modes (Solid , Wire etc...) standards.
Ensuite, tous les autres engines doivent avoir la possibilité d'utiliser les draw modes du workbench + ceux qui leur seront propres. L'idée étant que pour certain workflow, on définisse de nouveaux draw modes.

Pour l'instant, il n'y a que deux draw modes : Solid et Rendered.
Le Rendered donne le résultat de l'engine actif (celui qu'on avait jusqu'alors de base pour Clay, EEVEE ou Cycles).
Mais le Solid a deux options : Flat Lighting pour un aspect shadeless et Studio Lighting (pour l'instant, un ombrage OpenGL très basique. Mais il devrait évoluer et supporter un éclairage à partir d'HDRI).
La seule option d'affichage restaurée est l'Object Color.
Il n'empêche que rien que ça permet d'espérer pouvoir bosser avec plusieurs viewports affichant différemment la scène.

[cedric]

C'est top tout ça, j'ai hâte d'en voir plus.

[cedric]

zeauro ça te dirait qu'on fasse un podcast special blender 2.8 vu que tu maitrise parfaitement le sujet.
A voir si clément serait intéressé, ce serait bien top.

[zeauro]

Ben, clément est en pleine codequest, là. C'est peut-être pas le moment de le déranger.

Depuis le dernier podcast fait sur le sujet, il n'y a pas grand chose de nouveau à montrer.
Mais je pense que très vite, il y aura un truc nouveau à apparaître du jour au lendemain.
C'est juste le tout début du workbench. Il n'y a pas encore de quoi faire une heure de vidéo.

Tu ne voulais pas plutôt faire un podcast sur le Grease Pencil 2.8 ?

[cedric]

ok,

Faut voir avec les gars pour le grease pencil, si ça leur dit mais oui c'est une bonne idée.

[zeauro]

Il y a eu 2 nouvelles vidéos provenant de la codequest :



Après quelques jours à trifouiller la topbar et la toolbar, ils sont passés à des avancées sur EEVEE, le depsgraph et le workbench.

Lukas Stockner, développeur du denoïser de Cycles, devrait les rejoindre pour ajouter la gestion d'UDIM à la 2.8.
Il a déjà commencé à remettre à jour la branche sur l'unwrapping utilisant l'algorythme SLIM créée par Aurel Gruber, il y a un petit moment.
http://youtu.be/PLUoLQUK3-s

Dans le master, Il a récemment fait en sorte que le scale des area lights puisse être appliqué.
Campbell a aussi résolu le problème de la modification de la transparence du vertex color changeant la couleur peinte en noir. Donc si vous voulez bénéficier du vertex painting amélioré dans le gsoc de l'année dernière; vous pouvez enfin le faire sans plus aucun souci dans le master.

Dans la branche du grease pencil, les couleurs sont devenues des matériaux ajoutées dans des slots de matériaux.
On peut donc remplacer une couleur avec ces paramêtres Fill et Stroke propres par une autre avec d'autres réglages. On peut faire des dérivés assez facilement et associer un matériau à un brush.
On peut copier les matériaux de l'objet actif à la sélection. Donc au final, on ne perd rien.

Et la branche mantaflow a adopté un nouveau système de cache où on bake séparément les particules de la simulation et le mesh high res pour les fluides ou la grid pour les smokes. Ca permet d'aller beaucoup plus vite au niveau du baking.