Curved Surfaces - Nachteile

[aths]

Also, ich denke, Curved Surfaces werden kommen. Radeon8500 bietet schon welche, der Nachfolger wird das auch tun, nVidia bleibt gar nichts anderes als nachzuziehen. Nun haben sie das mit dem GF4 still und leise in der Versenkung verschwinden lassen, und ich spiele mal John Carmack und versuche (u.a. mit seinen Argumenten) nahezulegen, dass Curved Surfaces überschätzt werden und man sie nicht nehmen sollte.

1. Darstellungsprobleme. Zwei CS schließen nicht genau aneinander. Man muss die Lücken "von Hand" füllen, was aufwändig ist.

Wozu diesen Aufwand? Mit herkömmlichem Geometrie-LOD und fertigen Modellen sind solche Lücken vermeidbar. Schon die 3dfx-Demo zur bikubischen Patches (mit Enviroment Mapping) zeigte Lücken von mehreren Pixeln Breite/Höhe, die gefüllt werden müssen.

Geometrisches LOD könnte auch HW-Support finden, was die CPU von einer Menge Arbeit entlasten kann. Sowie bei Stripes bestimmte Vertices mehrfach verwendet werden, könnten nach W-Wert bestimmte Vertices übergangen werden (was natürlich, wie bei Stripes auch, nur innerhalb einer Textur funktioniert.)


2. Weniger Flexibilität. Angenommen, ein bikubischer Patch wird in 128 Dreiecke zerlegt. Hätte man die 128 Dreicke gleich, könnte man damit viel mehr anfangen.

Das betrifft z.B. die Möglichkeit, diese Fläche in Stücke zu "zersprengen" oder nachträglich zu verformen. Das wäre nur noch über VertexShader-Programme möglich, die Flexibelität wird für einige Effekte schwerlich ausreichen.


3. Bump Mapping. In gewissen Grenzen kann man sanft gebogene Oberflächen auch mit wenigen Dreicken und Bump Mapping realisieren. Das wäre unter dem Gesichtspunkt, dass eigentlich jede Textur eine Bump Map haben sollte, dann noch nicht mal mit Performance-Verlust verbunden.


Kurz, CS bedeutet für den Programmierer eine Menge Fummelarbeit. Viele Vorteile lassen sich auch dann nutzen, wenn der Level-Editor CS unterstützt (und dann eben auch für die Tesselation verantwortlich ist.)

[Fragman]

ich bin der meinung, curved surfaces sind die zukunft, aber wenn, dann als volumenkoerper ohne poly zerlegung, denn polys halte ich nicht fuer der weisheit letzten schluss. schon jetzt werden volumen ein immer wichtigeres thema in der echtzeitdarstellung, viele sachen kann man ohne sie nicht realisieren, zb. explosions, lichtsources, clouds oder fur. mit polys wird die simulation von dynamischen effekten nur unnoetig erschwert. beispiele sind hierfuer einschuesse in waende, die physikalisch korrekt brocken rausbrechen, oder spuren im gelaende, die die goemetrie korrekt verformt (fussabdruecke etc) wird, ich meine richtige abdruecke, keine einsenkungen, wie man sie zb in 3d progs mit dynamics mahen kann. dazu muesste man aber wieder von vorne anfangen, wie anno '96 mit den 3d beschleunigern, deshalb glaube ich nicht an einen so schnellen einsatz von volumenkoerpern. also werden wohl erstmal curved surfaces mit polyzerlegung kommen. ich seh den vorteil vor allem in der realistischeneren darstellung. die probs, die du ansprichst koennte man mit eingescannten modellen umgehen, wies schon seit jahren in der filmproduktion gemacht wird. ich seh die probs beim texturing. bei einigen q3 engine titeln sieht man verzerrungen in den texturen bei curven. es muessen also neue texturing operationen her, die der graphikchip in hardware kann. der vorteil von kurven liegt ja auch in der caracter animation, alles schoen smooth, oder bei der animation von cloths, sieht mit kurven auch bedeutend besser aus als mit poly objecten. dafuer muessten die beschleuniger aber bedeutend leistungfaehiger werden. noch ein vorteil
der kurven liegt in der nutzung von displacement mapping. mit poly objecten sieht es scheisse aus, ausser man unterteilt die polys in zig andere, aber selbst dann kommts nicht an kurven ran.

gruss, Fragman

[RadioactiveMan]

