Fragen zu einem Schattierungsalgorithmus

[randa]

ich werd meinen Algorithmus so oder so versuchen, wie ich sagte, es ist Prinzipsache. Ich will es einfach so zum Laufen bringen. Wenn ich mich nicht anstrengen würde und meinen Gedankengang zuendeführe, was soll ich dann später bei anderen eigenen Algorithmen machen?

Aber ich bin absolut offen für Shadow Volumes und würde das auch implementieren, ohne frage. Ich hab übrigens nach Büchern gesucht, in denen solche Sachen erklärt sind, hab aber nix gefunden. Kennt jemand ein Buch das sich mit den Implementierungs- und Mathematikdetails in diesem Bereich befasst?

Nur googeln und ein paar lasche Seiten reicht ja meist nicht um sich in das Thema zu vertiefen.

Aber nun zurück zum Topic

Edit: @otze: ich bekomme ne wage idee, aber auf welche weise kommt man dazu, bestimmte Werte im Buffer zu speichern. Oder Klarer: Woher kommt z.B. der Wert 3?

[otze]

in directx ist der stencil buffer ein teil des zbuffers, und genau wie es beim zbuffer einen vergleich gibt der überprüft ob der alte oder neue pixel übernommen werden soll,so gibt es auch beim stencil buffer so eine abfrage.

an den wert 3 kommt man zb, wenn man sagt dass der stencil test immer bestanden wird, der stencil wert um 1 erhöht wird wenn der test positiv verläuft, und der pixel 3mal überzeichnet wird.

//edit das buch welches man bei scherfgen-software findet handelt diese ganze theorie inklusive schatten und lightmaps ab(auch wenn das erst ganz am ende geschieht)
alternativ gehste auf www.flipcode.com die haben alles(aber nur auf englisch)

[dot]

otze schrieb:

in directx ist der stencil buffer ein teil des zbuffers

afaik gilt das für moderne grakas allgemein ( nicht nur DirectX )

otze schrieb:

//edit das buch welches man bei scherfgen-software findet handelt diese ganze theorie inklusive schatten und lightmaps ab(auch wenn das erst ganz am ende geschieht)
alternativ gehste auf www.flipcode.com die haben alles(aber nur auf englisch)

seit wann kommen im scherfgen buch lightmaps vor?
außer einer kurzen erklärung was lightmaps sind is mir da noch nicht viel mehr untergekommen.

flipcode ist imho

auf GameDev ( imho noch mehr ) wirst du sicher auch einiges finden

[otze]

im buch werden die prinzipien der lightmaps imho relativ gut erklärt,mit dem text und von ner andren seite die algos, und du bist fit

[TomasRiker]

Light-Maps beschreibe ich in meinem Buch so gut wie gar nicht. Bei der Implementierung gibt es da nämlich sehr viel mehr zu beachten als bei der Stencil-Buffer-Variante, vor allem bei Direct3D ist das ziemlich problematisch. Die meisten Demos, die man findet, arbeiten mit OpenGL.

[TGGC]

Chaotischer Thread. Ich versuche mich nochmal auf die "originalen" Fragen zu beziehen, da ich sonst nicht wüsste, was du eigentlich wissen willst.

zu 1. Du musst einen eigenen Rasterizer schreiben, weil du die Pixel ja auf der CPU shaden willst. Der könnte die diese Informationen ausspucken.

zu 2b. Man müsste wahrscheinlich irgendein hierachisches System wie einen Octree verwenden. Zusätzlich könntest du noch für jedes Face die Occluder cachen und im nächsten Frame als early out test verwenden.

Bye, TGGC \-/

[rapso]

TomasRiker schrieb:

Light-Maps beschreibe ich in meinem Buch so gut wie gar nicht. Bei der Implementierung gibt es da nämlich sehr viel mehr zu beachten als bei der Stencil-Buffer-Variante, vor allem bei Direct3D ist das ziemlich problematisch. Die meisten Demos, die man findet, arbeiten mit OpenGL.

Eigentlich ist es in oGL und d3d das gleiche von der implementierung her.

