Ein Paar Dinge

[Della Morte]

hi all, bin neu hier :wink2:
und hab ein paar fragen über dirext x 9.0 und die T&L einheit.

kann man mit dx 9.0 Softshadows realisieren? ohne mehre lichter/schatten pass zu zu verwenden, oder wirt das erst möglich mit DX 11 :D
wenn einer sorce kennt oder hatt wäre ich sehr dankbar.

noch eine naja für gurus woll nee dume frage aber beim letzten 3dmark test (geforce 1 Sdr 32MB) viel mir den vertexshader test auf mhm und nun frag ich mich ob die geforce 1 einen echten VS hatt oder doch nur die T&L einheit ist, oder ist das gleiche? auch die leistung bei einer gforce 3 hatt die eine T&L leistung von 65miilionen polys und die VS leistung liegt bei 125 millionen?
bitte die daten der gforce nicht so genau nehmen weiss das nicht auswendig GG

oder ist das gleiche prinzip wie das vs 1.4 mehr power benötigt wie vs 2.0 bei gleiche pass,oder so?:D

sorry für ewt sehr dumme fragen

[Demirug]

Original geschrieben von Della Morte
hi all, bin neu hier :wink2:
und hab ein paar fragen über dirext x 9.0 und die T&L einheit.

kann man mit dx 9.0 Softshadows realisieren? ohne mehre lichter/schatten pass zu zu verwenden, oder wirt das erst möglich mit DX 11 :D
wenn einer sorce kennt oder hatt wäre ich sehr dankbar.

Mit den Pixelshadern kann man das durchaus realisieren. Mann muss aber nach wie vor die Schatteninformationen zuerst in einen Zwischenspeicher (Texture) rendern. Aufgrund der maximale Anzahl von Texturen pro Pass (16) kann man so aber nach wie vor nicht beliebig viele Lichtquellen in einem Pass abhandeln.


noch eine naja für gurus woll nee dume frage aber beim letzten 3dmark test (geforce 1 Sdr 32MB) viel mir den vertexshader test auf mhm und nun frag ich mich ob die geforce 1 einen echten VS hatt oder doch nur die T&L einheit ist, oder ist das gleiche? auch die leistung bei einer gforce 3 hatt die eine T&L leistung von 65miilionen polys und die VS leistung liegt bei 125 millionen?
bitte die daten der gforce nicht so genau nehmen weiss das nicht auswendig GG

Eine GF 1 hat nur eine HT&L Einheit. Technologisch gesehen ist das ein eingeschrängter Vertexshader. Benutzt man aber bei DirectX mit einer GF1 den Vertexshader so wird dieser immer von der CPU emuliert.

nv gibt die T&L Leistung mit Polys an und die VS Leistung mit Operationen dadurch kommen bei der VS-Leistung grössere Zahlen zustanden.

oder ist das gleiche prinzip wie das vs 1.4 mehr power benötigt wie vs 2.0 bei gleiche pass,oder so?:D

sorry für ewt sehr dumme fragen

Die Frage verstehe ich jetzt nicht ganz.

PS: *move*

[Della Morte]

thanx für info


mit der vs meinte ich das VS 1.4 mehr leistung braucht also vs 2.0 bei gleicher code, bzw 2.0 kommt mit wenniger code aus als 1.4 für gleichen effect was somit mehr leistung freigibt?

mfg


Nachtrag:

oder währen stencil softshadows möglich?

[Demirug]

Original geschrieben von Della Morte
thanx für info


mit der vs meinte ich das VS 1.4 mehr leistung braucht also vs 2.0 bei gleicher code, bzw 2.0 kommt mit wenniger code aus als 1.4 für gleichen effect was somit mehr leistung freigibt?

mfg

Du meinst Pixelshader (PS) und nicht Vertexshader (VS) oder?

So allgemein kann man das aber nicht sagen. Der Vorteil von PS 2.0 welcher zuerst zum tragen kommt ist das man Effekte für die mit den 1.X PS ein Pass nicht gereicht hat jetzt durchaus mit einem Pass erledigen kann. Wie schnell nun ein einzelner Shader jeweils ist hängt sehr stark von der Hardware ab.

Nachtrag:

oder währen stencil softshadows möglich?

Im Prinzip ja. Der Aufwand dafür wäre aber sehr hoch und leider wäre das ganze auch nicht sehr performant.

[Della Morte]

[QUOTE][SIZE=1]Original geschrieben von Demirug
Du meinst Pixelshader (PS) und nicht Vertexshader (VS) oder?

Nein meinte (VS) Vertex Shader, Ist mir aber klar das vertex shader keine pässe haben oder doch?.wahr nur auf die poly leistung bezogen

zu den softstencilshadows :D brauchts da einen grösseren stencil buffer oder ein gantz anderes konsept um das in realtime zu realisieren zb. mit 32 lichtquellen? oder gibs mit PS/VS 3.0 mehr flexibelität ausser die codelänge ,Loops ect.

[Della Morte]

:wink2: danke dir

