Le petit journal du pr0n

Benjamin GIGON's blog

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

Page [ 1 ] [ 2 ] [ 3 ] [ 4 ]

mardi 5 décembre 2006

Les JMJ 2007 dans le jardin magique

Récemment, une bonne partie des lutins magiques de GCU-Squad se sont réunis autour du conteur, venu du désert de Mourryie, pour raconter l'histoire d'OpenGL et de son voyage initatique vers le lac de Braraah.

Tout çà pour vous dire que j'ai donné un cours OpenGL aux frères-lutins de GCU-Squad

Note: Le cours commence à 14:00 pile

Saint Jérome, Chapitre +13, Verset -5.3

Mon seigneur Paul Chavent, 3ème évèque - à gauche après le routeur FreeIX - de la Sainte Parole GL, nous apportes son message de paix, affublé d'un long Chasuble mauve fashion, tendance GayPride et d'un étole vert-kaki-army.

Au menu de la bénédicité: la transformation et la multiplication des pains matriciels, par mon Seigneur Pipeline IX.

Vivement les JMJ 2008 ! [M]

jeudi 30 novembre 2006

*A votre droite, vous trouverez la représentation holographique de notre Commander*

Alors que je visitais un musée sur l'Empire Kilrathi - proposant, au passage, une superbe reproduction d'un village typique de la 25ème dynastie des Kilrathi - un élève-officier de l'unité Navcom nous présenta les différentes techniques de combats CQC [M] afin de se défendre en milieu urbain.
*Enjoy*

mardi 28 novembre 2006

*Vazy! féééé l'amouûûur à la caméra !*


Une "caméra" OpenGL peut-être gérée par deux méthodes générales : modifier la matrice de projection pour déplacer la caméra en elle-même ou bien modifier la matrice de modélisation des objets pour déplacer les objets autour de la caméra.

Pour cela, Gabriel Peyré nous présente deux types de caméra: la caméra freefly et la caméra satellite.
.
A noter, ces deux petits liens, l'un, également sur le déplacement d'une caméra libre en OpenGL.
Et l'autre, plus mathématique, sur les Quaternions et les rotations.


EDIT: Un petit code source d'exemple avec une camera satellite.

David Henry les a vus. Pour lui, tout a commencé par une nuit sombre ...

... le long d'une route solitaire de campagne, alors qu'il cherchait un raccourci que jamais il ne trouva.
Maintenant, David Henry sait que les envahisseurs sont là, qu'ils ont pris forme humaine et qu'il lui faut convaincre un monde incrédule que le cauchemar a déjà commencé... »

Bon, ok, c'est naze, c'était juste pour faire un jeu de mot avec David Henry - un talentueux codeur OpenGL, au passage - qui publie sur son site, des magnifiques codes OpenGL: samples, des librairies et quelques utils - ma foi - d'un fort beau gabarit;


Petit listing des features de Môssieu David Henry
EnvMap (orig. David Henry)
    Les samples :
  • Simple GLUT window
  • Simple SDL window with OpenGL
  • Simple GLX window
  • Reflective environment mapping demo
  • Object outlining demo
  • Particle Fountain
ToonShader (orig. David Henry)
    Les librairies :
  • 3D Math library (Vector, Matrix, Quaternion)
  • Texture loaders, Some OpenGL texture class
  • Shader library, GLSL shader classes.
  • TGA (Truevision TARGA, *.tga) Texture Loader
  • DDS (DirectDraw Surface, *.dds) Texture Loader
  • PCX (ZSoft PCX, *.pcx) Texture Loader
  • BMP (Windows/OS2 Bitmap, *.bmp) Texture Loader
  • OBJ (Alias|Wavefront Object, *.obj) Model Loader
MD5Loader (orig. David Henry)
    Les utils :
  • Quake's MDL Viewer (*.mdl)
  • Quake 2's MD2 Viewer (*.mdl)
  • Doom 3's MD5 Viewer (*.md5mesh, *.md5anim)
  • Doom 3's MD5 Viewer
  • Quake 3's MD3 Viewer
  • Quake 2's MD2 Viewer
  • Quake's MDL Viewer

jeudi 26 octobre 2006

Les cours de tantine Caro

