HL2-Engine vs Doom3-Engine

[(del676)]

ich hoff das hats bisher noch ned zu oft gegeben :biggrin:

aus 2. Hand sind mir inoffizielle Aussagen eines ID Entwicklers zugeflogen (Ex-Arbeitskollege hat mit dem ID Typen diskutiert)
laut ihm (ID) hat id mit der doom3 engine einen anderen weg als mit der Quake3 engine eingeschlagen, während bei der quake3 engine bei immer besserer hardware nicht wirklich viel bessere grafik zustandekam (in einem gewissen maße gabs schon wahnsinnige fortschritte, aber eben nicht so wie es hätte sein können) ist man bei der doom3 engine den weg gegangen eine engine zu programmieren die praktisch erst in 1-2 Jahren ausgereizt werden kann, und Doom3 also praktisch auf unterem niveau der engine spielt.

bei Hl2 allerdings soll das Game die Engine schon komplett ausreizen.

wenn dem so wäre, hätte die hl2 engine eine nicht gerade gute ausgangsposition?

kann das ein freak/guru bestätigen oder verwerfen?

[Skusi]

Ich bin zwar weder Freak noch Guru :redface: , würde aber gerne wissen woher du die Info hast HL2 würde die Source Engine komplett ausreizen.
Außerdem finde ich, daß die Q3 Engine im laufe der Jahre doch erheblich an grafischer Qualität zugelegt hat.
Und 3. glaube ich, daß gerade Zukunftssicherheit bei aktuellen und zukünftigen 3d Engines eine sehr große Rolle spielt. Und das beziehe ich auch auf die Source Engine, denke das mit leistungsfähigeren Rechnern da noch einiges rauszuholen ist.

[[dzp]Viper]

ich hoff das hats bisher noch ned zu oft gegeben :biggrin:

aus 2. Hand sind mir inoffizielle Aussagen eines ID Entwicklers zugeflogen (Ex-Arbeitskollege hat mit dem ID Typen diskutiert)
laut ihm (ID) hat id mit der doom3 engine einen anderen weg als mit der Quake3 engine eingeschlagen, während bei der quake3 engine bei immer besserer hardware nicht wirklich viel bessere grafik zustandekam (in einem gewissen maße gabs schon wahnsinnige fortschritte, aber eben nicht so wie es hätte sein können) ist man bei der doom3 engine den weg gegangen eine engine zu programmieren die praktisch erst in 1-2 Jahren ausgereizt werden kann, und Doom3 also praktisch auf unterem niveau der engine spielt.

bei Hl2 allerdings soll das Game die Engine schon komplett ausreizen.

wenn dem so wäre, hätte die hl2 engine eine nicht gerade gute ausgangsposition?

kann das ein freak/guru bestätigen oder verwerfen?

hm bisher war es so, dass man aus jeder engine über die jahre noch sehr viel rausholen konnte (auch aus der quake3 engine)
So wird das auch bei doom3 und der Sourceengine sein.

[Coda]

Da ist schon was wahres dran. In Doom 3 sieht man immer nur sehr wenige Lichter, weil sonst die Performance noch übler einbrechen würde, deshalb isses auch so dunkel.
Bei HL² ist das Licht aber vollständig vorberechnet und statisch, da wird sich auch durch bessere Hardware nicht viel tun, außer mehr Polygone und höhere Auflösungen.
Der Vergleich hinkt aber gewaltig, weil beide einen ganz anderen Anspruch haben. HL² will Massentauglich sein und trotzdem gut aussehen, D³ will eine neue Enginegeneration einführen.

[Godmode]

Also ich denke mal die HL2 Engine ist noch nicht ausgelastet, denn man könnte noch viele Features Implementieren, wie zb HDR, Motionblur, Dynamische Beleuchtung,....

Bei der D3 Engine wären Außenareale interessant!

[(del676)]

Ich bin zwar weder Freak noch Guru :redface: , würde aber gerne wissen woher du die Info hast HL2 würde die Source Engine komplett ausreizen.

das meinte der ID Typ

[Coda]

Also ich denke mal die HL2 Engine ist noch nicht ausgelastet, denn man könnte noch viele Features Implementieren, wie zb HDR, Motionblur, Dynamische Beleuchtung,....
Ich denke er meint in ihrer derzeitigen Form.
Sonst könnte man ja überhaupt nicht mehr vergleichen, in D³ kannst du auch Radiosity einbauen, wenn du lustig bist.

[Godmode]

achso, das hab ich etwas falsch verstanden

