N-Patch (TruForm) Test

[Demirug]

Wie in einem anderen Thread schon angekündigt hier ein kleiner N-Patch Test.

http://demirug.bei.t-online.de/EnhanceMesh.zip

Es handelt sich dabei um ein modifiziertes DX9-SDK-Sample.

Die Tastenbelegung kann der Readme Datei entnommen werden.

Erklärung zu dem Modies:

Hardware: Die Tesselation wird für jeden Frame von der Karte durchgeführt.

Software: Die Tesselation wird nur bei der Änderung des Levels einmal von der CPU durchgeführt. Das Ergebniss wird zwischengespeichert und dann in jedem Frame zur Karte geschikt.

Da AFAIK bisher kein Spiel mit TruForm support mit dynamischen Tesselationslevel arbeitet sind beide Techniken was den Praxsis bezug angeht gleichwertig.

[zeckensack]

Radeon 8500LE @200/200MHz vs Athlon XP 1800+

Komisch. Software ist erstmal immer schneller als Hardware, bis zum Grad 10 (430 zu 240fps).
Ab Grad 11 knickt die Software plötzlich total weg (auf 30fps), ab diesem Punkt ist die Hardwarelösung dann immer schneller.

Ich glaube aber nicht so recht an diese Zahlen ... kann es sein, daß die Software-Tesselation nur einen begrenzten Vertex-Buffer nutzt, der dann irgendwann (also ab Grad 11) zu klein wird? Das würde den extremen Leistungseinbruch erklären.

[Demirug]

Der Buffer ist gross genug da er dynamisch angelegt wird.

Der Einbruch kommt aber wohl scheinbar sobald die Anzahl der Faces die 64K überschreitet. Ich mache mich mal auf die Suche nach dem genauen Grund

In wie fern glaubst du nicht an die Zahlen? Das ist nur eine ganz normale FPS Messung.

[zeckensack]

Originally posted by Demirug
Der Buffer ist gross genug da er dynamisch angelegt wird.

Der Einbruch kommt aber wohl scheinbar sobald die Anzahl der Faces die 64K überschreitet. Ich mache mich mal auf die Suche nach dem genauen Grund

In wie fern glaubst du nicht an die Zahlen? Das ist nur eine ganz normale FPS Messung. Ich glaube den Zahlen grundsätzlich schon, aber dieser plötzliche starke Einbruch ist halt verdächtig. Da ist irgendetwas nicht 'skalierbar' genug ausgelegt, im Software-Pfad.

Oder der Graka geht der lokale Speicher für Vertex Buffer aus, aber wenn das wie du sagst nur 64k Faces sind, dann kann man das wohl ausschließen.

Komplette Meßreiche folgt in Kürze :)

[Quasar]

Das "m" für den Hardware-Modus bewirkt bei mir genau NULL. DX9 Redist und Cat3.0 sind drauf, Graka R9700p.

[Quasar]

Nach dem wohl obligatorischen Neustart funzt das jetzt auch bei mir.

Trotzdem:
Im wireframe-Modus deutlich sichtbar ist, dass Hardware-TruForm auf der R9700 höhere Einstellungen als NumSegs:8 ignoriert. Es wird nicht weiter tesseliert.

[Demirug]

@zeckensack:

Hast du einen DX-Caps Viewer auf dem Rechner? Falls ja bitte den Wert bei Caps->MaxPrimitiveCount prüfen. Ich vermute das da bei dir 65536 steht. Da das Object dann bei Tesselation über 10 zu viele Faces hat passieren da intern eine ganze menge Dinge um das Objekt doch noch richtig zu rendern die aber extrem auf die Performances schlagen.

@Quasar: Wie sind den die Performances unterschiede zwischen Software und Hardware?

Die M Taste funktioniert nur dann wenn die hardware N-Patch support meldet.

[zeckensack]

