Nurbs .... wann in Hardware?

[betasilie]

Mich würde mal interessieren wann man mit 3D-Chips rechnen kann, die Spiele, die auf Nurbs basieren, in Hardware Rendern. (?)

Wenn ich mich richtig erinnere hat NVidia im Jahr 2000 mal versprochen, dass sie 2003 Grafikchips auf den Markt bringen werden, die das können!? Jetzt kann der GFFX noch nicht mal DM in Hardware, obwohl das ja ein bissl in die Richtung geht. Und was nun? Weiß jemand wann die 3D-Chip-Hersteller diese Technik in Angriff nehmen wollen?

[Frank]

eine feine Sache ....

aber:
Mathematiker sind heute nicht mehr so viel wert wie Ingenieur (und das aus meinen Munde). Oder um es anders zu fomulieren: Heute setzt man einfach auf mehr Rohpower und Ruhe is. Damit kann man sich letztendlich schwierige (evtl effiziente) Algorithmen schenken, oder neue Standards zu etablieren auf den erst eine breite Masse setzen muss.

[zeckensack]

Nurbs haben kaum Vorteile ggü Dreiecksdarstellung.

Erstmal ist die Menge der darstellbaren Körper begrenzt(er).
Außerderm verschlingen die Kontrollpunkte einer sauberen Nurbs-Darstellung ungefähr genausoviel Speicher wie Vertices. Der Rechenaufwand ist im Gegenzug wesentlich höher, was logischerweise bei Echtzeitanwendungen schlecht ist.

[betasilie]

Zitat:

Originally posted by zeckensack
Nurbs haben kaum Vorteile ggü Dreiecksdarstellung.

Erstmal ist die Menge der darstellbaren Körper begrenzt(er).
Außerderm verschlingen die Kontrollpunkte einer sauberen Nurbs-Darstellung ungefähr genausoviel Speicher wie Vertices. Der Rechenaufwand ist im Gegenzug wesentlich höher, was logischerweise bei Echtzeitanwendungen schlecht ist.

Ja nur hat u.a. NV 2000 oder 2001 viel davon erzählt, dass es bald (2003) so weit ist.

Da Firmen wie NV einen Langzeitplan haben, ist daher davon auszugehen, dass Nurbs in Hardware "demnächst" ansteht. NV wird sowas nicht aus den Augen verlieren. NV und wahrscheinlich ATI und evtl. Matrox werden da sicherlich schon fleißig entwickeln, denn wer zuerst kommt malt auch zuerst.

Wenn man bedenkt, dass NV diese Technik für 2003 plante, könnte man ja vieleicht auf DX10 spekulieren!?

[Demirug]

native Nurbs unterstützung wird wohl nie kommen. Warum auch. Die notwendigen Berechnungen lassen sich auch im Vertexshader anstellen. Das einzige was man braucht ist das Grundgitter. Wobei in Summe die ganzen HOS Sachen in der Grafikkarte sowieso keinen Sinn machen. Denn durch HOS-Technik spart man ledigliche Speicher und Geometriebandbreite. Da sich aber bei HOS die Dreiecksmenge erheblich aufbläst und zwar auch an stellen wo es gar nicht nötig wäre zahlt man im Vertex-Shader bei HOS drauf.

Als NVIDIA damals solche Aussagen gemacht hat war man dort noch der Meinung das in HOS die Zukunft liegt. Aber die Entwickler (vorallem die Grafiker) mögen HOS nicht sonderlich. Deswegen ist man bei NVIDIA wohl entgültig davon abgekommen und bei ATI scheint man auch nicht mehr so richtig zu wollen.

Irgendwie ist das auch verständlich. Den so wie zu Beispiel TruForm bisher eingesetzt wurde ist es IMO bei genauerer Betrachtung blödsinn es in der Hardware zu machen. Wenn alle Modele (bzw. nur ausgewählte) ständig mit dem gleichen Faktor gerendert werden könnte man die Tesselation auch nur einmal bei laden durchführen und der Grafikkarte gleich das "grosse" Model vorsetzten. Ich gehe davon aus das es keine unterschiede in der Performances gibt. Da ich mich aber hier durchaus täuschen könnte werde ich einen kleinen Test programmieren.

[Fragman]

@ demirug:
hos wird sicher kommen, das graphiker das nicht leiden koennen kann ich mir garnicht vorstellen, mal zur klarstellung: zaehlen zu hos auch subdiv's und patches?, wenn ja, wird doch heut schon unterstuetzt. normale nurbs, bsp cv's sind nicht unbedingt noetig, allerdings, wenn man mal dazu uebergehen sollte sich fuer raytracing zu entscheiden, ist es doch egal welche geometrie form ich waehle, oder leig ich da falsch.

[Demirug]

Zitat:

