Unterschiede im Play und fertigen Build

[Roehrensockel]

In meinem Unity Weltraum Projekt habe ich neben einer 4k Erde den Mond und um beim Anflug auf die Venus einen realen Effekt der Annährung zu bekommen die Sonne in einer höchst möglichen Entfernung platziert.
Von 0,0,0 MR Camera die Erde bei +3000 den Mond bei +9000 und die Sonne bei +97000. Unity akzeptierte keine Werte über 100000. Im Play Mode unter Unity 2019.4.17f1 ist alles in Ordnung, Mond und Sonne sind zu sehen und ich kann zu allen Gestirnen fliegen auch wenns bei der Sonne über eine halbe Std. dauert, aber das gibt einen realen Effekt. Das ganze ist mit Holo Pack 1 aufgebaut weil das MRTK2.4 zuviel leistung kostet und deutlich schlechtere Grafik Qualität bringt.
Nach dem Build kann ich das Programm starten, meine Schiffe KI fliegt, ich kann Planet Erde sehen aber Mond und Sonne sind verschwunden obwohl ich bei Camera/Clipping Planes 100000 eingestellt habe. Ein weiteres Problem ist das bei meinen Motion Controllern die Grip Button Button 4/5 für das Rollover im Input Manager belegt wurden, im Play funzt das bei der compilierten EXE nicht, das betrifft die alten Controller sowie die neuen HP Reverb g2 Controller.
Hat Jemand eine Idee was ich falsch mache, einen Screen shoot der MRCam und des Build habe ich angehängt.
Das Programm ist in der Console Fehlerfrei.

Ergänzung:

Ich habe bei der MRCamera bei der Einstellung Rendering Path die Einstellung Deffered gesetzt, nun kann ich im Build den Mond sehen und etwas seltsames, wende ich das Schiff um 90 Grad kann ich aus dem Seitenfenster mit einer Koppfdrehung von über 90 Grad in einem Bereich von 2-3 Grad die Sonne sehen ?

Ergänzung2:

Die maximale Entfernung vom Camera Null 65535 also 64k, setze ich meine Sonne unter diesen Wert ist sie in jedem Blickwinkel sichtbar, über 64k wird der Seitenwinkel in dem sie sichtbar ist immer kleiner je weiter ich sie 100000 nähere. Also werde ich meinem Schiff nur soviel Sprit gönnen das bis zur Venus komme dann fällts nicht auf.

Vielleicht hilft die Erkenntnis ja Jemand.

[chrische5]

Hallo

 

Vielleicht hilft die das:

http://blog.13pixels.de/2019/things-that-can-make-a-difference-in-unitys-play-mode-compared-to-your-build/

 

Christoph

[Roehrensockel]

vor 2 Stunden schrieb chrische5:

Hallo

 

Vielleicht hilft die das:

http://blog.13pixels.de/2019/things-that-can-make-a-difference-in-unitys-play-mode-compared-to-your-build/

 

Christoph

Hallo,

Danke zum Tip, das könnte mir beim Problem mit den Grifftasten helfen, im Debug Mode habe ich eine Warnung aber mein Cpp ist nicht so toll, mal sehen ob ich dahinter komme, fliegen kann ich auch ohne Roll.

Manfred

[Sascha]

@chrische5 Jemand verlinkt meinen Blog! 😍

@Roehrensockel  So ernüchternd das auch ist - du musst dir bewusst machen, dass es diese Begrenzungen bei Unity nicht für die Lulz gibt. IEEE 754 hört halt bei astronomischen Werten ziemlich schnell auf, brauchbar zu sein. Du kannst z.B. mal Zahlen in diesen Konverter hauen und schauen, wie sehr die kaputt gehen. Bei 50000.005 hast du direkt nen Fehler von 0.001. Klingt vielleicht nicht nach viel, ist aber im Zweifelsfall spürbares Ruckeln und/oder Grafikfehler, z.B. bei der Lichtberechung. Also für den Spieler spürbare Sachen. Auch die clipping planes der Kamera sind nicht ohne Grund einfach per default auf Maximum geknallt. Alle Objekte rechnen ihre Matrix oben auf die inverse Kameramatrix drauf, damit sie auf dem Bildschirm passend zur Kamera an der richtigen Position gezeichnet werden. Diese Matrix hat halt auch wieder Gleitkommazahlen drin, und je weiter near und far clipping plane auseinander liegen, umso mehr Ungenauigkeit entsteht.

