Discussion :

[seeme]

Bonjour à tous,

Voilà: motivé par les excellents articles concernants le yes::engine, j'ai commencé à me documenter un peu sur la réalisation d'un moteur 3d.

Je vois régulièrement des projets se lancer (la plupart du temps infaisables...), et je souhaiterais me lancer à mon tour dans cette expérience.

L'objectif serait de faire une sorte d'incubateur sur lequel se faire ma main. Hors de question d'espèrer ratraper ogre ou n'importe qu'elle autre moteur, l'idée ici est de développer mes capacités sur un moteur correct qui devrait permettre de charger des modeles (quelques formats) de gérer l'éclairage, les ressources etc etc... mais un niveau minimal (l'objet permetra par la suite de développer un peu tout ca)
L'idéal serait de pouvoir se faire la main sur plusieurs algorithme "célèbres" (2/3 possibilités d'éclairage par exemple).

Nous serions deux sur le projet avec de bonnes capacités en c++ (cycle ingénieur).

Encore une fois, j'insiste, l'objectif est d'avoir un moteur minimaliste mais suffisement souple pour pouvoir par la suite l'améliorer et implémenter un maximum de solution pour chacun des problèmes.

Je souhaiterais donc avoir votre avis sur la réalisabilité (sic) d'un tel projet, les pièges à éviter, de la doc complémentaire à celle du yes::engine (dont la structure de notre moteur s'inspirerait)...

Merci d'avance
Seeme

[ash.ice.loky]

Plusieurs sujet traitent déjà de cette question.

La réponse est oui, tu peux tout à fait faire quelques choses de sympa, ludique et évolutif, tout est une question de design.

Fait une recherche sur le forum et tu y trouveras surement ton bonheur

[Emmanuel Deloget]

Bonjour à tous,

Voilà: motivé par les excellents articles concernants le yes::engine, j'ai commencé à me documenter un peu sur la réalisation d'un moteur 3d.

Je vois régulièrement des projets se lancer (la plupart du temps infaisables...), et je souhaiterais me lancer à mon tour dans cette expérience.

L'objectif serait de faire une sorte d'incubateur sur lequel se faire ma main. Hors de question d'espèrer ratraper ogre ou n'importe qu'elle autre moteur, l'idée ici est de développer mes capacités sur un moteur correct qui devrait permettre de charger des modeles (quelques formats) de gérer l'éclairage, les ressources etc etc... mais un niveau minimal (l'objet permetra par la suite de développer un peu tout ca)
L'idéal serait de pouvoir se faire la main sur plusieurs algorithme "célèbres" (2/3 possibilités d'éclairage par exemple).

Nous serions deux sur le projet avec de bonnes capacités en c++ (cycle ingénieur).

Encore une fois, j'insiste, l'objectif est d'avoir un moteur minimaliste mais suffisement souple pour pouvoir par la suite l'améliorer et implémenter un maximum de solution pour chacun des problèmes.

Je souhaiterais donc avoir votre avis sur la réalisabilité (sic) d'un tel projet, les pièges à éviter, de la doc complémentaire à celle du yes::engine (dont la structure de notre moteur s'inspirerait)...

Merci d'avance
Seeme

Quelques pièges à éviter :

1) "je veux supporter OpenGL et DirectX" : non, tu ne veux pas. Vouloir s'auto-doubler sa charge de travail, ça s'appelle du masochisme. Sans compter que tu n'utiliseras jamais les deux en même temps. Et puisque les deux font la même chose... (note: OpenGL te donne accès au GS sous XP, contrairement à DirectX 10 qui ne fonctionne que sous Vista). (note n°2: mes respects à Laurent. Oui, je sais, le yes::engine supporte DirectX et OpenGL).

2) "le fixed function pipeline, c'est cool" : oui, et il est bien plus compliqué d'abstraire deux fonctionnements très différents qu'un seul. Alors autant l'abandonner tout de suite - quitte à le réimplémenter en utilisant des shaders simples.

3) "et comme ça, je peux attaquer directement OpenGL..." (ou DirectX (mais pas les deux, hein ?)) : tu veux faire un moteur pour t'abstraire de ces problèmes, alors autant t'abstraire de l'API. Mais s'isoler de l'API n'est pas forcément quelque chose de très simple : on a tendance à répliquer son architecture. Et bien, ça n'a pas de sens.