mit mehr Details und so weiter, würde man aber bei HL2 sicherlich noch etwas näher an die Realität rücken.

[iam.cool]

Also ich persöhnlich halte die Source Engine nicht für sonderlich gut, HL2 und Vampires2 zeigen ziemlich gut das die Engine nur für kleinere Gebiete/Level geeignet ist und das halte ich nicht mehr für Zeitgemäss. Die Doom3 Engine wiederum verbraucht mir für das Grafisch gebotene zu viel Rechenleistung....
Von den aktuellen Engines halte ich die Cry Engine mit grossen abstand für die beste, da sie fast keine beschränkungen hat, mit der Cry Engine zb liesse sich auch ein RPG alla Morrorwind/Gothic mit einer grossen Welt realisieren, mit der Doom3 und Source Engine ist das nahezu unmöglich ATM.
Aber auch vom Technischen her ist die Cry Engine überlegen, Dynamische Lichtquellen (kann Source nicht) usw, sogar Nebel/rauch lässt sich anleuten was weder Doom3 noch HL2 bietet.




MFG

[Coda]

HL2 und Vampires2 zeigen ziemlich gut das die Engine nur für kleinere Gebiete/Level geeignet ist und das halte ich nicht mehr für Zeitgemäss.
Geeignet wäre sie wohl auch für größere Gebiete, das Problem ist nur das ewige Preprocessing, weil die Visibilitiy und vor allem das Licht per Radiosity eben vorberechnet sind.
Man könnte durchaus größere Bereiche machen, aber dann würde der Leveldesigner noch länger warten vor jedem Testlauf...

Die Doom3 Engine wiederum verbraucht mir für das Grafisch gebotene zu viel Rechenleistung....
Nein. Dynamische Lichter brauchen soviel Leistung, daran gibt es nichts zu rütteln.

Aber auch vom Technischen her ist die Cry Engine überlegen, Dynamische Lichtquellen (kann Source nicht) usw, sogar Nebel/rauch lässt sich anleuten was weder Doom3 noch HL2 bietet.
"Nebel anleuchten" sind Partikelsysteme mit Projektoren und das kann sogar UT2004. Und in Doom 3 habe ich es auch irgendwann mal gesehen in nem Techndemo, das ist auch nicht wirklich ein großes Problem technisch.

FarCry ist ein großes Mischmasch an verschiedenen Lichtsystemen (Lightmaps, Stencil und Shadowmaps), aber die Engine ist ziemlich unoptimiert wie wir im Forum schon öfter festgestellt haben. Radiosity für realistisches vorberechnetes Licht hat sie auch nicht (Pluspunkt an Source)

[Gandharva]

also wenn das stimmt und die source-engine wirklich schon ausgereitzt sein sollte dann gute nacht valve.

von der d³ engine ist in den nächsten jahren sicher noch einiges zu erwarten. alleine weil sie auf ogl basiert und ein völlig neuer ansatz dahinter steckt finde ich das sie lob verdient.

die bis jetz beste engine ist imo die cry-engine. nur leider haben die entwickler beim content-design von farcry völlig daneben gegriffen.

am schlechtesten finde ich die source-engine. sie bietet nämlich absolut nix neues und frisst noch dazu relativ viel leistung.

fazit:

1. Platz Engine: cry-engine (farcry)
2. Platz Engine: d³-engine
3. Platz Engine: source-engine (hl²)

1. Platz Content: hl²
2. Platz Content: d³
3. Platz Content: farcry

1. Platz Zukunftsorientierung: d³-engine
2. Platz Zukunftsorientierung: cry-engine
3. Platz Zukunftsorientierung: source-engine

[RLZ]

am schlechtesten finde ich die source-engine. sie bietet nämlich absolut nix neues und frisst noch dazu relativ viel leistung.

mhh? (http://www2.ati.com/developer/gdc/D3DTutorial10_Half-Life2_Shading.pdf)
Wenn man sich damit mal richtig auseinandersetzt, kommt man aber zu ner anderen Meinung als du sie hast ;)

[iam.cool]

Radiosity für realistisches vorberechnetes Licht hat sie auch nicht (Pluspunkt an Source)


Warum solte die Cry Engine auch Radiosity beherschen wenn sie Dynamische Lichtquellen ohne grossen Performanceverlust berechenen kann, Dynamischen Licht ist vorberechnetem immerr überlegen was Realismus angeht(HL2 Taschenlampe lol) :wink:

[Benedikt]

