RT-Patches......

[HOT]

Hab grad beim stöbern was interessantes entdeckt.... anscheinend hat Nv die HOS Implementation nicht ohne Grund im DetoXP deaktiviert.... ich bin hier auf einen interessanten Artikel von Reactorcritical ( www.reactorcritical.com ) gestossen,


Not so long ago various sites reported that NVidia disabled its curved surfaces implementation, Higher Order Surfaces, for DirectX in DetnatorXP. The reason of this is the information from independent developers, according to which that in some of the games RT-triangles caused enabling emulation of N-patches/PN-triangles also know as ATI TruForm. Of course, such behaviour caused a big perfomance lost when using the GeForce3.


Damit sind die RT Patches wohl vorerst mal gestorben.....

[StefanV]

Hab ich das richtig verstanden:

Wenn NV ihr HOS enablen würde, dann würden Truform (N-Patches) Games auf einer GF3 in Emulation laufen??

[Xmas]

Das halte ich für ziemlich unwahrscheinlich. Denn diese Emulation müsste dann ja Teil von DirectX sein (wenn sie im Treiber wäre hätte NVidia sie ja einfach rausnehmen können statt RT-Patches zu deaktivieren). Insofern wäre es ein DX-Bug und wäre bestimmt mit DX8.1 behoben worden, oder soll das erst jetzt jemandem aufgefallen sein??

[HOT]

Vielleicht hat NV auch nur die Rechnung ohne den Wirt gemacht....

[nggalai]

Dies ist ein Gerücht, welches von The Inquirer (http://www.theinquirer.org/05120104.htm) in Umlauf gesetzt wurde, und darüber hinaus jeglicher technischer Grundlage entbehrt.

ta,
.rb

[Razor]

Kommt zwar ein bissel spät, aber eine Funktion im neuen Riva Tuner (2.0 RC9) weist darauf hin, daß diese Funktion tatsächlich (vorerst ;-) deaktiviert wurde...

So gibt es dort ein Patch-Script, welches es ermöglicht, die RTPatches (in D3D wohgemerkt !) zu 'unlocken', i.e. zu aktivieren. Dafür werden in der nvdd32.dll dann bestimmte Byte-Sequenzen ersetzt und somit die RTPatches wieder aktiviert. In OpenGL wird's weiterhin verfügbar sein, da es hier 'eh um Chip-Spezifische Erweiterungen geht und 'ati_' nun mal nicht mit 'nv_' verwechselt werden kann (und logischer weise in OpenGL auch weiterhin verfügbar ist).

Aber all das nützt überhaupt nichts, wenn es keine Anwendungen gibt, die die 'nv_'-Erweiterungen unter OpenGL nutzen und es generell noch keine Anwendung für Truform bzw. RTPatches unter D3D gibt (außer vielleicht die ATI-Techdemo's)...

Insofern viel Wind um gar nichts und wer's in D3D wieder haben möchte (für was eigentlich ?), der kann's dann ja wieder aktivieren, da die Unterstützung nicht entfernt, sondern lediglich dekativiert wurde.

Gilt im übrigen für die Deto's ab 21.8x...

In diesem Sinne

Razor

[nggalai]

Hi there,

dass RT-Patch-Support in den aktuellen NVIDIA-Treiber für D3D deaktiviert wurde ist klar (die Gründe jedoch ... das ist Spekulation. Ich tippe auf Marketing-Politisches).

Dass eine Applikation bei TRUFORM/N-Patch Aufrufen dann "in Emulation" von NV-Karten abgearbeitet werden soll und dass daher HOS-Support deaktiviert wurde, ist Unsinn.

RT-Patches werden unter D3D so aufgeführt: D3DDEVCAPS_RTPATCHES

TRUFORM/N-Patches so: D3DDEVCAPS_NPATCHES

Wie soll da der Treiber "verwirrt" werden und dann N-Patches trotz fehlendem N-Patch-Support "in Emulation" abarbeiten können? ??? Meinte der Urheber dieses Gerüchtes, dass es einfach einen, hmm, D3DDEVCAPS_HOSSUPPORT oder so gäbe? ;)

ta,
.rb

[Quasar]

Dazu fällt mir doch glatt was interessantes ein...

Von wegen, es gibt nix, was RT-Patches unterstützt....

Ihr habt doch sicher alle mal vom Aquamark geträumt, oder?

Nun ja, ab Det. v.21.81 lief die alte Version 2.2 nicht mehr. Und angeblich wurden in ihre für einige der Gegner RT-Patches verwendet..

Ich bin grad dabei, das Script vom Rivatuner auszuführen...mal schauen was draus wird.

[Razor]

@nggalai

Und was ist dann
D3DDEVCAPS_QUINTICRTPATCHES
???

Das wird durch das RivaTuner-Script ebenfalls wieder 'aktiviert'...

@Quasar

Gibt's den Aquamark denn nun endlich irgenwo im Netz ?
???

Razor

[aths]

nggalai,

du vermutest also auch, dass HOS-Support mit dem NV25 groß vermarktet wird?

[nggalai]

aths,du vermutest also auch, dass HOS-Support mit dem NV25 groß vermarktet wird?Jupp. Sie können's zwar nicht als "echtes neues Feature" anpreisen, da's schonmal gelaufen ist (und auch damit geworben wurde), aber es wäre gut denkbar, dass das dann so laufen wird:

"Dank der zweiten frei programmierbaren Vertex-Shader-Einheit bieten NVIDIA Ti-1000-doppelplusgut-Karten erstmals schnelle Unterstützung von professionellem HOS im Consumer Markt für noch realistischere Modelle ..."

OK, einige Bindestriche zuviel, but you get my drift. ;)

