-
Bonjour à tous !
Une nouvelle création que je viens d'atteindre un avancement présentable. Dans ma recherche du meilleur moteur 3D, j'ai testé IrrLicht, Ogre3D et maintenant, je sors du domaine des moteurs pour me retrouver dans les API graphiques. J'ai d'abord été tenté par DirectX, mais voyant sa taille de plus de 500 Mo, j'ai décidé de me tourner vers OpenGL (et la SDL pour la fenêtre).
Petite annecdote : J'ai passé au moins 1 heure à chercher les librairies d'OpenGL. Puis, j'ai découvert qu'elles étaient intégré à la SDK de Windows :badsmile:. Avis au futur utilisateur d'OpenGL.
Après avoir appris les rudiments du OpenGL, j'ai décidé d'essayer de charger un mesh d'Orbiter. Merci à Martin pour sa documentation claire et son format tellement bien fait, j'ai réussi à lire un fichier .msh d'Orbiter en une avant-midi de travail. Puis, il est venu le temps d'afficher le résultat à l'écran. Ça, ça été plus difficile à cause de la grande hiéarchie des fichiers meshs. Après plusieurs arrachements de tête (sens figuré, of course... :badsmile: ), j'ai finalement réussi à faire apparaître le mesh à l'écran !
Pour l'instant, je ne lis pas les matériels, ni les textures. Seulement les coordonnées des triangles. Il y a un ZBuffer mais pas de buffer d'ombre ce qui donne un aspect cartoon au rendu. La caméra ne bouge pas (il faut jouer dans les sources) et le choix du fichiers non plus (il faut encore jouer dans les sources). Il reste encore beaucoup de travail à faire avant de voir une release futur (pas encore sûr...).
Tout de même, j'étais tellement joyeux de mon succès, je n'ai pas pû résister à vous le montrer.
ISS
(http://i1029.photobucket.com/albums/y355/BibiUncle/iss-1.jpg)
Atlantis
(http://i1029.photobucket.com/albums/y355/BibiUncle/atlantis.jpg)
ShuttlePB
(http://i1029.photobucket.com/albums/y355/BibiUncle/shuttlepb.jpg)
Message modifié ( 13-11-2010 17:08 )
-
Chapeau bas, c'est top ! c'est déjà vraiment pas évident d'obtenir cela, j'en sait quelque chose :) un super premier pas.
Et finalement pourquoi as tu abandonné les moteurs comme irrlich et ogre ?
-
Petit cachotier !
Si je comprends bien , tu es entrain de créer ton propre moteur3D , de A à Z ?
C'est toi qui crée les vertexbuffers , les matrices , etc ... ?
Tu as pris une pomme sur la tête ou quoi ?
Espèce de Newton , va !
Nan , c'est génial et je suis très curieux d'avoir plus de détail .
:applause::applause::applause:
-
J'ai abandonné Irrlicht et Ogre3D car j'ai vite vu les limitations (Ogre3D est plus complexe qu'Irrlicht) et j'ai voulu m'essayer directement dans OpenGL. J'ai trouvé plus facile d'y aller directement dans lui. Les fonctions sont extrèmement simple et puissante. Ex : Pour faire des triangles, glBegin(GL_TRIANGLES); puis tu entres les coordonnées des triangles. Tu peux en mettre comme tu veux, OpenGL va faire des triangles. Quand t'a fini, glEnd(); Fini !
Oui MrSpock, c'est un peu le cas. Ce petit programme est un début de moteur 3D. Je pense me limiter à la visualisation de mesh d'Orbiter. Pour le ZBuffer, c'est OpenGL qui le fait pour toi. Encore une fois, c'est hyper simple. glEnable(DEPTH_TEST); et à chaque frame, un glClear(GL_DEPTH_BUFFER_BIT);.
Je travail présentement sur les matériels. Ça avance plutôt bien. Le programme sait lire dans le fichier .msh les donnés sur les matériels. Reste juste à les incorporer à la scène.
-
J'ai commencé à coder mon propre moteur 3D en java avec JOGL (Java OpenGL)
C'est sympa et là on voit bien la complexité de créer des polygones ;) Mais c'est très formateur ;)
-
Ex : Pour faire des triangles, glBegin(GL_TRIANGLES); puis tu entres les coordonnées des triangles. Tu peux en mettre comme tu veux, OpenGL va faire des triangles. Quand t'a fini, glEnd(); Fini !
Non , là , Respect !! canadien ...
J'ai jamais eu le coeur de m'y coller , à fabriquer des triangles ...
Si tu commences par là , c'est une longue route qui s'ouvre à toi , et je ne pense pas que tu vas t'arrêter à visualiser
des meshs .
Un de ces matins , tu vas te dire : " Bon , si je le faisais bouger un peu , pour voir ? " .
Etc ... etc ...
Bravo Bibi !!
:wor:
Après réflexion , je crois que c'est la barrière de la langue qui m'a le plus handicapé .
Lire une doc technique en anglais demande parfois des acrobaties cérébrales ... éreintantes ( pour moi ) .
Je te sens bien parti mon bibi !
Message modifié ( 14-11-2010 17:34 )
-
J'ai intégré les matériels au Viewer ! Certains meshs bug toujours, m'ai Carina est simple et je peux la voir avec de la couleur. Je prend les donnés Diffuse, Ambient, Specular et Emssive, tout comme Orbiter. Les textures ne sont pas chargés encore.
Je suis sûr que tu serais capable Spocky. Une langue ça s'apprend (et l'anglais, encore mieux :badsmile: ). En plus, avec OpenGL, il y a des Bible sur ce domaine. En voilà une : http://www.falloutsoftware.com/tutorials/gl/gl8.htm Un site qui traîte des matériels et des lumières.
(La lumière est mal placée sur ce screen, c'est pourquoi Carina est sombre.)
(http://i1029.photobucket.com/albums/y355/BibiUncle/carina.jpg)
Une autre screen avec plus de lumière et un GL_SMOOTH pour adoucir les triangles.
(http://i1029.photobucket.com/albums/y355/BibiUncle/carina-1.jpg)
Message modifié ( 14-11-2010 17:44 )
-
Vous avez déjà fait un bruit comme "hann !" sans pouvoir vous en empêcher avec le sourire aux lèvres tellement une chose est superbe? ça vient de me le faire :badsmile:
-
Un grand merci à Fast_toche pour m'avoir aidé à lire les vertices dans la bonne ordre. En effet, je les lisais un part un, dans l'ordre du mesh. Mais lorsque je chargeais un mesh avec des écritures dessus (le CentaurD-1T, il y a écrit "USA" avec des vertices), le 'S' était à l'envers.
-
Vous avez déjà fait un bruit comme "hann !" sans pouvoir vous en empêcher avec le sourire aux lèvres tellement une chose est superbe? ça vient de me le faire
ctrl-v !
-
J'ai ajouté une rotation de la caméra avec les touches du NumPad et un zoom avec les touches + et - du numpad aussi. Très pratique pour bien visualiser le mesh.
-
Exellent !
Bientôt : " J'ai rajouté un systeme de propulsion ... " " J'ai rajouté un systeme de detection collision ... " etc ...
Note que le visualiseur externe , it's a great idea .
:eek:
-
J'ai tenté d'implémenter un spot ligth mais je ne sais pas trop comment il est gérer. Il semble bouger avec la rotation de l'objet... mais bouger avec la caméra. Bref, c'est très bizarre. J'ai aussi essayé d'ajouter la gestion des normals et je ne suis pas sûr que c'est correct.
Encore du boulot à faire.
-
J'ai tenté d'implémenter un spot ligth
Mmouais ...
Je pense à un problème de matrice de projection dans le monde 3D .
Si ta lumière est crée dans l'espace de la caméra , c'est possible qu'elle subisse les transformations de la matrice pendant .
Vérifie ta méthode de création de l'objet pour commencer .
Ensuite , toutes les lumières ne se créent pas avec les mêmes paramètres .
Le spot light demande une position et une direction je crois ( au minimum ) .
Pour que ta lumière soit statique , il faut utiliser une méthode du genre MatrxixMultiply , pour atteindre le niveau "Parent" de la scène il me semble .
En fait , c'est ce qui m'avait découragé , les opérations de matrices répétitives .
Mais une fois que le principe est compris , ce n'est plus un soucis .
Accroche toi !
:eek:
-
OpenGL a un très gros inconvenient, c'est une machine à état. Grosso modo les modifications que tu as faites se répercutent sur la modification courante. Par exemple pour les positions, tu as une pile avec au début qu'un seule matrice identité, tu fais une translation pour placer un objet, il va modifier cette matrice, et si tu refais un nouveau déplacement pour placer un autre objet tu vas modifier la matrice précédente, donc tu vas bouger par rapport à l'objet précèdent.
Pour éviter ca plusieurs solution, tu recharge la matrice identité à chaque fois ( glLoadIdentity() ) ou tu utilises la pile ( glPushMatrix() rajoute une matrice identité en haut de la pile et glPopMatrix() retire la matrice du haut de la pile).
Mais si tu as compris ca tu devrais pouvoir régler ton problème de lumière qui se balade.
Sinon pour la camera je te conseille d'utiliser gluLookAt(.....)
Voili voilou j'espère avoir été clair
EDIT : glPushMatrix() rajoute la recopie la même matrice sur le dessus de la pile.
Message modifié ( 17-11-2010 14:43 )
-
tu as une pile avec au début qu'un seule matrice identité ...
Voilà !
C'est ce que je voulais dire , mais avec les termes corrects !
Good Job snoopy !
:beer:
-
je vais donner un exemple pour etre plus clair.
On veut faire un système solaire avec 1 soleil et 1 planète avec 2 satellites.
etat initial de la pile : mId
On dessine le soleil.
On fait la translation + la rotation. etat de la pile : m1
on dessine la planete
glPushMatrix() etat de la pile : m1 m1
on supprime l'ancienne rotation + on fait la translation + rotation du sattelite 1. etat de la pile : m2 m1
glPopMatrix() etat de la pile : m1
glPushMatrix() etat de la pile : m1 m1
on supprime l'ancienne rotation + on fait la translation + rotation du sattelite 2. etat de la pile : m3 m1
Sinon l'année dernière en cours on a fait un système solaire en OpenGL, si ca peut aider je peux l'envoyer
-
ton exemple était super bien choisit mais j'ai été perdu.
corrige moi si je me trompe,
etat initial de la pile : mId (Identité, le centre 0,0, du monde, pas de rotation)
On dessine le soleil.
On fait la translation + la rotation: glPushMatrix(t1) glPushMatrix(r1)
etat de la pile : t1 . r1
on dessine la planète
on supprime sa rotation : glPopMatrix()
on se place sur le 1er satellite : glPushMatrix(Ts1)
on tourne ce satellite: glPushMatrix(Tr1)
etat de la pile : t1 . Ts1 . Tr1
On dessine le satellite
On reviens sur la planete : glPopMatrix(); glPopMatrix();
etat de la pile : t1
on se place sur le 2nd satellite : glPushMatrix(Ts2)
on tourne ce satellite: glPushMatrix(Tr2)
etat de la pile : t1 Ts2 Tr2
On dessine le second satellite
-
Je pense que tout le monde (français...) comprendra facilement le mal de crâne que cela représente de s'attaquer à
OpenGL avec une doc en anglais ...
:arg:
L'interprétation de tofitouf avec les "t" et les "r" pour translation et rotation est plus facile à suivre , mais bobo quand même hein ...
:damn:
En gros , les moteurs 3D nous permettent d'éviter 70% de ... çà .
Mais sans çà , pas de moteur 3D !
Push Push then Pop !
:music:
-
Si je ne me trompe Tofitouf, Push et PopMatrix ne prennent aucun argument.
Je vais regarder ça. Pour l'instant, je fonctionnais avec une seule matrices. Mais là, ça va attendre un peu, un long devoir de math m'attend :sad:.
-
Salut Bibi !
Quand tu auras fini ton long devoir de maths , tu pourras te reposer de cet effort en allant sur le site que je te propose,
qui je l'espère , t'aidera dans la continuation de ton projet .
(http://jeux.developpez.com/faq/math/images/faq_mq.gif)
Ben oui , encore des maths ...:badsmile:
http://jeux.developpez.com/faq/math/?filtre=OOOOOOOOOOOO
-
Ah oui autant pour moi.
Remplacez chacun de mes glPushMatrix par des glTranslated, glRotate suivis d'un pushMatrix.
Push ne fait que sauvegarder dans une pile l'état actuel de la matrice.
-
Tofit OUF Spocky ! J'ai beaucoup de lecture à faire avec ce site-là ! Allez, je me lance...
Message modifié ( 18-11-2010 22:57 )
-
:top:
Si çà peut te rassurer , j'y suis jusqu'au cou moi aussi ...
Enfin moi , çà part dans tous les sens ( les shaders c'est bien fort aussi ... )
Bon allez , bonne lecture et surtout bonne application !
A+
-
Je suis pris dans une weirdeté (vive les anglicismes ! :badsmile: ) vraiment étrange. Lorsque je dessine pour une première fois le frame, tout est parfait. Par contre, lorsque je dessine une deuxième fois un frame (ex : après rotation de la caméra ou simplement en exécutant 2 refreshs consécutif pour les tests, un groupe disparaît (le premier je crois, à confirmer). J'ai regardé toute les boucles pour vérifier qu'il ne passe aucun groupe, mais je ne trouve rien. Il commence à 0 à chaque fois.
Des idées ?
-
Problème résolu !
[/color]
Je mettais un glBegin(GL_TRIANGLES) trop tôt. Il commençait lorsque je définissais les matériaux. OpenGL n'aimait pas il faut croire...
Message modifié ( 29-11-2010 03:39 )
-
Triple post ! Un nouveau record ! :badsmile:
Maintenant avec un affichage du nombre de triangles dans la barre titre. C'est impressionnant comment des meshs sont optimisés... et d'autres pas du tout.
(http://i1029.photobucket.com/albums/y355/BibiUncle/OMV.jpg)
Message modifié ( 29-11-2010 04:03 )
-
Hallucinant !
Bravo Bibi !!
:hot:
-
Hip hip hip! hourra! :drunk:
-
Je suis pris dans une weirdeté (vive les anglicismes ! :badsmile: ) vraiment étrange
et vive les pléonasmes :)
mais ce pléonasme apporte une emphase que je trouve assez adéquate avec certains prbsl.
je note ça bien au chaud ;)
-
excellent, le résultat est trsè bon. chapeau
-
cslevine a écrit:
Je suis pris dans une weirdeté (vive les anglicismes ! :badsmile: ) vraiment étrange
et vive les pléonasmes :)
mais ce pléonasme apporte une emphase que je trouve assez adéquate avec certains prbsl.
je note ça bien au chaud ;)
:lol: Je ne m'étais même pas rendu compte du pléonasme.
Je vais monter en haut juste pour voir les 2 jumeaux...
-
Bien joué bibi! Je pense qu'il faudra que je fasse ça aussi, un de ces quatre. Ca doit être un super exercice de prog.
-
Je te le recommande Nico. Juste lire le fichier, c'est un bon défi. Et pour dessiner les triangles, c'est une boucle dans une boucle dans un boucle... Un joli casse-tête à résoudre !
Je viens de trouver le problème pour les normals. Dans les fichiers tel que le mesh de Voyager (superbe réalisation en passant :top: ), les normals sont donnés en utilisant la notation scientifique. Par exemple : -6.80888e-005. C'est facile à lire pour un humain, mais pour un ordinateur, il faut que je lui réapprenne les maths.
Bon, allez, je me lance.
Message modifié ( 02-12-2010 01:51 )
-
Ah non, c'est manqué. Il m'a tout l'air de prendre en considération la notation scientifique. Et en regardant de plus près le mesh de Voyager, je crois que c'est le fait de ne pas avoir de texture qui crée cette effet bizarre.
DevIL, j'arriiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiveeeeeeeeeee !!!
Message modifié ( 02-12-2010 01:50 )
-
Il y a un début de support de textures !!!
Les DDS m'ont vraiment fait ch***, car DirectX et OpenGL, ça n'a pas été fais pour être ensemble. Toutefois, j'ai réussi à charger une texture et à l'appliquer. Merci à la fabuleuse bibliothèque DevIL, qui fais presque tout à ma place.
Aussi, j'ai réglé le problème avec le spotlight. Maintenant, la lumière suit la caméra.
Je cherche toujours un moyen d'indiquer un path via une boîte de dialogue. J'ai trouvé le fabuleux GetOpenFileName() que j'utilise déjà au début du programme. Par contre, il ne permet pas (du moins, je n'ai pas trouvé comment) seulement indiquer un répertoire.
Un screen pour vous mettre l'eau à la bouche :bave: :
(http://i1029.photobucket.com/albums/y355/BibiUncle/esa.jpg)
Message modifié ( 04-12-2010 21:55 )
-
:top:
Par contre, il ne permet pas (du moins, je n'ai pas trouvé comment) seulement indiquer un répertoire.
Tu veux scanner le contenu d'un dossier ?
Sois plus précis sur tes besoins , différentes fonctions du SDK win32 sont à considérer .
Selon ce que tu veux faire , j'ai pt'et bien une solution .
A+
-
Je veux avoir le path du dossier "Textures" d'Orbiter. Pour ce qui est de l'intérieur, je m'en fou un peu, car c'est moi qui va ajouter le nom de la texture.
En gros, je veux que la fonction me retourne un truc du genre :
C:\Documents and Settings\Émile\Mes documents\Orbiter2006Test\Textures
-
En faisant différents test, j'ai essayé avec un Ummu et le résultat est spectaculaire !
(http://i1029.photobucket.com/albums/y355/BibiUncle/ummu.jpg)
Message modifié ( 04-12-2010 23:26 )
-
Oui , le résultat est super !
Ok , j'ai utilisé une fonction pour créer mes bases dans CityDesigner , je vais fouiller dans mon code et te ramène l'info .
A+
Message modifié ( 04-12-2010 23:51 )
-
Le mieux c'est que tu fasses exécuter ton programme à partir du répertoire racine d'orbiter , et d'utiliser la fonction
char Buffer[100];// [s]256 c'est plus sûr ...[/s]maxpath=255 ...
GetCurrentDirectory(100,Buffer);
qui te ramènera le path d'orbiter , auquel tu rajoutes avec strcat(...) le chemin des textures .
Je pense que c'est le plus simple , Orbiter n'ayant pas de traces dans la base de registre .
(sinon la lecture dans la base de registre est faite pour çà ...)
Voilà , en espérant que cela te suffise .
Sinon , la méthode dure :
http://msdn.microsoft.com/en-us/library/aa364418(v=VS.85).aspx
mais dans ton cas , ce serait trop compliqué ( tester tous les lecteurs , tous les paths ...)
A+
Message modifié ( 05-12-2010 22:39 )
-
justement cela me rappelait bien City Designer....
Sacrée fonction que celle d'afficher du mesh !
pour le moment je suis vraiment à la bourre question personnel genre paperasses et trucs toujours pas finis de remplir et tant que j'ai pas l'esprit libre... bref je réserve mes futures mises à jours de .bmp etc. pour quand j'aurai réglé un certain nombre de trucs, sinon ce sera jamais fait.
A++
-
Alllo ? Sammy ?
P..... de répondeur ...
Heu , c'est spock à l'appareil , je voulais te dire que pour cityDesigner , c'est plus qu'au point mort , et j'ai trouvé un truc plus marrant à faire ailleurs . Si d'aventure tu avais besoin de nouveaux trucs , je pourrais m'y remettre , mais sinon , c'est dans les cartons . D'ailleurs , si tu veux stocker les sources en c++ dans tes archives pour la lune , pas de problème , je te les envoies .
A+
-
cslevine wrote:
OK j'en veux bien une copie d'archives en C++, je les stockerai en lieu sûr en tant que copies de sécurité. ;)
De toute façon même en l'état, City Designer rend de sacrés services, et en rendra d'autres au fil des prochains mois où j'ajouterai ici et là des objets additionnels.
Disons qu'il hiberne.
Post Edited ( 12-06-10 01:00 )
-
* doubled posted *
Post Edited ( 12-06-10 01:00 )
-
Ah ... C'est trop bien de pourrir le fil de Bibi Uncle !
:badsmile:
Sinon , Canadien , t'en es où ??
De toute façon , le plus important tu l'as déjà fait avec la gestion des triangles , normales , textures .
( et la lecture de fichier ... ) .
Tiens , tu pourrais accoupler ton programme à un mod du scenarioEditor , qui afficherait la 3D à la place d'une image2D du vaisseau sélectionné. Tu récupères le path du vaisseau via les fonctions du sdk d'orbiter , et tu lances ton programme
avec ce chemin en params d'éxécution ?
Il me semble avoir vu un code d'exemple du scénarioEditor dans le sdk ...
:music:
-
J'aimerais bien que mon programme puisse être exécuter de n'importe où. OpenGL Orbiter Mesh Viewer serait bien utile pour les modeleurs qui ne veulent pas lancer Orbiter à chaque fois. Mon programme prend 1 seconde à ouvrir, contrairement à Orbiter. S'il faut absolument que l'utilisateur mette ses texture dans le dossier texture, c'Est moins efficace.
Je cherche toujours mais Google me donne toujours des liens vers des forums de C#, VB ou autres languages.
Pour ta suggestion, pourquoi pas. Ça ferait du bien aux yeux !
Message modifié ( 06-12-2010 02:23 )
-
Nouveau problème. Orbiter ne dessine qu'un seul côté des triangles. Moi, OpenGL dessine les 2 côtés. Ça fait que certains triangles, lorsqu'ils sont doubles apparaîssent flashant et avec une texture inadéquate. Je cherche mais je ne trouve aucune fonction pour spécifier de dessiner un seul côté des triangles.
-
OpenGL Orbiter Mesh Viewer serait bien utile pour les modeleurs qui ne veulent pas lancer Orbiter à chaque fois.
C'est un bon argument .
Ton programme est rapide , c'est vrai aussi .
Le problème du standalone , c'est qu'orbiter puisse être installé n'importe où .
Une astuce de programmeur serait de demander à l'utilisateur de renseigner le programme à la première utilisation ,
pour lui demander le chemin d'Orbiter . Ensuite , c'est du gateau ... Tu stokes l'info sur un .ini , et c'est tout .
Tu peux coder une routine qui vérifie à chaque lancement que le .ini existe , sinon tu relances la procédure .
( Bon , ce n'est pas infaillible , city designer fonctionnait comme çà , mais chez CSLevine , il fallait recommencer la procédure à chaque fois , je n'ai pas compris pourquoi ) .
A+ !
-
Nouveau problème.
Tiens mon petit ... :
http://www.videotutorialsrock.com/opengl_tutorial/backface_culling/text.php
:badsmile:
Message modifié ( 06-12-2010 04:11 )
-
Merci Spocky ! Le culling, c'est magique ! En plus, je gagne beaucoup dans l'utilisation du processeur (merci au Gestionnaire de Tâches :badsmile: ).
Un petit screen du DG (c'est la première fois que je réussi à l'afficher correctement :eek: ) :
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)
(http://i1029.photobucket.com/albums/y355/BibiUncle/dg.jpg)
Message modifié ( 06-12-2010 04:13 )
-
E-X-C-E-L-L-E-N-T
exe lent
:top::top::top:
-
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 :grrr: ! 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 ! :help:
drill.msh
(http://i1029.photobucket.com/albums/y355/BibiUncle/drill.jpg)
Apollo_magnet2.msh
(http://i1029.photobucket.com/albums/y355/BibiUncle/magnet.jpg)
Message modifié ( 09-12-2010 01:21 )
-
(http://i1029.photobucket.com/albums/y355/BibiUncle/magnet.jpg)
Mwah ah ah ah ah ah ah ah ...
T'es trop fort !!
:ptdr::ptdr::ptdr:
J'ai les larmes aux yeux ... je me retiens de la poster au concours , celle là !
Trop marrant !!
Mwah ah ah ah ah ....
:beer:
-
C'est de l'art contemporain Spocky ! :badsmile: 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 )
-
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 )
-
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 ...
:eek:
Message modifié ( 09-12-2010 03:02 )
-
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 ?
:music: happy inside .
Message modifié ( 09-12-2010 03:03 )
-
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 :grrr: ).
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.
-
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 !
-
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 .
:badsmile:
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 ...
:beer:
Message modifié ( 20-12-2010 06:21 )
-
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.
-
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 )
-
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.
-
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 :badsmile:. 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.
-
miam miam ...
pense au joystick (http://www.gameprogrammer.org/main.php?page=tutorials&no=80) , c'est hyper simple ...
QUoi ? non , j'ai rien dit !
:beer:
-
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 :eek: ).
(http://i1029.photobucket.com/albums/y355/BibiUncle/ogl.jpg)
Après Noël, j'ajoute un menu "Options" avec des réglages pour la sensibilité de la souris et (au bonheur de Spocky :badsmile: ) la possibilité d'utiliser un joystick. Finalement, ce sera au tour du fichier INI pour le dossier de textures. Ensuite, une release peut-être... :wonder:.
J'ai aussi ajouté un raccourci vers la doc de la Win32, maintenant que j'y vais très souvent :badsmile:
(http://i1029.photobucket.com/albums/y355/BibiUncle/desktop.jpg)
-
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 !
:applause:
-
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
-
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 ?).
-
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.
-
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 :badsmile: ). Mais programmé un moteur graphique, ou juste en incorporer un à Orbiter, c'est des heures de travail.
-
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é.
(http://i1029.photobucket.com/albums/y355/BibiUncle/o.jpg)
Je suis en train de travaillé sur le fichier INI. Presque tout fonctionnait tantôt, mais là... ça fonctionne plus. :wonder:
Message modifié ( 26-12-2010 03:24 )
-
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 !
:eek:
hé ? Psssst ...
au cas où ... (http://raptor.developpez.com/tutorial/opengl/skybox/)
Message modifié ( 26-12-2010 13:43 )
-
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.
:help:
Message modifié ( 27-12-2010 03:16 )
-
Alors alors ...
Je n'ai jamais utilisé la fonction dont tu parles , qui semble être une fonction de plus haut niveau que la base que j'utilise
souvent , à savoir fopen() , fread(), fwrite().
Exemple :
* fopen example */
[glow=yellow,2,300]#include [/glow]
int main ()
{
FILE * pFile;
pFile = fopen ("myfile.txt","w");
if (pFile!=NULL)
{
fputs ("fopen example",pFile);
fclose (pFile);
}
return 0;
}
J'utilise souvent une structure pour sauvegarder mes données .
L'avantage , c'est que c'est possible d'enregistrer les datas en mode binaire .
Exemple :
struct S_INIFILE{char TexturePath[255];char MeshPath[255];char OrbiterPath[255]};
Pour lire un fichier :
http://www.cplusplus.com/reference/clibrary/cstdio/fread/
Tu déclares ta structure qui sera remplie par la fonction.
S_INIFILE inifile ;//ce n'est pas un pointeur !
Tu ouvres ton fichier :
FILE * File;
File = fopen ("myfile.cfg","r");
//tu passes l'adresse de ta structure , c'est un pointeur ...
fread ( &inifile , sizeof(S_INIFILE), 1, File );
fclose(File);Normalement , inifile.TexturePath contient les données qui avaient été enregistrées .
Pour l'écriture c'est sensiblement la même chose .
http://www.cplusplus.com/reference/clibrary/cstdio/fwrite/
S_INIFILE *inifile ;//c'est un pointeur !
inifile->TexturePath="Textures/";
inifile->MeshPath="Mesh/";
inifile->OrbiterPath="C://Orbiter/";
File = fopen ("myfile.cfg","w");
fwrite (inifile, 1 , sizeof(inifile ) , File );
...
fclose (pFile);
Je n'ai pas testé ce code , mais si mes souvenirs sont bons , çà devrait le faire .
Message modifié ( 27-12-2010 08:32 )
-
Aaaah les pointeurs.... :love: .... :grrr:
-
Je ne réussi toujours pas :sad:.
Voilà mon code :
À remarqué que j'utilise fopen_s(), une version modifiée par MS, afin d'assurer aucun overbuffing.
bool SaveIni(void)
{
typedef struct
{
float Mouse;
float Wheel;
char *Path;
} INIFILE; // La structure pour sauvegardé.
INIFILE *iniFile = NULL;
iniFile = new INIFILE;
iniFile->Mouse = sensMouse; // sensMouse est une variable locale pour la sensibilité. C'est un float.
iniFile->Wheel = sensWheel; // voir commentaire du haut.
iniFile->Path = Mesh.GetTexturePath(); // cette fonction retourne un char*. En déboguage, je vois qu'il retourne ce qu'il faut
FILE *file;
fopen_s(&file,"OGLOMV.ini","w+"); // w+ car je veux créer un fichier s'il le faut.
if (file==NULL)
return false; // On quitte s'il y a un problème.
int test = sizeof(iniFile); // variable pour des test.
test = fwrite(iniFile,1,sizeof(iniFile),file); // On écrit
fclose(file); // On ferme.
return true; // On retourne.
}
Ça me retourne : ÍÌÌ= dans mon fichier OGLOMV.ini.
Message modifié ( 27-12-2010 17:06 )
-
INIFILE *iniFile = NULL;
iniFile = new INIFILE;
Une structure ne s'initialise pas avec l'opérateur new .
Si tu veux l'initialiser à zéro , utilises memset(...)
http://www.cplusplus.com/reference/clibrary/cstring/memset/
// sensMouse est une variable locale pour la sensibilité. C'est un float.
Cette variable est GLOBALE , tu veux dire ?
Parce que sinon , sa valeur est NULL ...
int test = sizeof(iniFile); // variable pour des test.
test = fwrite(iniFile,1,sizeof(iniFile),file); // On écrit
fclose(file); // On ferme.
Ton " int test = sizeof(iniFile);" ne sert à rien puisque test est reécrit dans la fonction suivante .
Et pour finir , tu as interverti les paramètres , canadien .:badsmile:
Ben oui , observe la definition de la fonction :
size_t fwrite ( const void * ptr, size_t size, size_t count, FILE * stream );
size , c'est la taille de ta structure .
count , c'est le nombre de fois que tu veux écrire ta structure dans le fichier .
Donc essaye :
test = fwrite(iniFile,sizeof(iniFile),1,file); // On écrit
Ok ?
C'est normal de tatonner , tu vas y arriver !
AU fait , ce que tu écris de cette manière n'est pas lisible pour un humain !
Tu dois utiliser la fonction de lecture dans ton programme pour lire les données compactées dans la structure .
Utilise des MessageBox(....) pour debugger ?
A+
Message modifié ( 27-12-2010 18:16 )
-
Moi aussi je ne croyais pas qu'elle s'initialiserais comme ça. Par contre, si je ne fais pas de new, j'obtiens cette erreur lors de l'exécution :
Exception non gérée à 0x004125de dans OpenGL Orbiter Mesh Viewer.exe : 0xC0000005: Violation d'accès lors de l'écriture à l'emplacement 0x00000000.
et selon ce que j'ai lu, c'est à cause que je n'utilise pas l'opérateur new.
Oui, sensMouse est une variable globale, faute de frappe. Elle est déclaré avant le WinMain() qui est la première fonction. En déboguage, elle vaut toujours ce qu'elle doit.
Le test me servait lorsque je déboguais pas à pas (ce que je fais souvent). J'appuis sur F10 après un breakpoint que je mets au début de la fonction et je regarde ce que chaque variable vaut.
Finalement, je testait avec le sizeof() des 2 côtés car je ne savais pas trop. Par contre, lorsque je met le sizeof() du côté que tu m'indiques, la fonction me retourne qu'elle a écrit 1 seul byte. Quand je le met comme je l'ai mis, elle me retourne 12 bytes. J'ai donc opté pour cette dernière.
Je cherche toujours...
-
Le test me servait lorsque je déboguais pas à pas (ce que je fais souvent). J'appuis sur F10 après un breakpoint que je mets au début de la fonction et je regarde ce que chaque variable vaut.
Ok , je comprends maintenant .
Finalement, je testait avec le sizeof() des 2 côtés car je ne savais pas trop. Par contre, lorsque je met le sizeof() du côté que tu m'indiques, la fonction me retourne qu'elle a écrit 1 seul byte. Quand je le met comme je l'ai mis, elle me retourne 12 bytes. J'ai donc opté pour cette dernière.
Suis la procédure je pense , mets les bonnes variables à leur place , sinon tu ne t'en sortiras pas .
Je vais voir si je peux te sortir un bout de code qui marche .
A+
Edith : Je viens de trouver une classe sur un forum , capable d'écrire des sections entières et vraisemblablement éditables , un vrai .ini . http://farscape.developpez.com/Samples/CDataFile.zip
Pas le temps de tester pour toi , mais j'ai jeté un coup d'oeil , çà à l'air bien .
Je viens de créer un code qui marche : A toi de l'améliorer , pas de test d'erreur ...
#include
struct INITFILE
{
char *msg1;
char *msg2;
float mouse;
} ;
void ecrire()
{
INITFILE init ;
init.msg1="message1";
init.msg2="message2";
init.mouse=0.001f;
FILE* file=fopen("bibi.ini","w");
fwrite(&init,sizeof(INITFILE),1,file);
fclose(file);
}
void Lire()
{
INITFILE init ;
FILE* file=fopen("bibi.ini","r");
fread(&init,sizeof(INITFILE),1,file);
fclose(file);
//Caption=init.msg1 ; ignore çà , j'étais sous borland , c'est le titre de la fenetre , utilisée comme debugger ...
}
çà fonctionne , t'as plus qu'à rajouter des params dans les fonctions lire et écrire .
A+
Message modifié ( 27-12-2010 21:04 )
-
Ton programme fonctionne (sauf pour le tableau de char qui fait la même chose que tantôt) mais je retourne encore au même problème : dès que je charge un mesh, il ne fait rien dans le fichier de config.
-
dès que je charge un mesh, il ne fait rien dans le fichier de config.
Montre voir la fonction qui charge le mesh .
Et tu devrais changer de procédure :
1 Verifier la présence du fichier ini .
Si le fichier ini n'existe pas , tu ouvres une dialogBox , demandant le chemin de la racine d'Orbiter .
Tu crées le fichier , et conserve le chemin dans une variable globale ( temps de vie = durée du programme )
Une fois que tu as la racine , tu déduis le reste . ET TOUT CELA SE FERAIT AVANT TOUTE OUVERTURE DE FICHIER MESH.
2 Ensuite , tu n'as plus rien à écrire , juste à lire ( puisque tu cherches le path et qu'il est dans le ini .) à chaque ouverture du programme ( et une seule fois !) , avant même la création de la fenêtre .
Edith : Pour le problème de char* , tu ne serais pas en Unicode dans tes options de compil , par hasard ?
Au cas où , essaye de changer l'option en " not set " plutot qu'Unicode . Ou alors utiliser des fonctions et variables unicodes ?
Message modifié ( 27-12-2010 22:55 )
-
J'AI TROUVÉ !!!
Les fichiers étaient bels et bien sauvegardés... dans le répertoire des meshes. Je croyais qu'il sauvegardait dans le répertoire de l'exécutable, mais il doit faire un GetCurrentDirectory().
Donc, il me reste plus qu'à toujours sauvegardé dans le dossier de l'exécutable ! Ouf ! Je croyais devenir :fou:
-
:wall:
...
:ptdr:
quand même :top:
Message modifié ( 28-12-2010 16:56 )
-
Si j'ai le temps, demain, je fais une release. Je vais laisser tomber le joystick pour l'instant, je le ferai dans une autre release. Le programme est très fonctionnel (plus que ce que j'aurais imaginé), il n'y a aucun fuite de mémoire (merci au Gestionnaire de tâches :badsmile: ), et beaucoup de choses ont changé.
J'écris la doc, je fais tester sur différent ordinateur, puis je release.
-
Et bien moi , je l'ai déjà et c'est ....
PLUS MIEUX ! GRAND .
:badsmile:
Bon , ok , l'oncle bibi a fait son annonce , je peux me lacher :
COURREZ VITE L'acheter le télécharger !par là ... (http://orbiter.dansteph.com/forum/index.php?topic=6795.msg106600#msg106600)
Cette nouvelle version est géniale , vous disposerez d'un menu pour peaufiner la vitesse de déplacement et de zoom de la souris , plus besoin de redonner le chemin des textures à chaque fois ( merci bib ... ) , et çà va continuer à évoluer .
Soyez nombreux à le télécharger , çà le motivera pour continuer à le faire progresser ( bientôt un joystick !! ) .
Enfin bref , notre " petit canadien " a bien travaillé , STAND UP !
:applause::applause::applause:
Message modifié ( 29-12-2010 21:17 )
-
Bibi ? Je viens d'avoir une idée .
En fait plusieurs , mais d'abord la 1 :
Créer une fonction DIAPORAMA .
Tu ouvrirais un mesh et sa texture , l'afficherais pendant (x) secondes , chargerais un second Mesh , affiché dès que le premier aurait été détruit , et ainsi de suite sur chaque fichier mesh que ta routine trouverais dans le dossier .
L'utiisateur pourrait règler la vitesse du slide show .
Idée 2 :
Ajouter une classe qui crée des vaisseaux en éditant des fichiers .cfg contenant du code Lua , en Asccii .
Exemple dans \ORBITER-2010\Config\Vessels scriptPB.cfg .
Comme tu sais maintenant travailler avec des chaines de caractères dans un fichier , tu t'es offert cette possibilité .
c'est ce que je faisais avec CityDesigner , en créant un fichier de base ou de planete .
Mais toi , ton fichier créerai un vaisseau ...
Il "suffirait " de remplir des structures de lignes de code , chaque structure étant un bloc ,
au milieu duquel tu ajoutes la valeur numérique ou le texte de l'utilisateur .
Un visualizer + one creator ...
Ce serait :fou: , a+ .
Message modifié ( 30-12-2010 04:20 )
-
Moi, j'avais pensé à un genre de Blender Jr. Tu sélectionne une vertice, tu la déplace avec la souris, puis tu peux sauvegarder tes changements. Quelque chose de simple, mais d'utile.
Ta première idée est bonne, mais la seconde, je ne crois pas la comprendre. Le fichier config serait toujours le même, sauf pour le nom du mesh. :wonder:
-
Je viens de regarder, il y a un bouton en français sur le dialog de sensibilité. ResEdit l'a mis par défaut. Je me demande s'il est traduit sur les autres Windows...
-
Ta première idée est bonne, mais la seconde, je ne crois pas la comprendre. Le fichier config serait toujours le même, sauf pour le nom du mesh.
Tu peux en effet comencer par là , en changeant juste le nom du mesh , tu offres un vaisseau formaté en Shuttle à tes utilisateurs . Plûtot sympa déjà de voir le mesh que l'on a créé , d'appuyer sur un bouton dans ton interface , et de se retrouver avec un vaisseau pilotable dans orbiter .
Mais là où je voulais en venir , c'est que pour définir un vaisseau , nous avons besoin de constantes qui le définissent .
Regarde dans ScriptPB.cfg :
-- Vessel parameters
vprm = { -- general Parameters
emass = 500, -- empty mass [kg]
fuelmass = 750, -- propellant mass [kg]
size = 3.5, -- mean radius [m]
pmi = {x=2.28,y=2.31,z=0.79}, -- principal moments of inertia [m^2]
cs = {x=10.5,y=15.0,z=5.8}, -- cross sections [m^2]
rd = {x=0.1,y=0.1,z=0.05}, -- rotation drag coefficients
co = {x=0,y=0.8,z=0}, -- cockpit camera offset
td1 = {x=0,y=-1.5,z=2}, -- touchdown point: front
td2 = {x=-1,y=-1.5,z=-1.5}, -- touchdown point: left
td3 = {x=1,y=-1.5,z=-1.5} -- touchdown point:
Ce bloc ci-dessus est formaté .Comment faire pour rendre un tel bloc par programmation ?
Une approche :
1 Je compte les lignes du bloc vprm , j'en compte 11 .
2 Je compose mes lignes :
char* ligne1="vprm = {\n" ; // un new ligne pour respecter le format
// çà se complique un peu , il faut découper la ligne en deux pour que tu puisses y insérer une valeur
char* ligne2a="emass =";
char* ligne2b=",\n" // un new ligne pour respecter le format
Ainsi de suite ...
en fait , le type char* ne conviendra pas pour " ligne2a" , car il doit être extensible pour contenir le reste de la chaine .
utiliser char[255] ....
Supposons maintenant que tu proposes une boite de dialogue qui demande à l'useur ( :badsmile: ) la masse à vide de son vaisseau (emass), et qu'il entre 1500 .
Toi , tu le stokes sous forme numérique , genre " float emass=datafromInput ; "
Maintenant , tu dois convertir cette donnée numérique en ascii , avec la routine correspondant au type à convertir .
char buf[256];
float f=3.1415926535;
sprintf(buf,"%f",f); // sprintf(buf,"%e",f); pour l'ecriture en exposant
buf contient la valeur à insérer dans la ligne emass = "?", que tu as préformaté .
Pour construire la ligne , tu peux faire :strcat(...) (http://www.linux-kheops.com/doc/man/manfr/man-html-0.9/man3/strcat.3.html)
strcat( ligne2a,buf) ; // ligne2a contient " emass = 3.1415926535 , il manque la virgule ...
strcat( ligne2a,ligne2b) ;// ligne2a contient " emass = 3.1415926535, "
Répéter l'opération pour toutes les lignes devant être modidiées .
Certes , cela demande beaucoup de travail préparatoire , mais une fois terminé , c'est de la bombe , bébé ! 8)
Une fois tes blocs formatés , tu écris en mode texte dans un fichier tes lignes , et c'est gagné .
L'utilisation de structures pour ... structurer ton fichier pourrait simplifier le codage , par exemple :
struct BLOC1{char* ligne1,char* ligne2a,char* ligne2b,...};
Chaque bloc étant particulier . le bloc "vprm " étant l'un des + plus importants .
c'est assez dingue pour me plaire en fait , je vais pt'et bien m'y coller .
Histoire d'aider Lua à décoller dans l'esprit des orbinautes ... et faire que Martin n'aie pas cogité en vain aussi :
C'est lui qui dit :
Vessel scripts are a quick and easy way to define new vessel types in Orbiter. Unlike vessel DLL modules, they don't require the compilation of a C++ file, but just a text file containing the script.
et encore :
You can try this vessel class in Orbiter. Launch Orbiter, open the scenario editor, and click "New" to create a new vessel. You should see your new vessel class in the list. It isn't very useful yet as it stands (for starters, it doesn't have any engines), but you can complete it by adding more parameters and functions, and see the effect directly in Orbiter. You can even edit the script file while Orbiter is running. Any subsequently created instance of the vessel class will immediately incorporate the latest changes
et voilà à quoi ressemble le scriptPB.cfg d'exemple :
(http://i1006.photobucket.com/albums/af186/MrSpock_photo/Capture-1-81.png)
A+
Edith : Ton idée de modeleur est interessante aussi , car tu utilises le format d'orbiter pour visualiser les meshs .
Donc , plus besoin d'exporter via un script pour être compatible . çà me parait être une bonne idée en effet .
Par contre , tu t'exposes à un copyright concernant les meshs que tu vas utiliser pour les modifier , non ?
Message modifié ( 30-12-2010 18:09 )
-
Salut , encore moi !
'serais pas long cette fois :
http://www.youtube.com/watch?v=4zhsKu2sQ6c
-
Excellente idée ! Un constructeur de vaisseau simple ! Je ferai ça un jour. Mais là... je crois avoir trouvé un projet. Je ne sais pas si je vais le faire, car c'est du lourd. En tout cas, j'utiliserai la nouvelle API d'Orbiter. J'ai hâte de voir ça les fameux panels...
Tiens, qu'est-ce que ce vaisseau ? Oups ! Ai-je révelé quelque chose... :badsmile:
(http://i1029.photobucket.com/albums/y355/BibiUncle/mercury_capsule_4_of_5.jpg)
Et j'ai Sentinel aussi à finir. J'ai du boulot en masse !
Message modifié ( 30-12-2010 22:56 )
-
VU !
Mettre un terme au maitre .
mwah ah ah ...
Message modifié ( 30-12-2010 23:04 )
-
Le maître ?
-
Thermomètre ... mercure ...
ouais , je charrie ( charade )un peu .
Message modifié ( 30-12-2010 23:34 )
-
:lol:
Moi qui cherchait "bah, c'est qui le maître ? Yoda ? Big Brother ?"
J'ai choisi Mercury car le vaisseau est vrai (ah oui ? :badsmile: ), il n'est pas trop compliqué (à comparé à Apollo et même Gemini) et que la dernière version est vieille.
Je galère un peu sur le modèle 3D. Les modèles du Project Mercury 5.0 sont très beaux, mais loin d'être optimisés. Chaque carré forme un groupe. Ça fait 295 groupes ! Les modèles dispo sur le site de la NASA ne sont pas super et j'ai bien essayé, mais je ne suis pas capable de les faire. J'ai la forme de base, mais lorsque j'arrive pour ajouter les petits RCS, je ne sais plus comment m'y prendre.
-
Purée c'est génial MrSpock ta vidéo !
Avec direct l'ambiance du vaisseau Enterprise de la série 1 !
Vraiment très beau ces sons. Inoubliables !
j'ai même pas fini de regarder, je lis même pas les réponses que déjà je post rapport à ton choix de la bande son.
Bon GAD elmaley sur la 6, après je reviens
-
je galère un peu sur le modèle 3D. Les modèles du Project Mercury 5.0 sont très beaux, mais loin d'être optimisés. Chaque carré forme un groupe. Ça fait 295 groupes ! Les modèles dispo sur le site de la NASA ne sont pas super et j'ai bien essayé, mais je ne suis pas capable de les faire. J'ai la forme de base, mais lorsque j'arrive pour ajouter les petits RCS, je ne sais plus comment m'y prendre.
Ton nouveau projet à l'air vraiment super .
Bah , tu vas t'en sortir , comme d'hab ...
Mais 295 groupes ...:
- un groupe , c'est un polygone non ?
- ben oui idiot il te dit que c'est un carré !
-Ah ... ouais ... ok . Ben 295 , ce n'est pas énorme !
- On voit bien que c'est pas toi qui les trie ...
-
Et bien, la coque est séparé en chaque carré. Le reste est séparé correctement. Par contre, beaucoup de vertex sont gaspillées.
J'hésite toujours pour le mesh que je vais utiliser...
-
Et bien, la coque est séparé en chaque carré. Le reste est séparé correctement.
Qu'entends-tu par " correctement " ? Triangle ?
A ce moment là , il faut soit entrer dans chaque groupe ( qui j'espère sont indexés ) , et reconstituer les triangles dans
ta liste de vertex . La difficulté étant de trouver l'ordre et le sens ( right or left handed ) de création des triangles qui forment tes carrés.
Sinon , les normales pointeront vers l'intérieur du modèle ( mais çà tu le sais déjà ) .
çà m'intéresserait de voir à quoi çà ressemble dans un listing ....
-
Une image vaut mille mots.
Voilà la coque. Chaque truc rose est un groupe. En voilà un seul :
(http://i1029.photobucket.com/albums/y355/BibiUncle/A-1.jpg)
Par contre, d'autres endroits sont regroupés de façon intelligente, comme le bouclier :
(http://i1029.photobucket.com/albums/y355/BibiUncle/B.jpg)
Et par gaspille de vertices, regarde ça. J'ai join tout les groupes pour montrer les vertices.
(http://i1029.photobucket.com/albums/y355/BibiUncle/C.jpg)
Quand on regarde dans Orbiter, plusieurs parties ne sont même pas visible, comme les espèces d'anneaux qui tiennent la coque.
-
Au niveau de Blender , tu peux modifier la structure du mesh en détail , via plusieurs commandes :
_ D'abord , du nettoyage : enlever les doubles ( vertex qui partagent les mêmes coordonnées) .
En mode Edit , sélectionne tout en mode vertice, va dans mesh->vertices->remove double .
Selon les modèles , le résultat peut être surprenant .
_ Ensuite , tu peux changer la définition des faces ( créées par 4 points ou 3 ... ) en utilisant Mesh->Faces->ConvertQuadTotriangles ou triangles to quad . Et tu peux définir les faces à transformer en les selectionnant .
Tu as au moins ce moyen de controle .
En espérant que cela te soit utile dans ce cas .
A+