Salut,

Je vous présente donc les débuts de mon petit moteur 3D (def Wikipédia) aux modestes fonctionnalités et aux grandes prétentions. Un moteur 3D est une bibliothèque permettant de gérer de manière simple le rendu d'une scène 3D à l'écran, et ce de façon entièrement dynamique, afin de créer des applications 3D intéractives.

SCEngine

Ça, c'est son nom, pour Simple C Engine (très précis pour désigner un moteur 3D, notez). Je n'étais pas au top de ma forme pour l'originalité, je ne suis pas contre un changement de nom si vous avez des idées, ça doit cependant rester une abréviation en trois lettres.
Le site web du moteur se trouve ici : http://scengine.tuxfamily.org/
Vous pourrez même parfois y trouver des articles qui parlent d'autre chose que moi et mon moteur.
Le site a été codé par Nab (à l'exception du forum qui est un forum FluxBB) ; merci à lui.
Le SCEngine a été intégralement développé en langage C et utilise exclusivement OpenGL pour le rendu.

Screenshots

Parce que c'est cool. Autant passer tout de suite aux choses sérieuses, voici ce que permet de faire mon moteur :

Vidéos

Parce que c'est encore plus cool.

Fonctionnalités

Voici un bref résumé des fonctionnalités actuellement implémentées dans le moteur :

• chargement et manipulation d'images via une sur-couche pour DevIL ;
• chargement (peu de formats gérés, mais implémentation de nouveaux aisée) et manipulation de meshs ;
• outils de manipulation d'objets mathématique, comme les vecteurs, les matrices et les quaternions ;
• gestionnaire de ressources ;
• shaders GLSL (et Cg mais non fonctionnel :p) ;
• render to texture ;
• génération <acronym title="Tangent Binormal Normal">TBN</acronym> ;
• et donc bump mapping ;
• scene graph ;
• octrees ;
• frustum culling ;
• progressive mesh (LOD) ;
• batching (par shader, texture, ou les deux) ;
• instancing ;
• contrôle des flux (paper) ;
• skybox ;
• contribution culling par octree.

J'allais oublier le plus important : mon moteur est libre et open-source, je le distribue sous licence GPLv3. Le site web est également sous GPLv3.

Si vous avez des questions, des suggestions et/ou des propositions, je suis bien évidemment ouvert.

Quoique, la doc est bien entamée avec Tuxer, toi, Ban, John et moi.

Moi j'attends les vidéo avec impatience!

Citation : N!ghtWolf

Moi j'attends les vidéo avec impatience!

Malheureusement il n'y en aura pas, car mon hébergeur ne me permet pas d'héberger des fichiers aussi lourds que des vidéos. Toutefois des vidéos existent, si tu veux en voir tu peux venir sur le canal IRC qui est dans ma signature et je t'en enverrai.

Citation : Yno

Malheureusement il n'y en aura pas, car mon hébergeur ne me permet pas d'héberger des fichiers aussi lourds que des vidéos.

et youtube/daily/... t'en fait quoi ? (voire megaupload)

DCC Send marche aussi bien

Citation : minirop

et youtube/daily/... t'en fait quoi ? (voire megaupload)

Hum, j'avoue ne pas y avoir pensé, mais les sites bourrés de flash, très peu pour moi.
J'ai donc décidé d'exploiter un de mes fidèles partisans, Kreeg, en lui empruntant quelques Mo sur son ftp.

Bon donc, voici dans un premier temps la vidéo du premier screen que je montre dans le sujet, le modèle est éclairé par trois lumières et l'éclairage est géré par un shader de Phong :
http://barbidou54.free.fr/Stuff/yno/sc [...] _05-04-08.ogg

Je demanderai à Kreeg d'héberger quelques autres vidéos, quand il les aura reçues via DCC.

Salut!
jvoulais savoir, tu comptes implémenter un gestionnaire de particules dans ton moteur 3D?
ça a l'air intéressant comme projet.

Huaaaa
Finalement tu l'as fais en C... impressionnant, faut que je jette un oeil aux sources un de ces 4.

Citation : Tuxer

jvoulais savoir, tu comptes implémenter un gestionnaire de particules dans ton moteur 3D?

Oui bien sûr. Un module permettant l'affichage de particules est déjà en place. Il s'agit en fait ni plus ni moins d'un gestionnaire de point sprites, qui se combine aux matériaux afin de créer toutes sortes de particules (texturée, colorées, transparentes, avec/sans blending, etc...).
Bon, et tant que je parle des point sprites, autant vous montrer un screen de ce que ça donne si je crée un matériau de type "point sprites".
Bon par contre, aucune gestion des mouvements pour le moment. Je ne me suis pas encore réellement penché sur les particules, j'ai vaguement cru voir en lisant quelques sources qu'il y a des feintes et des techniques pour proposer une interface user-friendly et qui permet à la fois de tout faire. Je verrai ça en temps voulu.

Citation : Kevin

Finalement tu l'as fais en C... impressionnant

Merci !
Eh oui en C, car en C++ il en existe déjà de nombreux, l'intérêt serait donc moindre, déjà qu'il ne l'est pas beaucoup (sauf pour moi).

Citation : Kevin

faut que je jette un oeil aux sources un de ces 4.

Bonne chance

ce n'est pas parce qu'il est codé en C et les autres en C++ qu'il aura du succes, au contraire, si on a deja gouté au C++(ou tout autre langage plus haut niveau) on ne reflechit plus au C pour faire un jeu (en 3D en plus)

Tout depend de ta definition de succes.
C'est certain que ce moteur ne sera pas utilisé par des dizaines de milliers de programmeurs à des fins commerciales, et ne sera pas le successeur du cryengine2. En revanche le fait de gerer seul un projet de cette envergure, et d'avoir quelquechose de fonctionnel (pas encore testé, mais les screens sont parlants), tout en se faisant plaisir, c'est deja un immense succès en soi

J'ai téléchargé ton moteur 3D et j'avoue que j'ai rien compris!!! x)
En fait, il semble que Windows ne reconnait pas les fichiers.

Citation : Yno

Malheureusement il n'y en aura pas, car mon hébergeur ne me permet pas d'héberger des fichiers aussi lourds que des vidéos.

Tu as pas mal bossé depuis le lancement du projet !!
Pour ton problème avec les vidéos, je résoudrai ça en te fournissant un accès FTP sur un serveur en datacenter (100Mb/s).

Bon courage !

Citation : Bachir ElMagnifico

ce n'est pas parce qu'il est codé en C et les autres en C++ qu'il aura du succes, au contraire, si on a deja gouté au C++(ou tout autre langage plus haut niveau) on ne reflechit plus au C pour faire un jeu (en 3D en plus)

Hum, je ne suis pas très d'accord avec toi. D'une part je ne recherche pas le succès mais l'intérêt (les personnes programmant en C++ ou tout langage supportant les bibliothèques C pourront quand même l'utiliser). D'autre part ce n'est pas parce qu'on a goûté au C++ qu'on ne touche plus au C. Personnellement le C++ me répugne. Et pour finir, je saisi mal l'intérêt du C++ par rapport au C pour le simple fait que l'application programmée manipule un environnement 3D. Mais à part ça, c'est sympa de t'être penché sur mon sujet