Originally posted by zeckensack
Komplette Meßreiche folgt in Kürze :)
400x300 Windowed, X8R8G8B8 D16
Segs HW SW
1 1320 1320
2 1000 1273
3 700 1227
4 554 1095
5 454 938
6 368 812
7 285 695
8 240 550 <<< höchste Tesselationsstufe der HW?
9 240 492
10 240 423 <<<
11 240 29 <<<
12 . 25
13 . 21
14 . 18
15 16.0
16 14.0
17 12.5
18 11.2
19 10.0
20 9.1

[zeckensack]

Originally posted by Demirug
@zeckensack:

Hast du einen DX-Caps Viewer auf dem Rechner? Falls ja bitte den Wert bei Caps->MaxPrimitiveCount prüfen. Ich vermute das da bei dir 65536 steht.So ist es :|

Ähm jo, DX9 'final' + Cat 3.0 + Win98SE

[Demirug]

Danke Zeckensack,

Das mit der 8 als höchste Stufe hat ja auch Quasar schon vermutet.

Ich prüfe den Caps wert dafür nicht. Im Viewer unter Caps->MaxNpatchTesselationLevel zu finden.

Deine Messreihe bestätigt aber was ich schon vermutet habe. N-Patch Tesselation in der Hardware ist nicht wirklich sinnvoll solange man den Level nicht über ein LOD dynamisch anpasst. Bei einem fixen Level wäre es wohl besser die Tesselation nur einmal beim Laden des Objects durchzuführen.

OK der Test berücksichtigt jetzt keine Situation in welcher im Grafikkartenspeicher noch viele Texturen enthalten sind.

Würde gerne mal sehen wie sich zum Beispiel UT2K3 mit einer solchen modifikation verhält.

[Quasar]

Na, dann klau' ich doch mal ganz dreist die Tabelle von Zecki ;)
400x300 Windowed, X8R8G8B8 D16
Segs HW SW
1 3125 3125
2 1231 3088
3 700 2601
4 436 2155
5 291 1825
6 209 1555
7 156 1330
8 121 1144 <<< höchste Tesselationsstufe der HW?Ja!
9 121 989
10 121 861 <<<
11 121 27 <<<
12 . 21
13 . 18
14 . 15,5
15 13,5
16 11,9
17 10,5
18 9,4
19 8,4
20 121 7,5

Ach so, System war eine DDR-P4 mit 2.53GHz und WineXPeriment

[Demirug]

Danke auch dir Quasar.

Das sieht ja noch übler aus als auf der 8500 von zeckensack.

[Quasar]

Ich hab ja auch eine "CPU-limitierte" Version von TF. Wartet's ab, wenn ich 'nen 7,5GHz-P4 habe, hau ich Zecki's R200 ausm Wasser...

[Demirug]

Originally posted by Quasar
Ich hab ja auch eine "CPU-limitierte" Version von TF. Wartet's ab, wenn ich 'nen 7,5GHz-P4 habe, hau ich Zecki's R200 ausm Wasser...

Ja aber das kann es doch wohl nicht sein, oder?

Aber das Thema hatten wir ja schon

[Quasar]

Ja, das Thema hatten wir zur Genüge. Auch mit DX9, wie einige ausm R3D-Forum postulierten, hat sich leider noch nichts getan.

Ich denke, ATi hat das klassische TF zu den Akten gelegt.

[Demirug]

Originally posted by Quasar
Ja, das Thema hatten wir zur Genüge. Auch mit DX9, wie einige ausm R3D-Forum postulierten, hat sich leider noch nichts getan.

Deswegen habe ich den Test auch extra für DX9 gemacht weil ja dort alles besser werden sollte. OK war gemein von mir.

Ich denke, ATi hat das klassische TF zu den Akten gelegt.

Genau wie NVIDIA sich scheinbar von dem nativen HOS Support verabschiedet hat.

[Quasar]

Ja leider.
Ich bin aber mal gespannt, ob es "inoffiziell" noch in der GFFX drin ist.

[askibo]

