SciGems

The OpenGL ES Shading Language ES 2.0, has range and precision qualifiers.

Precision qualifiers:

• highp (e.g. highp mat4 myMatrix)
• mediump (e.g. varying mediump vec2 myTexCoord)
• lowp (e.g. lowp float myColor)

default vertex precision shader:

• precision highp float
• precision highp int
• precision lowp sampler2D
• precision lowp samplerCube

default fragment precision shader:

• precision mediump int
• precision lowp sampler2D
• precision lowp samplerCube

Builtin variables:

Un rappel pour les combinaisons de touches distinctes:

• Ctrl-Alt-8 pour \
• Ctrl-Alt-6 pour |
• Ctrl-Alt-4 pour { et Ctrl-Alt– pour }
• Ctrl-Alt-5 pour [ et Ctrl-Alt-) pour ]
• Ctrl-Alt-2 pour ~

1. créer une interface IObj2dSceneNode (header) qui hérite de ISceneNode
2. créer la classe d’implementation CObj2dSceneNode (header + source)
3. ajouter dans ESceneNodeTypes.h un type ESNT_OBJ2D avec un id unique MAKE_IRR_ID(‘o’,'b’,’2′,’d')
4. modifier le fichier ISceneManager.h pour ajouter une méthode addObj2dSceneNode
5. modifier le fichier CSceneManager.h et .cpp pour y ajouter les implémentations
6. modifier le fichier CDefaultSceneNodeFactory.cpp pour ajouter notre nouveau type

Attention, lors de la sérialisation d’un node, la méthode writeNode stocke dans le fichier de scene les matériaux même si le loader  ne les utilise pas.

De nombreux mtoeurs 3D définissent les caméras avec:

• double fov
• double aspectRatio
• double zNear
• double zFar

Quelles relations avec les tailles de nos écrans: width et height. Simplement:
ytop = zNear * tan (PI/360. * fov)

ybottom = -yTop

yRight = yTop * aspectRation


Pour verifier le AndroidManifest.xml installé dans un apk, il suffit de faire:

aapt d xmltree path/to/My.apk AndroidManifest.xml

Pour rappel, la commande aapt est une commande livré avec le SDK android.

Depuis quelques mois, la 3D s’introduit partout: Navigateur Web, iPhone, Android…Aye aye implémentations différentes à chaque fois… Que nenni….

La bonne nouvelle est que certains standards semblent émerger. WebGL, disponible sur les versions alpha de Webkit et Firebox 3.7 n’invente pas une nouvelle API comme l’a fait O3D mais s’appuie sur le standard OpenGL ES 2.0, que l’on va bientôt retrouver sur nos mobiles préférés: Android, Iphone, WinMe…

Un lien pour découvrir WebGL:

http://learningwebgl.com/blog/

Un lien pour écrire ses fragment shaders:

http://www.iquilezles.org/apps/shadertoy/

L’injection de dépendance est un pattern que tout programmeur java connait. Forme spécifique du patttern IoC (inversion of control), il permet de rendre la programmation plus modulaire. Le principe :

• soit deux composants A et B tels que A utilise B (dépendance de A sur B);
• on les découple en indiquant que A utilise une interface de B et non plus B et dans un troisième composant C, on dit que lorsqu’on instancie notre composant A, on INJECTE dans la variable B une référence vers le composant B

Le composant C crée la liaison entre A et B. On injecte ainsi la dépendance; Les avantages?

• on peut changer les implémentations de B pour le composant A; Pour des tests unitaires, il peut être judicieux de mettre en place un mockup;
• le module C peut être dynamique et changer l’implémentation de B au runtime (faire des mises à jour à chaud);
• créer des librairies dont la configuration serait placée dans des composants placés dans d’autres librairies;

Les possibilités sont énormes et lorsque l’on y a gouté difficile de s’en passer.

Enfin, il est à noter qu’existe de nombreuses implémentations de Depedency Injection:

• guice (JSR 330);
• seam (JSR 299);
• spring;
• pico-container;
• hivemind;

Guice pour sa compacité semble aujourd’hui s’imposer. Simple dans ses usages triviaux, sa documentation reste toutefois trop sommaire sur ses possibilités avancées. Toutefois, un tutorial sympatique pourra vous éclairer :

http://www.ibm.com/developerworks/library/j-guice.html

A lire sans modération.

OSGI – Episode 2

Dans l’épisode précédent, nous avons vu comment installer rapidement une plate-forme OSGI avec pax runner. Dans ce nouvel épisode, nous allons mettre en place un serveur Web avec OSGI.

OSGI n’était pas destiné aux serveurs d’applications mais peu à peu OSGI s’est introduit dans le monde J2EE. Tout d’abord par sa modularité, il a été utilisé pour modulariser les serveurs d’applications afin de les rendre moins monolythiques :

• Jonas 5
• GlassFish V3

De son coté, le consortium OSGI a définit une spécification de service http permettant de gérer des pages statiques et des servlets. Ceci a du sens pour les produits embarqués voulant fournir de très simples interfaces HTTP mais cela reste peu productif pour de plus importantes applications.

