Aller au menu du forum Aller au contenu du forum Aller à la recherche dans le forum
Logo Khaganat
Menu principal
Menu

Voir les contributions

Cette section vous permet de consulter les contributions (messages, sujets et fichiers joints) d'un utilisateur. Vous ne pourrez voir que les contributions des zones auxquelles vous avez accès.

Voir les contributions Menu

Sujets - YannK

24 Septembre 2023 à 14:56:49
Cliquez pour afficher le message
Bon, on va s'y (re)mettre, qu'en dites-vous ? Mais il faut trouver un nom pour le dépôt avant tout, et je commence à sécher après en avoir recréé plusieurs à la suite. Je vais archiver Khanat client et je me disais qu'on devrait lui donner un nom comprenant « 3D »  pour spécifier que ce sera celui du client 3D. Ça ferait « Client 3D Khanat ». Mais je trouve ça un peu... plat.

Ça vous irait ? Vous avez d'autres idées/suggestions ?
Cliquez pour afficher le message
Vous avez trois voix chacune, merci d'indiquer vos trois directions possibles préférées.
23 Juillet 2023 à 11:34:00
Cliquez pour afficher le message
Je propose qu'on se note ici les plugins qui pourraient être intéressants à utiliser pour Godot. Selon leur maturité et adéquation au projet lorsque le besoin s'en fera sentir, on verra à les ajouter. Entre-temps, que les testeuses n'hésitent pas à faire des retours.
Cliquez pour afficher le message
Je propose qu'on échange ici sur la façon dont on met les choses en place sur la forge.

Nous allons travailler sur le client 3D Godot depuis le groupe MMORPG Khanat comme précédemment. Après un peu de ménage et d'archivage, on trouve en son sein :

  • Khanat Guide de Développement qui définit les bonnes pratiques et qui doit servir, à terme, à alimenter des pages du wikhan, peut-être à générer un pdf, un epub etc. afin d'en faciliter la consultation par les contributrices.

Un ensemble de dépôt qui ne seront alimentés que via des Merge Request afin d'avoir des Changelogs propres et des commits apportant un lot de fonctionnalités répondant à un Ticket :

Le dépôt suivant pourrait aussi n'être rempli que via des Merge Request, si un pipeline alimente automatiquement ensuite le dépôt Khanat client 3D assets. Il pourrait aussi être alimenté via un plugin Blender dédié (du type Khanat tools, en cours de conception) afin de garantir un contrôle qualité :

Enfin, ces deux dépôts servent à rendre accessibles des éléments pouvant alimenter les différents travaux, sans qu'un fonctionnement précis pour chacun ait été décidé :


Et il reste encore :
  • Khanat server docker que je me propose d'archiver car plus en rapport avec le développement actuel.

Enfin, il y a le milestone 0.1 que je me propose d'effacer et d'en réorganiser les tickets pour correspondre à ce qu'on peut faire avec Godot 4 en l'état.

Qu'en pensez-vous ?

Une fois qu'on sera un peu fixées, je reprendrai la page Contribuer : les dépôts du projet Khaganat du Wikhan.
29 Juin 2023 à 22:07:04
Cliquez pour afficher le message
Cliquez pour afficher le message
Pour l'instant, nous avons sur le Gitlab un sous-groupe de Khaganat qui est dédié à tout ce qui a trait au jeu à venir : MMORPG Khanat.

Je pense qu'il serait bon qu'on y crée encore un sous-groupe, tu type « Godot Khanat » où nous mettrions tous les projets qui généreront les exécutables tels que proposés dans Exécutables et partages structurels. Cela permettra d'avoir des paramètres de groupe pour les CI, des accès globaux pour les développeuses etc.



Je propose de le mettre en place avec un dépôt pour tester les fonctionnalités de base nécessaires dans la CI pour la gestion des changelog tel que je l'ai envisagé sur le dépôt Bareto. Cela fera partie des fonctionnalités de base pour nos dépôts. Une fois cela fait, j'effacerai mes tests et je mettrai en place le premier dépôt, pour le client 3D, faisant encore une fois référence au schéma proposé. Si c'est possible pour notre Gitlab, je créerai un template de dépôt. Dans le cas contraire, je ferai un dépôt exemple pour se simplifier la tâche à l'avenir. On verra également avec les développeuses si nous commençons le dépôt « Khanat Core » dès maintenant ou pas.