ta,
.rb

[HiddenGhost]

Originally posted by nggalai
aths,Jupp. Sie können's zwar nicht als "echtes neues Feature" anpreisen, da's schonmal gelaufen ist (und auch damit geworben wurde), aber es wäre gut denkbar, dass das dann so laufen wird:

"Dank der zweiten frei programmierbaren Vertex-Shader-Einheit bieten NVIDIA Ti-1000-doppelplusgut-Karten erstmals schnelle Unterstützung von professionellem HOS im Consumer Markt für noch realistischere Modelle ..."



H(igh)O(rder)S(urfaces)(?). Ich dachte ,das ist die Technik ,die sich Hinter den RT-Patches verbirgt. Wieso wollen die die neuanpreisen, wenn die doch schwer zu emplementieren sind => geringe Unterstützung, bei Games ,o.ä.

MfG PCg

[aths]

N-Patches sind auch HOS. Die Implementierung in heutige Engines mag schwer sein. Wird eine Engine aber erst mal auf HOS als zum Dreieck alternative Fläche ausgelegt, lassen sich viele Formen viel einfacher erstellen. Ausserdem kommt eine HOS mit recht wenig Kontrollpunkten aus. Das vermindert die Datenflut über den AGP-Bus und bringt anderweitige Vorteile (wie adaptive Tesselation usw.)

[HiddenGhost]

Originally posted by aths
N-Patches sind auch HOS. Die Implementierung in heutige Engines mag schwer sein. Wird eine Engine aber erst mal auf HOS als zum Dreieck alternative Fläche ausgelegt, lassen sich viele Formen viel einfacher erstellen. Ausserdem kommt eine HOS mit recht wenig Kontrollpunkten aus. Das vermindert die Datenflut über den AGP-Bus und bringt anderweitige Vorteile (wie adaptive Tesselation usw.)

Mir ist schon der Vortil und Funktionsweise des HOS (jedenfalls für N-Patch)klar,und dass Games mit HOS-Engines deutlich besser aussehen und mehr davon profitieren wüeden würden,wenn sie darauf aussgelegt wären, da die Engine Mdels mit weniger Polygonen zur Graka schicken könnte, die diese dann in hardware aufwerten kann.ich verhaspel mich aber leider immer mit den ganzen Bezeichnungen dafür.

MfG PCg

[aths]

PCgenius,

wenn du dir die Zeit nehmen würdest, kürzere Sätze zu schreiben, könntest du dein Anliegen sicherlich deutlicher darstellen.

[Quasar]

Weiß noch jemand von den älteren hier, wie das mit der nV1 gewesen ist?

Die ist ja total gefloppt, u.a. weil sie eben keine Dreiecke als Grundgerüst für ihr geometrisches Setup nutzte. Ähnlich, aber trotzdem völlig anders die Rendition v2200. Die war doch durch mikrocode-patches in gewissen Grenzen programmierbar, oder?
Manche haben dies als erste "frei" programmierbare GPu angesehen....


