petite idée de zoom

[Profil supprimé]

Voici une idée qui me trotte dans la tête dpeuis un moment. Ceci est vraimetn réservé aux programmeurs confirmés.

Je me demandais s'il était possible de créer un module permettant de zoomer. Là je ne pense pas au FOV qui est très
limité. Je pensais plus un truc du genre CAMERA MFD mais avec une vue zoom de type télescope sur l'écran.

Observer la lune, Mars ou tout autre astre depuis l'orbite terrestre doit être génial. Ou meme observer la terre de
près comme un sat espion. Cela irait bien avec Hubble en plus.
Bon le pointage serait délicat et surtout le verrouillage de la cible.
Croyez vous que cela soit réalisable pour Orbiter ?

[DanSteph]

En utilisant le même truc que camera MFD à savoir ouvrir une deuxieme surface
de rendering directx oui (mais pas évident) sinon non pour une raison simple,
quand tu est loin les objets "n'existent pas" dans Orbiter il ne sont que
mathematique, quand on s'approche seulement il s'affichent.

Dan

[Schimz]

Je crois que justement, pendant un changement de FOV, l'affichage d'un objet change. Ce doit pas être la distance qui est
prise en compte mais la taille apparente.

(à vérifier)



Message modifié ( 17-03-2007 16:59 )

[Jim Lovell]

Même si tu y arrivais, le résultat serait affreux...

En effet, observe la lune depuis une orbite terrestre basse. Tu verras qu'elle est très "carrée", j'exagère, mais que
ses contours sont très marqués.

En fait, plus on est éloigné d'un astre ou d'un objet, plus Orbiter lui attribue un niveau de détails faible. Dans ce cas-
ci, la lune doit être en mode 4 voire 5, sur l'échelle des résolutions des textures (max 10). Parfois, lors de très
lointains vols, la texture de la planète ou de l'objet est simplement désactivée.

[edit] ça rejoint un peu le post de Dan..

Alors imagine que tu veuilles faire un zoom sur cette "boule carrée", je te laisse imaginer la chose..

Maintenant, j'ai cru comprendre à un moment que certains programmeurs de NASSP implémentaient un téléscope
dans le cockpit d'Apollo, mais je n'en suis pas sûr, et je pense que d'autres personnes, comme Coussini, pourront
mieux répondre à ma place...



Message modifié ( 17-03-2007 17:17 )

[Profil supprimé]

Ok pour ces précisions. Mais vu qu'au chargement on voit qu'Orbiter charge toutes les planètes j'ai du mal à croire
que les planètes n'existe pas quand on est en orbite terrestre.

Pour les astres carrés je suis surpris. Mais si on arrive à faire croire au programme qu'on est pas loin mais proche
peut être que nous pourrions l'avoir ronde.

[DanSteph]

Mustard a écrit:
Ok pour ces précisions. Mais vu qu'au chargement on voit qu'Orbiter charge toutes les planètes j'ai du mal à croire
que les planètes n'existe pas quand on est en orbite terrestre.

Elles existent mathématiquement mais c'est une question d'optimisation de ne pas les afficher...
On ne fait pas mouliner le proc pour afficher des trucs qui ne seront pas vu, première rêgle
d'un moteur 3d. Quand tu t'éloigne le LOD (level of detail) change, donc le nombre de poly
diminue passant de quelques dizaines de milliers à quelques milliers puis une centaine et 2
(le carré) ensuite l'affichage est simplement désactivé.

Ca marche pareil pour les vaisseaux on peut d'ailleurs controller l'albedo du dernier petit carré
qui est blanc par defaut... (éloigne toi progressivement juste avant de disparaitre un carré blanc
apparait, on peut en regler la couleur dans Orbiter)