Je verrai aussi comment avoir une gestion pratique des tickets et une fois tout cela testé et validé, je compléterai le guide de développement pour indiquer la marche à suivre pour contribuer.

Sans veto dans la semaine qui vient, je m'attaquerai à ces tâches.
17 Avril 2023 à 16:06:18
Cliquez pour afficher le message
Je n'ai pas encore vraiment d'idée pour la coiffure du premier personnage, mais j'ai plein de propositions d'inspirations.  :D



Faites votre choix ^^
13 Avril 2023 à 18:06:16
Cliquez pour afficher le message
Après une bataille homérique contre les générateurs d'images, j'ai enfin trouvé un moteur avec lequel j'arrive à quelque chose de correct, et qui me laisse mettre le produit de mes prompts sous la licence que je souhaite. J'ai donc cherché à avoir des idées pour le cmuzda du Dispensaire.

J'ai tenté de mixer Art déco, Art Nouveau et Franck Lloyd Wright avec un zeste de solarpunk, le tout sous terre. J'ai récupéré énormément d'images, avec beaucoup d'hallucinations (des erreurs visuelles plus ou moins flagrantes pour nous humains), mais je pense que j'ai ainsi une direction visuelle assez claire de ce vers quoi je souhaite aller.

Je vous partage donc une capture d'écran de mon tableau d'inspiration. Il est réalisé avec le logiciel gratuit, mais pas libre, PureRef. Je peux mettre le fichier sur le Kloud, je ne l'ai pas fait par défaut car il est très gros (plusieurs dizaines de Mo).



Comme pour le be'ibi, mon idée est de travailler essentiellement avec les images principales (en haut du panneau) comme base que je combinerai au mieux, en intégrant les détails dessous pour certains éléments et/ou détails.

Sans veto sous une semaine, j'avancerai à partir de ça pour les éléments 3D de départ. n'hésitez pas si vous avez des remarques/précisions/questions :)
13 Avril 2023 à 17:14:41
Cliquez pour afficher le message
Cela fait longtemps qu'on n'en a pas parlé, mais on a prévu un petit robot d'assistance pour les ra qui fonctionne selon l'effet Tsupa'a Galton - Cfiden Mojig : le be'i bi (car c'est la 8e déclinaison de ce type de robot qui transporte les objets).

J'ai enfin des visuels à vous proposer pour valider leur aspect. Ils sont en forme de cylindre étiré et bombé, avec des ouvertures latérales qui s'écartent et d'éventuelles trappes ailleurs sur le corps. Ils peuvent apporter de l'éclairage, porter des sacs grâce à des crochets escamotables...

La plus grosse image est celle qui est la plus proche en ce qui concerne l'aspect général et les autres sont des déclinaisons pour y puiser des idées pour les détails et zones arrières, voire des variantes pour certaines zones. Je pense qu'on pourra le customiser un peu, ne serait-ce qu'au niveau de la couleur.



Sans veto formel d'ici une semaine, je considérerai ce concept comme valide et je passerai à la phase suivante d'ajout sur l'UM1 puis de modélisation. Si vous avez des idées/remarques/questions, les avis sont les bienvenus :)
Cliquez pour afficher le message
En discutant avec Zatalyz de l'architecture des données dans le jeu, on a repensé au système de compétences, qui doit être unifié afin de permettre d'être utilisé pour toutes les entités en jeu, car toutes ont la capacité de devenir ra. Techniquement parlant, le but est de n'avoir qu'un système qui gère les capacités des différentes entités (via des fichiers XML avec une notion d'héritage comme dans OpenNeL).

Le système se base donc sur des Khompétences par exemple la danse. Dans celles-ci, on acquiert des Khapacités composées de Khases. Dans notre exemple de danse, les Khapacités seraient le type de danse  : solo, en groupe, à deux. Les Khases seraient la Durée, l'Intensité, le Type de pas (par ex. les pas de la spadzura). On combine les Khases en fonction de la Khapacité qu'on veut réaliser. Par exemple : Faire une Spadzura à deux de façon Intense et d'une faible Durée. Il y aura des notions de bonus/malus avec les Khases pour équilibrer la création de la Khapacité.

Pour l'acquisition de ces Khompétences, chaque Khase a un coût en Point d'Unité Mémorielle (P.U.M), en sachant que chaque ra est dotée d'un maximum de PUM (à déterminer). Ainsi certaines Khases peuvent coûter 0 PUM (permettant de les attribuer de façon invisible, genre pouvoir bouger), et certaines valoir très cher (Ajouter des effets de particule quand on danse : le K'Deed effect). Le total des PUM dépensés dans une Khompétence permettra d'estimer le profil de la ra.

Le fait d'acquérir une Khase sera proposée à la ra selon plusieurs modalités (en observant, en s'entraînant...). Il pourrait y avoir une préférence de la joueuse qui accepte toutes les nouvelles Khases tant qu'elle n'a pas atteint son budget (ou pas), mais dès lors qu'un arbitrage devra être fait, la joueuse validera ou non l'acquisition de la Khase.