Also ich persöhnlich halte die Source Engine nicht für sonderlich gut, HL2 und Vampires2 zeigen ziemlich gut das die Engine nur für kleinere Gebiete/Level geeignet ist und das halte ich nicht mehr für Zeitgemäss. Die Doom3 Engine wiederum verbraucht mir für das Grafisch gebotene zu viel Rechenleistung....
Von den aktuellen Engines halte ich die Cry Engine mit grossen abstand für die beste, da sie fast keine beschränkungen hat, mit der Cry Engine zb liesse sich auch ein RPG alla Morrorwind/Gothic mit einer grossen Welt realisieren, mit der Doom3 und Source Engine ist das nahezu unmöglich ATM.
Aber auch vom Technischen her ist die Cry Engine überlegen, Dynamische Lichtquellen (kann Source nicht) usw, sogar Nebel/rauch lässt sich anleuten was weder Doom3 noch HL2 bietet.
1.) Was denkst du denn, wie beispielsweise die roten Leuchtfackeln realisiert sind, wie sie die Combine in manche dunkle Levelabschnitte werfen?
2.) Die Taschenlampe?

MFG,
B. W.

[Benedikt]

FarCry ist ein großes Mischmasch an verschiedenen Lichtsystemen (Lightmaps, Stencil und Shadowmaps), aber die Engine ist ziemlich unoptimiert wie wir im Forum schon öfter festgestellt haben. Radiosity für realistisches vorberechnetes Licht hat sie auch nicht (Pluspunkt an Source)
Kannst du uns ein Beispiel sagen oder per Screenshot zeigen, wo in Half-Life 2 Radiosity-Licht vorkommt, was kann man sich darunter vorstellen? Die Deckenlampen? Die Scheinwerfer, die mit dem "Lichtstrahl"? Oder was?
Was mir auffiel, ist dass manche Beleuchtungseffekte in Half-Life 2 ähnlich sind zu Max Payne 2, was ja AFAIK auch Radiosity unterstützt...

MFG,
B. W.

[Coda]

Radiosity ist für die Lightmap-Berechnung zuständig. Das ist ein globales Beleuchtungsmodell, daraus resultiert auch der realistische Look von HL².
D.h. Licht kann auch indirekt einfallen.
Kannst dir also einen beliebigen Screenshot aussuchen, jede Wand ist mit Radiosity beleuchtet ;)

1.) Was denkst du denn, wie beispielsweise die roten Leuchtfackeln realisiert sind, wie sie die Combine in manche dunkle Levelabschnitte werfen?
2.) Die Taschenlampe?
1.) Der gleiche Fake den Quake 1-3 auch schon verwendet hat. Auch kein wirkliches dynamisches Licht.
2.) Projektor. Das ist kein dynamisches Licht, sondern auch ein Fake.

Hier ist aber sehr schwer eine Grenze zu ziehen. Für mich muss dynamisches Licht auch dynamische Schatten beinhalten und das hat HL² nicht.

Warum solte die Cry Engine auch Radiosity beherschen wenn sie Dynamische Lichtquellen ohne grossen Performanceverlust berechenen kann, Dynamischen Licht ist vorberechnetem immerr überlegen was Realismus angeht(HL2 Taschenlampe lol)
Weil dynamisches Licht nur direkt beleuchten kann, was nicht sehr realistisch ist. D.h. nein, es ist sogar sehr unterlegen was realistischen Look angeht, auch wenn die Szene dann statisch ist.

[IVN]

Kannst du uns ein Beispiel sagen oder per Screenshot zeigen, wo in Half-Life 2 Radiosity-Licht vorkommt, was kann man sich darunter vorstellen? Die Deckenlampen? Die Scheinwerfer, die mit dem "Lichtstrahl"? Oder was?
Was mir auffiel, ist dass manche Beleuchtungseffekte in Half-Life 2 ähnlich sind zu Max Payne 2, was ja AFAIK auch Radiosity unterstützt...

MFG,
B. W.

Go up,and take a look at RLZ's post.The pdf is from ATI,but it shows all those wonderful features of the source engine.

[Kladderadatsch]

vorsicht- sehr wenig ahnung

mir stellt sich gerade die frage, ob die engines überhaupt "wgf-kompatibel" sind. oder hat das damit nichts zu tun?

und ist dann eine engine, deren shader (oder was wird auf dx, bzw. dann wgf optimiert?) auf wgf optimiert sind, nicht den alten immer überlegen?

jetzt müsste man halt wissen, wo die unterschiede zwischen dx und wgf sind:tongue:

ich will blos einhaken wegen der "zukuntssicherheit" der 3 engines...

[mapel110]

vorsicht- sehr wenig ahnung