Man sollte bei dem Begriff CS doch schon unterscheiden in parametrische CS(Bezier Patches, NURBS) und Subdivision Surfaces(Clark-Catmull, Butterfly, Loop). Erstere haben keine Zukunft, selbst bei Kinofilmen wie Final Fantasy(Square Pictures) oder A Bugs Life(Pixar) wurde während der Produktion von NURBS auf Subdivision Surfaces umgestiegen, da sie viel flexibler und leistungsfähiger sind. Im Gegensatz zu polygonal basierten Körper kann man die Auflösung der Patches nicht lokal erhöhen/verringern, wenn man also bei NURBS in Gesicht Falten reinmodellieren will so kann man es erst tun wenn man die Auflösung des ganzen Objekts erhöhen, etwa auch am Hinterkopf wo man die Auflösung gar nicht benötigt und es eigentlich nur rund sein muß, die ganzen Kontrollpunkte an denen man dort "herumzupfen" kann sind überflüssig. Arbeitet man mit mehreren NURBS Patches zb. einen niedrig aufgelösten für den Arm und einen hochaufgelösten für die Hand, kann es bei der Animation schon schnell passieren das diese auseinanderbrechen, Unregelmäßigkeiten und Löcher entstehen an dieser Nahtstelle dann. Zum Modellieren sind NURBS mit den richtigen Tools(Maya oder Rhino3d) einfach klasse, im Spielebereich werden sie aber wie Bezier Patches floppen. Könnte auch u.a. daran liegen das 3dmax(DER 3D SW in der Branche) in Sachen Nurbs nicht viel zu melden hat da es diesbezüglich ultralahm und benutzerunfreundlich ist. TRUFORM ist ja ganz lustig(wenn man Waffen net Truform-gerecht bearbeitet sehen sie ganz süß aus) wird aber wohl in Zukunft auch bedeutungslos wenn Subdivision Surfaces in HW unterstützt werden. Jede 3D SW unterstützt sie mittlerweile(Hypernurbs, NURMS, Meshsmooth sind so ziemlich das gleiche) zahlreiche Erweiterungen(z.b. crease-Knicke) ermöglichen eine sehr effiziente Mesh Representation. Henry Moreton(Mitglied der architecture group von NVIDIA und der Kopf hinter den NV HOS) hat in Zusammenarbeit mit anderen Forschern auf der Siggraph 2000, ein Paper " Displaced Subdivision Surfaces" veröffentlicht und auch Richard Huddy(NV DX Dev Relation) hat auch schon mal in einem Dev Board Bemerkungen gemacht das ausgereifte Subdivision Surfaces in HW kommen werden.

[Quasar]

Nach der ganzen Theorie, von der ich eh nur 20% kapiert hab', hier mal ein ganz praktisches Problem:

Wie soll die eventuell nötige Dreiecksbandbreite über den AGP-Port zu realisieren sein?

Schließlich benötigt ein Vertice auch ein wenig Bandbreite und selbst bei einem ausgefeilten LOD in der 3D-Engine, wird es über kurz oder lang nötig sein, die zur Verfügung stehende Bandbreite sinnvoller zu nutzen, als ständig Eckpunkte einzelner Dreiecke über den Bus zu schicken.
Oder seht ihr ausreichend große Vertex-Buffer, um das gesamten Triangle-Aufkommen eines Levels im lokalen RAM zu bevorraten?

[Fragman]

bei nurbs reicht doch das versenden der kontrollpunktdaten, den rest macht dann der chip, jedenfalls sollte es so sein. bei subdivs reicht ja eine vergleichsweise geringe zahl an vertex punkten, falls man die objecte als polys rueberschickt und der chip dann die subdiv op's durchfuehrt, alles andere waere jedenfalls bandbreitenschaedigend und auch bloedsinnig, da man den bus nur unnoetig belasten wuerde und subdivs sich dadurch fuer die naehere zukunft selbst disqualifizieren wuerden, da nicht genuegend bandbreite zur verfuegung steht. btw, ist es bei den g3 hos nicht so, das die kompletten poly daten ueber den bus gehen und nicht nur die kontrollpunkte?

gruss, Fragman

[AlfredENeumann]