Le Monde des Rêves pourrait être un endroit où acquérir ou perdre des Khases de façon... onirique. Et les Brumes seraient l'endroit où l'Oubli pourrait s'imposer violemment avec la perte de Khases aléatoires. D'où l'expression ratique « Celle-là, depuis qu'elle est passé par les Brumes, il lui manque des Khases. »


PS : La terminologie en Kh est une touche personnelle du chef.
Cliquez pour afficher le message
Bonjour à toutes,
en travaillant sur les modèles architecturaux pour le Khanat, je me suis rendu compte que je manquais de concepts pour penser certains espaces de transition.  Sur terre, nous avons le dedans et le dehors, avec des zones intermédiaires qui permettent de se sentir dans l'un ou l'autre. Mais dans le Khanat, nous ne sommes pas dans un système binaire : il y a du dedans et du dehors dans culno (qu'on pourrait désigner comme le Dehors) et il y en a aussi possiblement dans ratmidju (qui serait donc le pendant du Dehors, le Dedans), et ce ne sont pas les mêmes. Il faudrait qu'on pense un peu ces concepts, qu'on les nomme (avec des termes courts de préférence car ils sont certainement usuels) pour que je tente de les traduire en propositions architecturales.

Vous avez des idées, des remarques, des propositions, des critiques ?
29 Décembre 2022 à 20:03:31
Cliquez pour afficher le message
Faisant suite à l'idée de Zatalyz que les ra aient une technologie basée sur le mycélium (voir ce sujet), je me suis dit que ça pourrait être la base de leur plasturgie, basée sur les champignons et pas les dérivés pétroliers comme nous. En outre, cela permettrait d'avoir un matériau très zbasu qui ne soit pas minéral sans être du bois (je pense en particulier au mobilier). Et comme j'aime bien la bakélite, je réfléchis à en faire un truc qui pourrait s'en inspirer (cela pourrait servir des formes rétro-futuristes).

Et donc, avant de faire une fiche dans l'UM1, je me disais qu'il faudrait lui trouver un nom à ce truc, plus sympa que plastic ou bakélite (qui est une marque, en plus).

j'ai trouvé ces termes, mais ils ne m'inspirent pas trop :

- slasi: plastique
- mledi: champignon/moisissure

Donc avez-vous des idées ?
07 Décembre 2022 à 20:49:19
Cliquez pour afficher le message
Je viens de me rendre compte en allant sur l'UM1 qu'il n'y avait pas les termes en langue sacrée pour le code de l'honneur. Ce serait bien qu'on ait au moins les piliers qui soit définis vu que ce sont des termes qui pourraient être visibles à pas mal d'endroits.

Il nous faudrait donc définir :

Des idées, propositions ?
23 Novembre 2022 à 21:58:02
Cliquez pour afficher le message
En étudiant certains aspects de la décoration à venir des lieux, je me suis posé la question de la logistique sur le Khanat. Les ra transportent leurs produits d'une région à l'autre, mais dans quels contenants et sous quelles formes ? Ont-ils des cartons, des containers standardisés et des caisses ?

En discutant avec Zatalyz, on a eu l'idée que tout serait né du transport fluvial : les ras évidaient à l'origine des troncs qu'ils refermaient ensuite avec une peau et ils faisaient des grands radeaux de ces cylindres pour transporter leurs produits ici et là. L'avantage c'était qu'on pouvait y mettre plein de truc aisés à transborder à l'arrivée et au départ. Et qu'on pouvait ensuite placer ces produits dans d'autres contenants pour leur transport final.

Puis les petits gars de ratmidju se sont dits qu'on pouvait optimiser un peu, la Légion a amélioré le tout pour ses trains logistiques et on en est arrivés à la solution actuelle : le cylindre de transport cylindrique :

Une petite vidéo schématique du truc : https://kloud.khaganat.net/s/6xMbzro4Ty7ywXW

L'idée serait que ça soit relativement standard pour la version zbasu, soutenue par la légion, les transports souterrains etc. et de plus en plus « adapté localement » dans les coins culno. Mais de façon générale, on pourrait retrouver ces modules hexagonaux de manutention un peu partout (comme les cartons et les palettes chez nous).

Cela ferait qu'on stocke pas mal de choses dans des contenants hexagonaux, car ils peuvent ainsi aller là-dedans. Il est aussi possible que les installations techniques aient des systèmes TGCM pour déplacer ces cylindres, des pinces robotisées pour les charger/décharger etc. (équivalents de nos transpalettes et autres Manitou).

Ça m'offrirait une déclinaison d'objets de stockage nécessaires au fonctionnement du monde et un peu plus sympas que la palette ISO ou, encore pire, la caisse en bois et le tonneau qu'on trouve dans tous les jeux (quand bien même on ne les voit jamais être vraiment utilisés ^^ )

C'est une ébauche d'idée, mais qu'en dites-vous ? Si vous êtes partantes, ce serait cool de leur donner un nom :)
25 Octobre 2022 à 18:15:24
Cliquez pour afficher le message
Bonjour à toutes,

pour celles qui ont eu la joie de bosser un peu dans les dépôts d'assets de Ryzom, il est certainement apparu qu'il est complexe d'organiser les choses pour que la contribution artistique soit aisée et les manipulations fluides d'un bout à l'autre de la production, depuis la création par l'artiste jusqu'à l'intégration en jeu. La cohérence des versions utilisées pour générer les objets finaux est souvent complexe (voir par exemple les différentes armatures incompatibles entre elles utilisées pour les humanoïdes dans Ryzom). C'est un sujet très épineux pour beaucoup de studios, d'autant que les compétences nécessaires pour appréhender ces questions ne sont pas si fréquentes, surtout pour les animations.

Richard Lico, ce héros
Pour notre plus grand bonheur, un vétéran de l'industrie extrêmement talentueux (Richard Lico, le sus-nommé) a décidé de prendre la question à bras le corps. Il s'agissait pour lui de faciliter la gestion des données d'un bout à l'autre du pipeline, avec le moins de maintenance possible. Et de chercher une façon pour que les animatrices soient les plus libres possible tout en ayant une rapidité de travail décuplée. D'un autre côté, il n'avait pas le choix, il venait de devenir indépendant et se retrouvait tout seul sur de nombreux aspects pour un gros projet :D (le jeu Moss pour les curieuses, qui lui a donc valu de nombreuses récompenses.)

Aparté : Si certaines sont intéressées, deux conférences où il parle de son travail sur Moss, justement : Animating Quill: Creating an Emotional Experience (sur lequel il y aurait d'autres choses à dire, mais j'y reviendrai à un autre moment) et Animation Workflow Siggraph 2018

Brad Clark, ce héros (parce que lui aussi le vaut bien)
Sur ce, Brad Clark un gars devenu référence mondiale dans son domaine (le rigging) depuis des années (le genre qui a bossé sur le motion capture de Gollum pour « Le seigneur des anneaux » il y a 20 ans...), et qui a décidé de se plonger dans Blender parce qu'il s'est dit qu'il y avait du potentiel inutilisé (vous avez deviné pourquoi il me plaît tant ? ^^ ), s'est dit qu'il faudrait trouver comment pousser ce genre de pratique. Et il fait alors la connaissance de deux frangins, qui se sont dits dans leur coin que ce serait cool d'avoir des outils de ce type dans un addon Blender (Rig On the Fly). Et paf, voilà, ça veut dire que Blender peut le faire et qu'en plus des gens planchent à rendre ça plus aisé.

Aparté : une vidéo revient sur ce processus de rencontres qui s'est fait peu à peu : Meet The Expert: BRAD CLARK (Rigging Dojo)

Tout cela m'a semblé extrêmement intéressant pour nous, qui n'avons pas les moyens de créer et de maintenir un pipeline de production trop lourd, ni de créer plein d'outils pour toutes les contributrices qui pourraient venir de temps en temps.

Ce que je vais dire ci-dessous l'est dans un contexte où ce sont les animations qui sont concernées, mais il faudrait voir comment l'étendre peut-être à d'autres pans de la contribution artistique, à étudier.

Le premier point est de simplifier le plus possible la gestion des ressources. Donc l'idée (du moins pour tout ce qui est résultat d'un workflow destructif, comme l'est l'animation) est de n'avoir qu'un format à gérer, celui qui est nécessaire au moteur (à savoir glTF dans notre cas). Le but d'une contributrice est donc de fournir un fichier glTF qui contient une animation pour l'armature de déformation d'un objet animé. Seule l'armature de déformation, et le skinning du mesh correspondant, ont besoin d'être fournis et versionnés. Vu que le rig de contrôle est ce qui est le plus complexe à faire, et le plus difficile à s'approprier et parfois s'avère limitant pour certaines opérations souhaitées par l'animatrice, on n'a plus à se préoccuper de sa maintenance et de sa cohérence tout au long du pipeline. Ainsi, ajouter un nouvel emplacement dans le dos pour fixer un sac ne pose pas de souci, c'est juste un bone dans l'armature de déformation. Pas besoin de reprendre tout le travail préalable où celui-ci n'est pas inclus et de le propager partout pour maintenir la cohérence du rig de contrôle, cet ajout sera simplement pris en compte lors du prochain import avec les scripts habituels afin d'être pris en charge. Car dans l'approche professée par Richard Lico, le rig de contrôle est généré à la volée par l'animateur via des scripts personnalisés (d'où l'intérêt de l'addon Rig on the Fly qui en fournit un certain nombre prêts à l'emploi), depuis l'armature de déformation, en se basant sur les keyframes déjà en place. Du coup, on a directement la ressource utile et on repart toujours toujours d'elle quand on veut faire des modifications, peu importe comment on fait cette dernière et les modifications qu'elle a pu connaître entretemps, on a forcément toujours la dernière version d'édition entre les mains.

