Autor Wątek: Zwiekszenie dokładnosci obliczen zmiennopozycyjnych  (Przeczytany 3240 razy)

Offline mrh

  • Użytkownik

# Sierpień 07, 2006, 21:58:40
Tak jak w temacje moj problem dotyczy zwiekszenie dokładnosci obliczen zmiennopozycyjnych. Czy jest na to jakas metoda. Jaka zmienna zapewnia najweksza precyzje ? Obliczenia oparte mam na zmiennych double no i po jakims czasie nagromadzaja sie dostzregalne błędy ;/

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Deus

  • Gość
# Sierpień 07, 2006, 22:07:46
.
« Ostatnia zmiana: Kwiecień 21, 2008, 20:38:19 wysłana przez Szalonuki »

Offline fofoo

  • Użytkownik
    • WebLog

# Sierpień 07, 2006, 22:09:10
Może to nie będzie to czego szukasz, ale jako ciekawostke powiem że w pythonie są liczby zmiennoprzcinkowe nieskończonej precyzji ( czy jakostak ), czyli ich dokładność jest ograniczona tylko przez pamięć komputera. Interpreter pythona napisany jest w c, jesli jesteś bardzo zdesperowany to możesz poszukać tam.

Deus

  • Gość
# Sierpień 07, 2006, 22:15:32
.
« Ostatnia zmiana: Kwiecień 21, 2008, 20:35:12 wysłana przez Szalonuki »

Offline mrh

  • Użytkownik

# Sierpień 07, 2006, 22:27:00
deus jest tak jak mowisz poruszam kamera a swiat stoi w miejscu ;]. Zaczynajac pisac gre nie przyszło mi do głowy ze moge miec taki problem ;] Stwierdziłem ze poruszanie swiatem zamiast kamera jest bardziej obciazajace dla karty dlatego taki wybor a nie inny. Niestety mysl o przerabianiu teraz całego projektu mnie pzrerazaja ;] Hmm moze przeskalowanie wszsytkiego by cos pomogło. Gierka to wyscigi błedy zaczynaja byc widoczne po kilku okrazeniach wiec nie jest tak zle no ale problem jest ;/

Offline TeMPOraL

  • Użytkownik
    • devBlog

# Sierpień 08, 2006, 03:29:14
Akurat grafika to mniej ważny przypadek znaczenia niedokładności; gorzej jest, jeśli takowe pojawiają się w kodzie fizyki, bo może to prowadzić do nienaturalnego zachowywania się obiektów zależnie od odległości od lokalnego 'centrum wszechświata'. Nie wiem jakie rozwiązanie byłoby sensowne na planszach bezterenowych (space sim), które z definicji są duże. Tu już trzeba sztuczki chyba robić. A przynajmniej nie przychodzi mi do głowy rozwiązanie, które zachowałoby dokładność we wszystkich pozycjach bez uwzględniania różnych przypadków szczególnych.
Pozdrawiam.

Offline Reg

  • Administrator
    • Adam Sawicki - Home Page

# Sierpień 08, 2006, 06:11:55
Liczby zmiennoprzecinkowe nieskończonej precyzji? To raczej niemożliwe, bo byle działanie takie jak 10.0/3.0 zapchałoby całą pamięć.

Najczęstszy błąd powodujący gromadzenie się błędów to obliczanie nowej pozycji (czy innej liczby) na podstawie poprzedniej tam, gdzie dałoby się ją policzyć na podstawie pozycji początkowej. Można też zainteresować się dokładniejszymi metodami całkowania, niż standardowe nowa_pozycja = stara_pozycja + prędkość * delta_czasu (jeśli ktoś nie wiedział, to też jest własnie całkowanie :)).

Deus

  • Gość
# Sierpień 08, 2006, 10:47:26
.
« Ostatnia zmiana: Kwiecień 21, 2008, 20:41:55 wysłana przez Szalonuki »

Offline shyha

  • Użytkownik
    • Shyha@Flickr

# Sierpień 08, 2006, 11:00:31
To jest tzw. całkowanie ruchu. Kiedyś był o tym artykuł tutaj i bardzo dobry bodajrze na gamasutrze

Offline mikael

  • Użytkownik

# Sierpień 08, 2006, 11:13:37
Jeśli chodzi stricte o grafikę, to http://developer.nvidia.com/object/floating_point_specials.html

Jeśli chodzi o opis świata, to był rozdział na ten temat (bodajże w Game Programming Gems). Nie pamiętam którym...

Offline Hadrian W.

  • Użytkownik
    • Homepage

# Sierpień 08, 2006, 12:51:00
Trzeba dbac o jak najbardziej rowna delte czasu. Najlatwiej mozna to chyba osiagnac przez limit FPS'ow.
Mialem problem z jedna swoja symulacja, ze co jakis czas fps'y lecialy gwaltownie w dol i powodowalo to zwiekszenie delty i niestabilnosc symulacji. Szybko udalo mi sie to zatrzymac przez minimalna delte, ustalilem ze delta nie moze byc mniejsza niz jakis-tam-czas i udalo mi sie osiagnac stabilnosc :)

Offline MoN

  • Użytkownik

# Sierpień 08, 2006, 18:00:32
Calkowanie i rozniczkowanie to najogolniej mowiac liczenie pola pod wykresem funkcji albo liczenie "stromizny" wykresu w danym punkcie, czyli tego jak szybko funkcja rosnie. Typowe nowa_pozycja = stara_pozycja + predkosc*dt to, jak powiedzial Regedit, caleczka - sprowadza sie to do tego, ze wykres predkosci dzielimy na odcinki dlugosci delta_czasu, zakladamy ze tam predkosc jest stala i liczymy droge (no wiadomo, druga = predkosc x czas :P), po czym dodajemy do reszty.

Jesli calkowana funkcje (w tym przypadku predkosc po czasie) mamy opisana wzorem to mozemy ja bezproblemowo scalkowac analitycznie (a nie numerycznie) i wtedy dostajemy nowa funkcje - w tym przypadku aby otrzymac polozenie obiektu w momencie t wystarczy wklepac polozenie(t) - polozenie(0), gdzie polozenie jest calka po predkosci - analogicznie z uzyskiwaniem predkosci na podst. polozenia.

Mozna to wykorzystac np. przy symulowaniu grawitacji w kosmosie - pod warunkiem ze ograniczymy ilosc obiektow, na ktore grawitacja dziala (nie ma problemu, jesli np. mamy jakas gwiazde przyciagajaca statki, ale afaik nie da sie analitycznie rozwiazac ukladu 3 cial, ktore sie nazwajem przyciagaja)

Offline Ocelot

  • Użytkownik
    • Ocelot's Jungle

# Sierpień 08, 2006, 19:49:55
mrh napisał:
Cytuj
deus jest tak jak mowisz poruszam kamera a swiat stoi w miejscu ;]. Zaczynajac pisac gre nie przyszło mi do głowy ze moge miec taki problem ;] Stwierdziłem ze poruszanie swiatem zamiast kamera jest bardziej obciazajace dla karty dlatego taki wybor a nie inny. Niestety mysl o przerabianiu teraz całego projektu mnie pzrerazaja ;] Hmm moze przeskalowanie wszsytkiego by cos pomogło. Gierka to wyscigi błedy zaczynaja byc widoczne po kilku okrazeniach wiec nie jest tak zle no ale problem jest ;/

Przeskaluj. Najszybsze, najłatwiejsze, najlepsze ;). Porównaj 1e8 z 1e-8 i zaraz wiadomo o co chodzi.