Si on prend l'architecture DirectX 9, l'objet central est le Direct3DDevice9. Une instance de cet objet permet de créer des ressources, envoyer des ordres à la carte graphique, etc. Ce qui est très bien puisque l'interface représente la carte video - c'est très bas niveau. Il ne sert à rien d'encapsuler ces appels dans une classe C++ engine:irect3DDevice qui offre les même services (autant utiliser directement DirectX, on s'économise pas mal de travail). La plupart du temps, on souhaite créer un renderer - et c'est là que le bât blesse : un renderer n'a pas pour mission de créer une ressource (c'est une factory de ressource qui doit s'en charger) ou de maintenir l'état des ressources (une collection de ressource s'en chargera très bien).

Mais trop d'abstraction tue l'abstraction : on obtient assez aisément une architecture rigide et difficile à maintenir si on y fait pas attention.

4) "et là , mon renderer, j'en fait un singleton..." : et là, mon coeur, j'en fait du hachis parmentier. Non, votre renderer n'est pas un singleton. Ca ne sert à rien (non, vous n'allez pas créer deux instances. Pourquoi diable feriez vous ça, mon cher ?) et fera plus que vous ennuyer par la suite (et si je décidait de binder un renderer à une surface de rendu + un viewport dès la création et jusqu'à sa destruction, pour me simplifier la vie ?). De toute manière, je déconseille formellement à quiconque d'utiliser le pattern singleton, au moins tant qu'on a pas compris à quoi il sert vraiment (et pourquoi il est plus génant qu'efficace). Mais c'est un point de détail. (note n°3: mes respects à Laurent. Oui, je sais, le yes::engine utilise des singletons).

5) "je refais les fonctions de gestion de vecteurs / plans / matrices... ": oui, pourquoi pas ? Les gens qui les ont écrit sont incompétents de toute façon. Il écrivent exprès du code lent et buggé, de manière à vous forcer à réécrire ces parties hautement passionnantes. Après ça, mettez vous à memset() et memcpy(). C'est très intéressant aussi. Et pourquoi ne pas développez vos propres conteneurs en C++ ? Voire un compilateur, au point ou on en est...

Rien d'autre ne me vient à l'esprit pour l'instant.

Ah si, un mot, pendant que j'y pense: faisabilité.
C'est un peu mieux que réalisabilité, et en plus, ça existe...

[smashy]

Ah si, un mot, pendant que j'y pense: faisabilité.
C'est un peu mieux que réalisabilité, et en plus, ça existe...

Tout le reste, ca ressemble a du trollage (mais pas aveugle au final), mais la (particulierement) je te suits :

[Emmanuel Deloget]

Tout le reste, ca ressemble a du trollage (mais pas aveugle au final), mais la (particulierement) je te suits :

Disons que c'est écrit sur un mode ironico-informel, ce qui n'était peut être pas une bonne idée. Mais je suis sûr que notre interlocuteur a de l'humour.

Je suis pas vraiment un fan du trollage. Ou trolling. C'est le condensé de la somme de 5 ans de réponses sur gamedev.net (non, pas les miennes).

[smashy]

Je vous rassure, le ton ironique ne m avait pas echappe et au final , je trouve les reflexions d'Emmannuel pleinnes de bon sens.

[ZeGlobox]

Quelques pièges à éviter :

1) ...
2) ...
3) ...
4) ...

5) "je refais les fonctions de gestion de vecteurs / plans / matrices... ": oui, pourquoi pas ? Les gens qui les ont écrit sont incompétents de toute façon. Il écrivent exprès du code lent et buggé, de manière à vous forcer à réécrire ces parties hautement passionnantes. Après ça, mettez vous à memset() et memcpy(). C'est très intéressant aussi. Et pourquoi ne pas développez vos propres conteneurs en C++ ? Voire un compilateur, au point ou on en est...

J’suis entièrement d’accord avec toi (sur tous les points) et sur le dernier particulièrement : réinventer la roue ne sert à rien…
Mais d’un autre coté, s’il cherche a faire son propre petit moteur 3D, c’est sans aucun doute dans un but pédagogique.. Et là, ça change tout : réinventer la roue est, je pense, particulièrement souhaitable. Concevoir, implémenter, debugger, optimiser sa propre librairie, puis, étape très importante, la confronter à la ‘concurrence’ est hautement instructif et bénéfique, beaucoup plus que de simplement regarder le code ultra-optimisé des autres !
Assembler un ensemble de briques déjà faites, juste en les regardant vaguement n’apprend pas forcement grand-chose même si, dans la plupart des cas, c’est bien évidemment la meilleure chose à faire en terme de productivité et d'assurance de bon resultats…
Durant ma petite carrière de programmeur, j’ai du, et je suis certainement pas le seul evidemment, à de nombreuses reprises, réécrire complètement certaines choses que l’on considère habituellement comme acquises, comme par exemple plusieurs gestionnaires d’allocation mémoire, des librairies mathématiques, et même des containers justement, etc… : Et bien c’est un exercice à la fois passionnant et ultra instructif dans la plupart des cas !!

