OpenGL Orbiter Mesh Viewer

[Bibi Uncle]

Merci Spocky ! Le culling, c'est magique ! En plus, je gagne beaucoup dans l'utilisation du processeur (merci au Gestionnaire de Tâches ).

Un petit screen du DG (c'est la première fois que je réussi à l'afficher correctement ) :
J'ai utiliser les texture low-res, ne voulant pas passer entre le dossier Textures 2 et Textures tout court. Je dois spécifier chaque texture à la main)

Message modifié ( 06-12-2010 04:13 )

[MrSpock]

E-X-C-E-L-L-E-N-T exe lent

[Bibi Uncle]

Bon, là, le programme est en stage final. Je ne trouve presque plus de bugs sauf... des foutus meshs qui se chargent toujours n'importe comment ! En voilà une liste :

-XR2 (seulement le vaisseau, Lee, Kara et les compartiments sont parfaits)
-Au moins 80% des meshs d'AMSO.

Je débug pas à pas, mais je ne vois pas ce qui cloche. Il m'a l'air de respecter le fichier MSH à la lettre, pourtant, ça fait un joli gâchi. Les vertices m'ont l'air aux bons endroits, c'est l'ordre des triangles que je suspecte.

Un petit défi, trouvez la différence qui pourrait faire décaler tous les triangles entre le mesh drill.msh (fonctionne) et Apollo_magnet2.msh (fonctionne pas) dans les mesh d'AMSO. J'ai cru que c'était le nombre de vertices/triangles car la plupart des mesh d'AMSO sont gros, mais Apollo_magnet2 n'a que 28 triangles et ne fonctionne pas !

drill.msh

Apollo_magnet2.msh

Message modifié ( 09-12-2010 01:21 )

[MrSpock]

Mwah ah ah ah ah ah ah ah ...
T'es trop fort !!

J'ai les larmes aux yeux ... je me retiens de la poster au concours , celle là !
Trop marrant !!

Mwah ah ah ah ah ....

[Bibi Uncle]

C'est de l'art contemporain Spocky ! Et tu ne l'as pas vu sans clipping. Là, tu ne vois qu'un seul côté des triangles.

Mwa ha ha ha !



Message modifié ( 20-12-2010 03:05 )

[Bibi Uncle]

Trouvé ! Luis, le créateur des meshs d'AMSO, a codé plusieurs meshs. Alain (le programmeur), fais faire une animation au début pour remettre les triangles en place. Voir ici :

http://orbiter-forum.com/showthread.php?t=894&page=3



Message modifié ( 09-12-2010 02:54 )

[MrSpock]

C'est de l'art contemporain Spocky !

Ben ouais , pour récompenser les pros au cinéma , il y a les " césars , oscars " et compagnie , et pour les concours de screen d'Orbiter il y a  le ...
 "bibiUncle " ?

Et ce trimestre , le gagnant du concours est ...




Message modifié ( 09-12-2010 03:02 )

[MrSpock]

Ouch !!
Encryption ...
J'avais pas pensé à çà .

extrait :

To steal (or make utility for stealing) AMSO's meshes one need to be familiarized with orbiterapi. Chances are this person is orbiter addon developer and as such have more respect for intellectual property. Also "encrypted" meshes could be considered as signatures for copyrighted mesh. And in case user hadn't read the last page of manual, they could warn him of their status
Is this the line of logic?

Ben voilà , le coté obscur de la protection , c'est qu'il s'exclut du processus global de visualisation .
Mais bon , sa volonté est que son travail soit lisible dans Orbiter exclusivement , et là , c'est réussi !
Pro jusque dans les détails ...Amso what ?
happy inside .



Message modifié ( 09-12-2010 03:03 )

[Bibi Uncle]

Je respecte le choix d'Alain et Luis. Ils ont travaillé fort pour arriver à ce magnifique résultat, et si quelqu'un leur vole leurs meshes sans autorisations, ça fruste facilement quelqu'un (moi en premier ).