Eure Meinungen?

@Razor:
Ja, gibt es. allerdings passwortgeschützt und darf NICHT weitergegeben werden.

[Legolas]

Originally posted by Quasar
@Razor:
Ja, gibt es. allerdings passwortgeschützt und darf NICHT weitergegeben werden.

So wie die inoffizielle Aquanox 'Testversion' *eg*:D:D ;D

[Ceiser Söze]

Der NV1 unterstützte meines Wissens als Standardprimitive sog. "Quadratic Texture Maps", ein NURBS-Derivat. Die Idee war eigentlich gar nicht mal so schlecht: Mit QTM wäre bei der Darstellung von ruden Oberflächen rein theoretisch ein hoher Detailgrad möglich gewesen, ohne dabei die CPU-Last stark zu erhöhen - man hätte ja eine Kurve nicht zuerst in Dutzende von Dreiecken zerlegen müssen.
Nachteil: QTMs sind im Vergleich zu Polygonen ein ziemlich komplizierte Sache und darum konnten sich die Entwickler kaum damit anfreunden (John Carmack hasste, soviel ich weiss, die QTMs regelrecht *g*). Naja, und als dann Microsoft auf Empfehlung der Spielentwickler mit Direct3D auf Dreiecke setzte, wars vorbei mit dem NV1...

[Fragman]

@razor:
der aquamark war auf meiner treiber cd von meiner g3 ti 200(elsa) drauf, laeuft aber nicht, findet wohl genuegend graphikram :);
"out of videomemory" kommt dann immer wenns ich starte.
ich persoenlich glaub nicht, dass es noch kommen wird, die aquanox veroeffentlichung ist ja auch schon ein weilchen her.

gruss, fragman

[Quasar]

Dann installier mal nen Detonator vor Version 20.80, bsw. 12.41. Damit würd's laufen *g*

HOS sag ich nur...

[Xmas]

Originally posted by Razor
[B]Und was ist dann
D3DDEVCAPS_QUINTICRTPATCHES
???

Das wird durch das RivaTuner-Script ebenfalls wieder 'aktiviert'...
Quintic Patches sind Patches 5. Grades, die der GF3 (zumindest unter OpenGL) gar nicht beherrscht. Deshalb verwundert es mich etwas, dass das durch den RivaTuner "wieder" aktiviert wird...
Seltsamerweise gibt es unter D3D keine Patches vierten Grades.

[Razor]

@Fragman & Quasar

Der Aquamark ist auf 'ner Treiber-CD, Paßwortgeschützt und darf nicht weiter gegeben werden ?
???

Hmmm...
Und die D3D-RT-Patches können wi gesagt auch in den aktuellen Treibern vie RiveTuner 'frei' geschaltet werden...

@Xmas

Sehr schön...
Und was sagt uns das jetzt ?
???

Bis dann

Razor

[aths]

Also ich hab Xmas' Posting verstanden...

SCNR :)

[Xmas]

Originally posted by Razor
@Xmas

Sehr schön...
Und was sagt uns das jetzt ?
???
Na dir anscheinend nix ;)
Ich hoffe das werd ich bald etwas umfangreicher erklären können. Aber jetzt hier eine Kurzbeschreibung für Bézier-Patches fünften Grades, das bringt einfach nix...

[Quasar]

Moin Razor.

Also, was Fragman da bekommen hat auf seiner Treiber-CD weiß ich nicht, bin aber einigermaßen sicher, daß es nicht der Aquamark ist, sonst würde der nicht so streng bewacht ;)

Ich weiß nur, daß in irgendeiner Readme von dem Ding drinsteht, daß einige der Feinde mittels HOS erstellt wurden. Das war bis einschl. Version 2.2 so. Als nVidia dann aber ab Det. 20.80 die RT-Patches und damit die HOS deaktivierte, funktionierte der Aquamark nicht mehr. Ein Patch auf Version 2.3 brachte dann Besserung, so daß auch ohne HOS diese Gegner erstellt werden können.

[Fragman]

hab die treiber 14.40 installiert( ist die niedrigste version, die mit meiner ti 200 laeuft!) und damit laeuft aquamark ohne probs.

