D3D9 compatibilità addon

Questi giorni ho messo il nuovo client grafico D3D9 che sfrutta le directX9. Oltre che un gran miglioramento nella fluidità del simulatore, migliora notevolmente anche la percezione grafica dato che sfrutta i filtri e l'AA.
Veramente ottimo, consiglio di provarlo...
Dato che sto provando una marea di addon per vedere la compatibilità, ho deciso di aprire questo topic per segnalare gli addon pienamente funzionanti (ovviamente i principali).
La versione attuale è la D3D9ClientRC44 del 11/03/2012.
Comincio dagli addon FOI:
- CapoPassero pienamente funzionante (meravigliosa di notte)
- Eridanus ed Atares pienamente funzionanti, ma:
- Quasar e Jarvis mandano in crash, non compatibili
- Gli addon base (DG-Atlantis) sono compatibili
- Ummu e Ucgo funzionanti
- Sound funzionante
- MFD tutti funzionanti (i principali)
- Shuttle Fleet 4.8 compatibile
- Buran (SF) funzionante, ma non funziona il vettore (Energia)
- Skylab (SF) funzionante
- ISS e MIR nelle versioni UCGO sono compatibili
- Navi serie XR pienamente compatibili
- DGIV non funzionante (ma presto verrà aggiornato)
- Texture pianeti di quasiasi livello sono compatibili
- KSC HIres (versione ufficiale) compatibile
- Diverse basi tipo Wideawake sono compatibili ma:
- Ci sono problemi con le mesh delle montagne, tipo il cratere di Brighton Beach, è funzionante ma viene visualizzato male (risolto).
- Brighton Beach 2011 funzionante ma brutta visualizzazione mesh cratere (risolto).
- Basi Titan ed Europa funzionanti
- Base Olympus enhancement funzionante, ma stesso problema di visualizzazione con il Monte Olympus (risolto)
- Velcro Rocket compatibile

Questi sono gli addon che ho provato, cercherò man mano di tenere aggiornato il post in base alle prove.

Mir ha scritto:

...
- Quasar e Jarvis mandano in crash, non compatibili
...

Perché funzionano con i moduli Vinka, che non sono compatibili.

AMSO dovrebbe (dico, dovrebbe non ho provato ancora) essere compatibile.

Mir ha scritto:

...
- Brighton Beach 2011 funzionante ma brutta visualizzazione mesh cratere.
...

Bravo Mir! Ottima idea questa lista.

In questo mio post ho segnalato a jarmonik la situazione di BrightonBeach2011, e lui, dopo qualche risposta, mi ha dato la soluzione, sottoforma di file cfg!

Pete Conrad ha scritto:

...Perché funzionano con i moduli Vinka, che non sono compatibili...

Su questo post di OF (sviluppo D3D9) c'è una soluzione riguardante Spacecraft3.dll.

Pete Conrad ha scritto:

...AMSO dovrebbe (dico, dovrebbe non ho provato ancora) essere compatibile...

Per AMSO, Jarmonik stesso dice:
Orbiter/D3D9Client is tested to be OK with:
- NASSP, SSU, AMSO...

Inoltre qui dice di aver lavorato insieme ad Alain (ACSoft) per schiacciare un po' di bug che c'erano.

Grande funziona benissimo
Cerco di capire dove è l'errore e poi sistemo anche Wideawake International e Monte Olympus (hanno più o meno lo stesso problema di Brighton).
Si sa nulla riguardo a Vinka (per i nostri vettori), se c'è possibilità che venga reso compatibile?

Trovato, va aggiunta una linea denominata: UNDERSHADOWS
Nelle stringhe delle mesh all'interno del file CFG della relativa base, in seguito funziona alla perfezione.

Brighton Beach 2011:

Codice:

MESH
   FILE brcrater
   POS 0 0 -3900
   SCALE 0.35 0.35 0.50
   ROT 0
   OWNMATERIAL
   UNDERSHADOWS
END

Mons Olympus:

Codice:

MESH
    FILE olympus-mons
    POS -360000 -37000 85000
    SCALE 1 1 1
OWNMATERIAL
UNDERSHADOWS
END

Wideawake International:

Codice:

;****************************************** Topography Meshes
;mountain
MESH
    FILE AIAmsh\mountain
    POS -500 430.5 8000
    SCALE 1.2 1 1
    ROT -5
PRELOAD
OWNMATERIAL
UNDERSHADOWS
END
;crater 5
MESH
    FILE AIAmsh\crater5
    POS 1760 0 5510
    SCALE 1.2 1.6 1.2
    ROT -95