Le seul gros point noir à cette façon d'opérer est que l'animation demande alors quand même pas mal de connaissances théoriques en rigging et en scripting, ou au moins une très grande aisance avec l'outil qu'on utilise. Ce qui veut dire que la marche d'entrée pour contribuer me semble un peu plus haute. Mais son gros avantage est que celles qui contribueront perdront moins d'énergie à maintenir des outils plus ou moins adaptés (voire à les adapter au nouvelles venues) et bien plus à réellement fabriquer du contenu, ce qui est plus motivant. Par ailleurs, on peut plus rapidement obtenir des résultats de très bonne qualité.

J'ai étudié la façon dont on pourrait déployer ça dans notre pipeline Blender > Godot et je pense avoir trouvé comment faire pour que les animations puissent être réalisées une par une pour un même modèle et les importer séparément comme ressource dans Godot. J'ai commencé à noter ça dans le Guide de développement. On testera ça in vivo pour le premier client dès que Godot 4 sera un peu stabilisé.

Si vous avez des avis, des remarques, des questions...
Cliquez pour afficher le message
Bonjour à toutes,
j'ai bossé à une silhouette pour le premier personnage joueur que nous implémenterons. j'ai tenté de me rapprocher des formes de Ryzom en prenant comme bases leurs personnages et proportions. Mon but est d'arriver à un ra qui ne soit pas sexuée aisément et dont la tenue puisse être un mix tcara/ucikara afin de ne pas être trop techno ni trop peu. Ça s'affinera avec les détails et les textures, le but est dans un premier temps d'avoir une silhouette générale qui convienne à toutes puis d'itérer en peaufinant. Je m'attaquerai aux animations quand on aura terminé le modèle, et une grande partie de ses caractères perçus pourront aussi passer par ce biais.