mir stellt sich gerade die frage, ob die engines überhaupt "wgf-kompatibel" sind. oder hat das damit nichts zu tun?

und ist dann eine engine, deren shader (oder was wird auf dx, bzw. dann wgf optimiert?) auf wgf optimiert sind, nicht den alten immer überlegen?

jetzt müsste man halt wissen, wo die unterschiede zwischen dx und wgf sind:tongue:

ich will blos einhaken wegen der "zukuntssicherheit" der 3 engines...

Longhorn wird auch noch dx9 supporten, daher wirds da keine Probleme geben.
Und zukünfige Games werden dann wohl mehr oder weniger beide APIs getrennt unterstützen, wobei ich nicht glaube, dass es ein zu grosser Aufwand werden wird. Dafür wird M$ schon sorgen.

[Fruli-Tier]

am schlechtesten finde ich die source-engine. sie bietet nämlich absolut nix neues und frisst noch dazu relativ viel leistung.


Ich habe vor ca 30 Minuten HL2 auf einem XP2000 mit GF4Ti4800 un nem GB RAM gesehen. Das ganze in 1024x768 und absolut nice Spielbar. Und das mit einer gut ansehnlichen Optik, zumal ich sowieso noch keinen Vergleich zu einem High End System mit Full Detail habe, hat mich die Grafik schon beeindruckt. Ich weiss jetzt nur nicht, welche Einstellungen vorgenommen wurden.

Im Vergleich mit den andren Engines sehe ich Doom3 jedoch als Schlusslicht, sollte sie auch noch so ausbaufähig sein, in ihrer derzeitigen Verwendung ist man designtechnisch zu eingeschränkt, was deutlich im Doom3 Leveldesign zu sehen ist.

Far Cry bietet eigentlich alles, HL2 kann ich so direkt noch nicht sagen, habe nur ca 45 Minuten bei einem Kumpel gesehen.

[Coda]

Far Cry bietet eigentlich alles
Bis auf Radiosity und anständige Performance ;)

[mapel110]

Bis auf Radiosity und anständige Performance ;)

es gibt ja diese 64bit Benchmarks von Farcry, wo das Game 40% (?!) zulegen konnte. Kann das also sein, dass der 32bit extra ausgebremst wurde?!

[Kladderadatsch]

es gibt ja diese 64bit Benchmarks von Farcry, wo das Game 40% (?!) zulegen konnte. Kann das also sein, dass der 32bit extra ausgebremst wurde?!

nö. dann hätte amd dick geblecht und im intro wär ein bisschen werbung gewesen...

[Coda]

Die 40% sind wohl an sehr speziellen Stellen, ich denke nicht das durch x86-64 soviel durchschnittlich gewonnen werden kann.

[mapel110]

nö. dann hätte amd dick geblecht und im intro wär ein bisschen werbung gewesen...

http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_10543,00.html
;)

[Demirug]

Longhorn wird auch noch dx9 supporten, daher wirds da keine Probleme geben.
Und zukünfige Games werden dann wohl mehr oder weniger beide APIs getrennt unterstützen, wobei ich nicht glaube, dass es ein zu grosser Aufwand werden wird. Dafür wird M$ schon sorgen.

:D wenn das neuste Gerücht stimmt hat Longhorn kein DX9 mehr sondern nur noch WGF.

Allerdings dann gleich WGF 1.0 und WGF 2.0.

1.0 = DX9 plus ein paar Erweiterungen da die Longhorn braucht.
2.0 = Das was bisher als DX Next bzw WGF bekannt war.

[mapel110]

:D wenn das neuste Gerücht stimmt hat Longhorn kein DX9 mehr sondern nur noch WGF.

Allerdings dann gleich WGF 1.0 und WGF 2.0.

1.0 = DX9 plus ein paar Erweiterungen da die Longhorn braucht.
2.0 = Das was bisher als DX Next bzw WGF bekannt war.

würde Sinn machen. Dann stirbt der Begriff Directx etwas eher. =)

Heissts dann also "alte Games" werden durch WGF 1.0 Fully supported :D

[Demirug]

würde Sinn machen. Dann stirbt der Begriff Directx etwas eher. =)

Heissts dann also "alte Games" werden durch WGF 1.0 Fully supported :D

Ja, das würde es wohl bedeuten.

[Kladderadatsch]

http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_10543,00.html
;)

:tongue:
ok^^
kann man mit einem a64 32bit simulieren? dann würde man ja direkt sehen, ob eine als 64bit identifizierte cpu plötzlich höhere werte erziehlt...

