Indindi

Aller au contenu | Aller au menu | Aller à la recherche

samedi 17 octobre 2009

Realtime splatting optimisation

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 :

 

 

         ====> Blend File : Splatting.rar <====             

  

jeudi 15 octobre 2009

Optimisation du splatting temps réel

Cette procédure montre comment utiliser les informations RVB d'une image pour mixer ensemble plusieurs motifs afin de texturer de grands espaces, comme des terrains, par exemple. Nous ajoutons également la possibilité de peindre et/ou calculer l'occlusion ambiante, ainsi que la possibilité de peindre des effets de lumière directement sur le modèle.

Théorie :

     Les performances de l'affichage temps réel sont conditionnés par la place mémoire assignée aux textures et au nombres d'opérations parallèles que doit traiter la carte graphique. Ainsi si l'empreinte mémoire des textures d'une scène (textures des décors/personnages/objets) est suffisamment petite, ces données sont chargées dans la mémoire de la carte graphique, accélérant le rendu de l'image. En revanche, si l'empreinte mémoire des textures de la scène dépasse les capacités de la carte graphique, les textures doivent transiter de la mémoire centrale à la mémoire de la carte graphique,ceci pouvant occasionner des ralentissements au niveau de l'affichage.

    D'autre part, le nombre de matériaux (shaders) augmente sensiblement la charge de calcul d'une scène ; les calculs de l'illumination doivent s'effectuer pour chaque matériau, en fonction de ses propriétés (Spécularité, transparance Alpha, ombres projetées, Normal Map, spec map, propriété spéciales d'illumination spécialement programmées dans le pipeline de shading de la carte graphique, etc...). Il vaut donc mieux n'utiliser qu'un nombre limité de matériaux, pour éviter les soucis de baisse du framerate.

   Pour alléger un peu le calcul et l'empreinte mémoire nous pouvons partager les même textures et matériaux sur des matériaux nodaux qui partagent également une fraction de leurs traitements, sans pour autant trop perdre en qualité visuelle. Nous utilisons également les propriétés de spécialisation des entitées de blender pour partager des fonctionnalités communes aux différents matériaux.

   Ainsi, nous allons créer un processus générique qui vise à effectuer sur l'objet :

  • Le mélange alpha des couleurs des textures (Color Texture Blending par Texture splating)
  • Le calcul de l'occlusion ambiante
  • Les effets de lumière (glow)

Mise en place :

      1- Dépliage des UV

   Cette procédure fonctionne avec des objets dont l'UV map à été déplié par rapport à une vue orthogonale (par exemple la vue de dessus pour un terrain -> en mode édition "TAB" de l'objet sélectionné, "7" du pavé numérique, menu "Mesh > UV Unwrap > Project from view (Bounds)"  ) mais fonctionne aussi avec des uv dépliés manuellement. En revanche Il faut absolument que l'UV soit correctement déplié pour que la procédure puisse fonctionner.

      2- Création des textures et matériaux    

    Une ensemble de trois textures plus un matériau "basique" est utilisé dans cet exemple. Il est tout à fait possible d'utiliser 4 matériaux ou 4 textures, ou 2 matériaux et 2 textures, etc.... Les changements à faire à ce moment là n'impacteront que le node "Texture Pack" (voir plus loin).

    Il est conseillé de génériciser ces textures et matériaux au sein d'un groupe dans un fichier à part, comme indiqué dans La methode de multi-texturing , de façon à pouvoir les utiliser en suite en effectuant un lien sur le groupe.