Je vous laisse quelques jours pour faire des retours si vous voyez des modifs à apporter, faute de quoi j'avancerai sur cette base.


17 Octobre 2022 à 23:04:25
Cliquez pour afficher le message
Bonjour à toutes,
la boutique est créée, mais encore faut-il y avoir des choses à y proposer.

Alors on peut aisément faire des objets avec le logo de Khanat, afin de diffuser l'image, mais ce serait sympa aussi d'avoir des objets qui existeraient aussi dans le Khanat, utilisé par des ra. Merci de dire ici vos idées, vos envies... afin qu'on puisse concevoir les premières propositions.

Voici la liste de ce qu'il est possible d'y faire :

  • T-shirt
  • Robe
  • Sweat-shirt
  • Sweat à capuche
  • Coque /skin téléphones
  • Housse d'ordinateur
  • Impressions murales
  • Coussin
  • Mug
  • Horloge
  • Bloc acrylique
  • Tenture
  • Plaid
  • Housse de couette
  • Couvre-lit
  • Rideau de douche
  • Dessous de verre
  • Sac à cordon
  • Foulard
  • Tote bag
  • Mug isotherme
  • Pochette
  • Gourde
  • Chaussettes
  • Badges
  • Stickers
  • Cartes de vœux
  • Cahier à spirale
  • Carnet cartonné

