Reprise du message précédent :
ils ont voulu breveter le double-clic aussi je crois

Ce serait pas du au fait qu'en opengl c'est 1024x768 et dx9 800x600 ?

 
bon ok chuis noob mais pas à ce point    nan j'ai mis 1024 partout, vsync off etc...
Pis y aurait pas une telle difference.

Ok, j'ai testé 2 minutes et je pensais qu'on pouvait pas modifier les options

Vous connaissez ça : http://mrl.nyu.edu/~perlin/demox/Planet.html
 
C'est assez impressionnant il n'y a pas à dire !
 
PS : c'est un applet java

 
pas mal du tout
C'est vrai que les fractales c utile parfois mais lent

J'ai corrigé mon 2è post (document game design) et ajouté un petit paragraphe au niveau du gameplay: un tutorial me semble indispensable!
 
J'ai ajouté un nouveau draft, plus proche de mon modèle de document d'analyse, que je transformerai à nouveau lorsque j'aurai trouvé un document de game design qui convient.
 
A ce sujet, j'aimerais que ceux qui veulent participer au projet jettent un oeil au lien sur ces document dans le premier post, et me donnent leur avis sur la structure à adopter, afin que le document soit aussi clair que possible pour tout le monde, c'est dans votre intérêt en premier lieu

Eh bien je sais pas ce qu'en pensent les autres, mais la structure du doc d'analyse m'a l'air tout a fait acceptable.
 
Peut être regrouper par genre quand l'étude sera plus poussée, genre : interface, IA, géneration de l'univers, etc...

Merci
 
La structure globale est celle mes cours de graduat (analyse en cascade comme ils disent)

Tiens, tiens, un topic sur Elite. Je vois qu'un lien vers mon site a même été mentionné
 
Evidemment ce que je vais dire dépend beaucoup de ce que vous voulez faire, mais même en mettant la qualité des graphismes de côté, il y a un point que vous ne devez pas négliger si vous voulez quelque chose d'à peu près réaliste, c'est que votre moteur doit gérer les données en nombres flottants 64 bits au minimum. Ce qui exclue Ogre, Irrlicht et la plupart des autres moteurs 3D, a moins que vous ne soyez prêts à les modifier en profondeur - dans ce cas, bon courage.
 
Question stupide: pourquoi croyez vous que les distances entre les planètes, et la taille des planètes, sont de l'ordre de quelques kilomètres dans les jeux spatiaux style "Freelancer" ? Designers incompétants ? Ou restriction technique ?
 
Considérez l'échelle necessaire pour représenter la position d'un objet dans un système solaire (je ne parle même pas de la galaxie en entier). Le kilomètre ? Dans ce cas en 32 bits, la distance Terre-Soleil serait de l'ordre de 150 millions de km. La précision d'un nombre flottant décroit avec les grandes valeurs: a cette distance "réaliste", vous n'allez pas être capables de gérer de faibles vitesses (ie. de l'ordre de quelques milliers de km/h).
 
Mettons que vous choisissez l'UA (distance Terre-Soleil) comme unité. Dans ce cas la distance Terre-Soleil = 1; mais les faibles vitesse deviennent des nombres petits, très petits (ex.: 0.000001), en fait trop petits pour être représentés dans des floattants 32 bits la aussi.
 
Solution: passer en 64 bits (qui "réduit" le problème, mais ne le fait pas disparaitre complètement); ou utiliser du 32 bits avec des dimensions et des vitesses irréalistes.
 
Bref c'est à vous de voir, mais je crois qu'il s'agit d'un point essentiel à considérer pour le choix de moteur 3D.

oui c'est la question que je me posait aussi
 
on pourrait choisir l'UA pour le grandes distances et le km pour les petites non?
 
Et passer de l'UA au km lorsqu'une grande distance passe en dessous d'un certain seuil?  ( et vice-versa )

 
Ce que je regrette, c'est que vous n'ayiez pas mis les specs de la machine sur laquelle ont été faites les vidéos ...

P4 2 Ghz, 1 Gb RAM et Radeon 9700 (non Pro). Ca tourne entre 50 et 100 fps au niveau du sol, > 200 fps au niveau de la planète.
 