Worauf ich hinaus will: Bei astronomischen Werten empfehle ich Dringend, mit Tricksen anzufangen. Was zum Beispiel wunderbar geht, sind mehrere Kameras. Das kann man auch schön in mehrere Szenen aufteilen. Du baust eine Kamera (oder eben ganze Szene) für den Makroraum, wo dann die Planeten alle viel kleiner sind, sodass du das Sonnensystem komplett in einen <1000³-Würfel unterbringen kannst. Dann baust du eine zweite Kamera bzw. Szene, in der alles normalgroß ist. Dann gibst du der Makrokamera ein Script, das eine Weltraumposition plus der Position der anderen Kamera in die verkleinerten Koordinaten umwandelt und die Drehung der normalen Kamera übernimmt. Wenn du also die normale Kamera drehst, dreht sich die Makrokamera mit. Bewegt sich die normale Kamera aber, dann bewegt sich die Makrokamera nur einen Bruchteil der Entfernung. Dann noch depth und clear flags der beiden Kameras so einstellen, dass die Makrokamera für die andere Kamera quasi den Hintergrund rendert, und schon hast du zwei Koordinatensysteme miteinander verbunden.

Ich erwähne das alles, weil du dir mit solchen Techniken eine Menge Kopfschmerzen sparst, und vor allem, weil ich ganz stark das Gefühl habe, dass sich die von dir geschilderten Probleme ganz schnell von alleine erledigen werden, wenn du Unity nicht an seine Grenzen bringst

[Sir_Mathew]

Nu so als Idee.

könnte man nicht alles als lod_1-Lod_3 packen und z.b. alles viel näher aneinander rücken und langsamer fliegen. Un umso Näher man kommt,  je größer werden die Planeten anhand der lod Stufe.

[Roehrensockel]

vor 10 Stunden schrieb Sir_Mathew:

Nu so als Idee.

könnte man nicht alles als lod_1-Lod_3 packen und z.b. alles viel näher aneinander rücken und langsamer fliegen. Un umso Näher man kommt,  je größer werden die Planeten anhand der lod Stufe.

Danke erst mal für die Anregungen und Tips.

An der Stelle der Geschwindigkeit habe ich gerade angesetzt, ich werde das Schiff in der Bewegung bremsen  je weiter ich mich von der Erde entferne die Geschwindigkeitsanzeige aber konstant halten, das fällt nicht besonders auf wenn ich eine gewisse Entfernung von Erde und Mond habe und das Gameobjekt Erdsystem in die entgengesetzte Richtung bewegen und zusätzlich eine hohe Geschwindigkeit durch ein Partikelsystem um das Schiff simulieren, ansonsten ist im realen Weltraum ja sowieso nicht so viel los. Das Vorhaben alle Planeten und Monde direkt anzufliegen habe ich auch schon aufgegeben und ein Scenen Management aufgebaut und setze dazu Sprungtore die ich für einen Scenenwechsel anfliegen kann und mich dann in die Nähe der Planeten teleportiert, gleichzeitig wechsle ich dabei die Skybox die dann z.B. die ferne Erde und Sonne zeigt. Auch ein Anflug auf die Planeten ist für mich als Anfänger ein zu dickes Brett, da werde ich wohl einen Autopiloten einsetzen der das Schiff in eine Raumstation bringt um dann von dort auf den Planeten zu teleportieren, in dem Scenenwechsel kann dann auch gleich die Bewegungssteuerung wechseln.

