Hello tous!

Comme j'en bouffe tous les jours en ce moment j'ai décidé vous faire partager le très intéressant billet de Master Zap: Making Better Metal with mia_material.

Ceux qui l'ont déjà lu en long en large, passez votre chemin, je ne fait que répéter les dires du maitre.

Les autres, avec un peu de chance, vous allez apprendre quelque chose aujourd'hui.

Un bon metal, c'est d'abord une bonne map HDR

Avant de commencer, aller récupérer une des magnifiques image HDR de sIBL Archive.

Elles sont toutes sous licence Creative Commons Attribution-Noncommercial-Share Alike 3.0, ce qui veut dire que vous ne pouvez pas gagner d'argent avec et que si vous les utilisez (comme ça va être le cas ici) il faut citer l'auteur et partager votre travail à l'identique.

Pour le choix de l'image. J'ai toujours eu une préférence pour Factory Catwalk:

Et go Maya!

Comme d'hab', ouvrez Maya, mental ray, preset Production:

Filter en Triangle:

Puis on créé une IBL:

Et on y met notre hdr:

Créez une sphère et appliquez lui un mia_material_x:

Virez le highlight (je le fait car je ne peux pas plus le supporter personnellement):

Mettez la Specular Balance a 0.0

Pour avoir une colorimétrie correct, on applique une correction gamma:

createNode mip_gamma_gain;
setAttr "mip_gamma_gain1.gamma" 2.2;
connectAttr -f mip_gamma_gain1.message perspShape.miLensShader;

Et voila:

Bon, pour faire du métal, a priori, on met la color en blanc et le weight a zéro, la reflectivity a 1.0 et on coche la case Metal Material:

Comme on est des graphistes on met aussi de la couleur:

Le centre de la sphère semble sombre ça ne ressemble pas vraiment à du métal.

Si vous connaissez un peu le mia_material, vous savez qu'il existe un paramètre dans l'onglet BRDF pour donner les deux valeurs extrêmes de reflection quand la surface est face à la camera et quand celle ci est complètement perpendiculaire (0/90 Degree Reflection). Avec un autre paramètre qui définit la courbe pour passer d'une valeur à l'autre.

Pour faire du metal à priori, il suffit de monter la première valeur (0 Degree Reflection) à une valeur proche de 1.0:

Oaaah De l'or qui briiiiille!

Bon, et bien en fait, vous n'y êtes pas complètement.

Là vous avez fait un bête miroir jaune... Dans le fond c'est assez proche du résultat final. Mais un des grand challenge du "Physical Based" c'est bien que ce n'est plus simplement une question d'oeil.

Et pour avoir un comportement de métal plus réaliste, il va falloir regarder du coté de Fresnel (si si).

Donc vous cochez la case:

Ne vous inquiétez pas, ce n'est pas le résultat final!

Maintenant, ce que vous allez faire, c'est mettre l'index de refraction (oui oui, reFRACtion) a 25:

La différence est assez subtile (comparez avec le Keep image de Maya) mais le second se rapprochera beaucoup plus d'un métal physiquement correct, notamment sur les bords.

En fait, pour le métal, la courbe qui définit la valeur de reflection en fonction de l'angle de la surface par rapport à la camera est très particulière (voir sur le billet de Zap). Quand elle se rapproche de 90 dégrées, elle descend pour remonter en flèche.

Quand à la théorie. Je doit avouez ne pas maitriser la chose (Master Zap non plus d’ailleurs):

Metals are indeed not refractive, and are indeed not dielectrics (meaning, electrical insulators). They are Conductors, and for some baroque reason these are also considered to have an "Index of Refraction".

Comme je suis du genre curieux, j'ai fait un peu de recherche (d'un niveau bien trop élevé pour moi) et j'en ai conclu que (Attention, grand moment de mathématique a trois francs six sous ):