En fonction des premiers retours, je vous posterai des visuels de ce qu'il est possible de façonner chez RedBubble.
16 Août 2022 à 18:43:44
Cliquez pour afficher le message
Références (quasi archéologique) :

Ça fait longtemps qu'on n'en a pas parlé (presque 10 ans, ce n'est rien du tout  :music:), mais je viens de voir une implémentation du PvP que je trouve intéressante (dans une vidéo sur le MMORPG à venir Ashes of Creation).

Il se base sur un État du joueur qui peut varier et qui a des conséquences sur le loot possible de ton inventaire à sa mort. Si j'ai bien compris, cela pourrait être un fonctionnement de ce type, schématiquement :

- Vert : tu n'as porté aucun coup à aucun joueur et n'en a tué aucun. Résultat : à ta mort, tu ne proposes au loot que très peu de choses, très accessoires (genre quelques matériaux ramassés sans grande valeur) voire rien du tout
- Violet : tu as tué un personnage joueur de statut Violet/Rouge ou porté des coups à un personnage joueur de statut Vert sans le tuer pour autant. Résultat : à ta mort, tu proposes plus de choses de ton inventaire, dont certains objets peuvent être de valeur
- Rouge : tu as tué un personnage joueur Vert. Résultat : à ta mort, tout ton inventaire peut être looté

J'aime bien cette idée de prise de risque qui entraîne une réflexion sur les conséquences de son acte en terme de GP. Qu'en dites-vous, sur le principe, dans l'échelle de gradation de Statut qui pourrait exister et des répercussions pour chacun d'eux ?
08 Août 2022 à 13:31:20
Cliquez pour afficher le message
Bonjour à toutes,
comme l'alpha de Godot 4 approche à grands pas, il faudrait qu'on réfléchisse à la façon dont on va implémenter le premier milestone et arrêter juste de faire mumuse avec les nouvelles fonctionnalités :)