Cela dit je continue de développer mon moteur, et je recherche plus la qualité que la performance. 30 fps avec un incroyable niveau de détails, même si cela nécessite une machine de la mort, cela me conviendrait plus que 200 fps avec des vertex colors (ala Frontier). Même si j'essaie de faire quelque chose qui puisse s'adapter aux plus petites configs.

 
il y a deux choses:
1) le modèle de positionnement interne
2) le rendu
 
pour le rendu, dans freelancer, les distances sont bidonnées pour faire rentrer les planètes dans le zbuffer.
 
y'a moyen de faire mieux (et j'y travailles). ça consitera en construisant la scène en plusieures étapes.  
 
ie pour l'instant je fais un rendu avec le frustum sur 10/20km de champ de vision, et les planètes sont traçées hors-frustum, avec leur propre plan proche/lointain de frustum, z-buffer désactivé. le stencil pourvant servir ultérieurement à réduire l'overdraw.
 
pour le modèle de positionnement interne, au niveau des planètes, effectivement il faut un modèle stable (pour l'instant je suis resté sur un modèle style axe d'orbite+rayon d'orbite+vitesse angulaire d'orbite + axe de rotation+vitesse angulaire de rotation).

En ce qui concerne vitesses/distances, j'ai une idée plus précise de la question: Star Trek
Ils indiquent les distances en années-lumières ou en kilomètres selon la proximité, tout simplement. Je n'ai jamais vu de référence au parsec par exemple, ou à une unité inventée spécifiquement pour un tel usage.
 
Dans mon document, je me réfère à 3 modes de propulsion (toujours Star Trek ):

• rétrofusées: en fait, je ne connais pas la vitesse maximale, j'ai fixé arbitrairement à 100.000 km/h, sachant que les navettes spatiales américaines actuelles vont jusqu'à 27.700 km/h environ en vitesse d'orbite;
• propulsion par impulsion: l'impulsion pleine correspond à la vitesse de la lumière (enfin c'est ce que j'en déduis ). Référence ici. Malheureusement, ils ne disent pas quelle est la vitesse maximale
• propulsion par distorsion: vitesses supraluminiques. Une référence des vitesses exprimées se trouve d'ailleurs ici  Vous verrez d'ailleurs que la vitesse augmente exponentiellement à mesure qu'on augmente le facteur distorsion (warp).

 
En physique Newtonienne ( on va eviter la physique relativiste svp ) il n'y a pas de vitesse maximale dans l'espace : tant que tu peux accelerer, tu peux aller plus vite. La seule limitation vient donc de plusieurs autres facteurs :
- quantité de carburant. Quand tu n'as plus de carburant, tu ne peux plus accelerer
- acceleration fournie par les moteurs en tenant compte de la distance à parcourir : en effet, il faut penser à prendre le temps de freiner. En gros, tu accelère constament et tu commence à ralentir à mis parcours. La vitesse max est donc ici la vitesse à mis parcours.

de retour de l'hosto (temporairement)
bon, j'ai décortiqué les drafts de Drasche pendant que les infirmières me piquaient le cul, et j'ai testé Squirrel, toujours à l'hosto !
le Drasche de draft est très complet, et me semble proche de ce qu'on aimerait obtenir, du bon boulot.
par contre, j'ai juste une question à propos de Squirrel, et des langages de script en général : que va t'on coder en script, et en quoi celà sera t'il plus pratique qu'en C++ ?

