raafal - un project de framework d'application 3d

[Ulix]

Bonjour a tous .

Sujet intéressant !

Dobro a écrit :

"de sorte qu'on supprime le Flou de la profondeur de champs"

Cela me fait pensé au film de Pitof : Vidocq sorti en 2000 et quelques

J'avais apprécier le côté technique, le fond était aussi net que le premier plan parce que filmer avec une caméra numérique. (si mes souvenir son bon!)
J’aime assez regarder les détails , l'environnement, etc... surtout quand je vois le film, disons pour la 2ème ou x fois (normal je connais déjà l'action, donc je regarde plus le contexte.)

A+
Ulix
 

[Ar-S]

Bonjour a tous .
J'avais apprécier le côté technique, le fond était aussi net que le premier plan parce que filmer avec une caméra numérique. (si mes souvenir son bon!)
J’aime assez regarder les détails , l'environnement, etc... surtout quand je vois le film, disons pour la 2ème ou x fois (normal je connais déjà l'action, donc je regarde plus le contexte.)

Salut Ulix !
Pour ce qui était des paysages je ne me souviens plus trop, mais j'avais trouvé les effets de détourage des acteurs particulièrement mal fichus dans se film. Bon faut dire qu'il date maintenant, c'est bien que des Français aient tenté le hightech au cinéma, c'est encore trop rare aujourd'hui.

[Backup]

Cela me fait pensé au film de Pitof : Vidocq sorti en 2000 et quelques
 

arf ; n'etant pas un gros cinéphile , j'ai du passer a coter de ça

[venom]

ecran 3D sans lunettes et résolution 8K
Sympa cette effet.
Pas bête ce système de multi dalles

Et bonne continuation a grabiller






@++

[MetalOS]

Moi je vient d'investir dans une Tv 3D ou je me suis acheter en même temp avatar en blueray. Et bien je peut vous dire que par rapport à la version cinéma j'ai comlètement redécouvert le film. La 3D est super présente sur toutes les scènes du film contrairement à la version ciné ou beaucoup de passage semblais en 2D.

[grabiller]

j'ajoute que pour la Stereoscopie, l'avenir semble venir des plans
filmé avec plusieurs camera , par exemple une pour filmer le fond
une pour les plans un peu plus proche , et une autre pour les plans proches
de sorte qu'on supprime le Flou de la profondeur de champs../..

Bien que tout cela soit un peu hors sujet avec le topic, il me semble important de rectifier un malentendu.

Quand je parlais de profondeur de champ qui 'ne marche pas' avec la stéréoscopie, je parlais de profondeur de champ limitée volontairement par le réalisateur (Cameron), pas d'une impossibilité technique.

Il est tout à fait possible d'avoir tous les plans nets, cela n'a rien à voir avec la stéréoscopie ou le fait de filmer avec plusieurs caméras, uniquement du diaphragme utilisé et donc de la quantité de lumière utilisée.

En passant, question lumière et profondeur de champ, c'est aussi un grand problème avec le 'High Frame Rate', car plus on a d'images par seconde, plus l'éclairement du capteur (ou pellicule) est court, et donc il faut 'ouvrir' plus en perdant de la profondeur de champ, justement, ou bien éclairer beaucoup plus pour obtenir une grande profondeur de champ, ce qui représente des coûts beaucoup plus élevés en termes d'éclairage.

[djes]

Héhé, ça fait du bien ce retour à la réalité physique !

Tiens, je viens de lire là : http://www.cgsociety.org/index.php/CGSF ... ed_journey
un truc qui me fait un peu bondir, pourtant par un ponte, sur la limite de la perception. Pour moi les 60 imgs/s, c'est pour améliorer la fluidité des mouvements, surtout à grande vitesse ; bon, on peut simuler ça avec un motion blur, mais voir la différence entre par exemple 60i/s et 100i/s, ça ne m'étonnerait pas que certaines personnes bien entraînées (gamers, chasseurs ) y parviennent.

Sinon, j'aimerais bien voir le système de bones/muscles/couche graisseuse/peau dont il parle

[Backup]

bon , il en est ou le monsieur ?

depuis Janvier , ça va faire 5-6 mois ... j'imagine que c'est bien avancé ...

[Frenchy Pilou]

Salut,

Pour votre information, j'ai été embauché par WalkingTheDog
(Belgique / Bruxelles) à travailler en tant que superviseur CG sur le film "La
Mécanique du Coeur ", produit par EuropaCorp.

Normalement, je devrais travailler sur le film jusqu'en Septembre 2013. en attendant
Je n'ai que très peu de temps libre pour travailler sur raafal. Cela signifie qu'il
y aura un écart important dans le développement raafal durant cette période.
J'espère que vous comprendrez.