Je vous averti qu'une première release est très proche. J'écris en ce moment le READ-ME. Le programme n'est pas parfait du tout, mais emplement utilisable. J'ajouterai des fonctions à la demande (à commencer par une nouvelle GUI parce que la SDL est beaucoup trop limitée).

Avant la release, je devrai regardé ce que j'ai le droit de faire avec les DLLs de la SDL et de DevIL. Je ne sais pas si je peux les distribuer toute seule comme ça.

[Bibi Uncle]

La migration à la Win32 est presque fini ! Il reste les fonctions de caméra à gêrer. Sinon, tout va très bien. Le programme rafraîchi seulement lorsque c'est nécessaire (lorsqu'il y a un WM_PAINT d'envoyé, validé par ValidateRect(hWnd,NULL) pour les intéressés ). La fenêtre peut être agrandi comme on veut, la fenêtre s'y ajuste.

Après la migration, je doit incorporer le système de menu (la petite barre avec "File", "Edit", "About", etc.) et le fichier INI pour sauvegarder le dossier de textures. J'aimerais aussi pouvoir spécifier le dossier "Textures 2" pour que le programme vienne chercher automatiquement les plus grosses textures par défaut.

Je suis tombé amoureux de l'API Windows. Le seul point faible, les noms vraiment étranges... LPSTR pour un tableau de char ? WTF ? LPCSTR lorsque c'est constant...

C'était mon bulletin de nouvelles !

[MrSpock]

Je suis tombé amoureux de l'API Windows. Le seul point faible, les noms vraiment étranges... LPSTR pour un tableau de char ? WTF ? LPCSTR lorsque c'est constant...

Bingo !
15 ans en arrière , c'est moi tout craché . Sauf qu'en plus , il fallait que j'apprenne l'anglais .
Mon vocabulaire oscille entre celui de Bob Marley et bill gates les concepteurs de l'api win32 .


Bravo bibi , un de ces jours va voir l'api MIDI , il y a des trucs marrants à faire là-bas .
Ah ouii , la gestion des Josticks s'y trouve aussi , dans l'onglet multimédia .... hyper simple et rapide à mettre en place.
Good work mon'. t'es pas loin d'avoir créé ton premier simulateur ...




Message modifié ( 20-12-2010 06:21 )

[NLS le pingouin]

Tournant aussi sous linux, j'ai jamais voulu y toucher. J'ai toujours fait en sorte de coder des trucs portables, même lorsque c'était juste des tests ou des trucs perso.

[MrSpock]

La portabilité n'est pas un soucis de microsoft , qui comme tout le monde le sait , s'est approprié tout le code qu'il pouvait pour construire son OS .
Quand j'ai débuté , je ne connaissais rien à l'informatique ( normal...) et encore moins à son historique .
Quand j'ai appris ( il y a 15 ans hein ...) l'existence d'os alternatifs , c'était trop tard , j'étais lancé dans le coeur de windows. Tiens , je viens de me rappeller que le premier langage que j'ai appris , c'est Java . Mais les limites en 3d ( ce qui me plaisait ) mon poussé au c++ et à directX .A l'époque , c'était la voie royale pour programmer des jeux vidéos sur pc . Jusqu'à directX7 pour des amateurs . Ensuite , l'api se corse .

