Projet dans les cartons

[Jekka]

Pris de nostalgie de l'époque où j'étais un créateur relativement assidu sur ce forum, j'ai retrouvé deux trois trucs en stand-by qui me semblaient très intéressants, mais qui faute de collaboration pérenne, n'ont jamais vu le jour...

L'un de ces projets est une super sonde spatiale. Le but était d'avoir une sonde avec beaucoup de carburant et plusieurs atterrisseurs, atmosphériques ou non, pour faire une jolie excursion dans le système solaire. Une sorte de DG si on veut, mais plus "réaliste". S'inspirant de la sonde hypothétique JIMO ( http://www.jpl.nasa.gov/jimo/ ), elle aurait été lancée par une Ariane 6 ou tout autre lanceur bien lourd.

Malheureusement, le projet est un poil au delà de ce qu'un spc3 aurait permis. Il lui faudrait un dll propre, chose que je ne sais ni ne saurai faire.

Comme ça me chagrine de voir ces mesh, qui m'ont demandé des heures de boulot, finis et texturés, ne servir à rien sinon à regarder en photo, je lance un appel. Si quelqu'un de compétent en C++ et qui a le temps, serait intéressé à créer une dll pour ce projet, je lui remets avec le plus grand plaisir tous les mesh et les textures finis, ainsi que toutes les indications nécessaire à la réalisation du code. Tous les éléments sont prêts, optimisés et paramétrés pour les animations et le reste. Je me souvenais pas avoir aussi bien packé le truc...

Une tite photo pour montrer de quoi on parle

[Bibi Uncle]

Moi je serais bien volontaire. J'ai déjà transformer un vaisseau Spacecraft3 en DLL (Voyager), mais l'auteur ne m'a jamais vraiment répondu, donc il est resté au placart...