• L'index de réfraction est le "ralentissement" de la lumière quand il entre dans un "milieu" (un material).
• Cet index dépend de plusieurs paramètres dont la perméabilité diélectrique (material conducteur, ou pas). En effet, la lumière est une onde électromagnétique (Maxwell is watching you) donc (et c'est ça qui est fou!) la conduction d'un material joue un rôle dans la "déformation" de la lumière qui le traverse.
• Les coefficients de Fresnel intervenant à l'intersection de deux milieux ayant des indices de réfraction différent (toi tu rentre déformé comme ci, toi tu rebondie déformé comme ça) explique la relation qu'il y a entre l'index de réfraction et la reflection d'un material. En gros, lors d'une "transition" entre deux milieux ayant des index de réfraction différent, il y a une reflection qui se forme.

Perso, ça donne envie d’être physicien. J'imagine la révolution que ça a dut être dans la physique optique ça. D’ailleurs, si un physicien passe dans le coin et que je me suis complètement planté, qu'il se fasse un plaisir de m'insulter violemment dans les commentaires, je suis tout ouïe à une explication clair du phénomène.

Bref:

Fresnel + index de refraction sur un material 100% opaque = variation de la reflection.

Liens

Parce que je serai ravis de savoir si vous avez mieux compris que moi.

• Équations de Maxwell
• Indice de réfraction
• Permittivité diélectrique
• Perméabilité magnétique
• Coefficients de Fresnel

Je vous invite aussi a regarder ce PDF pour Maxwell Render (auteur: Roch).

Sur ce pdf, on voit que la reflection varie en fonction d'un curieux paramètre nomme Nd (Quand il passe a 10, on voit très clairement une reflection). Et d’après Wikipedia, Nd correspond a l'index de réfraction d'un medium dont la longueur d'onde est de 589.592 nanomètre (La raie de Fraunhofer D du spectre solaire. Le sodium... Et oui, ça renvoi loin et je vois pas pourquoi cette valeur la en particulier...).

En espérant vous avoir apporté quelque chose...

A bientôt!

MAJ 20 Mars 2012

Suite au commentaire de Tristan, j'ai demandé sur le forum de mental image d’où sortait ces index de refraction bizarre (25, 40, 50 etc...). rlevenne explique clairement qu'il s'agit d'un hack pour imiter la courbe de reflection du métal mais que les valeurs ne représentait rien mathématiquement parlant. Apparemment, le mia_material utilise l'approximation de Schlick pour calculer la BRDF. Cette approximation est rapide mais ne gère pas les index de réfraction complexes. Pour faire un métal physiquement correct, il faut une autre information: L’Extinction (la valeur k sur cette page). C'est un paramètre que Maxwell expose. Bref, si vous êtes intéressé, lisez le post.

Hello tous!

J’espère que vous avez passé de bonnes fêtes! Bonne année à tous! (Oui, je sais, ce n'est pas encore passé mais il est 2h du matin et on est le 31 donc vu qu'a priori aujourd'hui tout le monde va préparer sa soirée, personne ne verra ce billet avant 2012... A part, peut être, les GoogleBots... )

Avant de continuer, je vous prévient de suite, c'est un billet complètement osef.

J'avais juste envie de vous faire partager ce que j'ai reçu pour Noël!

Levitron Omega, c'est plus fort que toi!

Ça, c'est ma môman qui me l'a offert! C'est un peu le cadeau de geek par excellence (elle connait son fiston ma môman).

C'est une toupie qui flotte sur un aimant en anneau. Il faut quelques minutes pour équilibrer le socle (tout doit être parfaitement plat sinon la toupie "glisse") et lester la toupie (sinon elle est trop légère et pas assez stable).

Pour voir le truc en live:

Et si vous êtes pauvre ne voulez pas dépenser d'argent la dedans, vous pouvez toujours vous la fabriquer vous même.

OpenGL Superbible, la Bible-tout-court peut aller se rhabiller...

Sur les conseils de mon ancien collègue Adrien Herubel, j'ai profité de l'occasion pour demander la OpenGL SuperBible: Comprehensive Tutorial and Reference (5th Edition) (avouez que le nom en jette! ).

Ça fait longtemps que je tâte OpenGL sans jamais vraiment entrer dedans...

Il faut dire que j'ai commencé à une période "difficile" dans l'histoire de l'API car OpenGL 3 (la "nouvelle" version de l'API donc) a rendu complètement obsolète l'ancienne façon de faire (soit 90% des ressources disponibles sur le net...). Les spécifications d'OpenGL ont évoluées très lentement en quasiment dix ans. Donc forcément, l'arrivé de cette version 3 qui remet beaucoup (tout?) en cause fout un bon gros coup de vieux aux tutoriaux considérés comme les meilleurs du web...

Et je vous assure qu'il y a encore un an, quasiment tout ce que je trouvais sur OpenGL sur le net avait un arrière goût de poisson pourri (RIP GeoCities #geek). les choses changent... Rapidement même...

En effet, c'est assez déprimant d'apprendre (difficilement) des choses dont on ne sait même pas si elles seront encore utilisées d'ici quelques années. Et pire, dont la philosophie n'a même plus de sens...

Ce livre a l'avantage (et c'est aussi pour ça que je l'ai acheté) de faire complètement abstraction de "comment que c'est qu'on faisait avant" et de se focaliser sur une approche moderne.

Et pour tout vous dire, au bout de quelques semaines:

Image honteusement pompé sur le net sans l'accord de son propriétaire... Merci a lui en tout cas!

Bref, ça roxx du poney et c'est super intéressant!

Voili voulou!

A bientôt et bonne année!

Dorian

Je sais que mon blog parait un peu à l'abandon... C'est pas faux!

Il y a eu pas mal de changements de mon coté. Le premier c'est que je suis maintenant TD Nuke à Illumination Mac Guff (Compo sur The Lorax).

Forcement, Nuke j'y avais peu touché et c’était l'occasion de voir si la partie script de soft était aussi nul qu'on le disait.

De plus, j'ai pas mal bossé sur mon wiki (je sais, il y a quasiment personne qui sait que j'ai un wiki...). Dans ce billet je vous propose un résumé des choses que j'ai faites qui peuvent vous intéresser.