Opengl est une très bonne école je crois , pour qui persévère , et ne pas s'enfermer dans l'APIWin32 est un bon conseil à donner à un futur pro grammeur . Mais passer à coté serait aussi une erreur ( à mon avis , connaitre l'architecture et la logique de fonctionnement est un plus , si tu veux que ton code soit réellement portable par la suite) .
Si tu utilises des librairies de haut niveau , qui gèrent l'abstraction logicielle pour toi , ce n'est effectivement pas un soucis . Mais il reste que le bas niveau t'échappe alors , à moins que tu disposes des sources et que tu les modifies .
Mais à l'usage , peu le font : Il faut avoir en tête toutes les architectures possibles ...



Message modifié ( 20-12-2010 08:05 )

[Bibi Uncle]

J'ai choisi la Win32 car la plupart des gens qui utilisent Orbiter tournent avec Windows (à vrai dire, la plupart des gens qui ont un ordinateur ont Windows), mais surtout, car je ne voulais pas être pris avec des bibliothèque comme Qt avec lesquelles ont doit dévoiler nos sources et qui nécessitent des grosses DLL pour simplement créer des fenêtres.

Mais je crois qu'avec Wine ou autre, tu seras capable d'exécuter mon programme. La fenêtre est très basique et c'est du OpenGL 1.1. Rien de très complexe à émuler.

La SDL par contre, était portable. Mais elle est surtout pour des applications 2D. La gestion des boutons et des menus est manquante. J'ai vite passé à travers.

[Bibi Uncle]

Je viens d'ajouter des fonctions de caméras avec la souris. J'ai commencé avec le clavier, puis, voyant la simplicité de l'opération, je me suis interressé au mouvement avec la souris. Ça été très facile... une fois que j'ai su qu'il fallait que je définisse la version de Windows qui sera utilisé dans un préprocesseur . Le zoom utilise la molette, et la rotation est semblable à celle dans Orbiter, sauf que la rotation n'est pas illimité. Lorsqu'on dépasse le cadre de la fenêtre, la rotation arrête. Je vais essayé de corriger ça.

[MrSpock]

miam miam ...
pense au joystick , c'est hyper simple ...
QUoi ? non , j'ai rien dit !

[Bibi Uncle]

Le menu est créé ! Encore une fois, c'était très simple. J'ai été plutôt occupé aujourd'hui, c'est pourquoi je n'ai pas beaucoup travaillé dessus (par contre, j'ai de délicieux fudges et des biscuits de Noël qui m'attendent ).

Après Noël, j'ajoute un menu "Options" avec des réglages pour la sensibilité de la souris et (au bonheur de Spocky ) la possibilité d'utiliser un joystick. Finalement, ce sera au tour du fichier INI pour le dossier de textures. Ensuite, une release peut-être... .

J'ai aussi ajouté un raccourci vers la doc de la Win32, maintenant que j'y vais très souvent

[MrSpock]

Salut !
Un méga bravo pour ton endurance , et la facilité avec laquelle tu passas les niveaux .
Une première fois , c'est toujours compliqué , car l'expérience nous manque et donc , nous expérimentons .
Le Menu , c'est un très bon ajout , qui rendra de bons et loyaux services .
Tiens , je te suggère de jeter un coup d'oeil sur les menus popup , qui s'ouvrent avec un clic droit .
Ils se créent en prenant pour référence par exemple ton menu général . C'est dans le prolongement de ton programme .

Le joystick , ce sera un super ajout aussi .
Tiens , sur le forum paraissent parfois des questions au sujet du Joystick qui ne marche pas .
Tu pourrais proposer un diagnostic , l'utilisateur verrait par exemple l'ID de chaque bouton , l'étendue de l'AXE Z , etc ...
Au final , si tu arrives à te mapper sur Orbiter , l'intêret sera multiplié .
Et après , les mecs diront : " mais on faisait comment avant ? " . Je pense à OrbiterSound par exemple .
Bravo !

[cslevine]

mais dis donc : plus tard, je dis bien plus tard et dans la durée, tu nous mettraiit ça en relation avec Orbbiter_ng.exe, et alors là Olga pourra aller remettre son Damart ( ou venir aux coords 0.2037 49.7078 pour que je m'occupe de son cas ) + autre interface,
je sais pas, Orbiter s'améliore de jour en jour.
Orbiter + Freebox + XP + carte mère Asus = le choix des malins

[Bibi Uncle]

Si je le fais, ce sera beaucoup plus tard. Je suis très loin de l'optimisation complète. Mon programme utilise seulement le CPU, je ne génère aucune mipmap, j'utilise la GDI qui est dépassée (maintenant qu'il y a la GDI+) et il y a beaucoup d'optimisation que je ne connais pas. Si je m'y lance, ce sera dans un bon moment, et je n'utiliserai sûrement pas l'OpenGL 1.1 livré avec Windows. Il est vieux et dépasser. Je me tournerais vers les nouveaux OpenGL ou vers DirectX (mais à quoi ça servirait puisque Orbiter est déjà avec DirectX ?).

[cslevine]

y'a pas des moteurs de rendus graphiques de type Half Life qui prennent aussi en compte la physique (on casse un objet, il se casse avec les morceaux, les bruits etc. )  ? Ceci dit, ces moteurs 3D sont ils Open source ?
et le moteur de WinTerra (ou qqchose comme ça, un nom bizzaroïde qui à lui seul a fait faire Flop au projet, mais il me semble que le moteur est open source ou bien qqchose dans le genre. Mais où retrouver le nom de ce projet ?
ca s'appelait "WinTerra, ou Terrawin , mais pas exactement comme ça.

[Bibi Uncle]

Oui, y'a des moteurs qui prennent compte des collisions (IrrLicht par exemple). Parfois, on sépare le moteur physique du moteur graphique.

Oui, certains sont Open Source (comme IrrLicht, encore une fois ). Mais programmé un moteur graphique, ou juste en incorporer un à Orbiter, c'est des heures de travail.

[Bibi Uncle]

En passant, petite news, le contrôle de sensibilité est fait. On peut régler la sensibilité de la souris et de la roulette.

Encore une fois, c'était un jeu d'enfant. Une petite fenêtre en ressource, puis, à coups de GetDlgItem() et de messages, j'y suis arrivé.

Je suis en train de travaillé sur le fichier INI. Presque tout fonctionnait tantôt, mais là... ça fonctionne plus.



Message modifié ( 26-12-2010 03:24 )

[MrSpock]

Coucou !
( tiens ...? )
EUh , alors :

ou juste en incorporer un à Orbiter ( moteur graphique ), c'est des heures de travail.

A vrai dire , c'est de mois , voir d'années .
De quoi ne pas s'ennuyer pendant un bon bout de temps ...

Sinon , l'interface de ton programme est de plus en plus sympa !
Pour le fichier ini , persévère ! Mais fais attention , certains changements ou ajouts dans un programme peuvent le mettre  bien en danger .

Par mesure de sécurité , sauvegarde l'ensemble de ton projet avant d'ajouter une nouvelle extension ou fonction qui touche au coeur de ton processus .Au moins , commente tes changements pour te donner une chance de revenir en arriere au cas où ton essai n'était pas le bon . ( c'est comme en athlétisme , on a droit a plusieurs prises d'élan ... ).

Accroche toi bibi !


hé ? Psssst ...
au cas où ...



Message modifié ( 26-12-2010 13:43 )

[Bibi Uncle]

Je crois avoir trouvé le problème, mais je ne trouve pas la solution...

Lorsque j'essais de sauvegarder l'état, j'ouvre mon fichier avec file.open(), puis je test si tout s'est bien déroulé avec file.fail(). La fonction me retourne toujours qu'il n'y a pas de problème. Pourtant, lorsque je charge un mesh puis je quitte, rien n'est sauvegardé. Par contre, lorsqu'il n'y a aucun mesh de chargé, les infos sont sauvegardées. Je devine que c'est un problème avec les 2 fichiers ouverts, mais pourtant, les 2 sont fermés (le fichier MSH avant que j'ouvre l'autre). Je fouillé sur le web et on parle beaucoup de la fonction file.clear(). J'ai beau la mettre n'importe où, mes infos ne sont toujorus pas sauvegardées.





Message modifié ( 27-12-2010 03:16 )