aber die a64 rechnen doch ohnehin bisweilen in 32 bit? aber warum die dennoch schneller sind, ist mir schon immer ein rätsel...

[Coda]

Der Benchmark lief natürlich auf einer 64-bit Beta von Windows und einer speziellen FarCry Version im 64-bit Modus. Nix 32-bit.

Und das liegt garantiert nicht am "ausbremsen" von 32-bit. Das würde Crytek ja wohl nie machen, weil es z.Z. keine 64-bit OS gibt und bis es verfügbar ist FarCry eh nicht mehr großartig verkauft wird.

[(del676)]

hmm meine gedanken zu den 2 engines/games:

zur zeit sieht für mich HL2 "besser" aus - aber auch nur weil ich eher auf realistische games stehe und nicht auf "comic" stil (mein gesicht als ich das 1. mal auf den platz vorm bahnhof kam würd ich gern mal sehn :) )

doom3 hat hingegen mehr athmospäre aufgebaut (schatten, schockeffekte)

um nun die engines bewerten zu können beschränke ich mich als laie auf dass was mir logisch erscheint

HL2 - super texturen, gute shadereffekte (eher realistische, nicht so comichafte wie bei farcry z.b.), relativ viel polygone

Doom3 - besch...eidene Texturen nur hie und da mal ne gute, verdammt wenig Polygone, verdammt kleine levels, sehr gute "Shader" (z.b. der Raum mit den Roten Gedärmen), und viel Bumpmapping, sehr gute Schatteneffekte

was man nun - bei besserer HW in der Zukunft verbessern kann:

HL2 - läuft jetzt schon verdammt gut, was kann man verbessern? bessere (Echtzeit?)Schatten? mehr Bumpmapping?

Doom3 - viel mehr Polygone, viel bessere Texturen, viel grössere Levels

wenn ich dass so sehe, sind mehr Polygone, bessere Texturen und grössere Levels doch verdammt einfach zu realisieren oder? da braucht man an der Engine gar nix mehr rumschrauben, einfach die Maps/Models so gestaltet und gut is, allerdings bedarf es einer viel schnelleren HW

bei HL2 muss eigentlich schon an der Engine selber rumgeproggt werden damit man ne verbesserung erreicht

... Fazit eines Laien :)

[Spasstiger]

aber die a64 rechnen doch ohnehin bisweilen in 32 bit? aber warum die dennoch schneller sind, ist mir schon immer ein rätsel...

Wenn du dich fragst, weshalb der Athlon 64 in 32 Bit schneller ist als der Athlon XP, dann ist das keineswegs ein Rätsel, sondern völlig logisch bei näherer Betrachtung der Architektur (Speichercontroller nicht im Chipsatz, sondern im Prozessor selbst).

[Coda]

wenn ich dass so sehe, sind mehr Polygone, bessere Texturen und grössere Levels doch verdammt einfach zu realisieren oder?
Die Schattenvolumen-Berechnungen sind nur sehr polygonabhängig, deshalb kann man mit der D³ Engine nicht einfach viel mehr Polygone reinbauen, sonst bricht alles ein Performancemäßig.
Bessere Texturen sind natürlich zu realisieren, besseres Artwork allg. hätte D³ gut getan.
Größere Level hab ich in D³ jetzt gar nicht so vermisst. Falls du Außenareale meinst: Das ist auch so ein Ding mit den Stencilschatten... Offene Gebiete brauchen dann sehr viel Füllrate.

[Kladderadatsch]

wenn ich dass so sehe, sind mehr Polygone, bessere Texturen und grössere Levels doch verdammt einfach zu realisieren oder? da braucht man an der Engine gar nix mehr rumschrauben, einfach die Maps/Models so gestaltet und gut is, allerdings bedarf es einer viel schnelleren HW


so sehe ich das auch. es ist die engine die bessere, welche mehr potential hat. und das ist ja wohl die doom3-engine. ich würde mal gerne ein d3-model sehen, welches statt 5000 mal 50k besitzt- was ja nicht viel ist. das muss doch im verhältnis wesentlich besser ausschauen, als z.b. die unreal3-models mit 200k polygonen?

was macht denn überhaupt eine engine mit potential aus (von den features abgesehen)? die maximale polygon-zahl.

[DrumDub]

so sehe ich das auch. es ist die engine die bessere, welche mehr potential hat. und das ist ja wohl die doom3-engine. ich würde mal gerne ein d3-model sehen, welches statt 5000 mal 50k besitzt- was ja nicht viel ist. das muss doch im verhältnis wesentlich besser ausschauen, als z.b. die unreal3-models mit 200k polygonen?