Originally posted by Fragman
@ demirug:
hos wird sicher kommen, das graphiker das nicht leiden koennen kann ich mir garnicht vorstellen, mal zur klarstellung: zaehlen zu hos auch subdiv's und patches?, wenn ja, wird doch heut schon unterstuetzt. normale nurbs, bsp cv's sind nicht unbedingt noetig, allerdings, wenn man mal dazu uebergehen sollte sich fuer raytracing zu entscheiden, ist es doch egal welche geometrie form ich waehle, oder leig ich da falsch.

ja alle Arten von Patches gehören zu den HOS. Das Problem mit dem Graphikern ist das sie sich dadurch das HOS immer auf festen Regeln aufbaut eingeschränkt füllen. Ohne adaptive Tesselation macht IMO HOS auch gar keinen Sinn mehr weil man was die Geometriebandbreite angeht inzwischen genügend hat. Und wie gesagt jede Art von HOS läst sich mit den VertexShadern nachbilden.

Sobald man den Wechsel zum echten Raytracing vollzieht kann HOS wieder Sinn machen. Allerdings nur wenn das Raytracing wirklich auf der HOS ebene abläuft und nicht voher auf Dreiecke gewandelt wird. Nur echtes Raytracing werden wir so schnell wohl nicht sehen.

[Xmas]

Wenn man erst mal beim Raytracing ist, sind HOS sogar sehr viel besser als Massen von Dreiecken, um etwas rund zu bekommen.

[betasilie]

Also lohnen sich Nurbs nur beim echtem Raytracing.

Naja, ich glaube auf echte Echtzeitraytracing-Games können wir dann doch noch ein bissl warten. ... ne Zeitmaschiene müsste man haben.

Raytracing ist an und für sich kein Problem schon jetzt schnell zu machen. Das größte Problem sind dynamische Szenen.
IMO sollte man sich wirklich überlegen Raytracing zu forcieren, schliesslich macht die tolle Programmierbarkeit nur dadurch noch weiteren Sinn.

[ethrandil]

wie wäre es denn mit HOS + displacementmaps?
(Also für die Grafiker)

[Lost Prophet]

soooooooooooooo

mei freund das fernglas (google) hat mir jetzt mal geholfen raytracing zu verstehen

ich geh jetz mal von der (für heute eingentlich "kleinen") auflösung von 1024x768 aus

das ergäbe 786.432 bildpunkte

angenommen im durchscnitt kommt jeder lichtinpuls über 2 ecken zum tatsächlichen bildpunkt am blidschirm

das wäre imho ein enormer rechenaufwand

nur ich kann mir keine relation vorstellen
is ja heute auch kein problem die 2.280.000 blidpunkte für 1600x1200 in mehremaliger ausführung pro sec auszurechnen

kann mir bitte irgenwer ein GROBE relation sagen um wieviel die leistung einbricht

zb bei einer beliebigen szene von mir aus ein tal mit berg im hintergrund und teich im vordergrund (mal ungefähr wie der anfang in SSE:TSE)

oder irgenwas anderes würd nur gern das
leistungsverhältniss raytracing - nonraytracing
ungefähr wissen



noch eine frage zum topic

braucht man bei nurbs denn noch AA (zumindest die reine kantenglättung müsste doch hinfällig sein oder?)

[Xmas]

Zitat:

Originally posted by Purple_Stain
soooooooooooooo

mei freund das fernglas (google) hat mir jetzt mal geholfen raytracing zu verstehen

ich geh jetz mal von der (für heute eingentlich "kleinen") auflösung von 1024x768 aus

das ergäbe 786.432 bildpunkte

angenommen im durchscnitt kommt jeder lichtinpuls über 2 ecken zum tatsächlichen bildpunkt am blidschirm

das wäre imho ein enormer rechenaufwand

nur ich kann mir keine relation vorstellen
is ja heute auch kein problem die 2.280.000 blidpunkte für 1600x1200 in mehremaliger ausführung pro sec auszurechnen

kann mir bitte irgenwer ein GROBE relation sagen um wieviel die leistung einbricht

zb bei einer beliebigen szene von mir aus ein tal mit berg im hintergrund und teich im vordergrund (mal ungefähr wie der anfang in SSE:TSE)

oder irgenwas anderes würd nur gern das
leistungsverhältniss raytracing - nonraytracing
ungefähr wissen

Du gehst von der falschen Seite aus. Es ist nicht nur entscheidend, wie oft der Strahl letztlich abgelenkt wird, sondern hauptsächlich mit wievielen Oberflächen auf Schnitt getestet werden muss. Eine Szene mit einer Kugel und ein paar Spiegeln kann trotz häufiger Reflexion oftmals viel schneller gerendert werden als eine komplexe Szene mit Tausenden von Oberflächen. Denn bevor die Ablenkung eines Strahls berechnet werden kann, muss erst mal herausgefunden werden, wo er denn überhaupt auftrifft.

Und es gibt wirklich so viele verschiedene Techniken, dass man grob nur "irgendwo zwischen 1:10 und 1:100000" sagen kann.

Zitat:

noch eine frage zum topic