Traduction articles VRay

J'ai traduit deux articles très intéressants sur VRay. Il est à noté que les méthodes expliquées ici sont applicables à la plupart des moteurs de rendu raytrace. Vous ne perdrez donc pas votre temps en lisant ça.

• Les paramètres de V-Ray - Le Raycasting. Traduit depuis: Best V-Ray Settings – Raycasting de RenderStuff. C'est un article expliquant comment VRay (et les raytracers en général) utilisent la mémoire.
• V-Ray - Le DMC Sampler démystifié. Traduit depuis: Demystifying V-Ray DMC Sampler de Toni Bratincevic. Un article de référence expliquant les subtilités du DMC sampler de VRay par un gars de chez Blur.

Mental ray

Toujours dans le rendu, j'ai traduit quelques posts de Bitter sur le BSDF dans mental ray. Je ne connaissais pas bien, c’était très intéressant et je pense que ça va devenir la norme d'ici quelques temps.

Nuke

J'ai commencé une page sur les commandes de base Nuke. Ça me sert de pense bête. Je vous la donne... Si ça peut vous aider...

Et aussi une petite page sur comment créer un gizmo avec des attributs. C'est très basique hein...

Je commence à me sentir à l'aise avec le compo et je pense poster quelques billets.

Un qui me tient à cœur c'est concernant la profondeur de champs via Z-Depth. J'ai entendu tellement de bêtises la dessus que je pense qu'un petit tour des méthodes peut être intéressant.

Je parlerai peut être aussi, dans un billet express, des différences fondamentales dans la façon de scripter dans Nuke et dans Maya. L'approche n'est pas tout à fait la même.

Bref, faut que je me libère du temps pour tout ça. :)

Et surtout: coral!

De même, je code dans le projet coral (repo ici). C'est une sorte de "mini-houdini" pour faire toute sortes de choses procédurales. L’intérêt est de pouvoir le connecter à Maya:

Et encore, dans cette vidéo on est loin de voir toute les possibilités du soft...

Il a été code par Andrea Interguglielmi (Un ancien de chez MPC et Animal Logic... On a vu pire comme CV... ).

Personnellement je code dans la partie OpenGL que je remet un peu d'aplomb pour pouvoir faire des choses plus évolués. Les choses avances tranquillement. La correction de bug étant la priorité (le but étant de pouvoir utiliser coral en prod). Andrea a une idée assez claire de ce qu'il souhaite intégrer (deformer, contrôle de foule, etc...).

Je pense que coral a aussi un énorme potentiel en VFX pur (modification de géométries, effets procéduraux, etc...). C'est peut être une voie que je vais privilégier car travailler sur un vrai système de shading network (un point qui semble intéresser Andrea) ne me semble pas une priorité. Il faut que j'en discute avec lui pour savoir ce qu'il a derrière la tête .

Voila voila! Comme vous voyez, je suis pas mal booké!

A bientôt!

Dorian

Je sais pas pour vous, j'ai toujours galéré pour faire un rendu correct en wireframe.

Oui, vous vous dite que tout le monde s'en fout des wireframes, c'est juste pour faire une zolie demoreel de modeleur.

C'est pas faux! Mais n’empêche que j'ai toujours galéré.

La technique que je vous présente dans ce billet express n'est pas la meilleur mais je viens de la découvrir et elle est tellement simple/efficace que je voulais vous en faire part!

Il était une fois...

Tout commence donc par une réponse de bart sur le forum de mental image suite à mon article sur l'avenir de mental ray.

Il me propose de lister les trucs que je pense intéressants pour les prods.

Je commence donc une petite liste chez moi qui commençait à être bien fournies et que je m'apprêtais a poster sur le forum.

