Schnaldi schrieb am 26. Januar 2000:
> ElGrande schrieb am 26. Januar 2000:
>
> >
> > Apropos, sind 9MB nicht etwas zu wenig? Bei externem Speicher
> > haben wir dann ja wieder das bekannte Bandbreitenproblem ...
> >
> Nein, nicht zwingend, denn auf Texturdaten und Tiefeninformationen muss nicht
> so oft und damit so schnell zugegriffen werden. Die 9 MB dienen Hauptsächlich
> als Speicher für die Daten die unmittelbar zum Bildaufbau benötigt werden,
> also die aktuellen Rechenergebnisse, nur dafür ist die hohe Bandbreite besonders
> wichtig - um die Füllrate zusteigern. Dort werden auch nur die Texturinformationen
> gehalten die gerade benötigt werden. Alles andere kann sekundär ausgelagert werden
> und wird erst bei Bedarf geladen. Außerdem könnte man ja zusätzlich noch
> Kompressionsalgorithmen einsetzen? Das Neun Megabyte OnDie stellen nun wirklich
> keine Selbstverständlichkeit dar und wenn man bedenkt, dass der langsamere
> Externspeicher sicher auch mit den heute schnellsten Verfahren DDR oder SGRAM arbeiten
> könnte, wüsste ich nicht wie man auf die Idee kommen könnte, dass da Speicherknappheit
> besteht.
> ;o)
Dies stimmt nicht ganz. Ich weiss nicht wie bewandert du in den Kenntnissen von 3D engines
bist aber bei einem Z-buffer system sind die Tiefeninformationen sogar die am meisten
benutzen Daten ueberhaupt. Denn fuer jeden Pixel der Berechnet wird musst Du an der entsprechenden
Stelle die Tiefeninformation auslesen, vergleichen mit der aktuell berechneten.
Wenn die neue näher zur Kamara steht dann uebermalt man den bestehenden Pixel.
Wenn nicht dann verwirft man ihn. Somit sind schneidungen von Körpern im 3dimsionalen Raum kein
Problem und werden immer (da pixelweise) richtig dargestellt.
Die Texturen kann man tatsaechlich wohl am besten so verwalten das nur die geraden aktiven (meistens
sind eh die meisten Texturen eh nicht auf den Bildschirm und muessen deswegen auch nicht beruecksichtigt
werden) im embedded zwischengespeichert (gecached) werden.
Die Zwischenergebnisse muss man nicht zwischenspeichern.. das tut der 3D chips in seinen internen Registern
und die sind schneller als jedes RAM !
Wer Interesse hat wie sowas in Software realisiert wird der sollte ma hierher schauen:
http://www.hornet.org/
dort unter /code/3d findet man ne ganze Menge!
my 2 cents
Apollo/StigMa
> ElGrande schrieb am 26. Januar 2000:
>
> >
> > Apropos, sind 9MB nicht etwas zu wenig? Bei externem Speicher
> > haben wir dann ja wieder das bekannte Bandbreitenproblem ...
> >
> Nein, nicht zwingend, denn auf Texturdaten und Tiefeninformationen muss nicht
> so oft und damit so schnell zugegriffen werden. Die 9 MB dienen Hauptsächlich
> als Speicher für die Daten die unmittelbar zum Bildaufbau benötigt werden,
> also die aktuellen Rechenergebnisse, nur dafür ist die hohe Bandbreite besonders
> wichtig - um die Füllrate zusteigern. Dort werden auch nur die Texturinformationen
> gehalten die gerade benötigt werden. Alles andere kann sekundär ausgelagert werden
> und wird erst bei Bedarf geladen. Außerdem könnte man ja zusätzlich noch
> Kompressionsalgorithmen einsetzen? Das Neun Megabyte OnDie stellen nun wirklich
> keine Selbstverständlichkeit dar und wenn man bedenkt, dass der langsamere
> Externspeicher sicher auch mit den heute schnellsten Verfahren DDR oder SGRAM arbeiten
> könnte, wüsste ich nicht wie man auf die Idee kommen könnte, dass da Speicherknappheit
> besteht.
> ;o)
Dies stimmt nicht ganz. Ich weiss nicht wie bewandert du in den Kenntnissen von 3D engines
bist aber bei einem Z-buffer system sind die Tiefeninformationen sogar die am meisten
benutzen Daten ueberhaupt. Denn fuer jeden Pixel der Berechnet wird musst Du an der entsprechenden
Stelle die Tiefeninformation auslesen, vergleichen mit der aktuell berechneten.
Wenn die neue näher zur Kamara steht dann uebermalt man den bestehenden Pixel.
Wenn nicht dann verwirft man ihn. Somit sind schneidungen von Körpern im 3dimsionalen Raum kein
Problem und werden immer (da pixelweise) richtig dargestellt.
Die Texturen kann man tatsaechlich wohl am besten so verwalten das nur die geraden aktiven (meistens
sind eh die meisten Texturen eh nicht auf den Bildschirm und muessen deswegen auch nicht beruecksichtigt
werden) im embedded zwischengespeichert (gecached) werden.
Die Zwischenergebnisse muss man nicht zwischenspeichern.. das tut der 3D chips in seinen internen Registern
und die sind schneller als jedes RAM !
Wer Interesse hat wie sowas in Software realisiert wird der sollte ma hierher schauen:
http://www.hornet.org/
dort unter /code/3d findet man ne ganze Menge!
my 2 cents
Apollo/StigMa