PRELOAD
OWNMATERIAL
UNDERSHADOWS
END
;crater 4
MESH
    FILE AIAmsh\crater4
    POS 3102 0 4900
    SCALE 0.6 0.6 0.7
    ROT -25
PRELOAD
OWNMATERIAL
UNDERSHADOWS
END
;crater 3
MESH
    FILE AIAmsh\crater3
    POS 152 0 3400
    SCALE 0.8 0.6 0.8
    ROT -140
PRELOAD
OWNMATERIAL
UNDERSHADOWS
END
;Hill plain
MESH
    FILE AIAmsh\hill_plain
    POS 2232 24.9 310
    SCALE 0.9 1 1.1
    ROT 135
PRELOAD
OWNMATERIAL
UNDERSHADOWS
END
;Hill 80
MESH
    FILE AIAmsh\Hill_80
    POS 1897 32.1 670
    SCALE 0.91 1 0.91
    ROT -69
PRELOAD
OWNMATERIAL
UNDERSHADOWS
END
;Hill 228
MESH
    FILE AIAmsh\Hill_228
    POS 2615 114.3 1561
    SCALE 1.09 1 1.12
    ROT 151.5
PRELOAD
OWNMATERIAL
UNDERSHADOWS
END

A me non sembra che ASVI sia pienamente funzionante, le luci non sono come dovrebbero essere, vedi strade, seconda pista di atterraggio, il SAV e le luci dei palazzi.

Ma lo fa anche a voi o solo a me?
C'è qualche problema con le texture, vedrò che posso fare per rimediare.

Secondo me, visto il successone che hanno questi nuovi client grafici in sviluppo (D3D9 e D3D11) causato principalmente dall'enorme guadagno in termini di fps, e considerando la botta di popolarità che deriverà dal nuovo DGIV-2 compatibile (a proposito ho mandato un PM a Dansteph per entrare nel betatest), sarà necessario - leggi obbligatorio - includerli nel ciclo standard di sviluppo-test-compatibilità dei nostri (vostri) add-on presenti e futuri.

Dany ha scritto:

A me non sembra che ASVI sia pienamente funzionante, le luci non sono come dovrebbero essere, vedi strade, seconda pista di atterraggio, il SAV e le luci dei palazzi.

Secondo me è solo un problema di realismo, nel senso che le luci sono visibili man mano che ci si avvicina e in base al nostro orientamento. Infatti le luci delle piste sono messe in modo da risultare meglio visibili dall'osservatore allineato.

Capopassero con la D3D9 comincia ad essere visibile a circa 100km e la pista a 50 km, con la versione normale le luci si vedevano gia quando si era sopra la Sardegna, quindi secondo me la cosa è voluta per aumentare il realismo visivo.

Ripley ha scritto:

Secondo me, visto il successone che hanno questi nuovi client grafici in sviluppo (D3D9 e D3D11) causato principalmente dall'enorme guadagno in termini di fps, e considerando la botta di popolarità che deriverà dal nuovo DGIV-2 compatibile (a proposito ho mandato un PM a Dansteph per entrare nel betatest), sarà necessario - leggi obbligatorio - includerli nel ciclo standard di sviluppo-test-compatibilità dei nostri (vostri) add-on presenti e futuri.

Concordo pienamente, il guadagno sia in prestazioni che in qualità è molto elevato, senza contare che almeno per me ha risolto molti problemi. Dal problema grafico del cargobay di Eridanus, al terribile lag che si presentava con AerobrakeMFD.
Sicuramente le versioni successive di Orbiter le baseranno su questi client

Mir ha scritto:

...Secondo me è solo un problema di realismo, nel senso che le luci sono visibili man mano che ci si avvicina e in base al nostro orientamento. Infatti le luci delle piste sono messe in modo da risultare meglio visibili dall'osservatore allineato.
...
Capopassero con la D3D9 comincia ad essere visibile a circa 100km e la pista a 50 km, con la versione normale le luci si vedevano gia quando si era sopra la Sardegna, quindi secondo me la cosa è voluta per aumentare il realismo visivo....

Si, si, hai ragione.
Nelle utime pagine del thread di sviluppo (D3D9) ci sono post su post con schemi sulle luci delle piste di atterraggio, filmati reali di atterraggi dal cockpit di aerei.





...hanno preso la cosa sul serio per rendere la situazione più realistica!
La cosa è nata vedendo come asmi stava implementando le luci nel suo client D3D11!

Si quella cosa l'ho notata anch'io, ma non è per quel motivo. Mentre con le D3D11 le luci non esistono, neanche sulla pista.