eine frage stellt sich mir aber: wenn man aquamark nur mit rt-patch unterstuetzung laufen lassen kann, wo kamen denn damals die g2 benches vom aquamark her? dann waren die wohl auch nur marketing mist von nv?

gruss, Fragman

[Fragman]

die aquamark version ist die 2.0 und sie ist nicht passwortgeschuetzt.
der benchmark zeigt die bilder, die auch im netz zu finden sind.
einige der bilder auf der offiziellen aquanox homepage sind uebrigens aus dem benchmark.

habe uebrigens bei max detail durchschnittlich 31,7 frames.

gruss, Fragman

[Quasar]

In den 14.40ern sind die RT-Patches auch noch drin. Was die Benches mit anderen Karten angeht, so denke ich, das da im Treiber gleich gesagt wird: Moment, hier kein DX8, schick deine Dreiecke mal schön zur CPU. Bei der GF3 wurde eben davon ausgegangen, daß es funktioniert, also gleich bei Erkennen derselben die HOS-Feinde ausrücken lassen....

Version 2.0 ist nicht mehr allzu aktuell...bei welcher Auflösung hast du denn 31,7fps und was hast du sonst noch so eingestellt?

[aths]

Ich glaube, ich kauf mir doch keine NV20-Karte...

[Saukopp]

Aths und NV20? Ist doch ein Widerspruch in sich, eher friert die Hölle zu.

scnr

[Fragman]

@quasar:
die 31.7 frames sind bei 1024*768*32 bit
interessant ist, dass bei aktiviertem aa (2 samples)in dieser aufloesung kaum ein geschwindigkeitsverlust auftritt (30,8 frames)
30,5 frames sinds noch bei 1280*1024*32 bit,
bei 1600*1200*32 sinds immerhin noch 25,7

das der bench schon aelter ist, sieht man unter anderem an den noch alten explosionen, die aber nen coolen unterwsasserimplosionseffekt haben.

die einheiten sind glaub ich nen tuck detaillierter, jedenfalls sieht die phobocaster im bench runder aus. in aquanox ist das schiff eckiger.

gruss, fragman

[HOT]

Sieht so aus, als würde die Aquamark eine üble Geometriegeschwindigkeit haben. Vielleicht wegen den RT-Patches? Kann natürlich auch auf schlewchte CPU Optimierungen zurückzuführen sein, aber das halte ich für eher unwahrscheinlich.
Die Renderingleistung der Geforce3 scheint die Aquamark 2.0 jedenfalls kaum zu belasten.

[Fragman]

muss nochmals kurz korregieren, ich hab die aquamark 2.1 version, steht naemlich so in der txt-datei, die der benchmark ausspuckt.

hab gestern ausserdem noch massive per mail angeschrieben, ob ich vielleicht ein update auf meine aquamark version haben koennte (wegen dem ganzen rt-patch prob). kurze zeit spaeter kam eine mail zurueck, mit dem link auf den aquamark bereich. dort wurde dann gestern noch die seite aktualisiert, und darin steht auch, das massive keinen support fuer diese version anbietet.

gruss Fragman

[Quasar]

Aquamark v2.3, PS: on, 40MB Texturen, kein FSAA:

1024x768x32: 53,3 fps
1600x1200x32: 28,1 fps

[Razor]

@aths

"Also ich hab Xmas' Posting verstanden... "

Also Deine Kommentare waren auch schon mal sinniger...
Schön für Dich !
;-)

"Ich glaube, ich kauf mir doch keine NV20-Karte..."

Was Du ja 'eh nie vorhattest, also eher 'ne Null-Bemerkung, gell ?
;-)

@Xmas

Meine Frage war eigentlich nicht auf die Erklärung von "Bézier-Patches fünften Grades" gezielt, sondern vielmehr auf den Hintergrund Deiner Bemerkung:

"Quintic Patches sind Patches 5. Grades, die der GF3 (zumindest unter OpenGL) gar nicht beherrscht. Deshalb verwundert es mich etwas, dass das durch den RivaTuner "wieder" aktiviert wird...
Seltsamerweise gibt es unter D3D keine Patches vierten Grades."

Du schreibst, daß die gf3 Patches 5.Grades nicht unterstützt, obwohl diese im D3D-Treiber von nVidia ja offensichtlich aktiviert werden können. Insofern vermute ich mal, daß die OpenGL-Extensions dafür schlicht noch fehlen, oder wie war sonst Dein Post gemeint ?