was macht denn überhaupt eine engine mit potential aus (von den features abgesehen)? die maximale polygon-zahl.

ich glaub du verwechselt das was. selbst die u3-models werden nicht so viele polygone haben. wozu auch? es gibt ja normal mapping und natürlich in zukunft displacement mapping.

als ausgangsbasis werden aber sicher models benutzt, die eine solch hohe polygonanzahl haben. aber das ist nichts neues: bei far cry wurden auch schon models genutzt von denen die normalmaps erstellt wurden, die ca. 250.000 polygone, hatten, die dann auf die ingame-models mit ca. 2000 polygonen aplliziert wurden.

[IVN]

ich glaub du verwechselt das was. selbst die u3-models werden nicht so viele polygone haben. wozu auch? es gibt ja normal mapping und natürlich in zukunft displacement mapping.

als ausgangsbasis werden aber sicher models benutzt, die eine solch hohe polygonanzahl haben. aber das ist nichts neues: bei far cry wurden auch schon models genutzt von denen die normalmaps erstellt wurden, die ca. 250.000 polygone, hatten, die dann auf die ingame-models mit ca. 2000 polygonen aplliziert wurden.

Are you sure that displacement mapping doesn't need a high number of polys?

[Coda]

"Displacement Mapping" is not available on current hardware. I think he meant "parallax mapping", which does not require larger polygon counts.
But you should not see a great difference on playermodels when using parallax instead of bump mapping.

[IVN]

"Displacement Mapping" is not available on current hardware. I think he meant "parallax mapping", which does not require larger polygon counts.
But you should not see a great difference on playermodels when using parallax instead of bump mapping.

It is available on nv40 :rolleyes:
And i think it really needs a high poly count to look good.

[Demirug]

ich glaub du verwechselt das was. selbst die u3-models werden nicht so viele polygone haben. wozu auch? es gibt ja normal mapping und natürlich in zukunft displacement mapping.

Displacment mapping sieht mit Lowpoly Modelen echt unwürdig aus.

als ausgangsbasis werden aber sicher models benutzt, die eine solch hohe polygonanzahl haben. aber das ist nichts neues: bei far cry wurden auch schon models genutzt von denen die normalmaps erstellt wurden, die ca. 250.000 polygone, hatten, die dann auf die ingame-models mit ca. 2000 polygonen aplliziert wurden.

Also etwas mehr als 2000 sollte da noch dem herunterrechnen schon noch übrig sein. Ich kann das aber Notfalls nachprüfen.

[DrumDub]

Are you sure that displacement mapping doesn't need a high number of polys?

soweit ich das displacement mapping verstanden habe, werden die zusätzlichen polygone ja nicht mit dem model geliefert sondern durch den vs der grafikkarte in echtzeit erzeugt anhand der mitgelieferten mapping textur. das belastet zwar die vs der gpu, aber nicht mehr die cpu, wie das bei normalen high-poly-models der fall wäre. natürlich ist normal mapping wesentlich leistungsschonender für die gpu. alles nur afaik. ;)

[DrumDub]

Displacment mapping sieht mit Lowpoly Modelen echt unwürdig aus.

siehe meine erklärung oben. wenn die falsch ist, bitte korrigieren. ;)

Also etwas mehr als 2000 sollte da noch dem herunterrechnen schon noch übrig sein. Ich kann das aber Notfalls nachprüfen.

die jungs von crytek behaupten das zumindest.

[IVN]

soweit ich das displacement mapping verstanden habe, werden die zusätzlichen polygone ja nicht mit dem model geliefert sondern durch den vs der grafikkarte in echtzeit erzeugt anhand der mitgelieferten mapping textur. das belastet zwar die vs der gpu, aber nicht mehr die cpu, wie das bei normalen high-poly-models der fall wäre. natürlich ist normal mapping wesentlich leistungsschonender für die gpu. alles nur afaik. ;)

Well no matter how you take it the DM needs a high poly count to look good,in that time when the VSs are transforming the model (eating performance like hell) the PSs are sitting idle and waitting for the resoults of the transformation.
Please correct me if i'm wrong.

[Demirug]

soweit ich das displacement mapping verstanden habe, werden die zusätzlichen polygone ja nicht mit dem model geliefert sondern durch den vs der grafikkarte in echtzeit erzeugt anhand der mitgelieferten mapping textur. das belastet zwar die vs der gpu, aber nicht mehr die cpu, wie das bei normalen high-poly-models der fall wäre. natürlich ist normal mapping wesentlich leistungsschonender für die gpu. alles nur afaik. ;)