ripley ha scritto:

Secondo me, visto il successone che hanno questi nuovi client grafici in sviluppo (D3D9 e D3D11) causato principalmente dall'enorme guadagno in termini di fps, e considerando la botta di popolarità che deriverà dal nuovo DGIV-2 compatibile (a proposito ho mandato un PM a Dansteph per entrare nel betatest), sarà necessario - leggi obbligatorio - includerli nel ciclo standard di sviluppo-test-compatibilità dei nostri (vostri) add-on presenti e futuri.

Ciò significa che, o viene fatto qualcosa per rendere i nuovi client grafici compatibili con Multistage o io coi razzi vettori posso chiudere baracca, perché sarà necessario compilarli tutti con c++ E NON SARA' COSI' FACILE.

Ok, ma mica io volevo dire che Orbiter diventerà obbligatoriamente D3D9 (o superiori)...

Il core nativo è sempre D3D7, non penso proprio che Martin implementerà dentro Orbiter il client di jarmonik...proprio perchè fortunatamente l'architettura di Orbiter è modulare e uno può scegliere quale client attivare.

non è detto... si è già visto che Martin non ha sempre assicurato la retrocompatibilità con vecchi applicativi (e non potrebbe essere altrimenti)... già sono stati fatti dei bei salti mortali per mantenere i moduli Vinka usabili con Orbiter 2010... vedremo.

Ma credo (e spero) che ci sia sempre la possibilità che il D3D9 venga reso compatibile durante lo sviluppo, per errore avevo installato una vecchia versione e mi dava errori di compatibilità con tantissimi addon, ISS e MIR UCGO non funzionanavano, mentre su la versione attuale si.
Ma Vinka e il Multistage non esiste più lo sviluppo delle nuove versioni?

Non pare.

Gli aggiornamenti per renderli compatibili con O2010 sono stati realizzati da altri... anche se si diceva che l'autore stava preparando qualche novità.

Curiosità: Velcro Rockets funziona?

Andrew ha scritto:

...

Curiosità: Velcro Rockets funziona?

Apparentemente sì, ma se usato con Multistage (esempio Skylab) credo di no, non ho provato.

Funziona sia Skylab (quello di SF) che gli altri Velcro, ne ho provati un paio e funzionano (VelcroN1). Comunque cerco di provarne altri poi faccio sapere

Vinka chissà che fine ha fatto...lo stato del suo sito lascia molto a desiderare.

Comunque ripeto che sul primo post del thread D3D9 c'è un workaround per far funzionare Spacecraft3.dll.

Mir ha scritto:

Funziona sia Skylab (quello di SF) che gli altri Velcro, ne ho provati un paio e funzionano (VelcroN1). Comunque cerco di provarne altri poi faccio sapere

Veramente io parlavo di questo Skylab, e no, provato adesso, non funziona (multistage problem).

ripley ha scritto:

Vinka chissà che fine ha fatto...lo stato del suo sito lascia molto a desiderare.

Comunque ripeto che sul primo post del thread D3D9 c'è un workaround per far funzionare Spacecraft3.dll.

Sì letto, ma ogni volta fare sta manfrina ti passa la voglia ... e poi ho provato, con il mio sistema certi scenari ho più fps con il motore originale che non con d3d9etc

ragazzi ho provato tutto ma l'audio delle canzoni non parte, si può riparare?

È un bug che Dansteph ha corretto nell'ultima versione di OrbiterSound.

Partecipa anche tu al beta test (fà tanto zio Sam e: "I want you!") così avrai i file in anteprima!!

http://orbiter.dansteph.com/forum/read.php?f=2&i=15083&t=15083

Finalmente sono riuscito a rendere compatibili gli addon FOI con il client D3D9
Basta copiare il contenuto (pochi mb) della cartella: Orbiter/Config in:
Orbiter/Modules/Server/Config

Ho effettuato una missione completa con Eridanus (quindi anche Quasar) ed è stato tutto perfetto, i Vinka non hanno più dato problemi.
Nei prossimi giorni proverò anche gli altri addon e farò sapere...

neppure Multistage?

Funziona tutto regolarmente, sia Spacecraft che Multistage.
Quasar, Eridanus, Antares, Jarvis, Neptune, Verrazzano e Capo Passero...tutti perfetti. Vederli in D3D9, fluidi e nitidi è veramente bello.
L'unico piccolo problema che ho riscontrato riguarda il VC di Antares, i finestrini anteriori risultano opachi e non si vede all'esterno:

Al contrario il VC di Eridanus è perfetto e non da problemi

Mi dai un'ottima notizia!