Größere Probleme habe ich damit wieso meine Grifftasten im Build verschwinden obwohl sie im Inputmanager definiert sind und im gleichen Script wie alle anderen Axis abgefragt werden, da werde ich erst mal versuchen den rechten Thumbstick zu nutzen, mal schauen ob das klappt, visualsiere ich im Holokit die Motioncontroller als Animation kann ich sehen wie die Grifftasten bewegt werden. Auch die Belegung der neuen HP Reverb g2 Controller ist unklar, zu den alten habe ich eine Tabelle bei Microsoft gefunden und die neuen Controller stimmen bis auf die Touchpads überein, nun dachte ich die an der Stelle gesetzten Tasten A,B,X,Y würden die Zuweisungen der Touchpads übernehmen aber in einem Testprogramm für Controller werden alle Axis und Buttons angezeigt nur bei den neuen Tasten passiert nichts, versuche ich den Bereich im Inputmanager über 19 zu setzen nimmt Unity das nicht an, in der Hololens Animation der Motion Controller werden die neuen Controller aber völlig korekt angezeigt inkl. der neuen Buttons, die Scripts von Microsoft zu den Controllern sind aber momentan eine Nummer zu hoch für mich.

Manfred

[Roehrensockel]

vor 11 Stunden schrieb Sascha:

@chrische5 Jemand verlinkt meinen Blog! 😍

@Roehrensockel  So ernüchternd das auch ist - du musst dir bewusst machen, dass es diese Begrenzungen bei Unity nicht für die Lulz gibt. IEEE 754 hört halt bei astronomischen Werten ziemlich schnell auf, brauchbar zu sein. Du kannst z.B. mal Zahlen in diesen Konverter hauen und schauen, wie sehr die kaputt gehen. Bei 50000.005 hast du direkt nen Fehler von 0.001. Klingt vielleicht nicht nach viel, ist aber im Zweifelsfall spürbares Ruckeln und/oder Grafikfehler, z.B. bei der Lichtberechung. Also für den Spieler spürbare Sachen. Auch die clipping planes der Kamera sind nicht ohne Grund einfach per default auf Maximum geknallt. Alle Objekte rechnen ihre Matrix oben auf die inverse Kameramatrix drauf, damit sie auf dem Bildschirm passend zur Kamera an der richtigen Position gezeichnet werden. Diese Matrix hat halt auch wieder Gleitkommazahlen drin, und je weiter near und far clipping plane auseinander liegen, umso mehr Ungenauigkeit entsteht.

Worauf ich hinaus will: Bei astronomischen Werten empfehle ich Dringend, mit Tricksen anzufangen. Was zum Beispiel wunderbar geht, sind mehrere Kameras. Das kann man auch schön in mehrere Szenen aufteilen. Du baust eine Kamera (oder eben ganze Szene) für den Makroraum, wo dann die Planeten alle viel kleiner sind, sodass du das Sonnensystem komplett in einen <1000³-Würfel unterbringen kannst. Dann baust du eine zweite Kamera bzw. Szene, in der alles normalgroß ist. Dann gibst du der Makrokamera ein Script, das eine Weltraumposition plus der Position der anderen Kamera in die verkleinerten Koordinaten umwandelt und die Drehung der normalen Kamera übernimmt. Wenn du also die normale Kamera drehst, dreht sich die Makrokamera mit. Bewegt sich die normale Kamera aber, dann bewegt sich die Makrokamera nur einen Bruchteil der Entfernung. Dann noch depth und clear flags der beiden Kameras so einstellen, dass die Makrokamera für die andere Kamera quasi den Hintergrund rendert, und schon hast du zwei Koordinatensysteme miteinander verbunden.

Ich erwähne das alles, weil du dir mit solchen Techniken eine Menge Kopfschmerzen sparst, und vor allem, weil ich ganz stark das Gefühl habe, dass sich die von dir geschilderten Probleme ganz schnell von alleine erledigen werden, wenn du Unity nicht an seine Grenzen bringst

Danke für die Anregungen und Tips, ich habe schon dem Member Sir_Mathew geantwortet und die Anregung die Geschwindigkeiten anzupassen schon übernommen und bei allem Anderen werde ich mit einem Scenenmanagement arbeiten und ich hatte das Problem mit den im Build verschwundenen Grifftasten nochmal angesprochen. Werde jetzt erst mal versuchen die Scipts entsprechend anzupassen und die Belegung der neuen HP Reverb Motion Controller zu verstehen.

Manfred