Originally posted by Fragman
bei nurbs reicht doch das versenden der kontrollpunktdaten, den rest macht dann der chip, jedenfalls sollte es so sein. bei subdivs reicht ja eine vergleichsweise geringe zahl an vertex punkten, falls man die objecte als polys rueberschickt und der chip dann die subdiv op's durchfuehrt, alles andere waere jedenfalls bandbreitenschaedigend und auch bloedsinnig, da man den bus nur unnoetig belasten wuerde und subdivs sich dadurch fuer die naehere zukunft selbst disqualifizieren wuerden, da nicht genuegend bandbreite zur verfuegung steht. btw, ist es bei den g3 hos nicht so, das die kompletten poly daten ueber den bus gehen und nicht nur die kontrollpunkte?

gruss, Fragman

ist das denn nicht fast das gleiche wie TruForm ? Da läuft doch auch alles im Chip ab und kann Polygone per Tesselation im Chip in weitere Polygone aufteilen und so ein objekt sozusagen modelieren.
Oder verstehe ich da was falsch ?

[Unregistered]

hi,

ich denke mal, dass die umstellung auf nurbs auch noch viel zu gross sein wuerde. Was sollte man damit schon gewinnen? Eine Kiste wird dadurch auch nicht schoener aussehen und wenn ich drauf schiesse isses eher ein texturproblem als eine geometriesache.
Ein Prof von mir sagte mal: Die Menschen wissen vor allem eines: wie andere Menschen aussehen! Das wird wohl die einzige Stelle sein, in der wirklich sinnvolle anwendungen dafuer kommen werden, eben fuer Kleidung und Koerperanimationen. Die Eckpunkte kann man ja leicht animieren, die triangulation dann per vertexshader versuchen und die resultierenden dreiecke durch die truform-engine jagen.
da bei nurbs (kanns auch verwechseln) die Kurve nur von max drei weiteren Punkten abhaengt, kann man auch sehr leicht neue Punkte einflechten. Wenn man also einem Koerper ein Loch in den Bauch verpassen moechte ginge das ebenfalls recht leicht.
Ich denke, dass mit den neuesten Vertex-shadern genug leistung da ist, um parametrische flaechen zu triangulieren und neue Dreiecke zu erzeugen. Braucht man mehr? Mehr macht die Quake3-engine ja auch nicht...

MfG...
Ingmar.

[Exxtreme]

@ Unreg.
AFAIK kann man mit dem aktuellen Vertex-Shader keine Dreiecke oder Dreieckspunkte erzeugen. War AFAIK ein grosser Kritikpunkt an der aktuellen Implementierung. Man ist halt immer noch von der CPU abhängig, die die Dreieckspunkte vorher erzeugen muss.

Gruß
Alex

[Unregistered]

Also ich denke Subdidvision Surfaces werden sich in der Echtzeit-3D Grafik nicht durchsetzen, da man immernoch relativ viele Vertices über den AGP-Bus übertragen muß, um Modelle vernünftig darzustellen. Denn durch Verwendung von Subdivision Surfaces wird keine zusätzliche Information dem Modell hinzugefügt, es werden nur Ecken gesmoothed. Im Endeffekt ist der Gewinn durch Subdivision Surfaces relativ gering in der Echtzeitgrafik..man muss sich nur mal Demos mit normalen Modellen anschauen um zu erkennen, daß es nicht den großen Vorteil bringt. Ausserdem muss dem GPU noch eine Entscheidungshilfe mitgegeben werden, denn woher soll dieser wissen was jetzt gesmoothed werden soll. Die Einsparung an Vertices über den AGP-Bus ist relativ gering gegenüber Curved Surfaces, denn 3D-Daten, welche man mit Subdivision Surfaces verfeinert kann man genauso gut auch als NURBS oder sonstige parametrische Oberfläche übertragen und spart dadurch noch viel mehr AGP-Bandbreite.

Bei NURBS oder Curved Surfaces hat man den Vorteil, daß der AGP-Bus sehr gering belastet wird, und man diese auch in ein LOD-System miteinbeziehen kann. Verwenden kann man NURBS z.B. im Terrain Rendering und fast allen Objekten, die nicht wirklich eckig sind, wobei dies auch möglich sein soll. Löcher, welche durch NURBS/Curved Surfaces enstehen sollen, können auch ausgefüllt werden, darüber gibt es auch genug Papers. Ok da sind wir uns wohl einig. Ich denke wichtig für die Entwickler ist es vor allem ein effizientes Level Of Detail System in den Engines zu verwenden. Dies kann man gut mit allen Darstellungsarten kombinieren (NURBS,...) und die sichtbare Qualität weit erhöhen (bei gleichbleibender Belastung des AGP-Bus). Wenn man dazu noch parametrische Oberflächen verwendet spart man zusätzlich noch Bandbreite. Leider sind die meisten Spieleentwickler zu faul/nichtüberzeugt davon kompliziertere LOD-Mechanismen zu implementieren. Ok mein Fazit auch Curved Surfaces werden sich durchsetzen, Sub. Surfaces werden weitestgehend in der Animation verwendet. Und in 5-10 Jahren wird sowieso Alles mit Voxeln gemacht.