Citation : [ZBM]

En revanche le fait de gerer seul un projet de cette envergure, et d'avoir quelquechose de fonctionnel (pas encore testé, mais les screens sont parlants), tout en se faisant plaisir, c'est deja un immense succès en soi.

Je pense comme toi. Je verrai dans un premier temps quels sont les bénéfices personnels, c'est en fait ma première motivation pour la réalisation de ce projet. Après "on verra".

Citation : N!ghtWolf

J'ai téléchargé ton moteur 3D et j'avoue que j'ai rien compris!!! x)
En fait, il semble que Windows ne reconnait pas les fichiers.

Que tu n'y aies rien compris, c'est normal Et qu'entends-tu par "reconnaissance des fichiers" par Windows ? Ils sont normalement tous encodés en UTF 8, à part peu-être quelques exceptions (je sais, je suis laid), idem pour les retour à la ligne, certains sont en UNIX d'autres pour Windows... il faudrait que je standardise tout ça.
Sinon je tiens à préciser que pour compiler le moteur il te faut les bibliothèques suivantes :
- GLEW, afin d'assurer la gestion des extensions ;
- DevIL, qui se charge de la manipulation des images ;
- libwar, une bibliothèque perso qui effectue le chargement des meshs au format obj. On m'a souvent dit que l'archive était erronée, je l'ai souvent remplacée, mais rien n'y a fait, donc à voir... sinon je pense que je vais essayer de mettre un zip en ligne ;
- l'API Cg, mais c'est très facultatif, il me semble qu'il n'y en a pas besoin tant qu'une macro (que j'ai oubliée) n'est pas définie, et elle ne l'est pas par défaut, pas de soucis de ce côté donc.

