Zitat von »Man_In_Blue«

Warum du nur dazu was sagst? Hmm. Vielleicht weil du vor kurzem noch behaptest hast die Radeon 9700 Pro behersche weder d- noch n- mapping und wäre nicht DX9 kompatibel so das du dich nu raus hälst? (ned zu ernst nemen, aber das liegt mir immer noch quer das man hier und dir son Kohl verzapft hat)

Du kannst so ziemlich alles DirectX9-kompatibel machen, selbst eine S3 Virge ist mit den richtigen Treibern voll DX9-kompatibel. Das beantwortet aber in keinster Weise die Frage ob die vom Treiber gereichten Features überhaupt in Hardware implementiert sind oder nicht.
Und da sieht es bei dem R300 nicht so rosig aus...

cya
liquid

Nö, sry MiB, dat stimmt nun so gar net. Ich zitiere mal Demirug aus dem 3DCenter Forum.

Zitat

Displacement mapping geht auf Matrox zurück und wurde, wie Aquaschaf schon gesagt hat, in die DX9 Specifikation aufgenommen.

Allerdings benutzt man keine Graustufen-Bitmaps sonder Normal-Vektoren-Maps. Als BMP sehen diese sehr bunt aus, da die X,Y und Z-Werte als RGB Werte hinterlegt sind.

So wie die Lage derzeit aber aussieht würde ich dieses Feature aber in keinem Spiel erwarten.

-NVIDIA beherscht diese Technik nur durch einen Trick der keine gute Performances erwarten läst.

-ATI unterstützt nur eine stark eingeschränkte Variante und diese ist mit den aktuellen Treibern noch sehr CPU lastig da grosse Teile nicht vom Chip gerechnet werden.

-Matrox beherscht das Verfahren zwar aber aufgrund der geringen Anzahl von Matroxkarten in spielerhänden ist es für die Entwickler uninteresant.

-Der neue Vertex-Shader 3.0 enthält Features die DM überflüssig machen. Derzeit gibt es zwar noch keinen Chip der VS 3.0 beherscht aber diese dürften relative schnell verfügbar werden.

Und man sieht, dass man mindestens VS-3.0 braucht, also nix mit R300 hat 2.0 und kann das deshalb. UND das jetzige Verfahren ist zwar da, aber Großteil in Software und das zieht natürlich ganz schön an der Leistung.
DM in seiner wohl besten und einwandfreisten Form kann bis jetzt nur der Parhelia und der ist halt nicht besonders interessant für Game Devs. Ich weiß noch nix über den R350, aber das sehen wir dann schon

Schönen Tag noch!

Vielleicht weil die X Hardwareseiten keine Ahnung haben und einfach nur dumm nachplappern was ihnen die Hersteller in die Hand drücken?
Und sicherlich haben sie damit recht, dass der R300 D-Mapping unterstützt und wie ich schon gesagt habe, die Unterstützung allein gibt einem nicht die geringste Informationen wie dieses Feature implementiert wurde.

Und zu dem Auto-Dingen hab ich keine Ahnung, kann mir aber vorstellen, dass dort getrickst wird oder das gar kein richtiges D-Mapping ist, sondern nur dieses statische Variante, die man einmal im CPU berechnet, in den GPU-Speicher schiebt und fertig isses. Aber wie gesagt, da bin ich überfragt.

cya
liquid

Zitat von »Man_In_Blue«

Hö?EDIT: Beim R350 hat sich quasi all das bewahrheitet was ich bereits im CS Tread damals gesagt hab... die Shader wurden teis mächtig aufgebort um eingermaßen die flexiblität der GFFX Shader zu erreichen... auch wenn das nicht ganz möglich war...)

Ist das unser Thema? Nein, also versucht nicht abzulenken. Wir reden hier grade über den R300 und nicht den R350.

Zitat von »Man_In_Blue«

su hast dreister weise behauptet der R300 würde TrueForm2 ned unterstützen was nix anderes als d- & n-mapping ist.

Ich sage nicht, dass sie es nicht kann. Ich bezweifel allerdings ernsthaft, dass sie das Feature in Hardware hat.

Zitat von »Man_In_Blue«

In Wahrheit wird baer nur der n-Patch aus TureForm 1 nicht wirklich hardwareseitung unterstützt wie es Liqued eindrucksvoll "demonstrirt" hat... aber der n-Patch hat nix mit d- und n- Mapping zu tun. Kanna ber durch jede DX9 KArte emulirt werden. (Teo. jedenfalls)

Ein Wunder, dass er das mit TF1 überhaupt geschluckt hat. Das mit dem D-Mapping schluckt er auch noch, verlasst euch drauf.

Zitat von »Man_In_Blue«

EDIT: EIgentlich ist das Thema hier das NV nachgelassen hat.

Also wollen wir ein extra Thema für eine Sache aufmachen, die sowieso so klar ist wie sie Kloßbrühe nicht klarer sein könnte.