Wiso sind denn die Werte meines Systems (Xp2000, Ti4400) so hoch? :|
Ich hab z.B. bei 30 Segmenten immer noch ca. 75 fps.

[Demirug]

Originally posted by askibo
Wiso sind denn die Werte meines Systems (Xp2000, Ti4400) so hoch? :|
Ich hab z.B. bei 30 Segmenten immer noch ca. 75 fps.

Das kommt wohl daher das die NV2X Rheie nicht die Beschrängung auf 65536 Dreiecke pro Primitive hat. Dort liegt die Beschrängung erst bei 1048575 Dreiecken. Deswegen kommt der Einbruch wohl viel später.

[askibo]

Originally posted by Demirug


Das kommt wohl daher das die NV2X Rheie nicht die Beschrängung auf 65536 Dreiecke pro Primitive hat. Dort liegt die Beschrängung erst bei 1048575 Dreiecken. Deswegen kommt der Einbruch wohl viel später.

Danke, das ist schon die Antwort auf meine nächste Frage ;)

Wollte grad fragen warum ich bei 42 Segmenten nur noch 0.07(!) fps habe. Bei 41 Segmenten sind noch 41 fps.

[AlfredENeumann]

Originally posted by Quasar
Nach dem wohl obligatorischen Neustart funzt das jetzt auch bei mir.

Trotzdem:
Im wireframe-Modus deutlich sichtbar ist, dass Hardware-TruForm auf der R9700 höhere Einstellungen als NumSegs:8 ignoriert. Es wird nicht weiter tesseliert.

Bei mir geht Hardware nit. Nur Software.

[Quasar]

@AEN:
Neustarten, musst' ich auch erst.



400x300 Windowed, X8R8G8B8 D16
Radeon9700 Radeon9000Pro
Segs HW SW HW
1 3125 3125 1517
2 1231 3088 710
3 700 2601 530
4 436 2155 405
5 291 1825 309
6 209 1555 237
7 156 1330 188
8 121 1144 155
9 121 989 155
. . . .
. . . .
. . . .
20 121 7,5 155
[edit]Bitte die niedriegeren Maximalwerte bei den kleineren Tesselationsstufen ignorieren, da sie auf meinem Celeron-System mit 1,3GHz entstanden sind!
Oooh Hauerha!
Wenn ich das bei Rage3D poste gibt's Backenfutter ;)

Die "TF-Einheit" der RV250 haut die "TF-Einheit" der R9700 um 25% wech.
Demirug, Zecki, Xmas irgendeine Ahnung was da nun wieder los ist???

[ow]

Mitklau. Hier mal noch ein paar 'echte';) SW-Werte, auf GF2MX, Det. 41.80, XP1700.

400x300 Windowed, X8R8G8B8 D16 (Wireframe)
Segs SW
1 586 (538)
2 549 (452)
3 505 (377)
4 460 (312)
5 416 (258)
6 369 (213)
7 324 (177)
8 278 (148)
9 238 (125)
10 205 (106)
11 2.78 (2.78)
12 2.34 (2.34)

[ow]

Originally posted by Quasar
@AEN:
Neustarten, musst' ich auch erst.



400x300 Windowed, X8R8G8B8 D16
Radeon9700 Radeon9000Pro
Segs HW SW HW
1 3125 3125 1517
2 1231 3088 710
3 700 2601 530
4 436 2155 405
5 291 1825 309
6 209 1555 237
7 156 1330 188
8 121 1144 155
9 121 989 155
. . . .
. . . .
. . . .
20 121 7,5 155

Oooh Hauerha!
Wenn ich das bei Rage3D poste gibt's Backenfutter ;)

Die "TF-Einheit" der RV250 haut die "TF-Einheit" der R9700 um 25% wech.
Demirug, Zecki, Xmas irgendeine Ahnung was da nun wieder los ist???


Jo, und meine MX haut eure Radeons alle weg. Sagt mal, was bencht ihr da???