C'est plus que du cosmétique, une question de survie pour les simu, à 100'000 poly la planêtes
détaillée x 8 + sattelites +vessels = soirée diapo chez Orbiter. (c'est peut être même plus que
100'000 en Orbite basse à cause de la courbure)

Donc un moteur 3d (qui garde forcement une hiérarchie des objets) teste en tout premier
la distance à la caméra ce qui ne prend que quelques cycle processeur et rêgle le LOD
en fonction ou élimine les objets trop loin.

Camera MFD lui ouvre carrement une deuxième surface de rendering directx (caméra)
et traite la scene séparément.

Dan



Message modifié ( 18-03-2007 07:44 )

[Profil supprimé]

Ok, mais je ne comprend toujours pas pourquoi au lancement Orbiter charge toutes les textures et mesh des
planètes du systeme solaire. C'est du chargement inutile.
bon enfin, tant pis pour le "zoom", c'était une idée qui me passait par la tête mais si ce n'est pas possible alors tant
pis. Merci pour vos réponses éclairées.

[no matter]

Ok, mais je ne comprend toujours pas pourquoi au lancement Orbiter charge toutes les textures et mesh des
planètes du systeme solaire. C'est du chargement inutile.

C'est utile:
lorsqu' Orbiter aura besoin d'une texture par exemple, il n'y aura pas de temps de chargement en contrepartie, elle
sera déjà là en mémoire. Il y a le rendu et le chargement des textures & meshes devant être rendus. Si le rendu
n'impose absolument pas de rendre ce qu'on ne voit pas, les textures et meshes sont chargés afin que le rendu ne
soit pas perturbé par un temps de chargement qui dégraderait à coups sûr le FPS et se ressentirait dans la simulation.

Le FPS, tu sais comment çà marche et tu sais aussi que si il chute trop, la simu est compromise, y compris dans le
calcul d'un MFD. Dès lors tout moyen d'éviter un chargement pendant le vol est requis! Regardes la transition au largage d'un vaisseau par une fusée Multistage, rien qu'un simple vaisseau à charger fait marquer un petit temps d'arrêt à Orbiter alors imagines lorqu'il faudrait charger Saturne et Jupiter et les lunes.



Message modifié ( 18-03-2007 11:56 )

[Jim Lovell]

Voici un screen de l'avancement du téléscope de NASSP, pour info....




Comme tu le vois, en haut à droite du curseur, c'est une planète

[Profil supprimé]

Je comprend qu'on charge les textures de la planètes et des lunes où l'on se trouve mais pourquoi charger les
textures de Jupiter, Saturne etc alors qu'on est sur Terre ? pourquoi ne pas faire ce chargement quand on arrive à
moins de 10 millions de km par exemple ?
Un chargement durant une phase de décollage ou d'atterrisage oui c'est gênant mais pas durant un vol de transit
interplanétaire. Et entre nous, je trouve que déja en orbite terreste j'ai pas mal de blocage de 3 à 4sec, probalement
des chargement des textures level10 du sol.

Si la mémoire était chargé de toutes les textures de la planète orbité plutot que des planètes lointaines ce serait
mieux ... non ?



Message modifié ( 18-03-2007 14:47 )

[Schimz]

tu n'aurais pas les bases de Kulsh installées. Elles provoquent des mini freezes à chaque orbite.
En tout cas, avec 256Mo de mémoire vidéo et juste avec la Terre en L10 et Jupiter en 8 ça tourne trés bien à *100k en orbite
terretre basse.

[DanSteph]

Mustard a écrit:
Je comprend qu'on charge les textures de la planètes et des lunes où l'on se trouve mais pourquoi charger les
textures de Jupiter, Saturne etc alors qu'on est sur Terre ?

N'oublie pas qu'on peut switcher avec la caméra instantanement pour voir une autre planête
du coup la il y aurait 2-5 secondes d'arret pour charger les textures, pas très cool.

Néanmoins je trouve qu'effectivement ce comportement pourrait être sujet à option.
"charger textures des planetes lointaine en dessous de cette distance: nnnnn"
Ou alors carrement le nom des planête à précharger à cocher, ou un parametre
dans les cfg "PRELOADPANETE earth jupiter mars" etc etc.... (par absence= ALL)

En effet Martin à une vision plus "celestienne" de son simu que nous j'ai l'impression, il pense que les gens
vont s'en servir pour ce ballader avec la caméra pour voir le systeme solaire. Ceci peut être vrai pour les
premiers lancement mais en général pas pour une session normale ou on reste assez en local voir un simple
voyage entre deux planêtes.

Pour un gars qui vol exclusivement avec la navette en LEO ca veut dire que pour 500 lancement d'orbiter
il va charger 500 fois toutes les textures qui ne lui serviront pas, pas super top...

On pourrais tripoter les fichiers config ou les tex pour réduire les textures qui ne nous servent pas
et raccourcir le temps de chargement mais c'est galêre si ont veux changer à un moment.

Mais la plupart des ordi chargent Orbiter en un temps assez court, cette complexification en
voudrait elle vraiment la peine ?

A++

Dan



Message modifié ( 18-03-2007 17:04 )

[no matter]

On pourrais tripoter les fichiers config ou les tex pour réduire les textures qui ne nous servent pas
et raccourcir le temps de chargement mais c'est galêre si ont veux changer à un moment.

Il suffit de se faire un système solaire particulier (sol_light.cfg sur le modèle du fichier sol.cfg) et de n'y mettre que le
Soleil, la Terre et la Lune par exemple si on ne reste qu'en orbite basse.
Celà implique ensuite de changer la ligne "System Sol" par "System Sol_light" dans les scénarios impliqué (avec
Crimson editor ou UltraEdit-32 par exemple, histoire de pouvoir modifier tous les scénarios en 1 seul clic.
Çà vaut le coup pour un vieux PC.


Pour les bases qui ralentissent orbiter pour se charger même en orbite, on peut réduire le paramètre OBJECT SIZE ou
même SIZE. OBJECTSIZE est par défaut à 100 si il n'est pas précisé. Çà réduira l'altitude à partir de laquelle la base
est visible et se charge.



Message modifié ( 18-03-2007 20:18 )

[DanSteph]

no matter a écrit:
Il suffit de se faire un système solaire particulier (sol_light.cfg sur le modèle du fichier sol.cfg) et de n'y mettre que le
Soleil, la Terre et la Lune par exemple si on ne reste qu'en orbite basse.
.

Intteressant faut que j'essaie... surtout pour voir les "sides effects" (plantée si scn sans planete dans sol ?)

no matter a écrit:
histoire de pouvoir modifier tous les scénarios en 1 seul clic. Çà vaut le coup pour un vieux PC.

Mhhh ce serait pas plus simple deux bat qui renomme le cfg qu'on veux en sol.cfg ? mhhh ?
un seul fichier à editer et pas de risque de foirer un scn...

Dan

[DanSteph]

Vient de tester, ca marche et effectivement le lancement d'orbiter est plus rapide...
J'ai laissé mars et satelittes...

sol.cfg LIGHT -----------------------------------------------------------------------------------
; === Configuration file for solar system ===
Name = Sol

Star1 = Sun
Planet1 = Earth
Earth:Moon1 = Moon
Planet2 = Mars
Mars:Moon1 = Phobos
Mars:Moon2 = Deimos
------------------------------------------------------------------------------------------------------

Suffit de créer deux fichiers un complet "sol_all.cfg" et soll_light.cfg" et de faire deux *.bat
qui vont simplement renommer le full ou le light en sol.cfg pour switcher...

Très bonne idée no matter la modif du sol.cfg, quand on lance 500 fois pour tester un
addon au même endroit le temps gagné est bon à prendre.

Dan



Message modifié ( 19-03-2007 02:25 )

[Pagir]

Quelqu'un pourrait faire un p'tit truc avec ça, genre, .bat exécutable, et le rendre disponible, mmmhhh????

Pagir

[no matter]

Très bonne idée no matter la modif du sol.cfg, quand on lance 500 fois pour tester un
addon au même endroit le temps gagné est bon à prendre.

C'est justement pour çà que j'utilise cette manip.

Suffit de créer deux fichiers un complet "sol_all.cfg" et soll_light.cfg" et de faire deux *.bat
qui vont simplement renommer le full ou le light en sol.cfg pour switcher...

8)

[no matter]

Pagir a écrit:
Quelqu'un pourrait faire un p'tit truc avec ça, genre, .bat exécutable, et le rendre disponible, mmmhhh????

Ouaip! http://www.woofiles.com/dl-6682-SjHLXJTs-Fulllight.rar / Décompresses à la racine d'Orbiter.
Çà lance Orbiter dans la foulée.
Le mieux c'est que tu ouvres les 2 .bat avec notepad tu pourras changer les fichiers ou même les bat d'emplacement
en modifiant.

N'oublies pas que certains scénarios peuvent avoir un DG posé inutilement à l'autre bout du système solaire, si tu les lances avec la version light, CTD!!



Message modifié ( 19-03-2007 08:43 )