A mon avis, ton raisonnement ne marche au minimum que pour les rétrofusées (techno up to date s'il en est ).
 
Je ne connais pas les détails de la techno de moteur à impulsion, mais au niveau warp, c'est la création d'un champ warp autour du vaisseau, et le vaisseau ne se propulse pas: il est transporté par la bulle, ce qui explique qu'il peut accélérer très rapidement (la notion d'accélération reste, quoi qu'il en soit). Et quand un capitaine donne un ordre "arrêt complet", il est exécuté en quelques secondes.
 
Quant à la limite à Warp 9.9999, bof, les autres jeux (ni certains épisodes d'ailleurs) ne s'embarrassent de cette limite

Pleins de trucs. En gros, tout ce qui ne touche pas au moteur 3D

Mais je ne parlais pas de ce cas. Je parlais du cas moteur normal.
 
Et puis, qui a besoin de retro fusées quand il suffit de retourner son vaisseau pour ralentir avec toute la force des moteurs principaux

puisque tu le soulignes, tu n'oublieras pas de me faire part de ce qui manque

Pourquoi plusieurs types de propulsion?
Un seul ca suffit non ^^ propulsion avant/arriere
 
Dans elite2 tu avait 2 moyens de maneuvrer :  
- en total manuel, tu utilise propulsion avant ou arriere
- ou tu choisit la vitesse désirée, et le cap sera mis sur l'angle actuel du vaisseau ( je sais pas si suis clair la ^^ mais ceux qui ont joué à elite2 doivent s'en souvenir )

On aura besoin d'un autre mode de propultion a une vitesse superieure à la lumière en mode multi car on ne peux pas mettre de timescale et on ne peux pas demander a nos joueurs de passer 3 mois à faire le voyage terre jupiter

 
Oui, mais il ne s'agit que de l'affichage sur le HUD (ie. l'interface graphique). Pour ton moteur de physique, en interne, qu'est-ce que tu vas utiliser ? Car tu ne peux pas mélanger différentes unités.
 
Le problème des nombres flottants est réel (sans jeu de mot):
 
1. Avec une échelle de l'ordre du kilomètre, un objet situé à 150 millions de kilomètres du Soleil, qui se déplace à une vitesse de 1 KM seconde (3600 KM/H), restera immobile, car en nombre flottants 32 bits, 150000000.0f + 1.0f == 150000000.0f.
 
2. Avec une échelle de l'ordre de l'UA, de l'AL ou du parsec, les choses sont encore pires. Les positions peuvent être représentées correctement, mais les petites vitesses deviennent nulles. Pour reprendre mon exemple du dessus, l'objet sera situé à 1.0f UA, mais sa vitesse (pour être cohérent) sera de 0.000000007 UAs/s. Or en flottants 32 bits, 1.0f + 0.000000007 == 1.0f. L'objet reste donc immobile la aussi.
 
Quelle que soit l'échelle utilisée, les nombres 32 bits ne sont donc pas suffisants pour gérer des dimensions réalistes => vous allez avoir le même problème que Freelancer.

 
effectivement c'est indispensable.
mais c'est dommage ca tue un peu l'interet du jeu vu que le temps est important pour les missions style "apporter ce colis à Barnard Star avant le 15/05/3201" ^^  
 
Faudrait le mettre que en multi alors

et bien tu passes par un vecteur de position intermédiaire auquel on additionne le vecteur vitesse, et puis quand l'ordre de grandeur est assez grand, tu l'ajoutes au vecteur de position final.
 
enfin fo gruger, ou utiliser un système de référentiel temporaire créé dynamiquement. (un référentiel pour chaque base, et des référentiels crées dynamiquement quand deux vaisseaux sont proches, pour que les calculs de collisions ne souffrent pas du manque de précision).
 
ou une hiéarchie de float: un premier pour la position en UA du vaisseau, puis un autre comme offset en m/km.

sachant que si tu veux tester une collision, comparer la position en UA avec un tout petit delta permettera de rejetter  la collision.

 
Exactement, et c'est le point sur lequel j'essayais d'attirer votre attention. Vous allez surement devoir "gruger", reste à voir si ca va être facile ou difficile de gruger sur le moteur 3D que vous choisirez, comme Ogre ou Nebula.
 
Quand a la hiérarchie de floats, c'est un peu ce qu'est un "double" (flottant 64 bits) comparé à 2 flottants, non ? Alors autant vous simplifier la vie et utiliser des double partout. Je crois que c'est ce que fait Celestia, et donc à mon avis c'est Celestia qui est le plus adapté au projet que vous essayez de faire.

En gros tu crée ta propre norme de flottant 64bits en combinant des flottants 32bits.

réalisme l'essence même de la bulle warp est de te faire voyager beaucoup plus vite que la lumière  Et toujours pour le réalisme, une fusée ne te propulse pas à la vitesse de la lumière
Regarde la navette spatiale, elle-même dispose de différents types de moteurs pour exécuter une mission:  
1) les moteurs principaux + les 2 fusées d'appoint pour s'arracher à l'attraction terrestre;  
2) 2 moteurs d'appoint pour la propulsion dans l'espace + sans doute les rentrées en atmosphère;
3) des dizaines de moteurs pour effectuer les manoeuvres.