Les bonnes nouvelles sont que, après cette période de production, je serai le plus
certainement en mesure de travailler sur raafal à temps plein pendant un certain temps.

Cela dit, je vais quand même fournir des mises à jour de temps en temps quand j'aurai la chance de faire quelques progrès sur raafal.

[Backup]

ha bah oui en effet

[grabiller]

bon , il en est ou le monsieur ?

Et bien il avance tant bien que mal durant ses rares temps libres

J'ai cependant commencé à refactorer le code de la partie GUI avec les nouvelles fonctionnalités type Module, Runtime, BindEvent, PostEvent, etc.. et cela se présente plutôt bien à part quelques petits bugs que j'ai soumis sur le forum anglais.

J'aime beaucoup ces nouvelles features, à part le fait qu'on ne puisse accéder à la partie privée d'un Module depuis la partie privée d'un autre Module, ce qui serait très utile pour conserver la notion d'encapsulation avec l'inhéritance (Extends), et ce d'une manière 'clean'. J'ai suggéré à Fred d'y réfléchir encore mais cela n'a pas l'air de trop l'enthousiasmer, dommage..

La librairie Runtime est vraiment super, surtout pour les évènements, callbacks etc.. sans devoir créer de connexion 'en dur' à l'avance (ou sans avoir l'info à l'avance).

Bref, j'ai préféré commencer à 'refactorer' histoire de repartir sur de bonnes bases. C'est en bonne voie

[grabiller]

Quelques nouvelles en passant:

Le système de 'layout' de l'interface graphique de raafal est terminée. Il s'agit d'un système assez classique de 'viewport' splittables horizontalement, verticalement ou les deux. L'entête de chaque viewport permet de sélectionner le 'widget' qui sera vu dans ce viewport (explorer,log,vue 3d,etc..) et il est escamotable.

Chaque viewport peut avoir plusieurs 'tabs' (widgets), peut être 'maximisé'(M), 'fermé'(X) et 'splitté'(V/H/Q). Un particularité de ce système de layout est que chaque viewport peut être défini comme un 'groupe de maximisation', ce qui veut dire que si on split ce viewport, les sous-viewports ne seront maximisés que dans le cadre de ce viewport 'groupe' (il peut y en avoit autant qu'on veut).

Pour l'instant cette interface est complètement textuelle (pas d'icône).

Je dois maintenant continuer à implémenter les widgets et surtout les controls.

[G-Rom]

magnifique, par curiosité , comment procède tu pour la gestion de tout cela ?
Compte tu séparé la gui du reste de manière à l'utilisé pour d'autre projets ?

[grabiller]

magnifique, par curiosité , comment procède tu pour la gestion de tout cela ?../..

Et bien c'est géré par un system de quadtree, chaque viewport peut avoir 2 enfants (à chaque split), et peut se comporter comme un viewport ou comme un splitter (dès qu'il a 2 enfants), soit horizontal, soit vertical.

Le système est conçu pour que soit le viewport 'root' gère un CanvasGadget, auquel cas les descendants (y compris les widgets et contrôles car c'est transparent pour eux) dessinent dans ce même Gadget, soit que chaque viewport ait son propre CanvasGadget (je verrai par la suite le plus efficace, notamment quand je ferai intervenir l'OpenGL).

../..Compte tu séparé la gui du reste de manière à l'utilisé pour d'autre projets ?

Oui, normalement - et si je ne rencontre pas de problème majeur - le code de cette GUI sera dans une DLL/DSO utilisable pour d'autres applications.

En fait, dans ce genre d'interface, seuls les 'Widgets' font le lien entre la GUI et les données de l'application. Le fenêtrage, les viewports et les contrôles sont indépendants. Du coup pour une application différente il suffira d'implémenter (ou de modifier) des 'Widgets' propres à l'application.

Mais j'essaye de découpler au maximum la GUI de l'application, notamment grâce à la nouvelle fonctionalité 'Runtime' de PB et aux events customizables.

Il reste, ceci dit, encore beaucoup à faire.

[G-Rom]

Et bien c'est géré par un system de quadtree, chaque viewport peut avoir 2 enfants (à chaque split), et peut se comporter comme un viewport ou comme un splitter (dès qu'il a 2 enfants), soit horizontal, soit vertical.

Un peu comme QT ou gtk sur certain point de l'agencement , cela te permet d'avoir une application uniforme.

Il reste, ceci dit, encore beaucoup à faire.

Une gui ce code assez rapidement , du moins les fondements , les contrôles c'est une autre paire de manche
Pense aussi à faire une doc si tu comptes distribuer ou même travailler avec d'autres dev.
En tout cas j'ai hâte de voir toutes ces briques les unes sur les autres