dass man mehr demos für oGL findet liegt daran, dass die NV jungs damit lieber prototypen und weil dort die extensions früher vorhanden sind. aber von der implementierung her ist es auf beiden APIs eigentlich gleich
(sorry für den flame )

randa schrieb:

ber ich habe mit meinem Software Renderer schon recht viele Phong-Geshadete Objekte auf einmal darstellen können, flüssig. Egal, beim Software-Rendering erwarte ich ja auch keine Peformance, es geht mir im Prinzip um die Bildqualität

für phong mußt du ja auch nur einen vector interpolieren und dann ein paar dot3 und vielleicht noch paar normalise.
jetzt mußt du pro pixel den du setzt durch die welt raytracer. je 3polys die du testest werden mindestens soviel zeit ziehen wie dein phongshading.

aber ich würde sehr gerne deine demo davon sehen wenn es läuft ;D. btw vielleicht solltest du dir "deffered rendering" anschauen, für so rechenintensive rasteriser wie du den machen möchtest könntest du sehr viel performancesteigerung bekommen

rapso->greets();

[randa]

TGGC schrieb:

Chaotischer Thread. Ich versuche mich nochmal auf die "originalen" Fragen zu beziehen, da ich sonst nicht wüsste, was du eigentlich wissen willst.

zu 1. Du musst einen eigenen Rasterizer schreiben, weil du die Pixel ja auf der CPU shaden willst. Der könnte die diese Informationen ausspucken.

zu 2b. Man müsste wahrscheinlich irgendein hierachisches System wie einen Octree verwenden. Zusätzlich könntest du noch für jedes Face die Occluder cachen und im nächsten Frame als early out test verwenden.

Bye, TGGC \-/

Danke, die erste Antwort auf meine gestellten fragen.

1. Ich habe einen eigenen Rasterizer, sonst hätte ich ja auch keinen Software Renderer. Ich benutzte, wie gesagt, kein DX (außer für den Screen Pointer, den ich über DirectDraw hole), sondern code selber.
   Edit: Ok, die Frage ist schwachsinn, der Rasterizer hat die Informationen eh schon. Hatte irgendwie einen Blackout, sonst hatt ich das selber gemerkt.

2)Immer diese Anglizismen Was ist ein Occluder, was ist ein early out test?
Eine Hierarchische Struktur wäre wohl sinnvoll, damit ich nicht linear durch alle Polygone der Welt iterieren muss um den Kollisionscheck zu machen.

Ich muss mir die Formeln für den Geraden-Ebenen Schnittpunkt nochmal anschauen, denke aber das krieg ich schon hin. Aber bei der Überprüfung, ob der ermittelte Schnittpunkt tatsächlich auf der Fläche liegt, hab ich meine Probleme. Durch eine simple if-Abfrage ist es nicht getan, die ebene (bzw. die Polygonfläche) kann ja beliebig im Raum stehen. Wäre die Fläche z.B. parallel zu xy, könnte ich leicht durch "if (x>... && x<... && y>... und y<...) " die Prüfung machen.
Aber wie könnte ich die Prüfung für beliebige positionierte Flächen machen?
Das ist zur Zeit das einzige, wozu ich noch keine rechte Lösung hab.

[TomasRiker]

rapso schrieb:

Eigentlich ist es in oGL und d3d das gleiche von der implementierung her.

Ich habe ja auch nichts Anderes behauptet. Das Prinzip ist dasselbe, aber bei Direct3D gibt es laut diesem Artikel einige Dinge bei der Texturprojektionsmatrix, die etwas komplizierter sind: http://developer.nvidia.com/attach/6811

[rapso]

TomasRiker schrieb:

rapso schrieb:

Eigentlich ist es in oGL und d3d das gleiche von der implementierung her.

Ich habe ja auch nichts Anderes behauptet.

Bei der Implementierung gibt es da nämlich sehr viel mehr zu beachten als bei der Stencil-Buffer-Variante, vor allem bei Direct3D ist das ziemlich problematisch.

ja, oGL hat glPolygon offset und bei d3d muss man sich die matrix selbst generieren, aber ob das als implementierungsunterschied durchgeht?. das alte paper kenn ich, aber die haben es endlich geschaft die paper vom letzten workshop online zu legen, da gibt es ja ein schönes neues paper, das problem ist dort einigermassen gut gelöst und in deren demo sah das auch fehlerfrei aus.