Et une fois que tu auras réussi à faire fonctionner les trois premières bibliothèques sur ton IDE, il te faudra construire le projet par toi-même, et là je ne peux pas t'aider car je n'ai aucune connaissance des IDEs. Je n'utilise que des makefiles sous Linux, et rien sous Windows car je ne suis pas sous Windows. Et puis une fois que tu l'auras compilé, tu ne sauras pas t'en servir Il faudrait que je mette des exemples dans la doc.

Citation : golyfruit

Tu as pas mal bossé depuis le lancement du projet !!
Pour ton problème avec les vidéos, je résoudrai ça en te fournissant un accès FTP sur un serveur en datacenter (100Mb/s).

Bon courage !

Merci et, merci ! Il ne me restera plus qu'à (faire) programmer une preview des vidéos sur la page Médias, pour que ça donne un aspect de présentation similaire à celui des screenshots.

Yo, as tu deja programmé en C++?
sinon, je n'ai jamais dis que le C etait inutile, mais on l'emploie dans desdomaines un peu différent de celui là

Citation : Bachir ElMagnifico

Yo, as tu deja programmé en C++?

Je l'ai essayé, je n'ai pas du tout accroché.

Citation : Bachir ElMagnifico

sinon, je n'ai jamais dis que le C etait inutile, mais on l'emploie dans desdomaines un peu différent de celui là

Là dessus je suis d'accord. Toutefois le choix de ce langage s'est aussi fait pour la raison que c'est celui que je maîtrise le mieux.

"Je l'ai essayé, je n'ai pas du tout accroché."
donc tu n'est pas capable de comparer les deux langages objectivement
ce n'est le passé glorieux (noyeau d'Unix en C)qui va lui assurer un bel avenir , et puis dis moi, qu'est ce que le C a de plus que le C++ ?

Je vais être clair et concis : tais toi. Va faire ta propagande C++ ailleurs, merci, c'est un topic sur le SCEngine, pas sur "C++ vs C".

Je vais également être clair et concis : ici on ne parle pas du C vs C++ mais du projet de Yno. Tout message ne parlant pas de ce projet sera envoyé au fin fond de l'enfer ou ailleurs.
Merci de revenir au sujet.

Sa doit être cool ton moteur 3D, mais je fait pas de 3D.
En tout cas, bonne chance et bonne continuation pour la suite.

<hors sujet> Le grand modérateur Haku' !, mon préférer d'ailleurs.

Citation : Yno

- libwar, une bibliothèque perso qui effectue le chargement des meshs au format obj. On m'a souvent dit que l'archive était erronée, je l'ai souvent remplacée, mais rien n'y a fait, donc à voir... sinon je pense que je vais essayer de mettre un zip en ligne ;

En effet l'archive est corrompue d'après Winrar.

http://yno.goldzoneweb.info/libwar/dow [...] -0.1b-src.zip
Voilà, j'ai uploadé une archive .zip, en espérant que ça marchera. La page du site a également été mise à jour.

Citation : Pio154

En tout cas, bonne chance et bonne continuation pour la suite.

Merci pour tes encouragements

Salut,

Aux nouvelles cette semaine :

• une nouvelle version du moteur ;
• support de la transparence avec l'ajout d'un algorithme de tri des faces des meshs ;
• élaboration d'une nouvelle architecture pour le gestionnaire de scènes ;
• support du frustum culling et des niveaux de détail des meshs (<acronym title="Level Of Detail">LOD</acronym>) ;

Screenshots à l'appuis évidemment. À droite un screen présentant la gestion de la transparence sur un simple modèle. À propos de l'algorithme de tri, il s'agit d'un simple tri par insertion, mais dans l'ensemble le tri des faces d'un mesh est relativement rapide je trouve, tant que le mesh possède moins de 500 triangles la consommation CPU reste négligeable (sur mon vieux Sempron @ 1.8GHz en tout cas).