Donc, personnellement, si un débutant me dit qu’il veut faire un petit moteur graphique, je lui conseillerais, au contraire, d’essayer de faire lui-même certaines ‘briques de base’ du moins dans un premier temps, notamment tout ce qui est ‘calcul matriciel’ … Il apprendra beaucoup en le faisant ! Pour moi, c'est totalement indispensable de faire ca au moins une fois dans sa vie !

[silfride]

Envoyé par Emmanuel Deloget
Quelques pièges à éviter :

1) "je veux supporter OpenGL et DirectX" : non, tu ne veux pas. Vouloir s'auto-doubler sa charge de travail, ça s'appelle du masochisme. Sans compter que tu n'utiliseras jamais les deux en même temps. Et puisque les deux font la même chose... (note: OpenGL te donne accès au GS sous XP, contrairement à DirectX 10 qui ne fonctionne que sous Vista). (note n°2: mes respects à Laurent. Oui, je sais, le yes::engine supporte DirectX et OpenGL).

2) "le fixed function pipeline, c'est cool" : oui, et il est bien plus compliqué d'abstraire deux fonctionnements très différents qu'un seul. Alors autant l'abandonner tout de suite - quitte à le réimplémenter en utilisant des shaders simples.

3) "et comme ça, je peux attaquer directement OpenGL..." (ou DirectX (mais pas les deux, hein ?)) : tu veux faire un moteur pour t'abstraire de ces problèmes, alors autant t'abstraire de l'API. Mais s'isoler de l'API n'est pas forcément quelque chose de très simple : on a tendance à répliquer son architecture. Et bien, ça n'a pas de sens.

Si on prend l'architecture DirectX 9, l'objet central est le Direct3DDevice9. Une instance de cet objet permet de créer des ressources, envoyer des ordres à la carte graphique, etc. Ce qui est très bien puisque l'interface représente la carte video - c'est très bas niveau. Il ne sert à rien d'encapsuler ces appels dans une classe C++ engine:irect3DDevice qui offre les même services (autant utiliser directement DirectX, on s'économise pas mal de travail). La plupart du temps, on souhaite créer un renderer - et c'est là que le bât blesse : un renderer n'a pas pour mission de créer une ressource (c'est une factory de ressource qui doit s'en charger) ou de maintenir l'état des ressources (une collection de ressource s'en chargera très bien).

Mais trop d'abstraction tue l'abstraction : on obtient assez aisément une architecture rigide et difficile à maintenir si on y fait pas attention.

4) "et là , mon renderer, j'en fait un singleton..." : et là, mon coeur, j'en fait du hachis parmentier. Non, votre renderer n'est pas un singleton. Ca ne sert à rien (non, vous n'allez pas créer deux instances. Pourquoi diable feriez vous ça, mon cher ?) et fera plus que vous ennuyer par la suite (et si je décidait de binder un renderer à une surface de rendu + un viewport dès la création et jusqu'à sa destruction, pour me simplifier la vie ?). De toute manière, je déconseille formellement à quiconque d'utiliser le pattern singleton, au moins tant qu'on a pas compris à quoi il sert vraiment (et pourquoi il est plus génant qu'efficace). Mais c'est un point de détail. (note n°3: mes respects à Laurent. Oui, je sais, le yes::engine utilise des singletons).

5) "je refais les fonctions de gestion de vecteurs / plans / matrices... ": oui, pourquoi pas ? Les gens qui les ont écrit sont incompétents de toute façon. Il écrivent exprès du code lent et buggé, de manière à vous forcer à réécrire ces parties hautement passionnantes. Après ça, mettez vous à memset() et memcpy(). C'est très intéressant aussi. Et pourquoi ne pas développez vos propres conteneurs en C++ ? Voire un compilateur, au point ou on en est...

Rien d'autre ne me vient à l'esprit pour l'instant.

Ah si, un mot, pendant que j'y pense: faisabilité.
C'est un peu mieux que réalisabilité, et en plus, ça existe...