[Unregistered]

Der einzige Weg, wie Parametrisierte Flächen oder Subdivision Kram in die HW kommt ist eine relativ generische Primitive Assembly Language. Eines hat die Vergangenheit gezeigt, jede Technik hat ihre Vor- und Nachteile und jedes Tool arbeitet anders. Die Integration in die Artpipe entscheidet wesentlich eher über Erfolg/Mißerfolg eines Technik als deren mathematische Eigenschaften. Und hier haperts halt bei den parametrisierten Flächen, während die NPatches sich leicht integrieren lassen und sich deshalb durchsetzen.
Die Lösung: im Gfx Chip läuft ein dritter "Shader", der aus einem relativ generischen Datenstrom die eigentliche Polygone generiert. Diese Polygone werden dann an den Vertex Shader und von dort weiter an den Fragment Shader geschickt. Die Kunst ist es, die verschiedenen Algorithmen so zu abstrahieren, daß man mit relativ wenig Silikon und ohne Schleifen und Verzweigungen in der Sprache auskommt, so daß man das schnell und effizient umsetzen kann.
Aber nur auf diese Weise lassen sich imho HO Surfaces überhaupt sinnvoll in Game Engines integrieren. Bis man das allerdings in Hardware und erst recht in Software sieht, dürften einige Produktgenerationen vergehen. Also wird in der Übergangszeit der Schwerpunkt in Richtung NPatchtes gelegt werden.

Pitchfork

[RadioactiveMan]

@unregistered

Bei Subdivision Surfaces werden nur die Ecken nur gesmoothed, dies ist Blödsinn, man kann bei "ausgereiften" Subdivision Surfaces(also nicht so was billiges wie das alte 3ds Meshsmooth) definieren in welchem Grad die Kante abgerundet werden soll, man kann damit sowohl runde als auch eckige Oberflächen definieren, was für NURBS und andere parametrische Oberflächen eher zum Problem wird. Das Tesselieren eckiger Körper mittels Subdivision Surfaces hat besonders bei Per-Vertex- Lighting Vorteile, da dieses nur mit hochaufgelösten Meshes gut aussieht. U.a. wegen der schon von mir angesprochenen lokalen Auflösung(siehe oberes Posting), erreichen Subdivision Surfaces in Verbindung mit Displaced Maps exzellente Komprimierungsraten, Bandbreite sparen sie viel mehr als Nurbs/parametrische Patches.
In der Digital Production, dem Branchenblatt für DCC schlechthin, war vor etwa 3 Jahren nen Artikel über Subdivision Surfaces drin, in diesem haben auch Mitarbeiter von Pixar ihre Erfahrungen einfließen lassen, so etwa war die Rede davon, dass eine Szenenbeschreibung, die an dem Renderer übergeben wurde mit Subdivision Surfaces eine Größe von 1 GB hatte, mit NURBS hätte die gleiche Szene 5 GB Größe.
Trimming und boolesche Operationen gehen auch mit Subdivision Surfaces, womit sich eigentlich die Frage aufwirft, ob NURBS außer im Designbereich noch irgendeine Bedeutung haben werden.
Und das Voxel den Stein der Weisen darstellen, glaub ich auch nicht, Distance Fields und Surfels eignen sich um einiges besser für interaktive Sachen. ILM setzt, bsw. Distance Fields für Kizamu(Modellierwerkzeug der nächsten Generation) ein, voxelbasierte Modeller benötigen hier im Vergleich mehr Speicher und lassen sich eher schlecht als recht in andere "renderingfreundliche" Geometrierepräsentationen umsetzen im Gegensatz zu Distance Fields.

[Fragman]