Du bringst da was durcheinader. Beim Displacementmapping werden vorhanden Verticen in Abhängikeit einer Texture verschoben. Wenn man zusätzliche Verticen will muss man vor dem Displacement mapping noch eine Tesselation durchführen.

[Demirug]

die jungs von crytek behaupten das zumindest.

Die behaupten viel bis der Tag lang ist.

[Coda]

It is available on nv40
No it's not. You can displace vertices via the vertexshader, but that's not real Displacementmapping. And especially for playermodels that's useless, because with that method you need to submit the vertices anyway...
So for this method I agree that you need huge polygon counts, but then you don't need displacement mapping anyway ;)

[DrumDub]

Du bringst da was durcheinader. Beim Displacementmapping werden vorhanden Verticen in Abhängikeit einer Texture verschoben. Wenn man zusätzliche Verticen will muss man vor dem Displacement mapping noch eine Tesselation durchführen.

ah. okay. dann isses leider doch nicht so einfach, wie ich dachte. :(

ist denn mir normal mapping sowas wie realistisches self shadowing möglich? das geht doch nur mit displacement mapping, oder liege ich da auch falsch?

zu far cry hab ich noch das gefunden:
250000 polygone: http://www.crytek.de/screenshots/index.php?sx=polybump&px=poly_03.jpg
1500 polygone: http://www.crytek.de/screenshots/index.php?sx=polybump&px=poly_02.jpg
250000 vs. 1500: http://www.crytek.de/screenshots/index.php?sx=polybump&px=poly_04.jpg

[IVN]

No it's not. You can displace vertices via the vertexshader, but that's not real Displacementmapping. And especially for playermodels that's useless, because with that method you need to submit the vertices anyway...
So for this method I agree that you need huge polygon counts, but then you don't need displacement mapping anyway ;)

Ohhh,you think that a teselation unit is needed for real DM.Well,that's not the case.nv40 VSs are capable of real DM. ;)

[Demirug]

ah. okay. dann isses leider doch nicht so einfach, wie ich dachte. :(

ist denn mir normal mapping sowas wie realistisches self shadowing möglich? das geht doch nur mit displacement mapping, oder liege ich da auch falsch?

Self Shadowing ist dabei noch etwas einfacher wie korrekte Schatten die auf andere Objekte geworfen werden. Aber Spass macht das auf keinen Fall weil die üblichen Verfahren da nicht mehr mitkommen.

zu far cry hab ich noch das gefunden:
250000 polygone: http://www.crytek.de/screenshots/index.php?sx=polybump&px=poly_03.jpg
1500 polygone: http://www.crytek.de/screenshots/index.php?sx=polybump&px=poly_02.jpg

Das ist die Polybump "Werbung". Ich bezweifle das man jedes Model so schön von Hand bearbeitet hat.

[IVN]

ah. okay. dann isses leider doch nicht so einfach, wie ich dachte. :(

ist denn mir normal mapping sowas wie realistisches self shadowing möglich? das geht doch nur mit displacement mapping, oder liege ich da auch falsch?

zu far cry hab ich noch das gefunden:
250000 polygone: http://www.crytek.de/screenshots/index.php?sx=polybump&px=poly_03.jpg
1500 polygone: http://www.crytek.de/screenshots/index.php?sx=polybump&px=poly_02.jpg
250000 vs. 1500: http://www.crytek.de/screenshots/index.php?sx=polybump&px=poly_04.jpg

On that unrel 3 engine demonstration,was told that it supports self shadowing in combination with VDM.

[DrumDub]

Ohhh,you think that a teselation unit is needed for real DM.Well,that's not the case.nv40 VSs are capable of real DM. ;)

hmm, also für das sinnvolles displacement mapping scheint mir die tesselation doch notwendig zu sein. ohne tesselation habe ich ja die zusätliche belastung der cpu mit geometrie-daten, die imho ja gerade verhindert werden soll.

[Coda]

Eben. Dann kann ich mir DM auch gleich sparen.

ist denn mir normal mapping sowas wie realistisches self shadowing möglich?
Horizon Mapping geht zumindest mit beidem, also ja.

[DrumDub]

On that unrel 3 engine demonstration,was told that it supports self shadowing in combination with VDM.

dann bekommste aber probleme mit vielen models in einer szene, weil die cpu in die knie geht. also müsste man dieses vdm nur auf ganz spezielle ingame models beschränken. der rest bekäm nur normal mapping.

[IVN]

hmm, also für das sinnvolles displacement mapping scheint mir die tesselation doch notwendig zu sein. ohne tesselation habe ich ja die zusätliche belastung der cpu mit geometrie-daten, die imho ja gerade verhindert werden soll.

It's maybe to slow for games,but this doesn't mean it's not real DM.

[DrumDub]

Horizon Mapping geht zumindest mit beidem, also ja.

bei doom 3 scheint das aber nicht zu funktionieren.

[Demirug]

hmm, also für das sinnvolles displacement mapping scheint mir die tesselation doch notwendig zu sein. ohne tesselation habe ich ja die zusätliche belastung der cpu mit geometrie-daten, die imho ja gerade verhindert werden soll.

Eben. Dann kann ich mir DM auch gleich sparen.

Nein. Die Geometrie kann man entsprechend vorberechnet im Ram der Grafikkarte ablegen. DM ist zum Beispiel dann sinnvoll wenn man die Displacmentmap dynamisch von der Grafikkarte berechnen lässt.

[IVN]

dann bekommste aber probleme mit vielen models in einer szene, weil die cpu in die knie geht. also müsste man dieses vdm nur auf ganz spezielle ingame models beschränken. der rest bekäm nur normal mapping.

It's used for the walls,floors and ceilings.For huge objects.

VDM=virtual DM=parallax mapping isn't killing the CPU.Everything is done inside of the GPU pipeline.

[Coda]

DM ist zum Beispiel dann sinnvoll wenn man die Displacmentmap dynamisch von der Grafikkarte berechnen lässt.
Ack. Aber wir reden von Playermodels :)
Für eine Wasserwellensimulation habe ich mir das natürlich auch schon überlegt ;)

Ich meinte eher: Es ist als Ersatz für Bumpmapping sinnlos.

bei doom 3 scheint das aber nicht zu funktionieren.
Das benützt Doom 3 ja auch nicht ;)
http://www.delphi3d.net/download/uberbump.zip