[Demirug]

Quasar, was soll das los sein?

Die Hardware TF-Einheit des RV250 ist zwar nicht ganz so gut wie deine "CPU" wenn es um den maximalwert geht dafür bricht sie aber beim erhöhen der Tesselation weniger ein. In gewiesser Weise macht das sogar Sinn. Denn die Hardware Einheit erzeugt die zusätzlichen Vertexpunkte bestimmt via Interpolation und je mehr zusätzliche Vertexdaten pro Dreieck erzeugt werden müssen desto weniger fällt der Setupaufwand für die Interpolation ins Gewicht.

[Demirug]

Originally posted by ow
Jo, und meine MX haut eure Radeons alle weg. Sagt mal, was bencht ihr da???

Von nichts eine Ahnung aber mitreden wollen. ;) Hast du meinen ersten Post gelesen?

[Quasar]

Originally posted by Demirug
Quasar, was soll das los sein?

Die Hardware TF-Einheit des RV250 ist zwar nicht ganz so gut wie deine "CPU" wenn es um den maximalwert geht dafür bricht sie aber beim erhöhen der Tesselation weniger ein. In gewiesser Weise macht das sogar Sinn. Denn die Hardware Einheit erzeugt die zusätzlichen Vertexpunkte bestimmt via Interpolation und je mehr zusätzliche Vertexdaten pro Dreieck erzeugt werden müssen desto weniger fällt der Setupaufwand für die Interpolation ins Gewicht.

Sorry, hab's vergessen hinzuschreiben, aber das war von "diesem" System, CPU ist n T-Celli@1,3 mit SDRAM. Deswegen der niedrigere Maximalwert.
Ich find's erstaunlich, dass beide Software-TruForm Einheiten solch drastischen Performance-Unterschiede haben.

Ich verstehe nicht, wieso du 25% Mehrleistung als verständlich ansiehst?

[Demirug]

Originally posted by Quasar


Sorry, hab's vergessen hinzuschreiben, aber das war von "diesem" System, CPU ist n T-Celli@1,3 mit SDRAM. Deswegen der niedrigere Maximalwert.
Ich find's erstaunlich, dass beide Software-TruForm Einheiten solch drastischen Performance-Unterschiede haben.

Ich verstehe nicht, wieso du 25% Mehrleistung als verständlich ansiehst?

Hat die 9000 nicht die Tesselationseinheit von der 8500 bekommen?

Deiner Aussage nach zu folgern gehe ich mal von einem Nein aus. Dann ist es wirklich sehr merkwürdig. Da waren wohl unterschiedliche Programmierer am Werk. Oder die VertexShader des R300 sind so stark anders das es so wie man es beim RV250 gemacht hat dort nicht mehr geht.

[Quasar]

"Nein" ist richtig. Das TF der R9000pro ist sogar "so SW", dass ATi selber auf ihrer Produktpage davon kein Sterbenswörtchen mehr erwähnt.

Sry, ich dachte, das hättest du parat. :)

[askibo]

alles Diebe hier :D

die Werte für eine Ti4400, Xp2000, Deto 41.80

400x300 Windowed, X8R8G8B8 D16
Segs SW
1 3020
2 2810
3 2403
4 1974
5 1665
6 1422
7 1187
8 992
9 836
10 710
11 608
12 525 <=ab jetzt in 4er Schritten
16 315
20 206
24 114
28 86
32 67
36 53
40 43 <= keine 4er Schritte mehr
41 41 1011962 Faces
42 0.07 1061928 Faces

[Demirug]

Originally posted by Quasar
"Nein" ist richtig. Das TF der R9000pro ist sogar "so SW", dass ATi selber auf ihrer Produktpage davon kein Sterbenswörtchen mehr erwähnt.

Sry, ich dachte, das hättest du parat. :)

sry, bei den vielen Chips verliere ich da manchmal die Übersicht. Vorallem um diese Uhrzeit :)