Noch kleiner "technischer Anhang". Also, es ist ohne Vertex Shader der Version 3.0 unmöglich Daten in der GPU zu erzeugen. Sprich jeder Vertex der in den VS "reinkommt" kommt auch wieder raus. Halt verändert, aber würde man ihn irgendwie markieren, wüsste man, dass es immer noch der gleiche ist. Das Problem ist nun, dass bei all diesen Tesselationsverfahren neue Vertices generiert werden müssen. Man hat eine polygonale Fläche, die man durch ein Heightmap-Bitmap zusätzlich "auftesseliert". Der Grid, also das Raster der Bitmap, wird auf die polygonale Fläche gelegt und dann wird "auftesseliert". Danach werden noch anhand der Höheninformation die erzeugten Punkte verschoben, das sogenannte Displacement findet statt.
Das Problem ist nur, dass man in VS der Version 2.0 (oder sagen wir besser unter Version 3.0) keine Vertices in dem VS erzeugen kann. Hat was mit den Pipelining, Flow Control, etc. zu tun, fragt mich nicht, auf jeden Fall muß man da am Kern einiges ändern, damit das funktioniert.
Ich glaube man sieht das Problem. Wie soll eine Karte wie die Radeon 9700 Pro mit einer VS-2.0 GPU das in Hardware machen? Schlicht und ergreifend, es geht einfach nicht. Man erledigt die Tesselation in der CPU, das Displacement kann dann immer noch die Karte übernehmen. Das Problem ist dann nur, dass erstens die CPU belastet wird und zweitens ein Transfer von Geometrieinformationen von der GPU und zurück geleistet werden muss.
Der R200 konnte es, da er eine extra Einheit im Chip hatte, die einzig und allein für diese Aufgabe bestimmt war. Jedoch hat man diese Einheit in den kommenden Architekturen einfach weggespart und damit ist der Support für Tesselation innerhalb der GPu flöten gegangen.
Thats it!

Aber dafür hat die R350 ja den F-Buffer, den ich vom Konzept her eigentlich net schlecht finde. So hat jeder was woran er sich "klammern" kann. Die NVs ihre Turbinen *weh* und die ATis ihre Buffers. Wohl bekomms, ich mach Schluß für heut. Morgen letzte Abi-Vorklausur, ich bin schon ganz hibbelig! ;D

*liquid immer noch nicht im Bett wie er es eigentlich schon längst sein sollte*
Boah, habt ihr mal auf DHM.de geguckt? Deutsche Geschichte pur und super zusammengefasst, das macht wirklich mal Spaß!

Also noch kurz zur Physik. Ja, eigentlich müsste man die Einwirkung auf die Physik berücksichtigen, aber man wird es wohl nur an den Stellen anwenden, wo es entweder keine Rolle spielt (statische Geometire oder nicht zugänglich) oder halt in so kleinem Maße (Scaling ganz nach unten, damit das Displacement net so stark wirkt). Aber im Prinzip stimmt es.
Das hat auch Carmack gewurmt, der wird das nämlich auf keinen Fall in Doom3 benutzen, da es absolut nicht mit dem Schattierungsalgo zusammenarbeitet. Die Modelle sind ja alle lowpoly und die Silhouettengenerierung ist jetzt schon heavy genug. Das Problem ist auf der einen Seite, mache ich die Tesselation vor den Silhouetten, muss ich exponentiell so viel berechnen, da die Polygone ja mit hoch-X nach oben schnellen. Die Schattenvolumina werden dadurch noch komplexer, also alles Mist.
Zweiter Fall, Silhouetten vor der Tesselation. Kein Problem mit Performance, wenn das D-Mapping in Hardware ist. Aber! Und jetzt kommt der springende Punkt. Zich von Artefakten wegen dem Stencil Shadowing, der ja absolut nicht mehr zu den Modellen passt. Verstehst, Schatten von Lowpolymodelle zusammen mit Hightpolymodellen, gibt nur Chaos und sieht net schön aus. Deshalb nur normales Dot3-Bumpmapping (sieht man ja auch in der Demo).

cya
liquid

Warum soll das hinderlich sein große Polygonmengen darstellen zu können? Das ist sogar essentiell wenn man Tesselation in Hardware verwendet. Es geht halt darum, möglichst wenig Transfer von und zu der GPU zu haben. Wenn ich nur eine Bitmap über den Bus schieben muss und dann noch ein paar Vertices, dann macht sich das schon sehr bezahlt.
Ein schneller Rasterizer ist natürlich Pflicht, sonst kann man die intern generierten Dreiecke ja gar nicht schnell genug in den Framebuffer schreiben.

Zum Thema Rendertechnik. Da wären natürlich das von dir genannten Voxel (volume elements) Verfahren, dann könnte man noch auf Raytracing, Raycasting ausweichen, das bringt auch gute Ergebnisse, ist allerdings von der Technik her ein großer Unterschied zur traditionellen Renderarchitektur.
SaarCOR wäre ein Stichwort, wenn dich das interessiert.

cya
liquid

Dann mußte mal bei ACM Siggraph anklopfen, vielleicht haben die was für dich!