man sollte endlich von der vorberechnung der poly daten durch die cpu weg. ich glaube hier liegt der spruechwoertliche hund begraben. die gamewelten sollten wenigstens teilweise automatisiert enstehen, wie man es schon seit jahren in der filmindustrie einsetzt. das geht aber nicht mit den heutigen beschleunigern. man kann heute keine graphisch detaillierten games machen, wenn ne lahme " ich kann alles " cpu die vorarbeit leisten muss. die kritik musste sich auch schon der g1 gefallen lassen, selbst mit ner einigermassen programmierbaren shadereinheit wurde das prob aber nicht angegangen, da frage ich mich warum. anscheinend wollen die game programmierer die daten wohl doch lieber vorgefertigt, weils wohl einfacher ist damit umzugehen. deshalb glaub ich nicht, das wir in naher zukunft solche exotischen sachen wie hos sehen werden, die sind einfach nicht so gut kontrollierbar wie einzelne polys. im g4 wurde das faeture treiberseitig deaktiviert, es nutzt einfach keiner. selbst nv kann niemanden vorweisen, der das dann auch nutzen will, obwohl die ja immer mit ihren techdemos und gameankuendigungen der zeit meilenweit voraus sind. wie schon gesagt, ich hoffe auf voxel, fuer alles andere fehlt die bandbreite und die wird auch in zukunft nicht wesentlich mehr.

gruss, Fragman

[Fragman]

@ RadioactiveMan:
gibts zum thema distance fields nen link?
die tech interessiert mich naemlich.

gruss, Fragman

[RadioactiveMan]

@ Fragman

hier gibts nen Haufen Papers(pdf) zu dem Thema:
http://www.merl.com/projects/adfs/

Ich gebe Voxels(Achtung Off topic ;) ) höchstens eine reele Chance bei richtigen 3d Displays, denn da kann man sich ja auf eine Auflösung verständigen wie bei 2d Displays üblich(640x480 bzw. 1024x768). Wie aber auch im 2d Bereich wird man eher beim Design auf skalierbare Lösungen setzen(Stichwort Vektorgrafik), es macht wohl kaum Sinn das gleiche Voxelgebilde auf einem kleinen 3d Handydisplay darzustellen das man im zukünftigen hochauflösenden 3D Kino sieht.
So toll die Zukunft auch sein mag, Limitationen bezüglich Speicherung und Übertragung wird es wohl immer geben und gerade da machen solche fixen Einteilungen wie Pixel oder Voxel bei 3D Objekten nur wenig Sinn, da sie bei extremen Closeups leicht verpixeln( oder vervoxeln ? ;) ) können.

[jor]

@Radiactive

Also noch mal! Subdivision Surfaces werden sich definitiv nicht durchsetzen, denn wenn, dann hätten diese es sicher schon getan, weil diese sehr einfach zu implementieren sind. Im Artikel, den du ansprichst wird sicher bei NURBS die Größe der tesselierten Szene angegeben, die sicher über die Größe einer Szene die mittels Subdivision Surfaces liegt. Man kann aber doch davon ausgehen, daß die Szenengrößen eventell ähnlich groß sind, wenn man die Kontrollpunkte von parametrischen Oberflächen mit den Modell vor der Anwendung von Subdivision Surfaces vergleicht (1 Vertex = 1 Kontrollpunkt). Ich empfehle jedem mal sich kommerzielle Demos von SubSurf anzuschauen, wie z.B. das Intel/Digimation Demo, dann kann jeder sich sein eigenes Bild machen.

"Das Tesselieren eckiger Körper mittels Subdivision Surfaces hat besonders bei Per-Vertex- Lighting Vorteile, da dieses nur mit hochaufgelösten Meshes gut aussieht."
dazu:
Das tolle an Curved Surfaces ist ja, daß das Modell beliebig hoch aufgelöst werden kann, wenn dies im GPU - passiert bleibt die belastung des AGP-Bus konstant. Die "Auflösung" hängt dann nur noch von der Leistung des GPUs ab.

Zu den Distance Fields:
Soweit ich dem Artikel entnommen habe sind die Unterschiede bei einer kleineren Auflösung nicht so groß. Das könnte schon für die Zuknunft Bedeutung haben, aber in den nächsten 3-5 Jahren nicht in der Echtzeit-3D Grafik.