Aber um nochmal auf das UT2K3 Thema zu kommen. Wie überzeugen wir Daniel Vogel das er sowas in den D3D renderer einbaut? Damit hätte man "TruForm" für alle und schneller wäre es wohl wahrscheinlich auch.

[Quasar]

Wir drohen damit, es überall an die große Glocke zu hängen! ;)

Naja, eine nette Email (du als Mod&Dev hast sicher schon öfter mit ihm zu tun gehabt, als ich) könnte vielleicht schon reichen. :)

Allerdings kann UT2k3 IMO kleinere CPUs auch ohne TF schon ein bissel überlasten. Wenn dann noch zusätzliche Polys dazukommen, wäre selbst ein dicker P4 schnell am Ende, denke ich.

[zeckensack]

Originally posted by Demirug


sry, bei den vielen Chips verliere ich da manchmal die Übersicht. Vorallem um diese Uhrzeit :)

Aber um nochmal auf das UT2K3 Thema zu kommen. Wie überzeugen wir Daniel Vogel das er sowas in den D3D renderer einbaut? Damit hätte man "TruForm" für alle und schneller wäre es wohl wahrscheinlich auch. Stop!

UT2k3 muß die Models animieren. Der ausgestopfte Tiger ist nicht repräsentativ für beweglichen Dreieckssalat(TM).

PS: Prost
*sing*

[Demirug]

Originally posted by Quasar
Wir drohen damit, es überall an die große Glocke zu hängen! ;)

Naja, eine nette Email (du als Mod&Dev hast sicher schon öfter mit ihm zu tun gehabt, als ich) könnte vielleicht schon reichen. :)

Allerdings kann UT2k3 IMO kleinere CPUs auch ohne TF schon ein bissel überlasten. Wenn dann noch zusätzliche Polys dazukommen, wäre selbst ein dicker P4 schnell am Ende, denke ich.

Ich habe ihm mal was geschrieben. Aber soviel hatte ich bisher auch nicht mit Daniel zu tun.

Die CPU dürfte mit der zusätzlichen Vertexmenge gar nicht so viel zu tun haben (wenn Hardware T&L) vorhanden ist. Das einzige was zusätzlich gebraucht würde ist Bandbreite und da ist schwer zu sagen in wie weit diese dafür noch verfügbar ist.

[Demirug]

Originally posted by zeckensack
Stop!

UT2k3 muß die Models animieren. Der ausgestopfte Tiger ist nicht repräsentativ für beweglichen Dreieckssalat(TM).

PS: Prost
*sing*

Guter Einwand. Dabei ist nur die Frage wieviel von dieser Animation von der CPU und wieviel von der GPU übernommen wird. Selbst mit normalem Hardware T&L ist ja ein gewisses mass an Skelet-Animation möglich.

[Quasar]

Zecki hat da 'nen Punkt. Der Tiger-Mesh ist mit Soft-TF wirklich noch konkurrenzfähig, aber beim Q2-ModelViewer (animiert!) sieht's da schon wieder ganz anders aus. Das CPU-assisted TF von R>200-Chips kann da bei weitem (ca. 50% der Performance) nicht mit einer echten TF-HW mithalten.
Und dort werden nur zwei läppische Q2-Models dargestellt.

[Demirug]

Ja, ich habe den Einwand ja schon als gut anerkannt. Ich werde mal schauen ob ich da auch ein animiertes Model reinbekomme. Aber erst nachdem ich ein bischen Schlaf hatte.

[Quasar]

nvidia hat in ihrem cg-Kit (und auch schon im alten Effects-Browser) diesen häßlichen Typen drin, der auf der Stelle geht.
Kann man den dafür nicht klauen?

[Demirug]

Originally posted by Quasar
nvidia hat in ihrem cg-Kit (und auch schon im alten Effects-Browser) diesen häßlichen Typen drin, der auf der Stelle geht.
Kann man den dafür nicht klauen?