@Quasar

Das der Aquamark nicht auf 'ner Treiber-CD zu finden ist, hab' ich mir schon gedacht !
;-)

Und klar, daß dieser RT-Patches nutzen soll hab' ich auch schon mitbekommen und auch (ist ja der Inhalt dieses Thread's ;-), daß die neueren Deto's dies deaktivert haben...
(mit welchem Hintergrund auch immer)

Und ich will auch endlich mal den Aquamark live sehen, auch um Unterscheide zur Retail-Verision festzustellen und zu beurteilen, ob sich Aufwand (i.e. Performance) gegen Ergebnis lohnt.

Aber das wird wohl ein kleiner Traum bleiben...
:-(

Bis denne

Razor

[aths]

> "Ich glaube, ich kauf mir doch keine NV20-Karte..."

"Was Du ja 'eh nie vorhattest, also eher 'ne Null-Bemerkung, gell ?"

Da hast du wohl was überlesen.

[Xmas]

Originally posted by Razor
Du schreibst, daß die gf3 Patches 5.Grades nicht unterstützt, obwohl diese im D3D-Treiber von nVidia ja offensichtlich aktiviert werden können. Insofern vermute ich mal, daß die OpenGL-Extensions dafür schlicht noch fehlen, oder wie war sonst Dein Post gemeint ?
Razor, mein Post war genau so gemeint, wie es da steht. Unter OpenGL unterstützt die GF3 keine Patches 5. Grades, sondern maximal bikubische Patches. Da ich nicht glaube, dass NVidia diese Hardwarefähigkeit unter OpenGL absichtlich sperrt, läßt dies nur den Schluss zu, dass es ein Fehler vom RivaTuner ist, D3DDEVCAPS_QUINTICRTPATCHES "wieder" zu aktivieren.

[Razor]

@Xmas

Das müsste dann aber ein beabsichtigter Fehler vom RivaTuner sein...
Hier mal ein Auszug aus dem zugehörigen Dialog:
This patch unlocks the driver's D3DDEVCAPS_QUINTICRTPATCHES and D3DDEVCAPS_RTPATCHES capabilities, which have been disabled in the Detonator 21.xx and higher.
Schon merkwürdig, gell ?
;-)

Schaun' wir mal...
Vielleicht gibt's ja doch irgendwann (!) mal zumindest Demo's, die einem Zeigen, ob und was damit zu machen ist.

Bis denne

Razor

P.S.: Würde auch einen kleinen Unterschied zwischen "absichtlich sperren" und "noch nicht implementiert haben" sehen...
;-)

[Xmas]

Razor, da gibt es nichts noch großartig zu implementieren. Die Extension existiert und ist für Patches jeglichen Grades ausgelegt. Nur bekommt man als Maximalwert vom Treiber 4 zurückgeliefert, was in diesem Zusammenhang Patches dritten Grades bedeutet.

[Razor]

Was doch aber bedeutet, daß es im Treiber eben nur bis "4" implementiert ist, oder sehe ich das falsch ?

Desewgen darauf zu schließen, daß es Hardwareseitig nicht unterstützt wird, halte ich für falsch...

Auch sage ich ja gar nicht, daß es unterstützt wird, sondern nur, daß der daraus resultierende Rückschluß nicht legitim ist. Gibt es nicht irgend etwas Offizielles zu dem Thema ? Irgend ein White-Paper oder ähnliches, welches dieses 'Feature' sepzifiziert ?

Würde mich wirklich interessieren !
;-)

Bis denne

Razor

[aths]

Wenn dich das wirklich interessiert, warum stellst du nicht selbst Nachforschungen an (und teilst uns dann das Ergebnis mit)?

[Quasar]

Da ich ja net so faul bin wie der Razor ;-) .....

Also, die GF3 unterstützt unter D3D folgende HOS-Formen (natürlich nur mit älteren Treibern..):
- Bezièr
- B-Splines
- Catmull-Rom

Ich spekulier jetzt mal, das sind HOS dritten, vierten und fünften Grades (mit Mathe kenn ich mich net aus.).

Unter OpenGL dagegen ausschließlich Bezier-Patches.

Also liegt hier kein Fehler des RivaTuner (die Skript-Patches vom Rivatuner könnte man auch RT-Patches nennen...) vor, sondern schlicht eine Limitierung in der Hardware der GF3.