À gauche un screen de mes tests sur les deux techniques d'optimisation que j'ai implémentées. Celles-ci tentent de diminuer le nombre de vertices rendus. La scène comporte au total près de 63 millions de triangles divisés dans 1000 modèles de 62976 triangles chacun. Bien sûr, 62976 représente le nombre de triangles du niveau de détail le plus élevé. Comme vous pouvez le voir au fond de la scène, la géométrie est nettement simplifiée. Bien que "laide" visuellement, cette technique apporte un gain en performances impressionnant, je gagne environ 400ms de temps de rendu au milieu de la scène, et plus d'une seconde lorsque la quasi totalité de la scène est visionnée. Contre un minimum de 25ms de temps de rendu dans le pire des cas avec LOD, j'atteins largement 1100ms dans le pire des cas sans LOD.
C'est une technique qui vaut donc largement le coup, d'autant qu'avec quelques textures et quelques effets graphiques, les contours géométriques moins courbes se font peu remarquer.
Je précise que je possède une GeForce 6600GT en AGP.

N'hésitez pas à poser vos questions si vous en avez.

A+

PS: Merci à goldyfruit pour m'avoir offert un FTP pour les gros fichiers, dorénavant je pourrai héberger mes vidéos là bas

Le SS, c'est le même que tu m'as passé pour le projet de chevkmano ?

Yeaaa sa a vraiment l'air super

Un moteur 3D en C...et ben...me reste du travail a moi

Pour la technique qui fait un peu crade ne t'en fait pas va, ya peu de chance que quelqu'un soit asser fou pour mettre 600 mascotte de blender qui flotte comme sa dans son jeu

Flint eu a peine le temps de prononcer un "Bonne Continuationnnnnn" avant de s'évanouir dans le néant total de la stupidité
-> |°| <- (ceci est une porte)

++

Question idiote: ton LOD il est "automatique"?

Je veux dire par là que c'est un algo maison qui se charge de determiner la géometrie correspondant à chaque niveau de detail à partir du modele original (62976 triangles), ou bien tu charges plusieurs modeles de complexité différente t il reste "juste" à determiner lequel afficher selon la distance?

Citation : [ZBM]

ou bien tu charges plusieurs modeles de complexité différente t il reste "juste" à determiner lequel afficher selon la distance?

Oui, c'est comme cela que je procède, et ce pour deux bonnes raisons :

- déjà, je me vois mal implémenter un algorithme de simplification de meshs, je me suis déjà un peu penché sur le problème et ça n'a pas l'air d'etre de la tarte, donc très peu pour moi ;
- ensuite ce n'est pas vraiment le travail du moteur 3D mais plutôt du modélisateur, Blender dispose de cette fonctionnalité, je n'allais donc pas m'en priver, de plus le calcul de la géométrie simplifiée ferait perdre du temps lors du chargement d'un mesh. Je reconnais qu'en contre-partie il y a davantage d'espace disque utilisé.

Donc oui, il me reste "juste" à déterminer lequel afficher, pour ce faire je procède au calcul de la diagonale de la bounding box du mesh concerné en projetant deux points de celle-ci, et je compare cette distance avec sqrt (2) (distance qui serait obtenue si le mesh était "proche" de la caméra). L'utilisateur a bien sur la possibilité de spécifier la fonction qui déterminera le LOD à partir de la diagonale.

(ps: on dirait que la zform n'aime pas mes accents circonflexes)

Où trouves tu les renseignements nécessaires pour trouver les algos ?

Euh, à part celui qui génère les tangentes, binormales et normales je n'ai piqué aucun algo... y'a pas franchement d'algos dans mon moteur (et y'en a pas franchement besoin), en tout cas pas d'algos dans le sens où je les conçois, si tu pense au LOD, y'a pas d'algo à proprement parler. La plupart des "algos" c'est des maths, et les fonctions mathématiques (matrices, quaternions & cie) je ne les ai pas inventées hein, je les ai pompées où j'ai pu, pas mal sur les FAQs developpez.com.
Sinon, Google is your friend §