rapso->greets();

[TomasRiker]

rapso schrieb:

TomasRiker schrieb:

Bei der Implementierung gibt es da nämlich sehr viel mehr zu beachten als bei der Stencil-Buffer-Variante, vor allem bei Direct3D ist das ziemlich problematisch.

Aussage: Implementierung Shadow-Map ist komplizierter als Stencil-Buffer-Variante. Bei Direct3D gibt es zudem noch zusätzliche Schwierigkeiten.

[rapso]

TomasRiker schrieb:

rapso schrieb:

TomasRiker schrieb:

Bei der Implementierung gibt es da nämlich sehr viel mehr zu beachten als bei der Stencil-Buffer-Variante, vor allem bei Direct3D ist das ziemlich problematisch.

Aussage: Implementierung Shadow-Map ist komplizierter als Stencil-Buffer-Variante. Bei Direct3D gibt es zudem noch zusätzliche Schwierigkeiten.

mit dem komma dazwischen klang es als würdest du dich mit "besonders problematisch" auf die implementierung beziehen.... wir korrintenkacker wir.

rapso->greets();

[TGGC]

zu 1) Ok, funktioniert jetzt eigenltich genau wie Texturemapping, nur das nicht die TexCoords sondern die Vektoren der Eckpunkte interpoliert werden.

zu 2) Occluder= Verdecker, early out test= früh raus Überprüfung (kauf dich mal ein Wörterbuch)

Bye, TGGC \-/

[randa]

TGGC schrieb:

zu 2) Occluder= Verdecker, early out test= früh raus Überprüfung (kauf dich mal ein Wörterbuch)

dich auch

Danke für die Hilfe.

[dot]

das imho beste deutsch -> englisch und umgekehrt wörterbuch ist:

http://dict.leo.org

[randa]

dot schrieb:

das imho beste deutsch -> englisch und umgekehrt wörterbuch ist:

http://dict.leo.org

na also, einen Thread zu einem Schattierungsalgorithmus muss man aufmachen, um einen Tipp für ein Wörterbuch zu erhalten!

[TGGC]

randa schrieb:

TGGC schrieb:

zu 2) Occluder= Verdecker, early out test= früh raus Überprüfung (kauf dich mal ein Wörterbuch)

dich auch

Danke für die Hilfe.

Immer wieder gern.

Bye, TGGC \-/

[randa]

Hi leute
Ich steck gerade bei der Implementierung meines Algorithmus fest. Ich hab schon rumgeschaut und stundenlang dagesessen und versucht es zu verstehen, aber ich raffs nicht ganz. Ich rede von der Bestimmung des Schnittpunkts zwischen Gerade und Ebene. Der Hauptgrund, warum ichs nicht verstehe liegt wohl an meinen 5en in Mathe, konstant über viele Jahre hinweg
Gegeben sind mir: Anfangs und Endpunkt der Gerade, die Eckpunkte der Fläche (mit denen ich die Ebene beschreiben kann). Leider kann ich mit der Parameterform von Ebene nix Anfangen und die Gleichungen dazu übersteigen dass, was ich in Mathe gelernt habe, weit.
Vielleicht wäre jemand so nett und würde sich die Mühe machen, mir einen pragmatischen Ansatz zur Bestimmung des Schnittpunkts zu geben. Vor allem die Determinante, die dazu notwendig ist, begreife ich nicht ganz.

Soviel ich verstanden habe, kommt aus der Formel der Skalierungsfaktor (Lamda) raus, den ich mit der Gerade multiplizieren muss, um auf den Schnittpunkt zu kommen.

Die Tatsache, dass es dazu scheinbar mehrere Lösungsvarianten gibt, verwirrt mich zusätzlich.

Wäre dankbar für eine (mehr oder weniger) umfassende erklärung.

[TomasRiker]

Auf meiner Homepage gibt es Tutorials zur 3D-Kollisionserkennung, und dieses spezifische "Problem" wird da auch behandelt.

[randa]

danke vielmals
sieht vielversprechend aus und ich werds mir anschauen.