[Demirug]

Es gibt doch aber gar keine 1.4 Vertexshader?

Die Poly-Leistung eines Vertexshaders hängt sehr stark davon ab wie viele Anweisungen pro Vertex gebraucht und wie viele Verticen Pro Poly gebraucht werden. Deswegen macht Bei den Vertexshader eine Angabe wie Polys/Sekunden auch wenig Sinn.

Wenn man etwas Multipass rendert muss man genau wie im Pixelshader meistens auch im Vertexshader unterschiedliche Programme für jeden Pass verwenden. Multipass bedeutet ja das alles mehrfach durch die komplette Pipeline muss.

Um mit den bekannte Techniken Soft Stencil Schatten muss man jede Lichtquelle mehrfach rendern und dabei für das füllen des Stencilbuffers jeweils die Richtung der Lichtquelle etwas verschieben. Bei den folgenden Lichtpasses muss dann entsprechend skaliert werden. Es gibt da durchaus noch ein paar möglichkeiten zur optimierung aber für Softstencilschatten dürfte wohl derzeit keine Hardware genügend Leistung haben.

Loops, Branches und Unterprogramme. Was braucht man den noch mehr an Flexibilität? Das einzige was da noch fehlt ist das man auf mehr Teile der Pipeline einen Zugriff erhält wie zum Beispiel das man auf Stencilbufferwerte aus dem Pixelshader zugreifen kann.

[Gast]

Original geschrieben von Demirug
Es gibt doch aber gar keine 1.4 Vertexshader?


da hast du allerdings recht, hab allerdings gedacht das bei dx8.1=1.4 auch VS zugehört oder ist VS zb immer noch bei 1.0 wobei PS schon bei 2.0 bzw 2.+ ist?

wie kann ich mir die VS programmfragmente vorstellen gibs da auch pässe die den animation bzw transform operation unterteilen also für haare ein VS und für oberarme usw usw?

wirt es mal möglich sein nee pipline für einen pass zu vergewaltigen oder wirts es mit DX 10 VS/PS 4.0? gar keine pips mehr geben?
und wie viel mehr rohpower wäre nötig die games prozetual zu erzeugen? zbw was simples Q3 entliches texturen werden ja immernoch als zbw displace benutzt ?

[Della Morte]

ups böser login:bad1: war ich, habs leider need editen können

[Demirug]

Original geschrieben von Gast
da hast du allerdings recht, hab allerdings gedacht das bei dx8.1=1.4 auch VS zugehört oder ist VS zb immer noch bei 1.0 wobei PS schon bei 2.0 bzw 2.+ ist?

In DX 8 gab es VS 1.0 und 1.1 sowie die PS 1.0 und 1.1. Mit DX 8.1 wurde dann nur bei den PS bis auf 1.4 erweitert. Die 1.0 Versionen wurden später entfernt da es keine Hardwaregab die nicht mindestens 1.1 unterstützt hat.

wie kann ich mir die VS programmfragmente vorstellen gibs da auch pässe die den animation bzw transform operation unterteilen also für haare ein VS und für oberarme usw usw?

Multipass bedeutet ja das man die Arbeit nicht in einem Pass erledigen kann/will. Benutzt man nun mehr als einen Pass muss man natürlich auch den VS so programmieren das er dem PS die jeweils passenden Daten liefert.

Das man unterschiedliche Teile mit unterschiedlichen VS/PS Programmen bearbeitet ist etwas anderes und hat mit Pässen nichts zu tun.

Shaderfragmente gibt es aber denoch durchaus. Wobei das im Shaderhochsprachen umfeld dann eher Subroutionen sind.

wirt es mal möglich sein nee pipline für einen pass zu vergewaltigen oder wirts es mit DX 10 VS/PS 4.0? gar keine pips mehr geben?

Eine Pipeline wird es immer geben nur wie sich diese genau weiter entwickelt ist sehr vorher zu sagen. Was du jetzt mit "vergewaltigen für einen Pass" meinst ist mir nicht ganz klar. Es gibt ja schon immer Effekte welche sich mit einem Pass auch auf älteren karten erzeugen lassen.

und wie viel mehr rohpower wäre nötig die games prozetual zu erzeugen? zbw was simples Q3 entliches texturen werden ja immernoch als zbw displace benutzt ?

Das hängt davon ab wie aufwendig die Prozedur für die Texture ist. Der Pixelshader Test aus dem 3DMark 03 benutzt ja eine prozedurale Texture. Man kan sich also durchaus ausrechnen wie viel power notwendig ist wenn man nicht nur 3 Objekte sondern viel mehr mit dieser Technik rendern möchte.

[Della Morte]

Original geschrieben von Demirug

Eine Pipeline wird es immer geben nur wie sich diese genau weiter entwickelt ist sehr vorher zu sagen. Was du jetzt mit "vergewaltigen für einen Pass" meinst ist mir nicht ganz klar. Es gibt ja schon immer Effekte welche sich mit einem Pass auch auf älteren karten erzeugen lassen.