Nachzulesen im Higher Order Surfaces Dokument (pdf) (http://developer.nvidia.com/docs/IO/1354/ATT/Surfaces.pdf) von Henry Moreton, Seiten 18-20.

[aths]

Quasar,

diese Bezeichnungen haben nichts mit dem Grad zu tun. Es gibt z.B. Bezier-Kurven und -Patches 2., 3., 4., ... n. Grades. B-Splines und Catmull sind andere Verfahren, um Curved Surfaces zu erzeugen.

[Xmas]

Sorry, ich hab mich vertan. Die 4 gilt für Rational Bézier Patches, für "normale" Bézier-Patches ist das Limit 8, also sind hier sogar maximal Kurven siebten Grades möglich. Ich erwarte allerdings noch eine Auskunft, was denn nun tatsächlich in Hardware berechnet wird.

[Quasar]

Diskussion erledigt, würde ich sagen, da die GF4 nun offiziell gar keine HOS mehr untersützt, nicht im Treiber und nichtmal mehr auf dem Papier.

Keine Ahnung, was nVidia sich dabei gedacht hat. Vermutlich wird das Ganze im GeForce5 praxisnäher (n-Patches & polynomiale Flächen) als neues Killer-Feature vermarktet....

Ich denke, die Hersteller täten beide (!) gut daran, die jeweilige Technologie von demjenigen zu lizenzieren, der sie als erstes am Markt hatte, dadurch gäbe es keine Inkompatibilitäten mehr und die Features würde deutlich schneller und umfangreicher genutzt, was sich letztlich auch in erhöhter Kauffrequenz des Kunden widerspiegeln würde.

[aths]

Quasar,

so hätte ich bis vor 2 Tagen auch noch argumentiert. Dann hörte ich zu, was John Carmack von Curved Surfaces hält: Nichts. Er erläuterte einige Probleme und Beschränkungen damit und schien den CS-Ausflug in Q3 zu bereuen. Für das Modellieren nutzt er natürlich weiterhin noch CS (welche dann aber im Voraus zerlegt werden.)

Ich fühle mich nicht firm genug, um CS vs. geometrisches LOD auf alle möglichen Eigenschaften hin abzuwägen.

Es ist immerhin denkbar, dass zusammen mit dem NV30 auch ein NV26 vorgestellt wird, sozusagen die "GeForce4Ti Ti" und hier als "neues" Feature HOS vermarktet würden, zusammen mit NV30. (Das Szenario halte ich allerdings für wenig wahrscheinlich.)

[Quasar]

Hast du vielleicht einen Link, zu dem erneuten Ausspruch des Carmacks? Der genaue Wortlaut würde mich schon interessieren, da ich eigentlich nicht glaube, daß JC sich so einfach davon abwendet.

[Xmas]

Interview 4 (http://gamespot.com/gamespot/filters/products/media/0,11100,469881,00.html)

Ich könnte mir folgendes vorstellen: Spekulation: So wie nggalai es beschrieben hat, hat NVidia die Entwickler gefragt, ob sie denn HOS verwenden wollen. Da das Feedback eher gering ausgefallen ist, hat sich NV dazu entschlossen, den HOS-Support beim GF4 zu streichen, um Transistoren zu sparen (vielleicht war das auch der eigentliche Hintergrund der Frage). Um dem GF3 nun keinen Vorteil gegenüber dem GF4 zu geben, wird auch der Treibersupport gestrichen... IMHO eine denkbar schlechte Entscheidung.

[aths]

Vielleicht könnten wir hier ein stilisiertes Streitgespräch führen. Ich stelle mich auf die Position, CS bräuchte es nicht (obwohl es dessen selbst nicht richtig überzeugt bin) und versuche, Argumente zu finden; während du pro CS argumentierst?

Ich würde morgen einen entsprechenden Thread aufmachen.

[Quasar]

Wen meinst du? Xmas oder mich?

[Frank]

Na dann mach mal aths

Bin auf alle Fälle pro CS - egal in welcher Hardware implementiert

[aths]

Quasar+Xmas, ich geh jetzt erst mal in die Mensa :)

Danach habe ich ein paar SC-Matches offen und dann leg ich los, hehe...

edit: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=11603