Das Model habe ich mir schon ausgesucht. Tiny aus dem SDK. Aber es muss halt noch der ganze Animationscode mit dem Tesselationscode kombiniert werden und dazu bin ich im Moment nicht mehr fit genug.

[AlfredENeumann]

Originally posted by Quasar
@AEN:
Neustarten, musst' ich auch erst.



geht trotzdem nit. Was mache ich falsch ?

[Demirug]

Originally posted by AlfredENeumann


geht trotzdem nit. Was mache ich falsch ?

Geht überhaupt nichts oder nur der Hardwaremodus nicht?

Welche Treiber benutzt du den im Moment?

[Quasar]

AEN,

bei mir nutz' ich den Cat3.0 (sowohl die R300-only Version als auch die generische tun's), sowie das offizielle DX9-Redistributable.
Nach dem aktivieren von TF im ControlPanel verlangt Demirugs Anwendung einen Neustart, obwohl andere Programme sich mit dem aktivieren im CP zufriedengeben.
OS ist einmal Win2k (SP2) und einmal WinXP (ohne SP) gewesen.

So, jetzt muss erstmal die Pute gefressen werden... HMJAMM!

[AlfredENeumann]

So, jetzt gehts. Ich Hammel hatte im Treiber TruForm deaktiviert.

[Demirug]

Zwischenbericht:

Der neue Test ist leider noch nicht ganz fertig da andere arbeiten und der allgemeine Feiertagsstress die sache etwas verzögern.

Allerdings konnte ich bereits festellen das sobald eine DX7 Hardware T&L einheit verfügbar ist auf die CPU durch die statische Tesselation beim laden keine zusätzliche Last kommt. Das Skinning für die animation kann vollständig von der Grafikkarte gemacht werden kann.

Nur die Anzahl der Knochen (Bones) ist entscheident für die CPU belastung und diese ändert sich durch die Tesselation nicht.

[Unregistered]

finde den Test hier richtig genial!

Habs auch gleich mal ausprobiert und kann die genannten Sachen alle
nur bestätigen. Max Hw Tess. 8x und SW einbruch von 10x auf 11x

Was du da sagst hört sich sehr interessant an Demirug!

Sobald es wieder was spannendes zu Testen gibt bin ich dabei!

[AlfredENeumann]

Kleine Frage. Nach den ganzen Tests jetzt: Also hat die R300 Truform in Hardware, oder nicht ?

es geht um diesen thread: http://www.forum-3dcenter.org/vbulletin/showthread.php?postid=592288#post592288

[Quasar]

Naja, es hängt alles von der Definition "in Hardware" ab.

Für meine Begriffe haben die ATi-Chips >200 genausoviel TruForm in Hardware, wie eine Xabre einen Vertexshader in Hardware hat, eine GF2 Anti-Aliasing in Hardware oder eine KyroIISE eine TnL-Einheit in Hardware hat.

Man muss ATi zugestehen, dass sich das Feature aktivieren lässt und auch funktioniert. Leider ist die Geschwindigkeit nicht sehr berauschend, aber davon war in ihren Papers ja nicht die Rede.

[Demirug]

Um zu Testen in wie weit Truform von der CPU gerechnet wird muss man einfach nur mal mit unterschiedlichen CPUs (Takten) messen. Wenn es in der Hardware läuft sollte es so gut wie keinen Einbruch geben. Wenn es auf der CPU läuft sollte es einigermassen Linear mit dem Takt skalieren.

[Quasar]

Der P4, den ich hier hab', is leider Multi-locked, also musst ich über den FSB gehen.

Q2-Model Viewer, default-Fenster, Tess.Lev.7, Lighting: on)
R300@default, Cat3.0-Treiber, DX9
P4@19x145: 40,6
P4@19x133: 37,4
P4@19x100: 28,8

Na?
CPU-assisted, aber irgendwann scheint da auch irgendwas im R300 langsam zu langsam zu werden. ;)

[JTHawK]