Je ne peux pas te promettre de le sortir le lendemain, mais ça pourrait permettre de tester une bonne partie du code de Project Mercury pour voir sa réutilisation (dont le système de séparations d'étages).

[Pitx]

Je veux bien également apporter ma contribution. Mes interactions avec le forum francophone sont assez rare donc je comprendrais que tu ne veuilles pas m'inclure dans l'équipe. Je ne me vexerai pas, ne t’inquiète pas

Niveau expérience, aucun addon diffusé, mais pas mal de bricolages chez moi. Faut dire que je suis un branque en modélisation et texture donc j'utilise les modèles des autres que je customise.

Voila, a qui l'tour?

pitx

[Jekka]

Alors roulement de tambour.....



Le choix s'est porté sur Bibi Uncle ! Tadam

Merci pour ton offre Pitx ! En effet, Bibi Uncle est assez actif ici donc voilà. Et puis faire une équipe à trois, à mon avis c'est vite le bordel. Déjà à deux, expérience faite, c'est pas toujours simple... Mais merci quand même !

[Mars Bleu]

Meshes et textures sont superbes. Bravo, Jekka.
J'ai hâte de voir le résultat en action, une fois DLLé.

De mon côté, je commence à avoir des MSH à DLLer, moi aussi.
Il faut que je regarde la doc relative à ça.

[Pitx]

Jekka a écrit:
Alors roulement de tambour.....

Le choix s'est porté sur Bibi Uncle ! Tadam

Merci pour ton offre Pitx ! En effet, Bibi Uncle est assez actif ici donc voilà. Et puis faire une équipe à trois, à mon avis c'est vite le bordel. Déjà à deux, expérience faite, c'est pas toujours simple... Mais merci quand même !

Aucun souci
Bon chance à l'équipe Bibi-Jek!

pitx

[Bibi Uncle]

Hier (le 16 janvier je spécifie les dates, car j'ai 6 heures de retard sur vous), j'ai travaillé sur une jolie classes qui me permet de définir des animations hyper facilement et qui assurent l'animation. Je n'ai pas eu beaucoup de temps (devoir de math sur les statistiques... hyper ennuyant...), mais j'ai réussir à la finir.

Aujourd'hui (le 17 janvier), j'ai défini quelques animations. J'ai donc l'antenne principale, les quatres réacteurs et les quatres panneaux solaires (ces derniers étant une véritable "pain in the ass" à définir).

Les voici en action :


Et complètement déployées :


EDIT :

Pour le largage des différents landers et la gestion des animations, je vais voir si c'est possible dans un MFD, mais je ne promets rien. Un MFD est généralement global ;  il peut être utilisé par tous les vaisseaux. Par contre, dans notre cas, il faudrait qu'il soit spécifique au vaisseau MULE. La doc spécifie :

There are two types of custom MFDs: generic and vessel class-specific. Generic MFD modes are available to all vessel types, while specific modes are only available for a single vessel class. Generic modes should be registered in the InitModule callback function of a plugin module. Vessel class specific modes are not implemented yet.

Mais j'ai ma petite idée pour bypasser ce manque... Il reste à voir si ça marchera.



Message modifié ( 18-01-2012 04:12 )

[Pagir]

Ouains, il roule, le Bibi!

[Bibi Uncle]

J'ai presque réussi le MFD spécifique au vaisseau. Orbiter est assez flexible pour le permettre, mais pas OrbiterSound... Pour faire en sorte que le code compile, je dois enlever la bibliothèque OrbiterSoundSDK35.h, car elle redéfini les MFD pour une raison que j'ignore complètement. Mais si j'enlève cette bibliothèque, j'enlève la possibilité d'ajouter des sons au vaisseau (car le MFD est codé dans la même DLL que le vaisseau).

À part ce problème, c'est génial comment ça fonctionne. Dans un vaisseau MULE, le MFD apparaît dans la liste et on peut l'ouvrir. Sinon, dès qu'on change pour un vaisseau qui ne fait pas parti de MULE, le MFD n'est plus disponible. Si certains programmeurs sont interessés à savoir comment j'ai fait, vous pouvez me le demander, j'écrirai un post à propos du fonctionnement.

Donc, c'est soit le MFD, soit OrbiterSound pour l'instant. Je vais tenter de règler le problème...

EDIT :

Ce problème me fait vraiment chi*** en ce moment... Je n'ai pas encore réussi à trouver comment le détourner. La seule solution que je vois, ce serais de séparer le MFD dans une DLL séparée, mais je ne vois pas du tout comment je pourrais demander à Orbiter de charger la DLL...

P.S. C'est tempête de neige aujourd'hui, pas d'école ! Une belle journée de programmation attend devant moi !



Message modifié ( 18-01-2012 17:15 )

[Jekka]

Je... Eh bien...



wow...



Sans te sous-estimer évidemment, je pensais pas que tu t'y mettrais SI VITE...!

Tu manges un peu quand même de temps en temps ?

Pour ce qui est des dll, où je n'y vois goutte, il y a peut-être moyen de s'inspirer de l'addon San Ku Kai de Korben62 :

http://www.orbiterfrancophone.com/index.php?disp=addons&id=42

Ou encore de l'addon payload manager : http://www.kulch.spb.ru/Eng/PM_project.html

Je sais pas ce que ça vaut comme aide, mais elle est gratuite ! La tienne par contre est inestimable.

Merci !

[Pitx]

Ce problème me fait vraiment chi*** en ce moment... Je n'ai pas encore réussi à trouver comment le détourner. La seule solution que je vois, ce serais de séparer le MFD dans une DLL séparée, mais je ne vois pas du tout comment je pourrais demander à Orbiter de charger la DLL...

Tu peux toujours faire un module que tu actives dans le Launchpad mais tu vas devoir passer toutes les méthodes d'activation des anim en public... moué, à réfléchir...

pitx

[Profil supprimé]

Je découvre ce projet. Très beau, belle réalisation et idée tout à fait originale et interessante. Chapeau.
J'ai hate de voir ce que donnera le résultat final

[DanSteph]

Bibi Uncle a écrit:
J'ai presque réussi le MFD spécifique au vaisseau. Orbiter est assez flexible pour le permettre, mais pas OrbiterSound... Pour faire en sorte que le code compile, je dois enlever la bibliothèque OrbiterSoundSDK35.h

Un problème de code certainement aucun problème avec UCGO et bien d'autres. Je n'y ai plus touché depuis des lustres donc je n'ai pas de bon conseil sauf que l'ordre de déclaration des headers est important.

A++

Dan

[Bibi Uncle]

Je crois que le problème vient du fait que OrbiterSound a été compilé avec la SDK de 2006. Depuis la version 2010 d'Orbiter, il y a une classe MFD2 qui hérite de MFD. Dans le code d'OrbiterSound, tu dois créer le MFD d'OrbiterSound en héritant de MFD et en ne déclarant pas les clbk comme fonction virtuel. Quand j'ajoute OrbiterSound.h, il faut croire que VC++ a un problème avec ça...

J'y avais pensé avec le Launchpad, mais pour plusieurs raisons, ce n'est pas une solution envisageable (l'utilisateur peut avoir oublier de l'activer, je vais avoir un nouveau problème pour faire en sorte que le MFD est spécifique au vaisseau, etc.).

Bref, pour l'instant, pas d'OrbiterSound. Je vais voir si je peux résoudre le problème.

[DanSteph]

Je viens de recompiler Le arrow avec la SDK 2010 ça marche impec.

Tu fais bien dans cet ordre ?

UCGOFreighter.h, contient la déclaration de class Vessel2:

Code: [Select]

#include "orbitersdk.h"
#include "..\dan_SDK\UMmuSDK.h"
#include "..\dan_SDK\OrbiterSoundSDK35.h"
#include "..\dan_SDK\UCGOCargoSDK.h"
#include "..\dan_SDK\danlight.h"
#include "..\dan_SDK\SaveRestoreScenario.h"


[Bibi Uncle]

Mais le Arrow ne contient pas de MFD (de classes dérivant de MFD ou MFD2). C'est quand je défini un MFD que ça ne compile plus. J'ai beau séparé la définition du MFD et l'inclusion d'OrbiterSoundSDK35.h, VC++ se plaint de redéfinitions de MFD dans OrbiterSound35.lib.

Mon projet contient une classe MULE héritée de VESSEL3 et une classe MULEMFD héritée de MFD2. Le tout est compilé dans une même DLL.

En parlant de VESSEL3 et de MFD2, Jekka m'avait parlé de compatibilité avec Orbiter 2006 par MP. Pour l'instant, ce n'est pas compatible. Seulement Orbiter 2001 P1 est compatible. J'ai décidé de faire ainsi à cause du MFD. Orbiter a totalement changé la façon de dessiner sur des surfaces. Auparavant, tout était fait avec la GDI de Microsoft. Maintenant, on peut définir de nouveaux renderer 2D (via la classe Sketchpad).

Bref, le fait d'utiliser la nouvelle interface me permet d'assurer la compatibilité avec les différents clients graphiques. J'ai testé avec le client D3D9, et le MFD se dessine sans problème, et sans perte de framerate (puisque je n'ai pas besoin d'activer la compatibilité GDI).

[Bibi Uncle]

Désolé de ne pas avoir donné de nouvelles, j'ai pas eu beaucoup de temps pour la programmation. Pas mal de travail à l'école et... un peu de repos aussi

J'ai fini toutes les animations (incluant le radar qui était monstrueux à définir...). Pour le MFD, j'ai réglé la plupart des bugs. Le seul qui persiste est un bug totalement relié à Orbiter. Parfois, quand j'ouvre le Glass Cockpit (le cockpit de base avec les deux MFD) Orbiter rend disponible deux MULE MFD. Il faut sélectionner le deuxième car le premier plante à tous les coups. J'ai beau débugger pas à pas, j'appelle oapiRegisterMFDMode qu'une seule fois. Même avec une protection par boolean le problème reste. Mais c'est pas trop grave. Si on n'est pas pressé, ça fonctionne comme il le faut .

Ensuite, j'ai ajouté une petite interface graphique pour gérer les animations. Tout d'abord, il y a une forme de base en verte qui représente les parties non amovibles du vaisseau. Les parties amovibles sont coloriés en rouge lorsque retracté, en jaune lorsqu'elles bougent et en vert lorsq'elles sont déployés. De plus, le pourcentage de déploiement est indiqué lorsque la partie est en train de bouger. Pour l'instant, seul l'antenne et les panneaux solaires arrières sont représentés.

Une image vaut mille mots.

Tout est rétracté :


L'antenne principale est déployée et les panneaux solaires arrières sont en déploiements (les pourcentages sont mal placées, il suffit que je change une variable pour modifer leur endroit) :


Plus tard, je vais permettre d'animer les différentes parties en utilisant les boutons du MFD. UP et DN ne font rien présentement et ne seront pas là dans la version finale.

Les animations sont sauvegardés dans le scénario. Si vous quittez avec les panneaux ouverts, il seront ouverts lorsque le scénario sera chargé.



Message modifié ( 02-02-2012 01:23 )

[Mars Bleu]

/Mode sans voix:
                                     Mode sans voix/

[Pagir]

Dis dont, Bibi... ouf!

[Jekka]

Excellent !

[Bibi Uncle]

La gestion des boutons est maintenant intégrée. Seule l'antenne a été définie, mais ça ne devrait pas être trop compliqué d'ajouter les autres animations.

Le bug de multiples MULEMFD disponible semble être réglé.

Une petit démo en vidéo :
<a href="http://www.youtube.com/watch?v=q39DOZjtpjU" target="_blank">http://www.youtube.com/watch?v=q39DOZjtpjU</a>

[DanSteph]

Génial !

ça fait plaisir d'entendre ta voix et de voir le boulot qui avance

Dan

[jacquesmomo]

Je dirais même plus... Farpait !!!

[Jekka]

Ca m'a l'air très bien foutu tout ça...! Je l'aurais même pas imaginé !

C'est marrant d'entendre ta voix sur la vidéo, ça me rapelle mes vacances. Et ça me fait penser à ton topic sur les doublages.

En effet, dans ma tête, quand je lis "MULE", j'entends "mûle" et non "mioule", à l'anglaise. Pareil pour les MFD, j'entends "aimeffedé" et non "aimeffedi"... Ca m'avait jamais titillé l'esprit ce truc...
Merci encore pour ta collaboration !

[Bibi Uncle]

C'est drôle parce que je n'avais pas écouté le résultat après l'avoir enregistré. J'avais le disque Proximity de Joël and the Outsiders (excellent en passant, petite pub gratuite ) qui jouait en arrière pas très fort parce que j'avais biassé le volume de WMP. À 0:29, on entend mon MSN qui m'indique un nouveau message. Je me souviens avoir fait un saut en l'entendant

En effet, dans ma tête, quand je lis "MULE", j'entends "mûle" et non "mioule", à l'anglaise. Pareil pour les MFD, j'entends "aimeffedé" et non "aimeffedi"... Ca m'avait jamais titillé l'esprit ce truc...

Et j'ai fait attention pour utiliser un français le plus internationnal que je pouvais. C'est pourquoi il y avait beaucoup de "euh..." et autre. Quand on y pense, c'est difficile de remplacer certaines expressions.