Mais bien entendu, avant de passer pour le dernier des nigots, je vérifie une bonne fois pour toutes que ce que je demande n'est pas déjà faisable. (Histoire de pas perdre trop de crédibilité après les avoir un peu lynché dans mon billet...).

Le premier point que je cherche est: Un vrai shader pour faire du wireframe, avec moult options et tout, sans passer par les contours.

Notez que ce n'est pas le premier point de la liste sinon je suis vraiment a coté de la plaque. C'était aussi pour comprendre comment un raytracer, aux vues de son fonctionnement, était capable de sortir les edges d'un mesh (c'est le nerd qui parle là...).

Et je tombe sur ça:

Assign Surface shader to the mesh, feed it with a ramp (type: box), go to UVs:Unitize.

Source

C'est quoi son affaire là?

Unitize, c'est quoi ce truc?

Et bien figurez vous que Edit Uvs/Unitize permet tout simplement de mettre les uvs par face! C'est ça le secret!

Démonstration!

Prenez n'importe quel objet géométrique:

Notez l'originalité

Voici les UVs par défaut:

Et bien faitesEdit Uvs/Unitize:

Et...

Tadaaaa!!!

Le shading graph est aussi simple que ça:

Avec un surface shader:

Avec la ramp en Box:

Et voilà!

Donc vous voyez, c'est loin d’être un truc de prod (c'est franchement limité), mais vu le nombre de cliques nécessaires pour obtenir le truc, je ne pouvais pas ne pas vous en parler.

Si vous avez d'autres techniques de la mort n'hésitez pas!

A bientôt!

PS: Oui je sais, pas mal de moteurs proposent des shaders tout prêts (VRay, Final Render, et sûrement d'autres).

If you ever had to recover vertex positions of a mesh object, you probably crash yourself against the xform command and his legendary slowness.

In this post, I purpose a piece of Python script using the Python Maya API that allows you to faster recover the list of all vertex positions of an object.

Primarily didactic, these codes may interest peoples who want to look a little more deeply how to use the API while having a concrete application.

Using xform

Here is the xform version of the script:

def getVtxPos( shapeNode ) :
 
	vtxWorldPosition = []    # will contain positions un space of all object vertex
 
	vtxIndexList = cmds.getAttr( shapeNode+".vrts", multiIndices=True )
 
	for i in vtxIndexList :
		curPointPosition = cmds.xform( str(shapeNode)+".pnts["+str(i)+"]", query=True, translation=True, worldSpace=True )    # [1.1269192869360154, 4.5408735275268555, 1.3387055339628269]
		vtxWorldPosition.append( curPointPosition )
 
	return vtxWorldPosition

With Maya API

Alternative to xform.

import maya.OpenMaya as OpenMaya
 
def particleFillSelection(  ):
 
	# get the active selection
	selection = OpenMaya.MSelectionList()
	OpenMaya.MGlobal.getActiveSelectionList( selection )
	iterSel = OpenMaya.MItSelectionList(selection, OpenMaya.MFn.kMesh)
 
	# go througt selection
	while not iterSel.isDone():
 
		# get dagPath
		dagPath = OpenMaya.MDagPath()
		iterSel.getDagPath( dagPath )
 
		# create empty point array
		inMeshMPointArray = OpenMaya.MPointArray()
 
		# create function set and get points in world space
		currentInMeshMFnMesh = OpenMaya.MFnMesh(dagPath)
		currentInMeshMFnMesh.getPoints(inMeshMPointArray, OpenMaya.MSpace.kWorld)
 
		# put each point to a list
		pointList = []
 
		for i in range( inMeshMPointArray.length() ) :
 
			pointList.append( [inMeshMPointArray[i][0], inMeshMPointArray[i][1], inMeshMPointArray[i][2]] )
 
		return pointList

Notice: I thought that specifying the size of the list from the start would gain time but it changes nothing. It seems that Python handles it well. So, I learned a new saying: Premature optimization is the root of all evil.

Benchmarks

Well, it's fine to say it's faster. But how much?

Here are times I have with a 50x50 pSphere smoothed 4 (633602 vertices):

• With xform: 39 sec
• With Python Maya API: 4 sec

10x faster! This would give me almost want to code in C++, just to see results (which is suppose to be 10x faster than Python!)!!!

Conclusion

Well now it's up to you to know when use it.

You can try to optimize Djelloul's algorythm and let me know your results!

Now, I couldn't do without the API if I have to retrieve vertex positions of a mesh. It's much faster. Even if it's a little more complicate, I admit, but when you have this code, you keep it and use it at the right time!

Hope you like this trick!

See you soon!