Wie gesagt, ich denke nur das sich SubSurf nicht in der Echtzeit 3D-Grafik durchsetzen, in der Computeranimation spricht nichts dagegen.
Voxels oder ähnliche Renderverfahren, welche auf Volumen basieren (ADFs) werden wie gesagt in nächster Zukunft auch keinen Einfluß auf die Echtzeit-3D Grafik haben.
Wenn ich hier von Echtzeit 3-D Grafik rede meine ich natürlich für jeden zugängliche und kommerziell verwertbare Software, wie Spiele oder ähnliches. Es kann schon sein, das sich in CAD/CAM Anwendungen solche Verfahren eher durchsetzem, dort gibt es ja auch schon Curved Surfaces länger. Volumenrendering macht hier aber durchaus Sinn.

[RadioactiveMan]

@ jor

Nö, dieser Vergleich war keineswegs NURBS Modell nach der Tesselation vs. Subdivision Surfaces vor der Tesselation.

Aus einem Intel Dokument bezüglich NURBS:
Non-local refinement not supported - When refining a surface (i.e. adding detail), you must
add control points in complete rows and columns so the control mesh remains a regular grid
of points. This causes excessive control points to be added just to add detail in a small,
localized region of a surface. Note that this is not an implementation issue, but rather an
issue with NURBS surfaces (and other parametric surfaces).

http://cedar.intel.com/software/idap/media/pdf/games/real_time_nurbs.pdf
ich hasse es mich zu wiederholen(lies meine Erklärung im ersten Posting) , die fehlende Lokalität(und den damit verbundenen höherem Speicherbedarf als bei Subdivisions) ist nun mal einer der Hauptschwachpunkte von NURBS.

Intel stellt zu daraus resulierenden Schwierigkeiten und deren aufwendiger Lösung ein nettes Tutorial bereit:
http://cedar.intel.com/cgi-bin/ids.dll/content/content.jsp?cntKey=Generic%20Editorial::nurbsii&cntType=IDS_EDITORIAL

Die Demo von Intel/Digimation ist technisch veraltet, die darin eingesetzten Subdivision Surfaces sind eher einfacher Bauart, State of Art ist derzeit dies hier http://multires.caltech.edu/software/fastsubd/index.html
Diese Subdivision Surface Libary optimiert auf PIII/PIV, zeigt bezüglich Cachegängigkeit/ FPU Auslastungen sehr gute Werte (siehe das dazugehörige fastsubd.pdf ), einen NURBS SW Tesselierer mit ähnlicher Effizenz habe ich noch nicht gesehen.


Das tolle an Curved Surfaces ist ja, daß das Modell beliebig hoch aufgelöst werden kann, wenn dies im GPU - passiert bleibt die belastung des AGP-Bus konstant. Die "Auflösung" hängt dann nur noch von der Leistung des GPUs ab

Redest du hier von SW Subdivision im Vergleich HW NURBS? In bezug auf die Zukunft spreche ich eher von Subdivision Surfaces in HW, also in der GPU, die obengenannte Implementation lässt sich auch sehr gut mit längere Pipelines und viele parallele Ausführungseinheiten nutzen. Ein anderer Ansatz, der sich gut für Subdivision Surfaces eignet( bei den Clark Catmull Surfaces in Pixars Renderman etwa) ist forward differencing, welches schon in ähnlicher Weise bei NVIDIAs derzeitigen HOS genutzt wird.
Das Argument das sich Subdivision Surfaces nicht durchsetzen werden kann ich nicht ganz nachvollziehen, bei PS2 gibt es zahlreiche Engines die bestimmte Objekte mit Subdivision Surfaces rendern, ohne entsprechende HW können die ganzen Vorteile von Subdivision Surfaces im interaktiven Bereich nicht genutzt werden, bei der Reyes Pipeline(Renderman - nächstes Ziel der 3d Echtzeit Grafik) zeigen sich aber auch schon die Vorteile gegenüber NURBS.
Oder wie sonst erklärt man sich erklären, dass Square während ihrer Produktion" Final Fantasy The Movie" von NURBS auf Subdivision Surfaces umgeschwenkt sind. A Bug's Life wurde ja auch mit NURBS angefangen(wie Toy Story1), nachdem aber bei der Produktion von Geri´s Game die Vorteile von Subdivision Surfaces erkannt wurden, entschied man sich damals auch für den größeren Film für die "neue" Technik. Während die Entwicklung von NURBS stehengeblieben ist, entwickeln viele Forscher Technologien auf Basis, bei den 3d Tools wird der Fokus auch auf besseren Subdivision Surface gelegt(bsw. bei Softimage XSI 2.0, Maya 4 Unlimited, 3dsmax 4.x).