Originally posted by Demirug
Allerdings konnte ich bereits festellen das sobald eine DX7 Hardware T&L einheit verfügbar ist auf die CPU durch die statische Tesselation beim laden keine zusätzliche Last kommt. Das Skinning für die animation kann vollständig von der Grafikkarte gemacht werden kann.

Nur die Anzahl der Knochen (Bones) ist entscheident für die CPU belastung und diese ändert sich durch die Tesselation nicht.

hab das mal mit meiner Geforce 1 SDR unter DirectX 8.1 getestet zum spass

das Harware nit lüppt versteht sich ja .. aber software tuts auch und da ergibt sich genau das was du sagst ... .. beim sprung von 10 auf 11 bricht er dann auf lustige 0.07 ein .. alles vorher lüppt wunderbar ... ich habe eine konstante cpu auslastung von niedlichen 70 prozent auf meinem alten athlon 700 und bei stufe 10 noch knuddelige 130 fps !

[tb]

Originally posted by Demirug
Wie in einem anderen Thread schon angekündigt hier ein kleiner N-Patch Test.

http://demirug.bei.t-online.de/EnhanceMesh.zip

Es handelt sich dabei um ein modifiziertes DX9-SDK-Sample.

Die Tastenbelegung kann der Readme Datei entnommen werden.

Erklärung zu dem Modies:

Hardware: Die Tesselation wird für jeden Frame von der Karte durchgeführt.

Software: Die Tesselation wird nur bei der Änderung des Levels einmal von der CPU durchgeführt. Das Ergebniss wird zwischengespeichert und dann in jedem Frame zur Karte geschikt.

Da AFAIK bisher kein Spiel mit TruForm support mit dynamischen Tesselationslevel arbeitet sind beide Techniken was den Praxsis bezug angeht gleichwertig.

Tach!

Ich hab mal ATi's N-Patch Demo auf DX9 portiert und die stufenlose(bei mir halt 0,125) Tesselation aktiviert. Dies würde sich ideal für LOD's anbieten, da es aber ein ATi only Feature ist, werden Entwickler wohl eine anderen Universalweg gehen.

http://www.tommti-systems.de/main-Dateien/TOOLS/npatch.sfx.exe

Thomas

[Demirug]

Originally posted by tb


Tach!

Ich hab mal ATi's N-Patch Demo auf DX9 portiert und die stufenlose(bei mir halt 0,125) Tesselation aktiviert. Dies würde sich ideal für LOD's anbieten, da es aber ein ATi only Feature ist, werden Entwickler wohl eine anderen Universalweg gehen.

http://www.tommti-systems.de/main-Dateien/TOOLS/npatch.sfx.exe

Thomas

Funktioniert die stufenlose Tesselation bei ATI? Refrast mag irgendwie nicht.

Ansonsten ist das ja schon lange ein Punkt den ich bei allen Games die TruForm nutzen kritisiere. Da wird einfach stur immer mit der gleichen Anzahl von Segmente gearbeitet. Und mit meinem kleinen Test wollte ich nur beweisen das es in einem solchen Fall besser wäre das Model beim laden gleich hochzurechen. Ok man braucht etwas mehr Speicher für die Vertexdaten aber das sollte bei vielen Spielen gar nicht so ein grosses Problem sein.

[Xmas]

Nicht ATI only, Matrox bietet es auch.
Auch RT-Patches bieten Continuous Tessellation, das ist quasi Pflicht für eine HOS-Implementation.

[Quasar]

Auf meiner R9000 funktioniert's schon, nur bis zur Stufe 7.0, danach gibt's keine Veränderungen mehr in der Dreiecksanzahl. Als ich das Programm beendete, riss es mein komplettes System mit sich (ich hab jetzt keine Lust auszuprobieren, ob das reproduzierbar ist....).

Ansonsten bleibt die Framerate konstant über 300fps, selbst auf halber TF-HW. Zu wenig Vertices?