Plutôt bizarre ton humour Emmanuel Deloget, Comment tu peux dire que réinventer les phases de développement de quelque chose est inutile c’est complètement absurde, peut être que c’est le cas pour une entreprise par contre pour un étudiant ou autre débutant je conseille vivement de connaître les détailles d’une conception et plus pour un moteur graphique, tu leur conseille d’améliorer un moteur graphique alors qu’ils ne connaissent même pas comme tu dis : « les rouages » laisse moi rire.
Personnellement je développe un moteur 3D sous java et cela sans utiliser l’Opengl ou Directx et franchement le temps consacré a apprendre les bases du développement d’un Moteur 3D je n’ai jamais considéré cela comme une perte de temps au contraire c’est très enrichissant d’ailleurs c’est mon sujet de fin d’étude (cycle ingénieur).

[Emmanuel Deloget]

Plutôt bizarre ton humour Emmanuel Deloget

Ma foi, j'étais fatigué.

Comment tu peux dire que réinventer les phases de développement de quelque chose est inutile c’est complètement absurde, peut être que c’est le cas pour une entreprise par contre pour un étudiant ou autre débutant je conseille vivement de connaître les détailles d’une conception et plus pour un moteur graphique, tu leur conseille d’améliorer un moteur graphique alors qu’ils ne connaissent même pas comme tu dis : « les rouages » laisse moi rire.
Personnellement je développe un moteur 3D sous java et cela sans utiliser l’Opengl ou Directx et franchement le temps consacré a apprendre les bases du développement d’un Moteur 3D je n’ai jamais considéré cela comme une perte de temps au contraire c’est très enrichissant d’ailleurs c’est mon sujet de fin d’étude (cycle ingénieur).

Faire un moteur 3D sans faire de jeu est quelque chose de
1) très répandu.
2) très peu utile.
La raison en est très simple : à mois de connaître l'architecture des jeux vidéo, c'est à dire à moins d'avoir une certaine expérience dans le développement de jeu vidéo, il est difficile de concevoir un moteur de jeu - au niveau architecture.

Je sais que c'est très à la mode de faire son propre moteur (après tout, Crytek le fait, Epic le fait, etc). Le truc, c'est que Crytek et Epic font aussi des jeux - ni l'une ni l'autre ne se considèrent comme des boites dont le premier business est de vendre des moteurs (quoi que... Mark Rein est assez ambigu sur ce sujet). Ce faisant, ils s'assurent que leur moteur permet de développer des vrais jeux.

Ceci dit, malgré le ton très sarcastique de mon post, je ne cherche pas à décourager qui que ce soit - juste à donner quelques idées sur ce qu'il ne faut pas perdre de temps à faire.

En ce qui concerne une librairie géométrie, il est certainement plus utile de réutiliser du code déjà écrit que de réécrire le code à partir de rien. Les raisons pour ça sont très simples :

1) il s'agit de mathématiques - pas d'architecture logicielle. Une règle mathématique ne change pas très souvent, mais il est quand même possible d'injecter des bugs en la transcrivant en code. Ensuite, il faut débugger tout ça - et ce n'est pas forcément de la tarte.
2) c'est très long et très frustrant à écrire (ce n'est pas comme si je ne l'avais pas fait plusieurs fois avant de vous dire ça).
3) en réutilisant des librairies existantes et en écrivant juste l'interface (via des classes vector3d, matrix4d, etc), on s'affranchit de la part agaçante tout en gardant la part intéressante (l'architecture autour du code; c'est là qu'est la valeur ajoutée).

Il ne s'agit même pas d'une vision purement productive - il s'agit aussi d'une vision programmeur hobbyiste - pour qui la frustration est un ennemi mortel.

Que faire alors si je veux profiter de l'écriture d'une telle lib pour 'apprendre' ? La réponse est là aussi très simple : un bouquin de math de terminale S (enfin, je ne sais pas à quoi ça correspond maintenant) contient toutes les informations souhaitées, voire plus. Si l'idée est d'apprendre un nouveau set d'instruction pour notre processeur 'chéri' (SSE, SSE2, ...), la lecture et l'étude du code déjà écrit aura plus de chance d'être utile (puisqu'il fonctionne (à priori)) que d'essayer de réinventer la roue (et de le faire moins bien, tout en ayant l'impression de l'avoir bien fait).

Suis-je plus clair ?

[silfride]