Caro est une gentille personne: Elle met à dispo' quelques petites stuffs OpenGL dont notamment ces cours et également ces TPs conviviaux dont La visualiseuz' de tonton Robert

Chapeau bas, Caro!

Le mirror si cela venait à disparaître dans les méandres du net.

dimanche 22 octobre 2006

Shadow of the Colossus

Une ombre est une zone sombre créée par l'apposition d'un objet opaque entre cette zone et la source de lumière. Elle se matérialise sur une surface par une silhouette à deux dimensions.

La taille de l'ombre dépend de la taille de l'objet intercalé et de sa distance à la source de lumière. Plus il est près de la source de lumière, plus la zone d'ombre sera importante, et inversement.

Pour des sources non ponctuelles, on distingue des zones d'ombre et de pénombre, avec comme caractéristique que plus la source est large et le support le l'ombre éloigné de l'objet qui masque la lumière, plus l'ombre est floue.[1]

Ceci est la théorie;

Dans la pratique 3D, les gestions des ombres sont un peu plus complexes que le simple fait d'activer un paramètre OpenGL.

La construction d'une ombre - ou des ombres s'y rattachant - demande quelques calculs supplémentaires pour obtenir quelques choses de cohérent.

De base, OpenGL n'intègre pas de gestion des "shadows", cependant plusieurs techniques permettent de simuler ces dernières.

De prime abord, il existe plusieurs méthodes comme la projection plane, le shadow mapping, les shadow volumes, etc..

Dans cette petite guerre des ombres et lumières, Tomas Akenine-Möller nous gratifie de superbes articles sur les Soft-Shadows, avec, petite cerise sur le gateau, de magnifiques code-sources développées par les amis Ulf Borgenstam et Jonas Svensson.

Afin de compléter la quinzaine des ombres, deux articles interessants de la part des équipes de NeHe (EN) sur les Shadow Volumes et de TeXel (FR), itoo.

lundi 9 octobre 2006

T'es trop rigide du coude, René !

Quand vous envoyez une balle contre un mur proche, vous aurez une chance sur deux pour qu'elle vous revienne en pleine tête.

Dans un monde simulé, lorsque vous envoyez une balle contre ce même mur .. il la traversera ... (et ne s'arrétera pas).

Pour cela, nous avons besoin (entre autres) d'un gestionnaire qui se chargera de ce genre de "petites" conditions: un moteur de collision (collision, friction, jointures, etc...).

Le projet "O.D.E." est fait pour cela.

O.D.E est l'acronyme de Open Dynamics Engine, une bibliothéque C/C++ gérant la simulation des dynamiques entre corps solides.
Cela se traduit par une gestion des jointures entres objets, une gestion des collisions en résultant et des frictions entre ces derniers.

O.D.E. se démarque par une utilisation relativement simple et indépendante des autres gestionnaires dont, notamment, le gestionnaire de l'environnement graphique (OpenGL/DirectX).

O.D.E. a une particularité que je crois ne pas avoir vu dans d'autres projets Open source dans cette catégorie: une utilisation sur des jeu-videos commerciaux.
A son palmarès, nous pouvons citer les bien connus S.T.A.L.K.E.R ainsi que Call Of Juarez et des éditeurs du monde 3D tel que SoftImage|XSI.

A ce sujet, Al's Programming nous offre quelques articles de mise-en-bouche du moteur physique ODE avec OpenGL:
Et afin de compléter notre formation, il existe le bien nommé OpenDE, site de la communauté O.D.E, où nous retrouverons quelques tutoriaux convivaux.

A noter qu'il existe - pour les plus fainéants ;) - des couches d'abstractions pour O.D.E :
  • Open Physics Abstraction Layer : OPAL
  • ODE Abstraction Layer : EZPhysics

Dans les solutions concurrentes, nous avons Newton Physics Engine qui n'est malheureusement pas libre; et son site communautaire
(je vous conseille les samples très sympathiques, notamment la gestion des collisions).

A vos collisions !


PS: Si quelqu'un retrouve le vrai site du projet "ODE Editor" (ODEEd), dont (l'ancien ?) site est malheureusement injoignable, je suis preneur. [Cache Google]

Page [ 1 ] [ 2 ] [ 3 ] [ 4 ]