nei ich meinte ob man die pipline dynamisch für spez pässe einleiten könnte bzw die pipline nur für eine bestimmte aufgabe zu benutzen zbw pipe 1 nur für pass 1 und die 2 pipe für pass 2 und 3?

Original geschrieben von Demirug
Das hängt davon ab wie aufwendig die Prozedur für die Texture ist. Der Pixelshader Test aus dem 3DMark 03 benutzt ja eine prozedurale Texture. Man kan sich also durchaus ausrechnen wie viel power notwendig ist wenn man nicht nur 3 Objekte sondern viel mehr mit dieser Technik rendern möchte.

also ist prozeduales texturing imho sinnlos *weill ich dachte sei for free weil es jo keine textur stegs mehr geben muss und das ja nur noch mathematisch umschrieben wirt?

[Della Morte]

noch nee frage zu prozedurales texturing, sind beide metoden kombinierbar also ein model texturiert einen teil mit normalen texturen und die details (anderer teil) prozedural erzeugen zu lasen?

[Demirug]

Original geschrieben von Della Morte
nei ich meinte ob man die pipline dynamisch für spez pässe einleiten könnte bzw die pipline nur für eine bestimmte aufgabe zu benutzen zbw pipe 1 nur für pass 1 und die 2 pipe für pass 2 und 3?

Von einer Spezialisierung geht wird ja eher weg. Zudem müssen ja mehrer Passes hintereinader durchgeführt werden. Es bringt also nichts diese auf mehrere Pipelines zu verteilen. Zudem macht ein solches Modell die Programmierung der Karten ja nur noch komplizierter.

also ist prozeduales texturing imho sinnlos *weill ich dachte sei for free weil es jo keine textur stegs mehr geben muss und das ja nur noch mathematisch umbeschrieben wirt?

Umsonst ist überhaupt nichts. Prozedurale Texturen erlauben eben eine höheren Detailgrad aber haben dafür eben auch einen Preis. Da man aber die rechenleistung normalerwiese schneller steigern kann als die Bandbreite ergibt sich da langfristig scon ein Sinn.

[Demirug]

Original geschrieben von Della Morte
noch nee frage zu prozedurales texturing, sind beide metoden kombinierbar also ein model texturiert einen teil mit normalen texturen und die details (anderer teil) prozedural erzeugen zu lasen?

Natürlich. Man kann da beliebig kombinieren. Auch bei einem einzelnen Pixel kann man eine normale Texture mit einer prozeduralen mischen.

[Della Morte]

Original geschrieben von Demirug
Von einer Spezialisierung geht wird ja eher weg. Zudem müssen ja mehrer Passes hintereinader durchgeführt werden. Es bringt also nichts diese auf mehrere Pipelines zu verteilen. Zudem macht ein solches Modell die Programmierung der Karten ja nur noch komplizierter.


ja ist schon der punkt war nur beim machbaren nicht beim produktiven


Original geschrieben von Demirug
Umsonst ist überhaupt nichts. Prozedurale Texturen erlauben eben eine höheren Detailgrad aber haben dafür eben auch einen Preis. Da man aber die rechenleistung normalerwiese schneller steigern kann als die Bandbreite ergibt sich da langfristig scon ein Sinn.

auch das war mir ein stücken klar, nur ist so das texturen mehr speicher braucht wie das Prozedural zu erzeugen oder? warum wurde nicht schon früher darauf optimiert bzw eingefürt.

an was würde es fehlen games Prozedural zu erzeugen, fillrate,banbreite,Rohpower? man könnte jo mischen zb bei einer mimic die haut Prozedural erzeugen und der rest mit Map? würde das nicht mehr sin geben wie alles zu texturieren?

[Demirug]

Original geschrieben von Della Morte
ja ist schon der punkt war nur beim machbaren nicht beim produktiven

machbar ist vieles aber warum mit Dingen befassen die keinen erkennbaren vorteil bringen?


auch das war mir ein stücken klar, nur ist so das texturen mehr speicher braucht wie das Prozedural zu erzeugen oder? warum wurde nicht schon früher darauf optimiert bzw eingefürt.

an was würde es fehlen games Prozedural zu erzeugen, fillrate,banbreite,Rohpower? man könnte jo mischen zb bei einer mimic die haut Prozedural erzeugen und der rest mit Map? würde das nicht mehr sin geben wie alles zu texturieren?

Ja eine Prozedurale Texture braucht im verhältniss zu einer "normalen" Texture recht wenig speicher. Das man es bisher nicht gemacht hat hängt einfach damit zusammen das es eben zu aufwendig war.

Für Prozedurale Texturen braucht man Rechenleistung und nochmal Rechenleistung. Es wird sicherlich am Anfang nur vereinzelt auf prozedurale Texturen gesetzt werden. Aber das ist bei "neuen" Techniken ja immer so.

[Della Morte]

Original geschrieben von Demirug
machbar ist vieles aber warum mit Dingen befassen die keinen erkennbaren vorteil bringen?

zustimm