Oui c'est vrai vu comme ça c'est pas très intéressant, par contre développer un jeu ou un moteur 3D c'est pas vraiment la même chose, pour faire un jeu il faut des compétences dans plusieurs domaines autre que programmation et seul une vrai entreprise peut prétendre faire un vrai jeu.
Je reviens maintenant au moteur 3D, je crois qu'actuellement les entreprises qui font des jeux ne s'intéresse pas a proprement dit au développement du moteur 3D souvent ils délestent cette partie a d’autre boite qui sont spécialisé dans ce domaine, donc on est pas forcé de faire un jeu si on développe un moteur 3D.
D’ailleurs il n’y a pas que les jeux qui sont concerné par le moteur 3D, la modélisation par exemple et beaucoup d’autre domaine.

Que faire alors si je veux profiter de l'écriture d'une telle lib pour 'apprendre' ? La réponse est là aussi très simple : un bouquin de math de terminale S (enfin, je ne sais pas à quoi ça correspond maintenant) contient toutes les informations souhaitées, voire plus. Si l'idée est d'apprendre un nouveau set d'instruction pour notre processeur 'chéri' (SSE, SSE2, ...), la lecture et l'étude du code déjà écrit aura plus de chance d'être utile (puisqu'il fonctionne (à priori)) que d'essayer de réinventer la roue (et de le faire moins bien, tout en ayant l'impression de l'avoir bien fait).

Suis-je plus clair ?

Oui un peu.......

[Mat.M]

Bonjour à tous,

Voilà: motivé par les excellents articles concernants le yes::engine, j'ai commencé à me documenter un peu sur la réalisation d'un moteur 3d.

Je vois régulièrement des projets se lancer (la plupart du temps infaisables...), et je souhaiterais me lancer à mon tour dans cette expérience.

Seeme

Je rebondis sur ce sujet : à quoi cela va-t-il te servir un moteur de jeu, je n'arrive pas à piger ce raisonnement que tout le monde a.
On fait un moteur de jeu destiné à un jeu et non l'inverse à moins de refaire un DarkBasic mais les gens qui font DarKBasic et autres ils ont bien plus d'avance.
Vouloir faire seulement un moteur de jeu c'est comme concevoir une machine-outil mais cette machine outil ne te servira à rien..

Oui c'est vrai vu comme ça c'est pas très intéressant, par contre développer un jeu ou un moteur 3D c'est pas vraiment la même chose, pour faire un jeu il faut des compétences dans plusieurs domaines autre que programmation et seul une vrai entreprise peut prétendre faire un vrai jeu.

oui mais la technique seule ne suffisent pas ; il faut que le jeu plaise et que les gens aient envie de joueur à ce jeu.
C'est une notion que la majorité des gens de ce forum perdent de vue..
A quoi ça sert de faire un jeu avec des effets dans tous les sens et des particules si tu y joues 10 minutes et qu'au bout du compte tu le laisses dans un coin ?
Je suis persuadé qu'il ya des jeux c'est pas des bombes techniquement eh bien les gens apprécient d'y jouer.
Regarde le premier de la série Sim les graphismes étaient un peu dépassé eh bien Maxis en a vendu des millions d'exemplaires..parce qu'il ya des gens chez Maxis qui ont su concevoir quelque chose qui plairait aux gens.
Quel intérêt de faire un superbe moteur de jeu si cela n'intéresse personne ?
Le premier des Sims il n'avait pas un moteur de jeu forcément génial qui-tue et pas dit que pour Sims version 2 cela soit pareil...

[Emmanuel Deloget]

Oui c'est vrai vu comme ça c'est pas très intéressant, par contre développer un jeu ou un moteur 3D c'est pas vraiment la même chose, pour faire un jeu il faut des compétences dans plusieurs domaines autre que programmation et seul une vrai entreprise peut prétendre faire un vrai jeu.
Je reviens maintenant au moteur 3D, je crois qu'actuellement les entreprises qui font des jeux ne s'intéresse pas a proprement dit au développement du moteur 3D souvent ils délestent cette partie a d’autre boite qui sont spécialisé dans ce domaine, donc on est pas forcé de faire un jeu si on développe un moteur 3D.
D’ailleurs il n’y a pas que les jeux qui sont concerné par le moteur 3D, la modélisation par exemple et beaucoup d’autre domaine.

Les entreprises qui développent des moteurs 3D pour être utilisées dans des produits tierces rentrent dans 2 catégories :