edit:
Der Absturz IST reproduzierbar. Win2k, SP2, DX9, Catalyst 3.0, Firewall, Virenscanner, SETI, Intellipoint und CL Remote Center liefen zusätzlich zu Thomas' nPatch-Anwendung.

[tb]

Originally posted by Demirug


Funktioniert die stufenlose Tesselation bei ATI? Refrast mag irgendwie nicht.

Ansonsten ist das ja schon lange ein Punkt den ich bei allen Games die TruForm nutzen kritisiere. Da wird einfach stur immer mit der gleichen Anzahl von Segmente gearbeitet. Und mit meinem kleinen Test wollte ich nur beweisen das es in einem solchen Fall besser wäre das Model beim laden gleich hochzurechen. Ok man braucht etwas mehr Speicher für die Vertexdaten aber das sollte bei vielen Spielen gar nicht so ein grosses Problem sein.

Auf der R9700 gehts bis Stufe 8, steht ja auch so in den Caps. Warum der Refrast nicht mag ist mir ein Rätsel, eigentlich solllte diese wirklich alle DX9 Features bieten. Mit Deinem Test hast Du natürlich vollkommen recht, wenn sich die Tesselation nicht ständig ändert, dann braucht man kein Feature im GPU, wenn dies auch noch langsamer als auf der CPU ist.

[tb]

Originally posted by Quasar
Auf meiner R9000 funktioniert's schon, nur bis zur Stufe 7.0, danach gibt's keine Veränderungen mehr in der Dreiecksanzahl. Als ich das Programm beendete, riss es mein komplettes System mit sich (ich hab jetzt keine Lust auszuprobieren, ob das reproduzierbar ist....).

Ansonsten bleibt die Framerate konstant über 300fps, selbst auf halber TF-HW. Zu wenig Vertices?

edit:
Der Absturz IST reproduzierbar. Win2k, SP2, DX9, Catalyst 3.0, Firewall, Virenscanner, SETI, Intellipoint und CL Remote Center liefen zusätzlich zu Thomas' nPatch-Anwendung.

Ich denk mal mein npatch Demo ist Schuld, entweder hab ich da was verhauen, oder die Treiber haben da eine gewisse Abneigung ;) - Die Interpolation der Normalen sieht auf der R9700 übrigens immer gleich aus, egal welches Verfahren -> Treiberfehler.

[Quasar]

Ich mach dir auch keinen Vorwurf, keine Sorge.....hier ist schließlich alles auf eigene Gefahr. ;)

[Demirug]

tb, also der Refrast will im Prinzip schon nur sehen ich keinen Unterschied zwischen discrete und continuous.

[tb]

Originally posted by Demirug
tb, also der Refrast will im Prinzip schon nur sehen ich keinen Unterschied zwischen discrete und continuous.

Yeph, jedoch ändert sich die Darstellung immer erst bei "vollen" Schritten und nicht in 0,125'er wie bei der R9700.

[AlfredENeumann]

Originally posted by tb


Ich denk mal mein npatch Demo ist Schuld, entweder hab ich da was verhauen, oder die Treiber haben da eine gewisse Abneigung ;) - Die Interpolation der Normalen sieht auf der R9700 übrigens immer gleich aus, egal welches Verfahren -> Treiberfehler.

unter XP kein Absturz.

[Paul]

hi,

ich poste einfach mal zum vergleich meine werte. ich hoffe einfach mal das "zeckensack" nichts dagegn hat das ich sein tabellenschema übernehme. natürlich mir meinen werten ;).

400x300 Windowed, X8R8G8B8 D16
Segs SW
1 3480
2 3060
3 2640
4 2190
5 1850
6 1570
7 1310
8 1090
9 920
10 780
11 660
12 570
13 500
14 440
15 390
16 340
17 300
18 270
19 250
20 220
...
...
...
40 45

so, jetzt habt ihr ein paar werte zum vergleichen. mein system -> sie unten

mfg
paul