This process shows How to use RGB information from an image to blend several textures together to textures big objects, like terrains, by example. We added the possibility to paint and/or calculate ambiant occlusion, Shadows, and the possibility to paint light effects directely on the model.

Theory :

   Realtime rendering performances are conditioned by the textures memory footprint and the number of parallel operation performed by the graphic card. If the textures memory footprint of a scene (textures of the landscapes, characters or objects) is small enought, these data fits all in the graphical card memory, this way the realtime rendering is sufficiently fast. However, if the textures footprint of the scene goes over the graphical card capacity, textures must go from the central memory of the computer to the graphical card. This can slow down the rendering.

   The number of materials and shaders used in the scene increases the processing of the scene ; lighting processing must be done for every material, according of its properties (Specularity, Alpha transparancy, Shadows, normal map, or any special process like CG shaders programmed in the graphic card...). So it's better to use a limited number of materials to avoid framerate drops.

   To ease the processing and the memory footprint we can share the same textures and materials on nodal materials. We can share some processing across materials too, without losing visual quality too much. We will use for that the hability of blender to make a data specific for an object., or to genericise data across multiple objects.

   This way we will create a generic process that allow us to :

• Alpha blend colors of textures (Splatting)
• Memorise ambiant occlusion
• paint light effects (glow)

Establishing the process :

      1- Unwrap UV :

       To work correctly this process need abject with an Unwraped uv. Unwraped uv from an orthogonal view works perfectly as it have been thought for terrains shading (Select the object and edit it "TAB" , "7" to go in top view, menu "Mesh > UV Unwrap > Project from view (Bounds)" ). But this process can work with uv unwraped in another way, as simply we didn't tryed.

      2- Textures and materials creation

    A collection of 3 textures plus one "simple" (non-nodal) material  are use in this example. It is absolutly possible to use 4 materials, or 4 textures, or 2 materials and 2 textures, and so on... Changes to that will have to be only in the "Texture Pack" node (see later).

    Genericising non-nodal materials into a group in an other file can be a good advise, as we've done in the realtime multi-texturing method. This way materials are easily re-usable in a complex scene.

In this sample we will use these textures and material :

      3- Establishing the nodes :

    Give a nodal material to the object or the terrain. Then go to the node editor.

    We are going to use default blender nodes to create a set of "evolved" nodes (we call evolved nodes some blender nodes that have been grouped together !) that we will connect together to generate the model shading. This shading wil be easily re-used by other models, sharing some ressources and having other specific data.

    Before we begin to build the nodes, just a little precision on the ressources and data sharing inside a .Blend file. There is sometimes a little number into a button at the right side of the name of data ressources (materials, textures, nodes, etc...) into the Blender UI. These numbers showing the number of objects/entities that are sharing this data.

    This numbers are like this :

When a data is shared across several objects (there is a number >1 at the side of the name) we say that thiis data (ressource) is generic. In contrast when ther is no number, or if the number is "1" in the button, the data is unique, or specific.

	Generic data (shared across 12 objects)
or	Specific data

By default blender create generic data when we duplicate an object, or when we use grouped objects. This default value can be changed in the option pannel of blender.

Well.. Err.. So what ? Would you say...

Concretely, when we modifie a generic data (...shared across multiple objects) then we modify it for ALL THE OBJECTS USING IT. Genericising a data can be see as a pooling of system ressources, as the data is in one and only place in memory.

But if we need variations of a generic data for an object without changing the other, then we need to change the data to a specific one ; select the object and click on the button with the number inside.

Pooling our generic data for fast processing is a way to minimising memory footprint.

Now that we know the difference between a generic data and a specific data, it's time to build our nodes. It will at the end look like this :

Each of these nodes are in fact node groups using masks to paint things on the model.

The generic node "Texture Pack" encloses 4 nodes (textures or materials or both) that will serve to alpha blend textures together.

It's possible to use materials instead of textures nodes. That said, realtime rendering performances with multiple lights might be low with a big number of objects...

The next node group "Splat and shadows method" is the more complex because it contains two methods ; one for splatting, and the other for shadows :

The two masks (Splat Mask and ambiance occlusion Mask) are directly used in blender to:

• Texture paint (Splat Mask) to paint textures on the object ; Black and RGB channels will designate a texture or a material
• Ambiant occlusion Backing and shadow backing (Shadow and ambiant occlusion). Theorically it may take 2 successives backings on the same texture (one for shadow and the other for AO)  or compositing the final texture with two bakes inside Gimp or Photoshop (I didn't have time to try, but it should work).

Then here is the "Lighting method" node, very simple :

Then the last big piece, the node that enable glow, splatting and shadow fusion, and ennable us to give a light diretion and intensity (Light direction node) :

It's enought for the nodes ! Yes!

Utilisation :

Now we just have to ... use this as a tool !

It's in fact extremely simple : you must get one of the three masks (Splat, shadow or glow) directely in the image editor and then paint directelu on the object in the "texture paint" mode.

• "Tab" to get the object in edition mode
• "a" to select all the geometry of the object
• In the "image editor" window, select the working mask (Splat, shadow or glow)
• Go to texture paint mode
• Get out of the edition mode and paint directely on the model

For this example, we generated the following masks :

	Splat Mask
	Shadow Mask
	Glow Mask

Final object :

This process show how to use RGB channels of the vertex paint from a modelisation to mix together some materials, under Blender. This is perfect to break the repetition of repeatable textures.

Theory :

On a sufficietly rich wireframe object we use a nodal material. From ther we want to separate R, G and B values of the vertex color to blend 4 materials. See Blender material nodes for more informations on nodal materials under Blender.

Ordering sequence :

First, create an object with sufficient wire to hold gradients, if necessary.

Unwrap UV for the object(see Blender UV Maps if necessary - for simple objects just use Mesh> UV Unwrap> Unwrap with the object selected in edition mode  - TAB - ).

Then we must create all the materials that will be used on the object (Color map, normal map, spec map, etc...).

In this example we will use 3 materials (even if it's possible do it with 4 materials)

Use simple objects (cube/speres) with the "invisible" tag ennabled in the game engine (F4 > Look for the "invisible" button in the button pannel). Save these objects and materials in an other file (named "materials.blend" by example) to create the singles simples materials upside. Then give to all these objects a group ("Materials", to be original !).

Finally, link the group in the working file (File > Append or Link with the "Link" option selected, navigate until the file "materials.blend" created before, enter in the file by double cliking it > Groups > select the group named "Materials" that we created precedently), then add the objects groupped in the scene (space bar > add > <name of the group> -> "Materials" for us).

Select the initial object, give it a nodal material ("Nodes" button in the material). In the nodal editor create the following nodes :

N.B : It is possible to genericise the nodes in an external linked file, as we did for the materials.

Set the working view in "textured" mode, enventually set the game engine on GLSL materials.

Get in "vertex paint" mode

Using the colors in the paint window under the "Editing" button (F9) it's now possible to create a paint that blends materials together...

Bonjour tous ! (enfin, plutôt "bonjour toi" qui t'es perdu sur notre blog en cherchant un tuto sur flash)

Nos amis de Neiio nous ont récemment contacté pour un retour d'expérience au sujet d'une discutions-bière autour de notre expérience de Flex et des frameworks MVC. Pour ceux qui savent pas, les frameworks MVC c'est... ben c'est la et flex, ben... c'est la.

Si on veut rester vulgaire flex c'est un langage de programmation pour le internet en flash qui s'anime et MVC c'est une brique logicielle pour ce langage qui permet de résoudre des problématiques de... programmeur.

Tu l'as compris, seul amis qui nous reste et qui passe nous voir de temps en temps, ce topic concerne les programmeurs. Si tu veux voir la suite des bd ou autre... ben.... on a pas le temps reviens plus tard ! Allez !

Pour ceux qui restent (s'il y en a) le débat a commencé comme ça : Damien (Programmeur/graphiste/ingé/Déménageur/homme à tout faire de chez Neiio , une entreprise pleine d'avenir et de talent qui va bien de par chez nous) nous a contacté pour nous relater ses expériences plus ou moins heureuses concernant Flex  :

Bonjour,

Hier j’étais en journée de repos, parce que j’avais séché plusieurs jour du seigneur, et plusieurs « vacances » ; donc j’ai raté l’apéro et la discussion au sujet de « wan’agad’ a flex ».

On utilise flex et papervision pour notre site web. Apparemment vous en avez fait les frais.

Très vite je me suis rendu compte de la nécessité d’utiliser une  ‘’micro-architecture’’ parce que flex, c’est sale ! On dit micro architecture quand on est flex, en fait c’est un framework.

Avec l’âge et la sagesse je suis devenu faignant donc hors de question de recoder un MVC. Des micro-architecture MVC j’en ai déjà développé à l’âge de pierre en PHP et en C++ ; à l’époque, ou on pensait que Microsoft Fondation Class c’était top. J’ai même vu des model view sans controler de chez QT, bref. MVC j’ai fini par comprendre ce qui est bon ou mauvais à l’usage.

Ce qui est sur c’est que je connais très mal flex et que je ne peux pas vraiment affirmer que c’est sale. Tout ce que je vois c’est que si caingorm, mate, pureMVC et swiz existent c’est qu’il y a un problème. Et le problème il me semble que je l’ai touché du doigt me semble t’il.

Je regarde l’application flex de base avec le fichier MXML qui déclare dans le même fichier les toutes les vues de l’application puis les ‘’include’’ ou import, et encore un genre de fonction statique le tout mixé avec le langage de description de la fenêtre et si ce n’était pas suffisant on y ajoute un css.

WOUAOU ! j’ai commencé par séparer les fichiers MXML, puis je me suis dit c’est le controller qui va se charger de créer les fenêtres, j’instancie les fenêtre à la main et la surrrprise ! Je me rend compte que rien n’est créé a oui il faut attendre le callBack « applicationComplete » quelle horreur. Ca signifie que le controlleur doit connaitre toutes ses vues et avoir attendre tous les callback complete avant de faire quoi que ce soit. C’est à ce moment que je me suis dit qu’il était temps de faire un tour chez caingorn mate swiz et pureMVC.

Caingorm est trop vieux trop verbeux, si trois autres existe c’est qu’il y avait des problèmes, on peut le penser. Je n’aime pas les outils complexes. Si je loue une mini pelle pour creuser ma piscine ce n’est pas parce que je n’aime pas piocher c’est pour creuser en une semaine au lieu de six mois. Avec caingorm il faut d’abord passer le permis, et la pelle est tellement complexe qu’on a plus vite fait de creuser à la main.

pureMVC ça me fait penser à mon second MVC c’est tellement propre que tu passes plus de temps à laver l’application qu’a coder : entre les commandes les proxy et tout le tsoin tsoin ça me fait penser à mon second mvc c’était une horreur à utiliser. Mais c’est sur c’est vraiment un MVC, mais parfois il ne faut pas suivre les patterns à la lettre parce que c’est mal.

Secrètement j’attend un quelque chose qui ressemble à QT avec son Model View + delegate si t’en veux le tout agrémenté de signaux slot ( http://doc.trolltech.com/4.0/model-view-programming.html ). Ou encore mieux Django qui débarque avec son concept de MTV modèle template view, concept excellent ( http://fr.wikipedia.org/wiki/Django_(framework) ).

Mate je n’ai pas fini de fouiller mate donc je ne peux que saluer l’effort de documentation, mais à priori il semble verbeux à souhait. A vrai dire seul swiz me fait rêver avec son IOC inversion of control, seul problème c’est si mal documenté que je vais devoir ouvrir les classes, utiliser avec et sans swiz pour comprendre l’apport de swiz.

Ce qui est certain c’est qu’en quittant C++/QT je perd les signal/slot (propager des callback dans une application) et pas mal de choses comme la possibilité de bien contrôler l’instanciation des objets.En fin de compte je me demande quelle est la productivité à laquelle je peux m’attendre avec flex et action script versus celle à laquelle j’aurais pu m’attendre avec C++. J’ai un peu l’impression que flex pousse le développeur à faire du sale. Qu’en est-il en vrai ? C’est aussi une question de débutant qui n’a pas encore lu la doc et qui s’est plongé dans le code. Je reviendrais donner un vrai avis après 3 à 6 mois de développement et je pourrais dans ce cas affirmer c’est SALE ou c’est PROPRE !

En attendant je demande l’avis de la communauté, mais quand on gratte juste la surface à priori ça n’a pas l’air propre. Faites moi plaisir dites-moi que je me trompe…

Voici un bon article sur les framework autour de flex http://www.insideria.com/2008/12/frameworkquest-2008-introducti.html

Et plus généralement j’ai eu à me poser la même question pour c++ php ou python

Et j’ai retenu QT pour C++ un genre de rolls…

Ez-component et zend framework pour php, et django pour python. Pour finir en matière d’architecture django et Qt forcent vraiment le respect. Et peut être un jour si je sors un framework les gens pourrons critiquer mon kungfu de mon vivant. Et parpevision , rien à dire

Cordialement Damien MIRAS

Par chez nous, chez Klakos , entreprise pleine d'avenir vu qu'elle n'a pas encore de passé, on a aussi travaillé sur des solutions techniques Flex, et, tenez vous bien, A BASE DE FRAMEWORK MVC ! Si si !... Mais on a laissé tomber. On préfère la plage. Non... je rigole. On a préféré s'orienter vers un autre type de développement avec du client lourd. Les raisons ? Je vous les expose ici !

Ma réponse, donc :

      Personnellement je n'ai rien à redire concernant Flex. Je le trouve simple et efficace, même s'il faut un peu de temps pour s'acclimater aux classes, le plus contraignant étant la recherche de documentation concernant les différentes versions du MXML, mais ça se trouve. En revanche l'ActionScript est parfaitement documenté et abordable, et avec un peu de rigueur il est possible de maintenir une application faite en flex, mais ça demande de découper l'application en micro-fonctionnalités en amont, en faire des classes et les réintroduire dans l'ensemble. C'est vrai qu'a ce niveau certains choix d'adobe peuvent laisser rêveur (cf leur implémentation du pattern "Interface" en "dur" au détriment de l'héritage multiple....ca m'a fait bizarre, j'avoue ) mais dans l'ensemble il est possible de faire avec si on ne recherche pas les performances absolues. Les raisons pour lesquelles nous avons finalement écarté l'utilisation de Flex pour le prototypage ne sont pas du tout liées à Flex mais résident surtout dans le manque de bibliothèques et de frameworks intégrés permettant la gestion (d'assets, notamment) en local, mais pas du tout en matière de productivité. On a bien pensé à générer une application AIR à partir de PureMVC mais cela n'a pas suffit, surtout concernant les animations, le pré-caching des effets spéciaux, la gestion des évènements sonores, j'en passe et des meilleures...

Concernant PureMVC il faut quelques jours pour s'y acclimater, mais c'est un framework extrêmement intéressant, pour peu qu'on y passe le temps de prise en main nécessaire. C'est vrai qu'il peu paraitre obscur au premier abord mais à l'utilisation y'a pas photo ; meilleure stabilité de l'application, complexité constante pour une application à grande échelle, et au final gain de productivité indéniable. Cela dit pour réellement avoir l'utilité d'un tel framework il faut une appli vraiment grosse qui tend à la complexité. Inutile d'utiliser PureMVC pour une application de moins de 1.000 lignes de code qui n'est pas censée gérer la persistance de ses données (ça reste mon avis).

    Concernant Papervision, la encore c'est à mon avis la meilleure offre concernant les moteurs 3D qu'on peut trouver en Flex/RIA. Les classes sont claires, certains outils sont disponibles, la licence n'a pas l'air contraignante et la communauté est bien réactive. Côté performances c'est aussi le meilleurs d'après moi, même s'il n'existe pas encore (enfin, à l'heure ou nous l'avons utilisé) de solutions ayant intégré la techno de flash 10. D'après Adobe, flash 10 intègre les pipelines des cartes accélératrices 3D... d'après les tests que j'en ai vu, flash 10 n'intègre que quelques-une de ces fonctionnalités, il manque encore le Shading et énormément des capacités d'éclairage des cartes actuelles... a voir si Adobe effectue l'intégration au fur et à mesure, ça peut être intéressant mais il faudrait que Papervision sur le coup intègre ces nouvelles fonctionnalités, ce qui doit demander un gros effort de remaniement du code bas niveau. J'ajouterais à ça que niveau productivité concernant Papervision j'ai été un peu dérouté au premier abord par leur outil intégré à Flash. Je conseille de ne pas l'utiliser et de tout faire en flex, les librairies sont suffisamment claires si on a l'habitude des moteurs 3d c'est un jeu d'enfant, mais la je dérive...

    Donc pour résumer ; oui, ce sont effectivement des outils qui permettent un énorme gain de productivité passé la phase de prise en main (qui est somme toutes assez rapide). Après... comparer une solution C++ à une solution RIA est toujours un peu délicat, mais je répondrais que le RIA est toujours plus intéressant en terme de rapidité de mise en œuvre lorsque les performances ne sont pas importantes et lorsqu'on veut s'affranchir de la problématique de la plateforme. Ça deviens vraiment épineux lorsqu'il s'agit d'applications 3D, étant donné que ces applications sont énormément demandeuses en terme de performances, proches du matériel (et donc du système d'exploitation) et demandeuses d'un set d'outils parallèles très large (suites de modélisation, animation, etc...)...Si la priorité est la mise en place sans trop regarder le niveau de technicité alors il vaut mieux une application RIA. En revanche, si la priorité concerne la complexité de l'affichage et des scènes, les effets de lumière, l'empreinte mémoire et la charge processeur, alors la, du coup, vaut mieux client lourd, et donc solution C/C++.

Mais dans ce dernier cas, a mon avis, c'est toujours beaucoup plus cher !

J'ai essayé de donner le plus de précisions, maintenant, si toi, passant du net programmeur a tes heures ou professionnel, tu trouve quelque chose à dire ou un retour d'expérience à offrir à Damien (et à moi par la même occasion) tu es ouailcôme (oui, je sais c'est pas comme ca que tu t'appelles et j'ai un humour de merde... c'est comme ça).

Donc voila...