Da wird Horizon Mapping aber auch nur zusammen mit parallax mapping verwendet. Es geht aber auch ohne.

[Demirug]

Ack. Aber wir reden von Playermodels :)

Da würde ich eher zu unterschiedlichen vorberechneten Auflösungsstuffen tendieren. Grafiker habe gerne die Kontrolle und vertrauen solchen automatischen Verfahren einfach nicht.

Ich meinte eher: Es ist als Ersatz für Bumpmapping sinnlos.

Als Ersatz niemals höchstens als Ergänzung.

[aths]

No it's not. You can displace vertices via the vertexshader, but that's not real Displacementmapping.NV40 hat (wie NV30 auch) das Feature "Render to Vertexbuffer". Damit ist dann wohl auch dynamisches Displacement Mapping möglich.

[DrumDub]

Nein. Die Geometrie kann man entsprechend vorberechnet im Ram der Grafikkarte ablegen. DM ist zum Beispiel dann sinnvoll wenn man die Displacmentmap dynamisch von der Grafikkarte berechnen lässt.

hmm... also liegt der vorteil darin, dass man die geometriedaten per dieplacementmap (also textur) übrträgt. mann kann also das gleiche model mit unterschiedlichen displacementmaps so verändern, dass man nicht mehr sehr veile unterschiedliche "basis-models" braucht? das dynamische berechnen der displacement map macht je eigentlich nur für wasser/wellen-effekte sinn. scgließlich verändert sich die oberfläche eines models nicht in echtzeit. (oder könnte man damit gesichtsanimationen realisieren?)

[Demirug]

hmm... also liegt der vorteil darin, dass man die geometriedaten per dieplacementmap (also textur) übrträgt. mann kann also das gleiche model mit unterschiedlichen displacementmaps so verändern, dass man nicht mehr sehr veile unterschiedliche "basis-models" braucht? das dynamische berechnen der displacement map macht je eigentlich nur für wasser/wellen-effekte sinn. scgließlich verändert sich die oberfläche eines models nicht in echtzeit. (oder könnte man damit gesichtsanimationen realisieren?)

Feste Geometriedaten würde ich nie per Displacementmap übertragen. Das bringt einfach nichts. Da kann man auch einfach mit einem zusätzlichen Vertexstream machen den man dynamisch zum Grundmodel wählt.

Gesichtanimationen macht man mit Bones Technik.

[Coda]

NV40 hat (wie NV30 auch) das Feature "Render to Vertexbuffer". Damit ist dann wohl auch dynamisches Displacement Mapping möglich.
Ja, ist richtig. Das funktioniert aber nur unter OpenGL soweit ich weiß.
Damit wäre mit Loops im Pixelshader natürlich richtiges DM möglich, hast recht.