Archiv verlassen und diese Seite im Standarddesign anzeigen : Die Technik der Source-Engine?
Karümel
2003-09-04, 19:51:35
Öhm was wißt Ihr eigentlich alles über die Source- Enginge?
Jetzt von der technischen Seite her gesehen?
Ich frage, weil ich so viel über die Engine noch nicht weiß, es mich aber doch schon interessiert ;)
Also ich kenne den Artikel von Zeckensack aus der PCGH, und das wars es eigentlich schon. Alles andere was ich so gehört habe waren sehr vage Vermutungen.
Das eine war das Texturen (für HL2) mit einer Auflösung von bis zu 2000 x 2000 Pixel verwendet werden und das andere was das die Physik- Engine auf dem Grundgerüst der (war das jetzt die?) Havoc-Engine aufbaut.
Wer hat noch mehr Infos?
Aquaschaf
2003-09-04, 22:49:48
2048x2048 Pixel bitte ;)
zeckensack
2003-09-05, 13:58:32
Recursive portal visibility (!=BSP ala Quake)
Antiportale für Outdoor
Flexibles 'pluggable' material system (zB Menschen aus Wasser)
"nur noch shader", inklusive Runtime-'Kompilation' für DX6/DX7-Targets
Skeletal animation (duh! =))
Alle Objekte/Glieder haben Masse, Reibung, Schwerpunkt etc, für die Physik
IMO shadow mapping auf einigen Objekten/Charakteren (kein Stencil)
BlackBirdSR
2003-09-05, 14:33:51
Ist was an dem gerücht dran, dass Displacement Mapping verwendet wird? (frage mich auf welcher Karte das dann laufen soll *g*)
micki
2003-09-05, 14:34:25
da möchte ich auch hin.. aber min die hälfte fehlt noch *hehe*.. z.B. runtime compilation finde ich sehr bemerkenswert wenn es für dx6/7 gemacht wird, da muss man ja aus dem assembler die combiner/stages selber richtig hinfummeln... hmm.. stell ich mir echt nicht so einfach vor
MFG
micki
Demirug
2003-09-05, 14:42:52
Original geschrieben von BlackBirdSR
Ist was an dem gerücht dran, dass Displacement Mapping verwendet wird? (frage mich auf welcher Karte das dann laufen soll *g*)
AFAIK wird das bei Bedarf von der Engine selbst gemacht. Es werden dann einfach ein paar LOD-Stufen vorberechnet und hinterlegt.
Demirug
2003-09-05, 14:48:52
Original geschrieben von micki
da möchte ich auch hin.. aber min die hälfte fehlt noch *hehe*.. z.B. runtime compilation finde ich sehr bemerkenswert wenn es für dx6/7 gemacht wird, da muss man ja aus dem assembler die combiner/stages selber richtig hinfummeln... hmm.. stell ich mir echt nicht so einfach vor
MFG
micki
So kompliziert ist das eigentlich gar nicht. Das grösste Problem dabei ist es wenn man etwas für Multipass zerlegen muss. Da bist du echt kurz vor einem Nervenzusammenbruch. 2 und 3 Pass geht ja noch einigermasse aber wenn es dann mal 4 oder noch mehr werden müssen und man die besten Splitpositionen finden muss. übel sage ich dir.
micki
2003-09-05, 15:04:41
ich glaube da unterschätzt du das, immerhin muss das on runtime passieren (also ohne dass vorher jemand eintippt wie das richtig auszusehen hat) und bei zu komplexen sachen, bei denen zuviele temp verwendet werden muss für fast jede operation dann die berechnung in einen anderen buffer gemacht werden und anschliessend müssen die richtig kombiniert werden, wenn das optimiert ist, ist es nicht einfach das richtig zum laufen zu bekommen...
ich glaube, dass das schon aus performancegründen dann einfach abgeschaltet wird sobald der shader ein wenig komplexer ist, und die haben fallbacks eingebaut und deren runtime compiler muss das nicht machen.... so mach ich das auch und eigentlich ist das ok wenn man so ein spiel wie HL machen würde... wenn man doom3-mässig machen würde, wäre es schwer das runtime zu machen denk ich mir.
ach naja, wenn ich vertig bin ist sind vs/ps 2.0 standard :D
MfG
micki
zeckensack
2003-09-05, 15:12:45
micki,
das geht garnicht anders, eben weil man das material system benutzt. Dafür müssen verschiedene Shader-Fragmente zusammengestückelt werden.
Daß zusätzlich Effekte abgeschaltet und/oder vereinfacht werden, wenn das ganze auf zu kleinen Targets läuft, ist natürlich auch klar.
Demirug
2003-09-05, 15:15:49
Original geschrieben von micki
ich glaube da unterschätzt du das, immerhin muss das on runtime passieren (also ohne dass vorher jemand eintippt wie das richtig auszusehen hat) und bei zu komplexen sachen, bei denen zuviele temp verwendet werden muss für fast jede operation dann die berechnung in einen anderen buffer gemacht werden und anschliessend müssen die richtig kombiniert werden, wenn das optimiert ist, ist es nicht einfach das richtig zum laufen zu bekommen...
ich glaube, dass das schon aus performancegründen dann einfach abgeschaltet wird sobald der shader ein wenig komplexer ist, und die haben fallbacks eingebaut und deren runtime compiler muss das nicht machen.... so mach ich das auch und eigentlich ist das ok wenn man so ein spiel wie HL machen würde... wenn man doom3-mässig machen würde, wäre es schwer das runtime zu machen denk ich mir.
ach naja, wenn ich vertig bin ist sind vs/ps 2.0 standard :D
MfG
micki
Ich unterschätze das nicht weil ich es selbst schon gemacht habe. Im Moment liegt der DX7-Support aber auf Eis. So gross sind die unterschiede gar nicht ob man nun für die DX7 Pipeline compiliert oder für einen DX8 Pixelshader.
Ich habe was die Techlevels angeht einfach entsprechende ifs im Sourcecode der Shader. So nach dem Prinzip:
if (TexturePerPass > 2)
{
...
}
else
{
...
}
DOOM III macht ja auch sowas in der Art zur Laufzeit. Das ist das alte Quake3 System auf Bumpmapping hochgebort.
BlackBirdSR
2003-09-05, 15:18:45
Original geschrieben von Demirug
AFAIK wird das bei Bedarf von der Engine selbst gemacht. Es werden dann einfach ein paar LOD-Stufen vorberechnet und hinterlegt.
also kein echtes dynamisches Displacement Mapping, sondern presampled?
Ist das dann überhaupt richtiges DM?
Wenn wir schon bei Fragen sind:
Hat jemand eine Ahnung wie das mit der Kollisionsabfrage bei DM aussieht?
Schließlich muss das ja die CPU berechnen, wenn aber der Grafikchip die Geoemtrie erst generiert, wie weiss dann die CPU wo ein Berg ist und so nicht? (falls man DM für Langdschaften nun wirklich sinnvoll nutzen kann)
Demirug
2003-09-05, 15:24:21
Original geschrieben von BlackBirdSR
also kein echtes dynamisches Displacement Mapping, sondern presampled?
Ist das dann überhaupt richtiges DM?
Ja nur Presampled und wie gesagt bei Bedarf auch als reine Softwarelösung.
Wenn die Karte richtiges DM kann wird das eventuel auch genutzt aber in ermangeln einer entsprechenden Karte kann man das ja nicht auspropieren.
Es ist schon DM und man kann da durchaus auch noch einiges an Speicher sparen.
Wenn wir schon bei Fragen sind:
Hat jemand eine Ahnung wie das mit der Kollisionsabfrage bei DM aussieht?
Schließlich muss das ja die CPU berechnen, wenn aber der Grafikchip die Geoemtrie erst generiert, wie weiss dann die CPU wo ein Berg ist und so nicht? (falls man DM für Langdschaften nun wirklich sinnvoll nutzen kann)
Ist doch ganz einfach. Die Physikengine bekommt auch die entsprechende Map und kann dann ja entsprechend selbst auch den entsprechenden Bereich berechnen. Macht man heute mit Highmaps ja auch nicht anders
x-dragon
2003-09-05, 15:27:55
Original geschrieben von BlackBirdSR
also kein echtes dynamisches Displacement Mapping, sondern presampled?
Ist das dann überhaupt richtiges DM?
... "Richtiges" DM beherrscht doch sowieso nur die Parhelia in Hardware, von daher dürfte es wahrschenlich viel zu rechenintensiv sein.
Demirug
2003-09-05, 15:30:34
Original geschrieben von X-Dragon
"Richtiges" DM beherrscht doch sowieso nur die Parhelia in Hardware, von daher dürfte es wahrschenlich viel zu rechenintensiv sein.
Und für die schreibt Matrox keine Treiber mit denen man es auch mal nutzen könnte.
Ist es eigenlicht nur mir aufgefallen oder seh ibh gespenster?
Die source Eningen benutzt doch keine Detailed textures. von weitem seiht das alles ja super aus, aber wenn man näh ran läuft ist weider fast nur pixelbrei zu erkennen. Das ganze ist mir in einem hl2 video aufgefallen aber fragt mich ned im welchen...
micki
2003-09-05, 15:59:31
Original geschrieben von Demirug
Ich unterschätze das nicht weil ich es selbst schon gemacht habe. Im Moment liegt der DX7-Support aber auf Eis. So gross sind die unterschiede gar nicht ob man nun für die DX7 Pipeline compiliert oder für einen DX8 Pixelshader.
Ich habe was die Techlevels angeht einfach entsprechende ifs im Sourcecode der Shader. So nach dem Prinzip:
if (TexturePerPass > 2)
{
...
}
else
{
...
}
DOOM III macht ja auch sowas in der Art zur Laufzeit. Das ist das alte Quake3 System auf Bumpmapping hochgebort.
quake macht das nicht zur laufzeit, es gibt einen wrapper für jede unterstützte graka und der macht dann etwas vordefiniertes (wird nicht zur laufzeit entschieden), anhand der gewünschten funktion... sowas ist aber sehr statisch, weil man nichts belibiges reinstecken kann, nur das was die D3 engine vordefiniert und in allen wrappern drinne hat.... ich kann mich auch irren
im bezug auf shader meinte ich 2.0, bis 1.3 sind die shader ziemlich den combinern gleich und relativ einfach damit zu emulieren, da geb ich dir rescht :D
MfG
micki
micki
2003-09-05, 16:00:53
Original geschrieben von Gast
Ist es eigenlicht nur mir aufgefallen oder seh ibh gespenster?
Die source Eningen benutzt doch keine Detailed textures. von weitem seiht das alles ja super aus, aber wenn man näh ran läuft ist weider fast nur pixelbrei zu erkennen. Das ganze ist mir in einem hl2 video aufgefallen aber fragt mich ned im welchen...
in dem autorennen am strand dort kann man sehen wie ne höcherdetailierte textur aufplopt.. aber in einem movie sollte dich matsch auf texturen nicht überraschen ;D
greets
micki
Demirug
2003-09-05, 16:56:08
Original geschrieben von micki
quake macht das nicht zur laufzeit, es gibt einen wrapper für jede unterstützte graka und der macht dann etwas vordefiniertes (wird nicht zur laufzeit entschieden), anhand der gewünschten funktion... sowas ist aber sehr statisch, weil man nichts belibiges reinstecken kann, nur das was die D3 engine vordefiniert und in allen wrappern drinne hat.... ich kann mich auch irren
Also wenn mich nicht alles täuscht ist das teilweise schon recht dynamisch aber halt eher in der Richtung Baukasten Prinzip. Man kann fertige Teile zusammenstecken und dieses Teile haben dann eben zum Teil noch ein paar Parameter. Ist aber bei DOOM III nach allem was ich bisher gesehen habe auch nicht anders. Es gibt jetzt eben mehr Grundelemente die man benutzen kann.
im bezug auf shader meinte ich 2.0, bis 1.3 sind die shader ziemlich den combinern gleich und relativ einfach damit zu emulieren, da geb ich dir rescht :D
MfG
micki
OK einen 2.0er auf DX7 herunter zu brechen kannst du wirklich vergessen mit etwas Glück ist ein 1.4er drin.
Ist es prinzipiell möglich, einen 2.0-Shader auf eine EMBM-fähige DX7-Pipe abzubilden?
Demirug
2003-09-05, 18:34:21
Original geschrieben von aths
Ist es prinzipiell möglich, einen 2.0-Shader auf eine EMBM-fähige DX7-Pipe abzubilden?
Nicht jeden. Mit einigen würde es gehen. Allerdings teilweise sehr umständlich und mit grösseren Verlusten bei der Genauigkeit verbunden. Als Gedankenspiel ganz nett aber praktisch nicht nutzbar.
EDIT: Wenn man natürlich die CPU für ein paar Hilfsjobs benutzt bekommt man jeden gerendert nur lohnt das noch weniger.
Ich fragte, weil ich mal sone Shader-Demo sah, die glaube ich mit 7 oder 11 Passes alles mögliche rendern konnte, afaik waren Pixelshader oder Register Combiner nicht mal zwingende Voraussetzung.
Aber alleine die Genauigkeit ist ja schon ein schlagendes Argument.
Alles mögliche? Ich glaube ich hab mal von einer Demo gehört die Dot3-BM in 7 Passes auf nicht-Dot3-fähiger Hardware rendert...
GiLo5
2003-09-12, 16:32:22
Original geschrieben von Karümel
[...] was das die Physik- Engine auf dem Grundgerüst der (war das jetzt die?) Havoc-Engine aufbaut.
Wer hat noch mehr Infos?
soweit ich weiss, war die havoc-engine nur am anfang geplant, da die aber nicht performant genug war, wurde die so stark modifiziert /neu geschrieben, das man nicht mehr havoc sagen kann...
mfg g5
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.