D'où ma question : quelle technologie va-t-on utiliser pour les terrains ?

Je résume très grossièrement ci-dessous pour celles qui ne connaissent pas nos options.

Option 1 : Heightmaps

Il s'agit d'une solution qui calcule le relief d'une plaque de terrain découpée en petits carrés à partir d'une texture en noir et blanc, et qui va soulever chaque petit carré plus ou moins haut en fonction du niveau de blanc/noir qui correspond à sa position sur la texture.

Ses avantages :

- facile à mettre en œuvre techniquement
- peut-être relativement léger en terme de puissance de calcul
- aisé de créer des textures pour avoir des terrains avec les formes souhaitées, facile de les retoucher/modifier

Ses inconvénients :
- pas de possibilité de faire des tunnels, grottes ou surplombs, il faut y ajouter des objets pour créer ce genre d'effets
- pas simple de superposer des niveaux les uns au-dessus des autres, il faut prévoir des objets passerelle
- nécessité d'uniformiser la façon dont les plaques se joignent les unes aux autres pour éviter les « crevasses »

Option 2 : Voxels


Il s'agit d'une solution qui défini l'espace en 3D et qui conserve la trace de savoir pour chaque point s'il est plein ou vide, quelles sont ses matériaux etc.

Ses avantages :

- continuité de toutes les zones entre elles, pas de système de plaques reliées
- aisé de créer des grottes, passages souterrains, superpositions, etc.

Ses inconvénients :

- plus complexe techniquement à tous points de vue (collisions, shading...)
- plus lourd en terme de puissance de calcul et complexe à optimiser
- besoin d'un outil de génération pour contrôler parfaitement le résultat ?

Option 3 (ou pas) : Courbes
Il pourrait y avoir une option 3, qui est celle retenue par Ryzom, et que Halo utilisait aussi, qui est de créer par courbes dans l'éditeur et de laisser le moteur transformer ensuite le résultat en triangles. Je ne sais pas si cela a déjà été implémenté dans Godot. Si quelqu'un a des pistes, on peut se l'ajouter comme option.

Je tiens à préciser que entre l'option 1 et l'option 2, on a des pistes d'implémentations déjà existantes pour Godot, grâce au fabuleux Zylann :)
- Heightmap : https://github.com/Zylann/godot_heightmap_plugin
- Voxel : https://github.com/Zylann/godot_voxel

Donc la question est plutôt d'anticiper la façon dont on arrivera à s'emparer de la technologie et à l'adapter au client de jeu Khanat en 3D que de se demander comment on va faire à court terme, car grâce à Zylann, dans les deux cas, il y a des bases :)

EDIT du 10/08/2022 :
- Conseils sur l'usage des voxels dans la documentation du plugin voxel de Zylann, pour référence : Is Voxel tools for you ?
25 Avril 2022 à 21:32:02
Cliquez pour afficher le message
Faisant suite à mon message d'hier sur l'architecture des services, j'ai mis au propre une proposition des exécutables sur lesquels nous devront nous pencher, et les dépôts Git qui y sont liés. Une partie de ces derniers seront communs, via des addons Godot qui permettront de partager les données entre les différents projets. Certains existent déjà, d'autres pas encore.



J'ai rassemblé les différents exécutables serveur sous un seul terme, « Ensemble serveur ».

Le « Khréateur » désigne ce qui servira aux level designers d'ajouter du contenu en jeu, de préparer les éléments, objets, missions, textes et cartes qui seront ensuite envoyés sur le serveur pour y être instanciés.

« L'oeil de la reine » servira à intervenir en direct sur le contenu en jeu : mise en place d'événements temporaires, action directe sur certaines données de jeu, modération en temps réel... Il pourrait même intégrer des caméras IG qui retransmettent des endroits.

Le client 3D est le premier à être envisagé, permettant de parcourir le Khanat en 3D.

Là encore, c'est une proposition qui est là pour être discutée, retravaillée etc. et mon svg est dispo pour celles qui veulent le reprendre.
Licences Mentions légales Accueil du site Contact