braucht man bei nurbs denn noch AA (zumindest die reine kantenglättung müsste doch hinfällig sein oder?)

Sicher braucht man AA. Die Rundung verhindert ja nicht das Entstehen von "Stufen".

[ethrandil]

Hmm kommt ganz drauf an
Wenn man die Rendertechniken umbaut und nichtmehr mit Dreiecken arbeitet ... Dann könnte man das AA schon sehr basic einbauen, indem einfach echtes AA an den Kanten gemacht wird
*träum*

[Lost Prophet]

erstmal big thx@xmas

ok, das mit dem letzten absatz hab ich irgenwie von daher abgeleitet

Zitat:

Originally posted by Dieser Internetseite
Worin unterschieden sich NURBS von Polygonen?
Die Unterschiede zwischen NURBS und Polygonen lassen sich mit den Unterschieden von Vektor- und Pixelgrafik vergleichen: Ähnlich wie in der Pixelgrafik Bilder aus kleinen Bildpunkten zusammengesetzt werden, bestehen Polygonobjekte aus einzelnen kleinen Geometriebestandteilen, den Polygonen. Ähnlich wie in der Vektorgrafik Objekte durch mathematische Kurven beschrieben werden, bestehen NURBS - Objekte aus im Raum liegenden Kurven, die eine Fläche aufspannen. Die Vor - und Nachteile der beiden Verfahren verhalten sich genauso wie die der Pixel zur Vektorgrafik: Polygonobjekte ermöglichen die Erzeugung von Dingen, die mit NURBS nicht machbar sind. Darüberhinaus benötigen Polygonojekte meist weitaus mehr Speicherplatz als NURBS - Objekte. Außerdem lassen sie sich nicht vergrößern, ohne dass irgendwann Polygonkanten sichtbar werden. - NURBS - Objekte sehen in jeder Vergrößerung perfekt aus.
Polygon bedeutet übrigens Vieleck und NURBS steht (wenn ich mich recht erinnere) für Non Uniform Rational B - Splines

mehrere möglichkeiten

• Du liegst richtig (davon gehe ich aus )
• Er liegt richtig
• Wir meinen nicht das gleiche

bitte höflich um aufklärung

danke

cya axel

[Demirug]

Purple_Stain, egal welche Technik man benutzt man wird immer AA brauchen weil ein Monitor keine unendliche Auflösung hat.

Nurbs lassen sich (wie alle HOS) beliebig skalieren weil jeder Oberflächenpunkt mathematisch berechnet werden kann.

Man braucht aber denoch AA beim Raytraceing. Der Grund dafür ist einfach. Wenn man pro Pixel einen Sichtstrahl in die Szene berechnet ist es durchaus möglich das dieser Strahl auf eine Kante eines objects trift. Dabei würde dann aber nur ein Teil des Strahls auftreffen der andere Teil müsste vorbeigehen. Man kann diese Problem nun mit Supersampling lösen. Also pro Pixel mehrer Sichtstrahlen komplett berechnen. Oder ein MS Verfahren. Also auch mehrer Strahlen pro Pixel berechnen aber für alle Strahlen die auf eine Fläche auftreffen nur einen Farbe bestimmen. Das könnte allerding probleme mit reflectionen geben. Raytracing läst aber noch ein anderes AA Verfahren zu. Dabei wird nur ein Strahl Pro pixel in die Szene berechnet. Tirft er nun ein Object nur Teilweise wird der strahl dupliziert und jeder der beiden strahlen weitergerechnet. Beim Duplizieren wird auch noch bestimmt welchen prozentuallen Anteil jeder der beiden Strahlen an der Endfarbe hat.

Um irgendwelchen grauen Theorien vorzubeugen, dass Echtzeitraytracing so schnell nicht machbar ist, sei folgende Url ans Herz gelegt

http://graphics.cs.uni-sb.de/RTRT/

(jaja auch deutsche Wissenschaftler kriegen was hin )

Bis jetzt wird, soweit ich weiss, dabei nur in Software gearbeitet. Wobei eine Umstellung der Datenstrukturen allein schon mehr als Faktor 10 entstand.....

Was bei einer Hardwareunterstützung zu erwarten wär kann man sich ungefähr ausrechnen

[Xmas]

Zitat:

Originally posted by Unregistered
Um irgendwelchen grauen Theorien vorzubeugen, dass Echtzeitraytracing so schnell nicht machbar ist, sei folgende Url ans Herz gelegt

http://graphics.cs.uni-sb.de/RTRT/

(jaja auch deutsche Wissenschaftler kriegen was hin )

Bis jetzt wird, soweit ich weiss, dabei nur in Software gearbeitet. Wobei eine Umstellung der Datenstrukturen allein schon mehr als Faktor 10 entstand.....

Was bei einer Hardwareunterstützung zu erwarten wär kann man sich ungefähr ausrechnen

Genau darauf basierte auch meine "untere Grenze" 1:10, da hier ja von einstelligen Frameraten gesprochen wird.