1) Si leur core business est le développement d'applications, le moteur est un produit dérivé. Il peut être très réutilisable, et de fait se retrouver à être vendu comme un produit en soi. L'application sert alors à prouver que le moteur peut être utilisé pour créer un autre produit. Un exemple : certaines sociétés livrent le code source d'un jeu à tout ses licensed developers. Si vous récupérer une license pour le moteur d'Epic, vous récupérez aussi le code source de Gears of War (si je ne m'abuse...).

2) si au contraire leur core business est la technologie (ça arrive: cf. gamebryo), alors elles peuvent compter sur des années d'expérience de personnes qui connaissent leur cible (dans le cas de gamebryo : les jeux vidéo). Les employés sont souvent d'anciens programmeurs de jeux vidéo. Ils savent quoi faire pour que leur moteur puisse être intégré dans un produit tierce.

Dans les deux cas, une constante : les personnes qui développent le moteur savent exactement comment concevoir celui-ci pour qu'il puisse être utilisé dans un produit tierce. Cette expérience ne peut s'acquérir que d'une seule manière : développer un tel produit, ou former une équipe qui a déjà développé ce type de produits.

Si le raisonnement tient la route en ce qui concerne les moteurs de jeu (forcément complexes), en est-il de même lorsqu'on parle de moteur 3D ?

Je pense que oui : sans avoir développé au moins un jeu sérieux, comment designer un moteur 3D ? Sans cette expérience, je ne sais pas si la vision que j'ai n'est pas en conflit avec l'utilisation qui sera faite plus tard de mon moteur. Celui-ci me forcera à adopter une architecture non-optimale pour le développement de l'application, alors que dans l'esprit, c'est au moteur de s'adapter à l'architecture de l'application. Un exemple frappant : le moteur irrlicht, et notamment le design de la gestion de la GUI intégrée : dès lors qu'on cherche à faire plus que d'afficher une dialogue simple, on se heurte à des problèmes de taille. Par exemple, il est très difficile de créer une boite de dialogue modale qui affiche une boite de dialogue modale (un cas simple : une message box de confirmation à la sortie d'une autre boite de dialogue). Les personnes qui ont modélisé cet outil n'avaient pas l'expérience et le recul nécessaire pour penser aux cas d'utilisation qui sont monnaie courante dès lors qu'on développe quelque chose d'un peu complexe. Le résultat : c'est inutilisable, sauf à ne faire que des GUI triviales.

Reste qu'on peut quand même modérer mes propos : il existe un type d'architecture qui peut être mise en place sans connaissance véritable du métier cible. L'astuce consiste en la création de couches d'abstraction. Pour un moteur 3D, il faut abstraire l'accès au device. Le problème, c'est que ce type de layer n'a qu'une valeur ajoutée très faible. Il est toujours possible d'étendre les fonctionnalités de cette librairie après coup, mais dans ce cas on retombe sur le problème sus-cité.

D'ou l'importance de faire un jeu de taille conséquente (je ne parle pas d'un mastodonte; juste d'un jeu conséquent. Par exemple, un petit FPS).

[Shirakana]

seeme, je te conseille de te fixer d'abord un thème et un but a ton projet.

Le projet: faire un moteur 3D, ok. Mais quelle va être l'utilisation de ce moteur ? Ça c'est quelque chose qu'il faut déterminer avant la conception du moteur en lui même car c'est ça qui va orienter ton design. Donc reformule ton projet en un autre qui utilisera ton moteur 3d: ex. je veux faire un jeu, je veux faire un logiciel d'architecture, je veux faire du design d'appartement, je veux faire de la visite virtuelle de musée, etc... Même dans le cadre d'un jeu il faut cibler le type de jeu que tu comptes faire: je veux faire un fps, je veux faire un rts, je veux faire un rpg, un jeu de course, une simulation... Choisis un gameplay de base et ce qui concerne le contenu du jeu viendra par la suite.

Tu verras qu'une fois que tu auras fait ces choix, des spécifications et contraintes vont apparaitre naturellement et vont t'aider a faire le design de ton moteur. Tu te rendras aussi compte que c'est beaucoup plus facile de designer et développer quand tu connais a l'avance l'utilisation qui sera faite de ton moteur.

Si pour toi le but c'est simplement de développer un moteur pour te faire les dents sur les algos de rendu, d'optimisations, d'effets spéciaux et cie, tu devrais pouvoir trouver facilement quelqu'un (sur ce forum ou ailleurs) qui aurait une idée de projet dans ses cartons mais qui n'aurait pas le temps (ou l'envie) de se lancer dans du code de moteur 3d.

Bon courage !

PS: pour ma part je fais la même chose que toi en ce moment, a savoir développer un petit bout de moteur minimaliste et j'avoue que c'est bien plus vaste que ce que je pensais