Mais quel peut être l’intérêt pour OSGI de pouvoir faire fonctionner des applications Web ? Simplement de fournir une application complète!

En effet, fournir une application Web consiste à fournir une application au format WAR ou EAR, à installer un serveur d’application, puis configurer et déployer le WAR ou l’EAR. Ceci est simplement hors de porté pour 99% des particuliers et de très nombreuses entreprises. Le risque d’erreurs de configuration est aussi maximal. Fournir une application unique qui embarque son serveur HTTP est au contraire une solution élégante et moins risquée. Ceci aurait pu être possible avec J2EE mais la taille des serveurs d’applications a découragé ce type de solutions.

Suite à cet aparté, retour les mains dans le camboui. Nous allons utiliser Pax Web 0.7.0. Ce bundle est un packaging de jetty permettant l’éxécution de servlets et de JSP. Dans le répertoire pax-runner-1.2.0 obtenu dans le répertoire précédent, il suffit d’exécuter :

bin/pax-run.sh --profiles=felix.config,web,war war:mvn:org.apache.wicket/wicket-examples/1.3.0/war

Et la vérification que tout est opérationnel avec son navigateur :

http://localhost:8080/mvn_org.apache.wicket_wicket-examples_1.3.0_war/helloworld/

Impressionnant, on a une application déployée en une ligne…

Ralentit Technique :

1. Pax runner installe Felix
2. Pax runner installe les bundles relatifs aux profiles felix.config, web et war ( cad config admin, pax web 0.7.0 et war extender)
3. Pax installe une application Web, un war modifié dans jetty

Voila pour aujourd’hui… Dans le prochain billet, nous verrons comment modifié un war pour le faire fonctionner sur le principe vu dans ce billet.

Ce vendredi, nous avons tenté d’utiliser le plugin maven-release-plugin pour automatiser nos mises à jour. Après avoir tenté notre idée de solution, c’est à dire mettre l’identifiant de release dans une variable nous sommes rendu compte qu’il s’agit d’une mauvaise idée. En effet, la variable dans les fichiers pom.xml n’est pas résolue et se retrouve sur le dépot central…. et là le drame.

Comme souvent avec Maven, il existe une solution préconisée qu’il faut respecter (les autres chemins sont sinueux). Bref, la solution est le plugin release. Attention, le projet doit être stocké par  une gestionnaire de configurations (svn, cvs, git, baazar …). Ce plugin crée un tag pour chaque release et mets à jour les identifiants de versions dans les fichiers pom.xml.

Utilisation du plugin:

1. dans les pom.xml, il faut définir une version avec SNAPSHOT comme 0.0.1-SNAPSHOT
2. ne pas indiquer la version dans les pom.xml uniquement dans la section parent
3. définir dans le pom.xml racine une section scm avec connection / developerConnection / url
4. définir la configuration du plugin release avec tagbase et configuration

Il ne reste plus qu’à faire:

• mvn release:prepare (si pb rencontré faites un mvn release:rollback)
• mvn release:perform

Le bug est rencontré sur svn >=1.5 et mvn-release-plugin version < 2.0.9. Lors de la preparation, il tente de créer un tag avec un svn copy et vous indique que la branche existe déja sans que cela soit le cas. Il s’agit d’un BUG svn. 2 solutions :

• ignorer l’erreur et refaire un mvn release:prepare et ca passe
• mettre à jour votre plugin en version 2.0.9

OSGI – Episode 1

Le premier épisode décrit la mise en place d’une plateforme OSGI. Afin de me simplifier la vie et après de nombreuses lectures, j’ai choisi l’approche “Pax Runner”.

J’ai alors suivi les étapes décrites dans le screencast (en prenant les dernières versions) :

• download de Pax Runner 1.2 (version tar.gz)
• décompression du fichier pour obtenir le répertoire pax-runner-1.2.0
• Ouverture d’un shell (console)
• Déplacement dans le répertoire pax-runner-1.2.0
• exécution de ./bin/pax-run.sh

Et me voila par défault sur la console Felix. Il me reste plus qu’à utiliser Felix avec les commandes suivantes:

• help affiche les commandes Felix;
• shutdown me permet de quitter;
• ps me liste les bundles chargés;

Après avoir quitté Felix, un répertoire de cache est apparu: runner. Ce répertoire stocke les bundles téléchargés pour éviter de les télécharger à chaque démarrage.

Pax runner, c’est beaucoup plus qu’un Felix packagé. Il permet également de lancer les autres plateformes OSGI:

• pax-run.sh –platform=equinox : choix d’Equinox (OSGI by Eclipse)
• pas-run.sh –platform=knopflerfish : choix de knopflerfish

Il existe bien d’autres options utiles comme le montre cette page.

En conclusion de cette rapide note, Pax runner permet d’installer rapidement les plateformes OSGI du marché et donc de valider et tester vos travaux sur celles-ci.

Références :

• pax runner
• screencast d’installation