spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

So wie ich das in der MSDN sehe würde ich sagen nein

D3DMATRIX
D3DVECTOR
D3DVECTOR3

Alle Strukture nutzen float bzw. FLOAT.

Aber ist es denn notwendig mit double zu arbeiten? Wenn ja könntest du es ja wie David_pb machen und deine eigenen Strukturen schreiben und dann die Berechnung selber implementieren. Dann kann deine Engine intern mit double arbeiten und muss nur bei der Anzeige mit einfacher genauigkeit arbeiten, was bei der Zahl an möglichen Pixeln auf dem Bildschirm ja egal sein dürfte.

da alle GPUs intern (im besten fall) mit 32bit float rechnen, wird alles letztendlich max. mit float genauigkeit bearbeitet.
es hält dich aber niemand davon ab mit double genauigkeit zu arbeiten. die grafikausgabe musst du dann halt irgendwie zusammenbasteln.

Zitat von »"Black-Panther"«

Es geht hier vor allem um die numerische Stabilität. Mit erhöhter Genauigkeit lässt sich jene steigern. Deshalb möchte ich alles umstellen.

wo genau treten da bei dir probleme auf?

Zitat von »"Black-Panther"«

Wenn ich aber jedesmal, wenn ich eine Transformationsmatrix setze, oder Vertizes in den Vertexbuffer speichere, ein casting von double nach float machen muss, wirkt sich das nicht negativ auf die Performance aus?

ein double -> float cast hat einen gewissen overhead. allerdings bedeutet das nicht zwangsweise, dass es sich negativ auf die performance auswirkt.

Zitat von »"Black-Panther"«

(Wie "teuer" ist eigentlich ein static_cast?)

das hängt erstens vom cast an sich ab (was wird in was gecastet!?) und zweitens von der zielplatform (und weiters noch vom dort verwendeten instruction set). auf nem pentium 4 z.b. wird ein short -> int cast evtl. total gratis sein. ein int -> float oder int -> double ist nicht so schlimm, ein float -> int hingegen kann unter umständen ziemlich bremsen...

Zitat von »"chriss"«

was bei der Zahl an möglichen Pixeln auf dem Bildschirm ja egal sein dürfte.

Sobald du Welten hast, die größer als ein paar tausend Einheiten in eine Richtung sind, wird's mit float schon eng mit der Genauigkeit. Das hat mit Pixeln garnichts zu tun.

jop, wenn man so große welten hat, sollte man sich überlegen, ob es nicht einfach reichen würde, z.b. einen herunterskalierten teil des sichtbaren bereiches zum rendern zu nehmen (man wird ja kaum immer die ganze welt zu sehen bekommen). außerdem könnte es evtl. einiges bringen, die sichtbaren objekte relativ zur kamera zu platzieren, da die genauigkeit von gleitkomma in der nähe des ursprunges höher is...wie gesagt: das, was du renderst, muss ja nur eine repräsentation dessen, was du herumrechnest sein. du kannst ja ohne weiteres deine welt in double berechnen und aus den daten dann den sichtbaren ausschnitt "zusammenbastlen". weiters könntest du z.b. die ganze welt in sektoren zerteilen. jeder sektor selbst ist relativ zu den anderen sektoren platziert, wobei z.b. die koordinaten innerhalb des sektors in km relativ zum sektorursprung sind und die sektoren selbst in parsecs relativ zum ursprung des universums (indizierte adressierung, wenn du so willst )...lässt sich sicher auch alles kombinieren, etc. nurmal so ein paar gendanken von mir dazu.

Zitat von »"David Scherfgen"«

Zitat von »"chriss"«

was bei der Zahl an möglichen Pixeln auf dem Bildschirm ja egal sein dürfte.

Sobald du Welten hast, die größer als ein paar tausend Einheiten in eine Richtung sind, wird's mit float schon eng mit der Genauigkeit. Das hat mit Pixeln garnichts zu tun.

ach was :roll:

Aber auf dem Bildschirm geibt es nunmal nur eine begrenzte Anzahl an Pixeln. Die Welt ist ja nur in der Engine existent wo er mit double arbeiten will aber wenn es um die Anzeige geht hat er nur die Pixel des Monitors zur Verfügung und wenn erstmal alle Punkte mit allen verwendeten Matrizen transformiert wurde macht der Rükschritt auf float nichts mehr da es kein Bildschirm so genau darstellen kann.

es macht aber sehr wohl was, ob das objekt jetzt 20 pixel weiter rechts erscheint als es sollte oder net. vor allem wenn es 40 frames später auf einmal 10 pixel weiter links ist, nur weil es sich ein bisschen bewegt hat.

so wie z.b. damals (weis nimmer in welchem forum das war) wo einer so ne sonnensystem simulation geschrieben hat und wo, wenn man die kamera bewegt hat, die planeten wild rumgewackelt sind, weil die genauigkeit bei den riesigen abständen nicht mehr ausgereicht hat.

Mein Gedanke zielte darauf ab alles in double werten anzugeben und dann über die matrizen zu transformieren. Die endgültigen Punkte können dann von double zu float gecastet werden da sie sich nun alle direkt vor dem Bildschirm befinden und die Dortige anzeige hat meist zwischen 800 un 1900 Pixeln in der Breite und 600 bis 1600 Pixeln in der Höhe. Da macht es keinen Unterschied mehr.
Davor macht es einen Unterschied, da stimme ich euch zu.
Eventuell haben wir da aneinander vorbeigeschrieben.

Ich denke in Java3D wird das genauso gemacht denn die Positionsangabe werden mit 64Bit fließkommazahlen gemacht aber die Anzeige wird dann über Direct3D bzw. OpenGL geregelt.