Original geschrieben von Demirug
Ja eine Prozedurale Texture braucht im verhältniss zu einer "normalen" Texture recht wenig speicher. Das man es bisher nicht gemacht hat hängt einfach damit zusammen das es eben zu aufwendig war.

Für Prozedurale Texturen braucht man Rechenleistung und nochmal Rechenleistung. Es wird sicherlich am Anfang nur vereinzelt auf prozedurale Texturen gesetzt werden. Aber das ist bei "neuen" Techniken ja immer so.




aber neu ist Prozedurales Texturing nicht mehr (wurde mit Gforce 3 Eingeführt, oder mir ist nur die bekannt darum tschuldigung wenns nicht stimmt.:D
man hätt wenn früher ab(gf3) die games schon darauf rocken lassen, wie du gesagt hast bringt prozedurales texturing more details zu mehr rohpower, das könnte man ja mit köpfchen einsetzen also nicht komplete location aus prozeduralem sondern wenn nötig prozedurales per pixel?

[Demirug]

Original geschrieben von Della Morte
aber neu ist Prozedurales Texturing nicht mehr (wurde mit Gforce 3 Eingeführt, oder mir ist nur die bekannt darum tschuldigung wenns nicht stimmt.:D
man hätt wenn früher ab(gf3) die games schon darauf rocken lassen, wie du gesagt hast bringt prozedurales texturing more details zu mehr rohpower, das könnte man ja mit köpfchen einsetzen also nicht komplete location aus prozeduralem sondern wenn nötig prozedurales per pixel?

deswegen war das neu ja auch in Anführungszeichen. Im nicht realtime Bereich gibt es das ja schon viel länger.

Ja die GF3 kann ein wenig prozedurale Texturen aber für alzu viel reicht da die Programmierbarkeit und Leistung eben nicht aus. Zum Beispiel ist prozedurales Holz ist mit einer GF3 einfach undenkbar.

[Della Morte]

Original geschrieben von Demirug
deswegen war das neu ja auch in Anführungszeichen. Im nicht realtime Bereich gibt es das ja schon viel länger.

ja klar komme aus der offline render Ecke (Softimage 3.9) ;)


Original geschrieben von Demirug
Ja die GF3 kann ein wenig prozedurale Texturen aber für alzu viel reicht da die Programmierbarkeit und Leistung eben nicht aus. Zum Beispiel ist prozedurales Holz ist mit einer GF3 einfach undenkbar.

mhm den war die gforce3 die erste realtime fähige graka für "prozedurale texturen"? hatte die readon1 auch prozedurale texturen supportet oder ewt. ne weiterentwicklung davon?

wahr mit gf3 kein prozedurales per pixel möglich gewesen ?

[Demirug]

Original geschrieben von Della Morte
mhm den war die gforce3 die erste realtime fähige graka für "prozedurale texturen"? hatte die readon1 auch prozedurale texturen supportet oder ewt. ne weiterentwicklung davon?

wahr mit gf3 kein prozedurales per pixel möglich gewesen ?

Die Frage ist ab wann man von einer Prozeduralen Texture sprechen kann. Das was mit Karten vor DX9 möglich war würde ich nicht als prozedurale Texturen bezeichnen.

[Della Morte]

Original geschrieben von Demirug
Die Frage ist ab wann man von einer Prozeduralen Texture sprechen kann. Das was mit Karten vor DX9 möglich war würde ich nicht als prozedurale Texturen bezeichnen.


sicherlich! allerdings müsst ihr ja wo anfangen und die grundstein ist schon mal gelegt, Naja ein kiselsteinchen, aber er ist da :D
DX 9.0 ist so oder so ein witz in meinen augen, OK ist flexibler,länger und uncut aber was bringts neue funktionen wenn die entwickler angst vor neuem haben, ich kenne das man will was schön machen aber keine zeit dafür, allerdings halte ich das vor allem in der gamebissnes von nöten sehe selber, nicht mal doom3 begeistern vom machbaren,heute, gestern wahrs top, weills einfach zu lange dauert, am schluss rennt die techick weg und die entwikler hinken hinterher, was heute schon so stark ist wird morgen überhand gwinnen?
mit der shaderlague sehts wider anders aus aber wo steckt die? GL lang ist nocht nicht raus OPGL 2.0 auch nicht Cg iss nur für nvidia extansions usw usw??

also wenn ogl 2.0 raus ist sind die grakas bei PS 3.0 und alles wirt wieder verworfen?

[Demirug]

Das Problem des Gamebussines ist rückwärtskompatibilität. Nicht jeder hat die neuste Hardware.

Die Shaderhochsprachen für OpenGL und DX sind schon weit genug gefasst das diese noch eine Weile zu gebrauchen sind.

Es ist ja auch nicht so das einfach alles verworfen wird. Man erweitert eher das bestehende.

[Xmas]

Original geschrieben von Della Morte
also wenn ogl 2.0 raus ist sind die grakas bei PS 3.0 und alles wirt wieder verworfen?
Wieso? GLslang ist eine High Level Shading Language. PS3.0 ist eine Low Level Spezifikation. Die HLSL abstrahieren so weit, dass man sie in 10 Jahren immer noch genauso gebrauchen kann. Ebenso wie z.B C schon Jahrzehnte überlebt hat, und das auf den unterschiedlichsten Plattformen.

[Della Morte]

Original geschrieben von Xmas
Wieso? GLslang ist eine High Level Shading Language. PS3.0 ist eine Low Level Spezifikation. Die HLSL abstrahieren so weit, dass man sie in 10 Jahren immer noch genauso gebrauchen kann. Ebenso wie z.B C schon Jahrzehnte überlebt hat, und das auf den unterschiedlichsten Plattformen.

na das kann ich nicht glauben 10 jahre ist sehr lang in einen so Kurtzlebigem geschäft, "Spekulations mode ON" vermute das GL 2.0 nur biss ps/vs 3.0 Geht aber spätestens bei zbw 4.0 den aber wider eine grundlegent neue technologien Kommt, den sonst hätte man auch dx 8.0 behalten können und die ps/vs 2.0 in dx 8.0 einbetten können, und nicht extra ein dx 9 ps/vs 2.0 /2.+ /3.0


Nachtrag :

Ja sehe c,c+,c++
OGL 2.0,2.1,2.2

[Della Morte]

Original geschrieben von Demirug
Das Problem des Gamebussines ist rückwärtskompatibilität. Nicht jeder hat die neuste Hardware.

Die Shaderhochsprachen für OpenGL und DX sind schon weit genug gefasst das diese noch eine Weile zu gebrauchen sind.

Es ist ja auch nicht so das einfach alles verworfen wird. Man erweitert eher das bestehende.


auch hier sehe ich bissel anders, atis truform/nvidias npatches zb. wurde wieder verworfen genau wegen magel an support?
auch matrox geniales displacemapping support seit G400 Bis heute noch kein support bzw wurde es einfach auf der liste gestrichen, cubemapps sind bis heute noch eine seltenheit obwoll es jetzt langsamm kommt (geforce 1, wenn nicht schon früher)

[Della Morte]

Original geschrieben von Demirug
Das Problem des Gamebussines ist rückwärtskompatibilität. Nicht jeder hat die neuste Hardware.



Das stimmt schon aber wenn ihr so oder so alles in higdetail etwickeln und den wieder zu tote optimieren statt den pfad für higend zu lassen und die optimierte version für lowend grakas zu verwenden?

[Demirug]

Original geschrieben von Della Morte
auch hier sehe ich bissel anders, atis truform/nvidias npatches zb. wurde wieder verworfen genau wegen magel an support?
auch matrox geniales displacemapping support seit G400 Bis heute noch kein support bzw wurde es einfach auf der liste gestrichen, cubemapps sind bis heute noch eine seltenheit obwoll es jetzt langsamm kommt (geforce 1, wenn nicht schon früher)

Die Patch verfahren haben eben keinem wirklich gefallen. Zu wenig Kontrolle.

DM seit der G400? Intern hatte man da unter umständen schon was aber Matrox hat niemals irgendwelche Infos dazu rausgegeben.

Cubemaps wurden doch schon immer mal benutzt wenn es sinn gemacht hat.

[Demirug]

Original geschrieben von Della Morte
Das stimmt schon aber wenn ihr so oder so alles in higdetail etwickeln und den wieder zu tote optimieren statt den pfad für higend zu lassen und die optimierte version für lowend grakas zu verwenden?

Für Highend macht man etwas Eyecandy die Hauptarbeit steckt im Lowend bzw in Bereichnen in denen das gar keine Rolle spielt.

[Xmas]

Original geschrieben von Della Morte
na das kann ich nicht glauben 10 jahre ist sehr lang in einen so Kurtzlebigem geschäft, "Spekulations mode ON" vermute das GL 2.0 nur biss ps/vs 3.0 Geht aber spätestens bei zbw 4.0 den aber wider eine grundlegent neue technologien Kommt, den sonst hätte man auch dx 8.0 behalten können und die ps/vs 2.0 in dx 8.0 einbetten können, und nicht extra ein dx 9 ps/vs 2.0 /2.+ /3.0


Nachtrag :

Ja sehe c,c+,c++
OGL 2.0,2.1,2.2
Es gibt wenig was nach PS3.0 noch grundlegend Neues kommen kann. Eines der wenigen Dinge wäre der freie Speicherzugriff und Pointer, aber spätestens dann ist die GPU nur noch minimal von der CPU entfernt.

Wie gesagt, PS/VS sind low-level Specs, die ändern sich relativ häufig. Und da man nicht weiß wie die Hardware in drei Jahren konkret aussieht, kann man hier nicht vorausplanen.
GLslang und andere HLSL müssen jedenfalls für PS3.0 fähige Hardware nicht erweitert und schon gar nicht verworfen werden. Man braucht ja auch für neue CPUs keine neue Programmiersprache.

C hat Jahrzehnte gehalten bevor es durch C++ abgelöst wurde, und wird mancherorts immer noch verwendet. Natürlich wird es Extensions zu GLslang geben, aber keinen Umbruch.

[Della Morte]

Original geschrieben von Xmas
Es gibt wenig was nach PS3.0 noch grundlegend Neues kommen kann. Eines der wenigen Dinge wäre der freie Speicherzugriff und Pointer, aber spätestens dann ist die GPU nur noch minimal von der CPU entfernt.

genau das ist der punkt wenn mir soweit sind wirt es kaum noch ogl 2.0 geben,Nicht weil es Ogl2.0 nicht schaffen würde sondern einfach wegen der technick? oder was ist rentabler ein altes haus zu renovieren, und grundlegent zu verändern oder ein neues haus optimiert auf meine einrichtung zu desingen?

Original geschrieben von Xmas
Wie gesagt, PS/VS sind low-level Specs, die ändern sich relativ häufig. Und da man nicht weiß wie die Hardware in drei Jahren konkret aussieht, kann man hier nicht vorausplanen.
GLslang und andere HLSL müssen jedenfalls für PS3.0 fähige Hardware nicht erweitert und schon gar nicht verworfen werden. Man braucht ja auch für neue CPUs keine neue Programmiersprache.


ja der sprung von Ps 2.0 auf 3.0 ist ein kleiner sprung, aber wie sehts mit ps 4.0 aus denke nicht das ogl 2.0 mit extanions das noch packt,weil einfach veraltet oder neue spec kommen, aber das kann hier woll keiner sagen?

mhm kann es den sein das ogl dx ablöst? für was den 2 apis die die fastselben hochsprachen haben?

[Della Morte]

Original geschrieben von Demirug

Cubemaps wurden doch schon immer mal benutzt wenn es sinn gemacht hat.
ja wahr bissel falsches zb. oder bumpmaps sind selten gg

[Demirug]

Original geschrieben von Della Morte
genau das ist der punkt wenn mir soweit sind wirt es kaum noch ogl 2.0 geben,Nicht weil es Ogl2.0 nicht schaffen würde sondern einfach wegen der technick? oder was ist rentabler ein altes haus zu renovieren, und grundlegent zu verändern oder ein neues haus optimiert auf meine einrichtung zu desingen?

OpenGL wird doch wie DX schon seit Jahren immer wieder erweitert. Wo ist also das Problem?

ja der sprung von Ps 2.0 auf 3.0 ist ein kleiner sprung, aber wie sehts mit ps 4.0 aus denke nicht das ogl 2.0 mit extanions das noch packt,weil einfach veraltet oder neue spec kommen, aber das kann hier woll keiner sagen?

Man muss hier ganz klar zwischen der Shaderhochsprache und der zugrunde liegende API unterscheiden. Die APIs für die Hochsprachen ändern sich ja nicht nur weil die Karten jetzt plötzlich mehr können. Auch die Grundzüge der Sprache bleiben gleich. Mann kann dann höchstens längere Programme schreiben oder hat ein paar zusätzliche Funktionen. Aber das ist bei einer anderen Hochsprache wie z.B. C ja auch nicht anders. Die Grundzüge von C ändern sich ja nicht dadurch das man eine neue Funktions biliothek hinzufügt.

mhm kann es den sein das ogl dx ablöst? für was den 2 apis die die fastselben hochsprachen haben?

Weil die APIs aus noch ein bischen mehr als nur der Hochsprache bestehen und OpenGL und DX dabei unterschiedlichen Zielsetzungen haben.

[Della Morte]

Original geschrieben von Demirug
OpenGL wird doch wie DX schon seit Jahren immer wieder erweitert. Wo ist also das Problem?


kein problem, aber das war nicht was gemein wahr, sondern das es 2 apis gibt die in etwa gleich mächtig sind ? und daher nicht die gantze power auf eine api gerichtet wirt? ist egal ob nun dx oder ogl,
dx ist heute zimmlich verbreitet in games mehr wie ogl, ogl hinkt dx hinterher zum teil,für was 2 apis zbw dx fürs gamen ogl für modeling? finde ich persönlich unnötig


Original geschrieben von Demirug
Man muss hier ganz klar zwischen der Shaderhochsprache und der zugrunde liegende API unterscheiden. Die APIs für die Hochsprachen ändern sich ja nicht nur weil die Karten jetzt plötzlich mehr können. Auch die Grundzüge der Sprache bleiben gleich. Mann kann dann höchstens längere Programme schreiben oder hat ein paar zusätzliche Funktionen. Aber das ist bei einer anderen Hochsprache wie z.B. C ja auch nicht anders. Die Grundzüge von C ändern sich ja nicht dadurch das man eine neue Funktions biliothek hinzufügt.

ja klar auch das leuchtet ein aber auch hier hast mich nicht richtig verstanden? das beruht nicht mehr auf ps 3.0 sondern schon weiter ps 4.0 wie du selbst gesagt hast ist das alles noch spekulation,aber denke nicht das zbw ogl2.0 noch für 4.0 shader reichen würden, warum? tja ich denke mir mal das vs/ps später einfach nicht mehr gibt, und was bringt den eine copiler wenn es gantz anderen code verlangt so zb.
und schon braucht man neuen copieler gllang 3.0 die wieder reichen bis shader 6.0?

aber nun gut THX an euch beide die woll zimmlich genervt scheinen gg bisbald:D

[Demirug]

Original geschrieben von Della Morte
kein problem, aber das war nicht was gemein wahr, sondern das es 2 apis gibt die in etwa gleich mächtig sind ? und daher nicht die gantze power auf eine api gerichtet wirt? ist egal ob nun dx oder ogl,
dx ist heute zimmlich verbreitet in games mehr wie ogl, ogl hinkt dx hinterher zum teil,für was 2 apis zbw dx fürs gamen ogl für modeling? finde ich persönlich unnötig

Nunja es gibt ja DirectX nur für Windows und die anderen OSen brauchen ja auch eine 3D-API. Funktional würde ich das jetzt nicht trennen man kann DX auch fürs modeling benutzten und OpenGL für games.

ja klar auch das leuchtet ein aber auch hier hast mich nicht richtig verstanden? das beruht nicht mehr auf ps 3.0 sondern schon weiter ps 4.0 wie du selbst gesagt hast ist das alles noch spekulation,aber denke nicht das zbw ogl2.0 noch für 4.0 shader reichen würden, warum? tja ich denke mir mal das vs/ps später einfach nicht mehr gibt, und was bringt den eine copiler wenn es gantz anderen code verlangt so zb.
und schon braucht man neuen copieler gllang 3.0 die wieder reichen bis shader 6.0?

Es wird immer Operationen auf Vertex und auf Pixelebene geben. Das ist ein fundamentales Konzept bei Renderer. Solange man also nicht zu Raytracern übergeht gibt es da kein Problem. Aber selbst mit einem Raytracer könnte man die Hochsprachen weiter verwenden.

aber nun gut THX an euch beide die woll zimmlich genervt scheinen gg bisbald:D

Da gehört schon mehr dazu um mich richtig zu nerven.

[Della Morte]

hehehe..... ich hab noch paar fragen:D


gerade in bereich raytracing, also die hlsl hochsprache würde noch damit laufen natürlich wirts extansion geben müssen, oder iss das schon seit anfang an mit gedacht?

macht raytracing nicht nur bei reflexions und refractions sinn? könnte man zukümpftig auch caustics lichtbrechungen in realtime realisieren via raytracing, oder wie schon besprochen softshadows?

was wären die anforderungen? gibs heute nur ein mir bekannte graka die raytract die fx 16 mit 8pa risc prozessoren und kostet ca.60,000€

[Della Morte]

Original geschrieben von Demirug
Nunja es gibt ja DirectX nur für Windows und die anderen OSen brauchen ja auch eine 3D-API. Funktional würde ich das jetzt nicht trennen man kann DX auch fürs modeling benutzten und OpenGL für games.


Tja eben Warum 2 Apis?:O kann ja auch dx für linux bzw unix/irix geben
ich persönlich arbeite schon seit 8 jahren mit ogl und meine meinung noch sind viel mehr For more powerhungris AppZ optimiert wie DX, dx lüppt im vergleich zu ogl 1.3 fast grottig im wirframe,denke aber ist optimierungssache? und da teilt es sich wider ogl iss professional weil optimiert wirt, und dx iss all user in a boot? das verstehe ich nicht so ganz.


konsepte für DXGL?:D :D ;D

[Demirug]

Original geschrieben von Della Morte
hehehe..... ich hab noch paar fragen:D


gerade in bereich raytracing, also die hlsl hochsprache würde noch damit laufen natürlich wirts extansion geben müssen, oder iss das schon seit anfang an mit gedacht?

macht raytracing nicht nur bei reflexions und refractions sinn? könnte man zukümpftig auch caustics lichtbrechungen in realtime realisieren via raytracing, oder wie schon besprochen softshadows?

was wären die anforderungen? gibs heute nur ein mir bekannte graka die raytract die fx 16 mit 8pa risc prozessoren und kostet ca.60,000€

Für einen Raytracer braucht man eher eine neue API. Aber zum Beschreiben der einzelnen Komponetenen (Oberflächen, Lichtquellen, Volumen, usw) kann man wieterhin die gleichen Hochsprachen benutzten wie jetzt für VS und PS.

In Saarbrücken an der Uni arbeitet man an einem Raytracerchip.

[Della Morte]

ja hab ich gelesen sehr interessant,10 athlon pc im cluster und 10fps:liplick: lecker


edit: quelle klick (http://www.heise.de/newsticker/data/law-18.03.03-002/)

[Demirug]

Original geschrieben von Della Morte
Tja eben Warum 2 Apis?:O kann ja auch dx für linux bzw unix/irix geben
ich persönlich arbeite schon seit 8 jahren mit ogl und meine meinung noch sind viel mehr For more powerhungris AppZ optimiert wie DX, dx lüppt im vergleich zu ogl 1.3 fast grottig im wirframe,denke aber ist optimierungssache? und da teilt es sich wider ogl iss professional weil optimiert wirt, und dx iss all user in a boot? das verstehe ich nicht so ganz.


konsepte für DXGL?:D :D ;D

An einem DX für Unix/Linux wird MS nicht wirklich interesiert sein und ich habe irgendwie auch den Eindruck das man auf der Linux Seite kein wirkliche interesse daran hat.

Die DX Treiber sind in der Regel nicht sonderlich für Wireframes optimiert. DX wird auch optimiert aber eben in eine andere Richtung. Bei richtiger Programmierung kann man mit beiden APIs das maximum aus einer Karte herausholen.

Bei den Spieleentwickler ist DX etwas beliebter als OpenGL weil dort de neuen Features gleich einheitlich genormt sind und man sich nicht mit vielen Hersteller extension rumschlagen muss.

[Demirug]

Original geschrieben von Della Morte
ja hab ich gelesen sehr interessant,10 athlon pc im cluster und 10fps:liplick: lecker

Ich glaube das verwechselt du was. Ich meine das:

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

[Della Morte]

Original geschrieben von Demirug
An einem DX für Unix/Linux wird MS nicht wirklich interesiert sein und ich habe irgendwie auch den Eindruck das man auf der Linux Seite kein wirkliche interesse daran hat.

Die DX Treiber sind in der Regel nicht sonderlich für Wireframes optimiert. DX wird auch optimiert aber eben in eine andere Richtung. Bei richtiger Programmierung kann man mit beiden APIs das maximum aus einer Karte herausholen.

Bei den Spieleentwickler ist DX etwas beliebter als OpenGL weil dort de neuen Features gleich einheitlich genormt sind und man sich nicht mit vielen Hersteller extension rumschlagen muss.


würde allerdings diese extension optimierung nicht preformanter sein? ok würde mit mehrarbeit verbunden sein und somit teurer? aber am schluss müsste nicht jedem montag eine neue graka revison rauskommen die nur wennig morepower bringt? und in welche richtiung optimiert dx? in richtung grottiges wireframe zum ogl user zu vergraulen, den der shadingaspeckt im viewport iss auch mit ogl 1.3 nicht relevant?

mir scheint es so als lieber neue hardware entwickelt wiert wie darauf zu optimieren?

[Della Morte]

Original geschrieben von Demirug
Ich glaube das verwechselt du was. Ich meine das:

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

ja hast recht aber imho ist raytracing voll in mode gg aber sehr interessant thx



Die Saarbrücker arbeiten zudem an einem Ray-Tracing-Chip (SaarCOR), der die optimierten Algorithmen in Hardware ausführt. Ein dritter Arbeitsbereich versucht, die leistungsfähigen programmierbaren Shader von DirectX-9-Grafikkarten für Ray-Tracing-Berechnungen zu iss dabei:) der quelle

[Demirug]

Original geschrieben von Della Morte
würde allerdings diese extension optimierung nicht preformanter sein? ok würde mit mehrarbeit verbunden sein und somit teurer? aber am schluss müsste nicht jedem montag eine neue graka revison rauskommen die nur wennig morepower bringt? und in welche richtiung optimiert dx? in richtung grottiges wireframe zum ogl user zu vergraulen, den der shadingaspeckt im viewport iss auch mit ogl 1.3 nicht relevant?

mir scheint es so als lieber neue hardware entwickelt wiert wie darauf zu optimieren?

Unter verwendung der Hersteller Extensions kann man unter umständen noch ein paar Prozent herausholen. Das ist aber wie du schon sagst einfach zu teuer. Es kommt ja auch jeden Montag eine neue CPU Revision raus die kaum mehr bringt. ;)

DX Treiber sind in der Regel für das optimiert für was man DX primär nutzt. Und dort kommt es im wesentlichen auf (Texture)Fillrate an.

[Della Morte]

Original geschrieben von Demirug
Unter verwendung der Hersteller Extensions kann man unter umständen noch ein paar Prozent herausholen. Das ist aber wie du schon sagst einfach zu teuer. Es kommt ja auch jeden Montag eine neue CPU Revision raus die kaum mehr bringt. ;)

DX Treiber sind in der Regel für das optimiert für was man DX primär nutzt. Und dort kommt es im wesentlichen auf (Texture)Fillrate an.


tja eben darum bleibt dx immer für gamer und ogl immer für 3dusers und mal zocking :|

zum raytrac, ist schon krass wohin die tech gehen soll, heute ansatzweisse radioray mit ps2.0 , morgen raytracking in realtime, ubermorgen protienspeicher in terragigs grösse, yehar ich freue mich schon mal, danke dir für deine masslose gedult mit einem newbie in der grossen harten dx welt *gg* :sulkoff:


------------
nachtrag: Staun 3 seiten, lol die sind mir gar need aufgefallen:O