[jor]

@Radiactive

Ähm, das hinzufügen von Details (Lokaltität) hat bei NURBS genau so wie bei Subdivision Surfaces den Nachteil, dass noch zusätzliche Controllpunkte oder Vertices eingefügt werden müssen. Bei beiden Verfahren!
Ok, es ist ja klar, dass es wünschenswert ist diese Verfahren in der Hardware auszuführen. Es ist nur keine Hardware die das macht in Sicht, da war NVIDIA im Bezug auf die parametrischen Oberflächen schon weiter.
Wie Du schon sagst werden Subdivision Surfaces hauptsächlich in der Computer-Animation verwendet, aber nicht in der Echtzeitgrafik.

[Xmas]

Originally posted by jor
Ähm, das hinzufügen von Details (Lokaltität) hat bei NURBS genau so wie bei Subdivision Surfaces den Nachteil, dass noch zusätzliche Controllpunkte oder Vertices eingefügt werden müssen. Bei beiden Verfahren!

Wenn du bei Subdivision Surfaces an einer bestimmten Stelle Details hinzufügen willst, dann fügst du nur dort neue Kontrollpunkte ein (Edit: Das kommt natürlich auf die Art der SS-Implementierung an). NURBS dagegen brauchen ein rechteckiges Kontrollpunkt-Raster, also werden über die gesamte Fläche mehr Kontrollpunkte benötigt. Oder du zerlegst in mehrere Patches, was auch nicht optimal ist.


Im Übrigen, ich bin wirklich begeistert, wie sich dieser Thread bisher entwickelt hat, und konnte doch noch ein bisschen Material sammeln. Big THX für die Links und Infos =).

[jor]

High order primitive rendering. A wonderful thing - a model loses its angles and becomes smooth and round! Unfortunately there works a support for splines and not for subdivision surfaces, it means patch structure of models and problems of smooth connection of patches - and this complicates modeling process by ten times! That's why I think that not all application developers turn to this interesting feature of the DX8. High order primitive rendering requires hardware support.

Quelle: http://www.digit-life.com/articles/dx8faq/

[jor]

The idea of higher order surfaces sounds great. However, it actually sounds too good to be true. I feel as if this feature was merely implemented into GeForce3 to ensure its full DirectX8 compatibility. We will see if the performance of games with higher order surfaces will be acceptable on GeForce3. First of all we need a game that uses it.

Quelle: http://www6.tomshardware.com/graphic/01q1/010227/geforce3-30.html

Ja unterstützt denn ATI auch parametrische Oberflächen, ist doch DirectX 8.1 kompatibel? Ich denke ATI unterstützt doch bisher nur NPatches?

[Fragman]

da liegt dann wieder das prob bei der integrierung in den 3d programmen. bei softimage zb kann ja patches ohne prob sauber verbinden (abstriche muss man im moment noch in xsi machen), komplexes modelling mit nurbs patches ist damit sehr leicht. wies bei maya oder 3d studio aussieht weiss ich nicht, glaube aber, dass man im moment noch mehr 3d studio einsetzt, oder? das nurbs modelling ist in 3d studio aber richtig mies ( wie das poly modelling allerdings auch). aber die firmen steigen ja auch langsam um und selbst bei softimage hat man erkannt, das man mehr tools fuer die spieleentwicklung bereitstellen muss. das war in der vergangenheit wohl auch ein grosser hinderungsgrund, der so langsam ausgeraeumt wird. allerdings muss man dann auch sagen, das wenn man nurbs flaechen die ganze zeit am zusammannaehen ist, dass man auch gleich sub divs benutzen kann, macht weniger arbeit, geht schneller, und mit den heutigen tools kann man auch sehr detailliert modelln, sind dann eben mehr kontrollpunkte. da wird dann naemlich das prob liegen. selbst bei wenigen ausgangs polys beim modell hat man noch der sub div op ne ernorm hohe anzahl an sub div polys, die schnell in die hoehe schnellt, mit ein paar ausgangspolys mehr. da muessen die beschleuniger noch enorm zulegen. heute machts mehr sinn lieber ne menge polys so verbraten als sie in sub div modelle zu stecken, die dann schon alleine soviel polys haben wie vielleicht die levelumgebung schon alleine hat.

Fragman

[jor]

@Fragman

Genau meine Rede!