Blender – Juggernaut VS analogue synthesizer

Qu’il est bon de retrouver Blender avec un véritable projet « from scratch » ! Ayant englouti les vidéos de Cédric Lepiller sur ses trucs et astuces en matière de modélisation, puis me rendant à l’évidence que son plugin Speedflow était un véritable couteau suisse que tout bon artiste se devait de posséder, je partais donc sur de bonnes bases pour remettre un pied dans le monde de la 3D.

Au départ, je me suis demandé comment modéliser un capuchon de potentiomètre vintage type Moog… Et une chose en entraînant une autre, j’ai construit un synthétiseur complet en 7 jours (les images ci-dessous ne sont pas le rendu définitif, mais on s’en approche).

EDIT : petite salve d’images finalisées !

Chrome et les DPPX

Aujourd’hui je découvre que le thème WordPress « DeCente » installé sur un mini-site au boulot ne passe pas sur Chrome OSX. Le texte, à l’affichage de la page, est manquant, comme s’il était blanc sur blanc… D’ailleurs Chrome affiche un avertissement dans la console :

Consider using ‘dppx’ units instead of ‘dpi’, as in CSS ‘dpi’ means dots-per-CSS-inch, not dots-perphysical-inch, so does not correspond to the actual ‘dpi’ of a screen.

(trad. : Privilégiez les ‘dppx’ plutôt que les ‘dpi’, car en CSS les ‘dpi’ concernent les points-par-pouces-CSS, et non pas les points-par-pouces réels de l’écran.)

Que signifie cet obscur message ? Et bien ce thème utilise un Bootstrap dopé, avec une propriété dpi (dot-perinch) dans ses media-queries, de façon à gérer l’aliasing selon les différents types d’écrans du marché. Car oui, le bon vieil écran 72 dpi de nos jeunesses va rejoindre le rang des antiquités…

Actuellement, on a deux cas de figure :

  • les écrans classiques, en 72 ou 96 dpi,
  • les écrans « folkloriques » (220, 227, 264 et 326dpi pour les terminaux Retina, 306dpi sur le Galaxy S3, 440dpi pour le HTC M8)

Ajoutons que le dpi natif de CSS est basé sur des inches (pouces) virtuels, et non pas sur les inches réels de l’écran… Ça y est, on a franchit le mur du çon à pleine vitesse.

Bref, devant l’habituel manque de réactivité du W3C, Google avait introduit une propriété dpi dans son moteur Webkit, pour gérer facilement l’affichage de texte/images sur les nouvelles dalles supérieures à 72/96dpi. Jusqu’ici ça paraissait plus ou moins acceptable (sauf pour la concurrence qui a du se mettre au diapason, de force).
Mais aujourd’hui, Chrome décide de privilégier une nouvelle métrique, et ne supporte plus que les dppx (dot-per-csspixel). Car comme les pouces sont totalement relatifs à CSS et non à l’écran utilisé, Chrome base désormais son affichage uniquement sur les pixels de la dalle (device-pixel-ratio), bien réels, eux.

Je vous passe les calculs de ratio, pixels, pouces, carottes, trains qui se croisent… Pour arriver à l’affirmation suivante :

1dppx = 96dpi.

À vous maintenant d’en faire ce que vous voulez avec vos media-queries. Genre détecter que si « écran > 3,3958 dppx » (soit 144dpi), toutes vos images (logos, icônes) seront remplacées par des versions HD qui apparaîtront nettes sur les Retina.

C’est louable, personne n’aime les images floues.

Cependant, dans le cas qui nous intéresse, le designer du thème DeCente a utilisé une librairie en dpi, ce qui veut dire que son thème est amputé d’une partie de sa portée initiale, car Chrome n’estime pas devoir assurer une retro-compatibilité concernant ses propres erreurs.

Comme à son habitude, Google n’en fait qu’à sa tête : lancer un standard de force, puis tout changer sur un coup de tête. Le travail principal des webdesigners n’est pas de suivre les girouettes.