tu peux très bien utiliser une hiérarchie de double.
 
et je pense pas que tu ayes le même comportemet avec un double en m/km, qu'avec deux float avec un en UA et l'autre en m/km.  
 
je suppose le nombre de bits que tu gagnes dans la mantisse an passant du float au double ne compense une telle explosion de l'ordre de grandeur.
 

 
oui il faudra simuler des asservissements au niveau des propulseurs pour les rotations.
 
bref, si tu veux faire quelque chose de réaliste, il faudra aimer les simulateur de vol.

tient ca me fait penser (sisi ), il faudrait peu etre prevoir  un jeu dans le jeu pour ceux n'aimant pas voler (en multi), comme vendeur dans les station spaciale, ou mecano ou je ne sais quoi

déjà qu'on veut les atterrissages en temps réel sur les planètes (et je suis pour), il faut ce qu'il faut
et j'ai vu des vaisseaux atterrir dans Star Trek, ça n'a pas l'air trop compliqué même si le pilote n'était pas rassuré lui-même
 
Perso je suis assez pour une double hiérarchie aussi.  Tiens, avec les CPU 64 bits qui s'installent, ya pas des floats 128 bits par hasard?

La double hierarchie ça ne sert à rien. Cela ne fait que nous compliquer grandement la tache sans jamais gagner plus de precision que les doubles nous permettent et cela va complexifié les calculs à un point qu'il est difficile d'imaginer.

 
ben deja dans elite2 c'etait pas evident, alors la j'ose meme pas imaginer

ah mais je veux pas que ça soit plus compliqué hein (d'autre part, n'ayant pas moi-même joué à Elite, je n'ai pas idée de la difficulté )
 
bon, ok ça va, je vais y jouer

 
oui & non.
 
ce qui compte c'est la localitée (je sais pas comme le dire autrement).
 
c'est comme l'approche avec des référentiels temporaire ou permanents (pour les objets statiques).
 
par exemple quand tu est à coté d'une base, le référentiel c'est celui de la base, pas l'absolu ou l'étoile du système solaire courant.
 
quand tu fais des requêtes de collisions, ou des tests de visibilitée/trajectoire pour l'IA, tu la fais dans la localitée courante.
 
alors que même si tu est en double, je suis pas convaincu de la stablitée des calculs si tu utilises des doubles mais en coodonnée plus ou moins absolue.
 
(je parle dans les structures/classes, puisque au niveau des calculs au niveau CPU ont peut profiter d'une plus grande précision temporaire).
 
donc bref, quand je veux dire hiéarchie, c'est pas hiéarchie dans la classe des vaiseaux/stations, bref des bidules spaciaux, c'est un système de référentiels.
 
de toutes manières tous les moteurs 3D partitionnent le monde, donc là c'est un peu ce que je veux dire.

 
tu devrais vraiment, oui ^^
 
je me ferai bien une ptit partie la lol, un ptit combat contre des dizaines de vaisseau de police, c'etait bien marrant ca ^^

Je comprends ce que tu veux dire mais un problème c'est qu'il n'y a pas forcement assez de points de references dans un système solaire pour faire tes calculs. Bien souvent, la masse la plus significative pour un vaiseau sera le soleil local, que le vaisseau soit entre la terre et venus ou entre uranus et pluton. Il faudra donc bien avoir la precision suffisante plus placer un point dans le système solaire avec comme base le soleil.

Partitionner la galaxie en secteurs (/systemes solaires) est, de toute facon necessaire, car meme les flottants 64 bits ne sont plus suffisants.
 
Au niveau d'un systeme solaire, on doit pouvoir se contenter de 64 bits. Je viens de faire un petit test, on peut avoir une précision de +- 1 millimètre à 100 UA (unités astronomiques = 100 fois la distance Soleil-Terre = taille du plus grand système dans Frontier, Proxima du Centaure si je me rappelle bien).