Dans cet exemple nous utilisons les matériaux ci-dessous :

      

      3- Mise en place du matériau nodal

     Affecter un matériau au terrain (ou à l'objet) et rendre nodal ce matériau (boutton "Nodes" du matériau). Créer une nouvelle fenêtre et lui affecter le node éditor.

     Nous allons utiliser les nodes par défaut de Blender pour créer un ensemble de nodes "évolués" qui permettrons, une fois interconnectés entre eux, de gérer le shading du modèles, voire de plusieurs modèles, partageant la même méthode de shading.

     Avant de commencer le montage nodal juste une petite précision sur le partage de ressources à l'intérieur d'un fichier blender. Dans l'interface de blender on peut parfois noter de petits numéros dans un boutton qui se situe souvent à droite des noms de ressources (matériaux, textures, nodes, etc....). Ils indiquent le nombre d'entitées (matériaux, animations, objets, node, etc...) qui partagent cette même ressource (cette même donnée).

Ces numéros se présentent comme suit :

Lorsqu'une donnée est partagée par plusieurs entitées (numéro élevé à côté du nom de la donnée) on dit qu'elle est générique. En revanche lorsqu'il n'y a pas de numéro ou lorsqu'il n'y a qu'un "1" dans le boutton, la ressource est unique ou spécifique.

   Donnée Générique (partagée par 12 objets)
   ou
Donnée spécifique

Par défaut Blender crée des données génériques lorsqu'on duplique un objet, ou lorsqu'on réutilise des objets groupés. Le fait de créer des données génériques ou spécifiques lors du clonnage d'un objet se paramètre dans le panneau des options de blender.

Et là vous me direz... Qu'est-ce que ça fait ?

Concrètement, lorsqu'on modifie une ressource générique (partagée par plusieurs objets,dans ce cas le numéro dans le boutton est >1) on modifie cette ressource POUR TOUS LES OBJETS UTILISANT CETTE RESSOURCE. La généricité des données est une mutualisation des ressources système ; la donnée n'est présente qu'à un seul et même endroit en mémoire, diminuant ainsi drastiquement les temps de calcul lors du rendu d'un nombre d'objets important partageant la même donnée.

En revanche si on veut une variation d'une donnée générique pour un objet sans pour autant la changer sur les autres objets, alors il faut la rendre spécifique ; il faut sélectionner l'objet en question, puis cliquer sur le petit boutton avec le nombre dedans.

En mutualisant nos données génériques pour les traitements et les ressources identiques à tout un ensemble d'objet (comme notre jeu de textures, par exemple) on gagne de la place mémoire.

Maintenant que nous savons faire la différence entre une donnée générique et une donnée spécifique, il est temps de mettre en place le montage nodal, qui se présente(ra au final) comme suit :

Chacun de ces nodes sont en fait des groupes de nodes faisant intervenir des masques utilisés pour peindre les différentes méthodes et des textures.

Le node générique "Textures Pack" renferme les 4 composants (Textures ou matériaux ou les deux) qui vont servir au mélange alpha des couleurs des textures.

Il est tout à fait possible d'utiliser des matériaux à la place des nodes texture. Cela dit les performances de rendu risquent de chuter en fonction du nombred'objets sur lesquels est appliquée la méthode.

Le groupe de nodes suivant "Splat and shadows méthod" est le plus complexe du montage nodal car il contiens deux méthodes de shading et permet de combiner les principales couches de shading :

Les deux masques (Splat Mask et Shadow and ambiant occlusion Mask) sont directement utilisés dans blender :

  • En texture paint dans le cas du splat Mask pour peindre les textures sur l'objet,  les cannaux Noir + RGB désignent une texture ou un matériaux.
  • En Backing de l'occlusion ambiante et des ombres pour le maske Shadow and ambiant occlusion. Théoriquement il faudrait alors faire deux backings successifs si on veut avoir les ombres et l'occlusion ambiante sur le même masque, ou encore effectuer le montage des deux sous Gimp ou photoshop (je n'ai pas essayé, mais ça devrait marcher)...

Vient en suite le node spécifique qu'on utilise pour le masque de glow (Lighting Method), extrêmement simple :

 

Enfin un dernier gros morceau, le node qui permet d'effectuer la fusiion du glow avec les autres méthodes (platting et shadow) et aussi de gérer la direction de la lumière (Light Direction Node) :

 Le montage nodal du matériau est terminé. Ouf !

Utilisation :

Maintenant il ne reste plus qu'a ... utiliser l'outil !

C'est en fait relativement simple ; il suffit d'affecter un des trois masques (Splat,Shadow et Glow) directement dans l'image editor et en suite de peindre directement sur l'objet en mode "texture paint"

  • "Tab" passage de l'objet sélectionné en mode édition
  • "a" pour sélectionner toute la géométrie de l'objet 
  • Dans la fenêtre "image editor" sélectionner le masque sur lequel on veut travailler (Splat, Shadow ou Glow)
  • Passer en mode texture paint
  • Sortir du mode édition et peindre directement sur le modèle

Pour l'exemple initial, nous avons généré les masque suivants :

Splat Mask

Shadow Mask

Glow Mask

Objet final :

 

                ===> Fichier Blend : Splatting.rar <====                    

 

 

 

mercredi 14 octobre 2009

Realtime Multi-texturing with vertex painting method

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...

 

 

 

       ==> Blend File : Vertex_Paint.rar  <==         

 

Méthode de multi-texturing temps réel en vertex painting

Cette procédure montre comment utiliser les cannaux RGB du vertex paint d'une modélisation pour mixer ensemble plusieurs matériaux avec Blender, de façon à casser l'effet de répétition des textures reboutées.

Théorie :

Sur la base d'un maillage suffisamment riche on affecte un matériau nodal à l'objet.
Le montage nodal vise à séparer les données R,V et B de la couleur des vertex pour pondérer (Blending) l'affichage de 4 matériaux.  Voir Blender material nodes (english) pour plus de précisions sur les matériaux nodaux dans Blender.

Mise en place :

D'abord concevoir un objet avec suffisamment de maillage pour permettre des dégradés, si nécéssaire.

Déplier les UV de l'objet (voir Blender UV Maps si nécéssaire - pour des objets simples un Mesh> UV Unwrap> Unwrap avec l'objet en mode édition sélectionné - TAB - suffira). Préparer en suite les matériaux qui vont être utilisés par l'objet (Color map, normal map, spec map, etc...).

Dans cet exemple nous utiliserons 3 matériaux (même si le montage nodal indiqué peut en supporter 4).

Utiliser des objets simples (cubes ou spères) tagués invisibles pour le game engine (F4 > chercher le bouton "Invisible") dans un fichier à part (nommé "materials.blend", par exemple) pour créer les matériaux simples ci-dessus. En suite affecter tous ces objets dans un même groupe ("Materials", pour plus d'originalité).

Enfin lier le groupe dans le fichier de travail (file > Append or Link avec l'option "Link" sélectionnée, naviguer jusqu'au fichier "material.blend", entrer dans le fichier en double cliquant dessus > Groups > sélectionner "Materials"), puis ajouter les objets groupés dans la scène (barre d'espace > Add > <nom du groupe>).

Sélectionner l'objet initial, lui affecter un matériau nodal (boutton "Node" dans le matériau). Dans l'éditeur Nodal créer le montage nodal suivant :

N.B : il est possible de génériciser ce montage dans un fichier externe lié, comme pour la gestion des matériaux précédemment.

Passer la vue de travail en mode "textured", éventuellement le game engine en GLSL materials.

Passer en mode "Vertex Paint"

En utilisant les tons de couleur dans la fenêtre paint sous le boutton "editing" (F9) il est maintenant possible d'effectuer un paint par blending de couleurs sur l'objet...

 

 

 

       ==> Fichier Blend : Vertex_Paint.rar  <==          

 

 

 

 

jeudi 16 avril 2009

RIA, frameworks et consort

 

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...

mardi 28 octobre 2008

Petit moteur AS3 libre - Open Source - as3isoGame

Je vous présente ici succinctement le travail de Paco :

Il s'agit d'un petit moteur de tile 2D (isométrique). Il a le mérite d'être accompagné d'un éditeur de map (cartes, décors, objets). Le tout développé en ActionScript 3. Son architecture est assez bien pensée et m'a servie de base pour faire le mien.


J'attire l'attention sur le fait que Paco cherche des Pixel Artists pour mettre en avant son boulot de manière un peu plus glamour.

En outre l'éditeur (téléchargeable ici : moteur+editeur - A décompresser avec un outil qui prend en charge le PKzip, ou simplement à installer en double clickant dessus après avoir installé Adobe Air) et fortement bogué : toute contribution sera donc la bienvenue...

Les sources du projet sont récupérables également sur SourceForge.net (mais la version de l'éditeur est en chantier, il convient donc de le récupérer via le lien ci-dessus).

http://sourceforge.net/projects/as3isogame/


Pour finir, voici le blog de Paco : Mo'blog ou il parle de ses divers travaux, en particulier le moteur de physique 2D sur lequel il bosse actuellement.
N'hésitez pas à le contacter via le blog en lui laissant des commentaires : il est réactif.


jeudi 11 septembre 2008

De la Collision de Bitmaps en Tenant Compte de l'Alpha en AS3 - ACTIONSCRIPT 3

Voici, un petit lien bien intéressant sur la collision entre des objets Bitmap (BitmapData) en Actionscript 3.

L'algorithme présenté prend notamment en compte l'éventualité d'une mise à l'échelle ou d'une rotation des Bitmaps considérés.

Je ne l'ai pas encore testé, mais cela semble digne d'intérêt...

Le lien : http://troygilbert.com/category/game-dev/


Lire la suite...