UnrealEngine 3

[=Floi=]

Hallo,
warum ist die UE3 ausgerechnet so extrem graka limitiert, wenn die UE2 eigentlich auch heute noch extrem an der cpu hängt? Ich denke das grundgerüst und grundkonzept sollte noch immer auf der alten engine aufbauen und da leuchtet mir das nicht ein, wieso nun trotz der shaderpower einer HD2900XT die engine komplett an der graka hängt.
MfG
Floi

[urpils]

ich bin zwar kein 3D-Guru, wie manche hier - aber folgendes klingt für mich logisch:

mit den neuen GraKa-Generationen sind immer mehr Effekte von der GraKa auszuführen (wie man bei D3D10 so schön sagt - im Grunde nicht viele oder keine neuen Effekte, dafür sind jetzt die verfügbaren Effekte in Massen einsetzbar).
Und dieser Einsatz von immer mehr Effekten, die die GraKa zu berechnen hat und NICHT die CPU, zeigt sich nunmal darin, dass auch die GraKas stärker belastet werden.

[Monger]

Die Unreal Engine 3 ist afaik nicht wirklich abwärtskompatibel. Ich gehe davon aus, dass man die Geometrie und wahrscheinlich auch die Texturen importieren kann, aber da hat sich schon einiges getan...

Es gibt z.B.keine Lightmaps mehr im eigentlichen Sinne. Es gibt drei unterschiedliche Beleuchtungsverfahren, die wohl eher die Shaderpower fordern als die Bandbreite.

Es wird wesentlich mehr auf Normal Mapping gesetzt als auf höhere Geometrieauflösung. Auch das läuft eher über die Grafiikkarte als über die CPU.

Es gibt auch keine Portale und Antiportale mehr. Die Engine stellt selbst fest, welche Geometrie sichtbar ist, und lässt den Rest aus. Auch das dürfte die CPU deutlich entlasten.

[Coda]

Es sind Jahre vergangen seit der UE2. Da kann vieles umgeschmissen worden sein. Vermutlich war bei der UE2 vor allem das Occlusion Culling so teuer auf der CPU, das wird nun anders gelöst worden sein.

Es gilt im Allgemeinen als gute Sache ein neues Spiel eher GPU-Limitiert rauszubringen, weil die GPU-Leistung im Laufe der Zeit schneller skaliert als die CPUs.

Es gibt auch keine Portale und Antiportale mehr. Die Engine stellt selbst fest, welche Geometrie sichtbar ist, und lässt den Rest aus. Auch das dürfte die CPU deutlich entlasten.
Ja sowas dachte ich mir schon.

[Mr. Lolman]

Die Unreal Engine 3 ist afaik nicht wirklich abwärtskompatibel. Ich gehe davon aus, dass man die Geometrie und wahrscheinlich auch die Texturen importieren kann, aber da hat sich schon einiges getan...

Die UE2 war auch nicht bwärtskompatibel. Schon damals konnte man die Texturen nicht einfach so importieren. (Was jetzt sogar weniger ein Problem sein dürfte, da man ja seit UE2 auf DDS setzt)


Es gibt z.B.keine Lightmaps mehr im eigentlichen Sinne. Es gibt drei unterschiedliche Beleuchtungsverfahren, die wohl eher die Shaderpower fordern als die Bandbreite.

Sicher? Dass neue Beleuchtungsverfahren gibt, kann ich mir denken, aber Lightmaps komplett rauszuwerfen ist imo nicht notwendig, da man damit ja schnell und billig statische Beleuchtung realisieren kann.


Es wird wesentlich mehr auf Normal Mapping gesetzt als auf höhere Geometrieauflösung. Auch das läuft eher über die Grafiikkarte als über die CPU.

Das ist wohl eher Sache der Artists.


Es gibt auch keine Portale und Antiportale mehr. Die Engine stellt selbst fest, welche Geometrie sichtbar ist, und lässt den Rest aus. Auch das dürfte die CPU deutlich entlasten.

Portale und Antiportale haben eher für ne CPU-Entlastung gesorgt. Die Engine rennt ja zu nem guten Teil über die CPU. Dass ein engineseitiges realtime-HSR die CPU entlastet, kann ich mir nicht ganz vorstellen.

[Coda]

Portale und Antiportale haben eher für ne CPU-Entlastung gesorgt. Die Engine rennt ja zu nem guten Teil über die CPU. Dass ein engineseitiges realtime-HSR die CPU entlastet, kann ich mir nicht ganz vorstellen.
Sicher nicht. Portale und Antiportale rechnen ist wesentlich teurerer als einfach alle Geometrie im Frustum zu rendern.

[Mr. Lolman]

Sicher nicht. Portale und Antiportale rechnen ist wesentlich teurerer als einfach alle Geometrie im Frustum zu rendern.

1.) Wozu hat man dann Anti-/Portale überhaupt verwendet. Ne Enginelimitation wars garantiert nicht.

2.) Befindet sich das Portal nicht im Screenspace wird alles, was dahinter ist, einfach verworfen. Und dass das teurer sein soll, als einfach alles zu rendern, widerspräche irgendwie dem Sinn der Sache, oder?

3.) Die Portale mussten in der UE1/2 ja manuell gesetzt werden. Hat man darauf verzichtet wurde CPU-seitig einfach die komplette Geometrie berechnet und erst GraKa-seitig gecullt.

[Coda]

1.) Wozu hat man dann Anti-/Portale überhaupt verwendet. Ne Enginelimitation wars garantiert nicht.
Na um die GPU zu entlasten.

2.) Befindet sich das Portal nicht im Screenspace wird alles, was dahinter ist, einfach verworfen. Und dass das teurer sein soll, als einfach alles zu rendern, widerspräche irgendwie dem Sinn der Sache, oder?
Für die CPU ist das in der Tat billiger, weil sie nur die Drawcalls an die GPU geben muss. Die hat dadurch aber natürlich mehr zu tun.

3.) Die Portale mussten in der UE1/2 ja manuell gesetzt werden. Hat man darauf verzichtet wurde CPU-seitig einfach die komplette Geometrie berechnet und erst GraKa-seitig gecullt.
Ja, und das ist deutlich billiger für die CPU. Vorsicht: Die UE1 machte die Transformationen auf der CPU, weshalb es da auch auf der CPU teurer war.

[Super-S]

Was meint ihr (Schätzung) wie lange sich die UE3 am Markt halten wird?

[gnomi]

Bis zur nächsten Generation an Konsolen. (3,4 Jahre)

[AnarchX]

Was meint ihr (Schätzung) wie lange sich die UE3 am Markt halten wird?

Wahrscheinlich bis zur UnrealEngine 4.0, was aber wohl noch etwas dauern könnte.
Da wird es wohl wie schon bei der UE2.x passieren, dass diese erheblich modifiziert wird von einigen Studios und vielleicht man dann sogar D3D11-Support hat.