Dot3/Bump
Übersicht

![]() |
FoppeleBetreff: Dot3/Bump |
![]() Antworten mit Zitat ![]() |
---|---|---|
Hallo,
Ich bins mal wieder und wieder mit 'ner Frage ![]() Also, Ist Bumpmapping/Dot3Mapping ein offizielles Feature von Blitz oder ist das in Heimarbeit entstanden? TextureBlend hat ja 'nen eigenen Flag dafür, in der Hilfe ist der allerdings nicht verzeichnet. Ausserdem muss man sich ja anscheinend eine eigene Funktion zur Berechnung der Normalen schreiben. Ich habe zum Thema folgenden recht alten Beitrag gefunden: https://www.blitzforum.de/foru...light=dot3 Leider funktioniert das auf diese Art nur eingeschränkt. Trotzdem Respekt an den Autor, ich finde das Tutorial gut gemacht, leider hat sich irgendwo ein Fehler eingeschlichen. Wie auch immer, ich will dieses Feature, und wenn ich mich selbst in die Tiefen der Materie stürzen muss... Aber bevor ich das tue...Gibt's vielleicht irgendwo nen Codeschnippsel wo das schon funktioniert? ![]() |
||
![]() |
The_Nici |
![]() Antworten mit Zitat ![]() |
---|---|---|
es gibt kein bumpmapping in Blitz, nur Normalmapping. | ||
![]() |
Foppele |
![]() Antworten mit Zitat ![]() |
---|---|---|
Wie auch immer, die Begriffe scheinen mir nicht immer ganz klar abgegrenzt...tut aber für meine Frage nicht viel zur Sache. | ||
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Fredborgs Athena Beispiel zeigt normalmapping, nur wird das mit animierten B3D Meshes nicht gehen solltest du das gehofft haben.
Prinzipiell ist es ein feature in Blitz3D jedoch ist es ein fortgeschrittenes feature was nicht einfach nur mit "Setze Textur und gut ist" zu machen ist, da die Vertexfarben entsprechend ihrer Normalenrichtung zum Licht eingefärbt werden müssen. Die normalen Lichter tun das nicht, denn das sind DX Hardware Lights, die machen nichts ausser einfach die Farben auf der Geometry ändern. Eine weitere einschränkung ist das man nur punktlichter nehmen kann, keine Cone etc, ausser man hat freude daran nochmehr performance mit der berechnung zu toasten ![]() |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Foppele |
![]() Antworten mit Zitat ![]() |
---|---|---|
Bist du dir sicher dass nur Punktlichter gehen, prinzipiell müsste das mit Spot und Directional genauso gehen,
ich wüsste nicht wieso das mehr zu berechnen wäre... das Beispiel was ich oben gelinkt habe ist übrigens ein Directional Light auf einem bewegten Mesh (rotierende Kugel). Und im grossen und ganzen funktioniert das recht hübsch, es ist bloss irgendein Fehler drin der vom Autor bestimmt nicht beabsichtigt ist, und zwar hat eine Änderung der Lichtfarbwerte Rot und Grün keinen Einfluss aufs Ergebnis, wenn man Blau verändert verändert sich lediglich die Intensität, aber nicht die Farbe. ![]() [EDIT] Sorry,rotiert doch nicht die Kugel, aber das Licht ist beweglich was ja auf gleiche rauskommt. [EDIT] Oops, peinlich: Kugel rotiert UND Licht ist beweglich! |
||
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
gehen würden alle typen von lichtern. Aber die anderen sind rechenintensiver speziell die Transformation in den Tangentialraum.
Speziell Spot hat in allen Samples die ich bisher gesehen hab nichts gebracht ausser hässliche Fehler ![]() Directional habe ich eigentlich nie beispiele gesehen. Wie gesagt, das Standard Beispiel ist Fredborg's (Mikkel) Athena beispiel da die Athena statue eigentlich das Standardmodel für Normalmapping Effekte ist. Es hat als highpoly zig zehntausend polygone, während es mit lowpoly + normalmap gleich aussieht aber keine tausend polygone hat. |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Foppele |
![]() Antworten mit Zitat ![]() |
---|---|---|
Schade, die Athena Demo scheint nicht mehr auffindbar zu sein ![]() Und ich fürchte in bin zu unfähig mir ne eigene Normalenberechnungsfunktion zu schreiben, ich kann zwar das Beispiel oben zu 90% nachvollziehen, aber warum das nicht richtig geht ist mir ein Rätsel. Na ja, falls hier noch irgendjemand Normalmapping benutzt, ich würd mich freuen wenn derjenige mir mit 'nem Codeschnipsel behilflich sein könnte... [EDIT] Ich hab auf der französischen Seite ein Tutorial/Codebeispiel aus der Feder von Mikkel Fredborg gefunden. Auch hier ist das Problem das gleiche, die normalgemappten Meshes reagieren nicht mehr auf buntes Licht. |
||
![]() |
Ray-Tracer |
![]() Antworten mit Zitat ![]() |
---|---|---|
http://www.selfmadegames.de/
schau dir den BSM-Renderer von Shodan mal an. |
||
__wunschklang__ |
![]() |
Foppele |
![]() Antworten mit Zitat ![]() |
---|---|---|
Scheint ja tatsächlich zu funktionieren, ich kanns leider mit der Blitz Demo nicht testen wg. Grössenbeschränkung für bb Files... muss ich wohl warten bis ichs mir mal kaufe...
Hab ich das richtig verstanden dass in der neuesten Version das Erzeugen von Meshkopien nicht mehr nötig ist? |
||
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Das war noch nie nötig, das ist nur so ne eigensart von dem system das ganze so zu handhaben.
Es gibt in Blitz nur etwas wozu man fast zwingend meshkopien braucht und das ist wenn man cartoon rendering machen will weil man dann das objekt kopiert, vergrössert, flipmesh macht und es schwarz einfärt als outline. |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Mr.Keks |
![]() Antworten mit Zitat ![]() |
---|---|---|
Dreamora hat Folgendes geschrieben: Directional habe ich eigentlich nie beispiele gesehen. Ich bin fast sicher, auf bb.com mal eine halbwegs simple Lösung dafür mittels einer Cubemap gesehen zu haben... Dadurch kann man ja halbwegs leicht eine Palette von RGBs für alle Richtungen vorgeben und die Hardware pickt dann durch die Cubemap die zur Richtung passende Farbe heraus - sogar auf animierten Meshes. Habe das auch mal in DGX umgesetzt... Da ich es allerdings nicht soooo Schick fand und Cubemaperstellung mir viel zu aufwändig wäre, habe ichs wieder ausgebaut.
|
||
MrKeks.net |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Das war aber doch damals auch pointlight?!
Man verwendet einfach die Cubemap um die Normalenfarben auf die Normalmap zu bekommen anstatt dafür die Vertices umzufärben. Erinner mich noch an das animierte Mesh mit dem die technik gezeigt wurde ... Wundert mich warum nie jemand da nachgehackt hat damit man die cube map (bei 6 pixeln nicht die gigantische herausforderung ^^) dynamisch hätte aktualisieren können ... sollten doch eigentlich einfach die lichtposition relativ zur entity umgerechnet auf die farben der normalen sein oder? |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Mr.Keks |
![]() Antworten mit Zitat ![]() |
---|---|---|
naja, wenn man für alle entities dieselbe cubemap nutzt, ist es ja schlicht wie directional light, oder? cubemaps sind doch von ihrer natur her directional. | ||
MrKeks.net |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
OK wenn du für alle die gleiche nutzt schon ![]() Allerdings ist das ja nicht zwingend die Idee dahinter, man kann auch für jede entity eine eigene über dem normalmap layer anlegen und die cubemap dynamisch anpassen ... sobald man denn die umrechnungsformel hat um das dynamisch zu machen ... |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Shodan |
![]() Antworten mit Zitat ![]() |
---|---|---|
Dremora hat folgendes geschrieben.
Zitat: man kann auch für jede entity eine eigene über dem normalmap layer anlegen und die cubemap dynamisch anpassen... sobald man denn die umrechnungsformel hat um das dynamisch zu machen ...
Und genau das macht der BSM_Renderer. Er berechnet die Lichtrichtung zw. Lichtquelle und Zielobjekt( welches an die Cubemap übergeben wurde). Bei direktionalem Licht kann man die Cubemap an mehrere Objekte vergeben werden( Der Befehl zum Erstellen der Cubemap gibt ja das Cubemap-Handle zurück), da die Richtung für alle gleich ist. Da spart man schon wieder Rechenzeit. Shodan |
||
www.selfmadegames.de |
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
Hab mir die Library nie wirklich angesehen, werd nur immer von usern davon die nicht so erfahren sind, gefragt warum das die Entity kopiert wird und kann ihnen dann jeweils keine gescheite Antwort geben, da ich keinen einleuchtenden Grund kenne ...
Vielleicht hättest du mir, da du hier grad aktiv zu dem thema schreibst, die Begründung für die Fälle? ![]() ![]() |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Shodan |
![]() Antworten mit Zitat ![]() |
---|---|---|
Aber es wird doch gar kein Objekt kopiert im BSM_Renderer.
Kann es sein, dass das Tutorial gemeint ist? Wenn ja, dann hat das nen völlig anderen Grund. In dem Tutorial wird das Objekt kopiert um die DirectX-Beleuchtung durch die Blitz3D-Lichtquellen und das ambiente Licht wieder herzustellen. Das klappt nämlich nicht mit einer Dot3-Map auf dem Objekt. Deswegen braucht man dafür ne Kopie des Objekts ohne die Dot3-Map. Der Renderer hat aber Funktionen, um ambiente Beleuchtung zu simulieren ohne das man eine Objekt-Kopie braucht. Ist dann allerdings unabhängig von der Blitz3D-Beleuchtung. Shodan |
||
www.selfmadegames.de |
![]() |
Foppele |
![]() Antworten mit Zitat ![]() |
---|---|---|
Also, ich fass es nochmal zusammen so wie ich es verstanden habe:
1. Bei Dot3Mapping gehen intern die Farbwerte der Lichtquellen verloren, warum auch immer. Jedenfalls gelingt es mir nicht, ein Objekt mit Dot3Mapping farbig zu beleuchten, weder mit der Standardbeleuchtung, noch wenn ich mir eine Funktion schreibe welche die Beleuchtung neu brechnet und das Ergebnis in die Vertexfarben schreibt. 2. Der BSM Renderer erzeugt für jeden Mesh eine Kopie, der eine wird normal beleuchtet, der andere bekommt Normalmapping, dann wird der eine über den anderen drübergeblendet (additiv oder multiply oder wie auch immer). Oder? |
||
Dreamora |
![]() Antworten mit Zitat ![]() |
|
---|---|---|
1. Nein nicht "warum auch immer" sondern weil DX Licht = Vertex Licht und Dot3Bump = Vertex Effekt der die Vertexfarben nutzt
-> das eine schliesst das andere aus. Dot3 Normalmapping oder Hardwarelicht aber nicht beides. |
||
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. |
![]() |
Foppele |
![]() Antworten mit Zitat ![]() |
---|---|---|
Dreamora hat Folgendes geschrieben: 1. Nein nicht "warum auch immer" sondern weil DX Licht = Vertex Licht und Dot3Bump = Vertex Effekt der die Vertexfarben nutzt
Wie ich schon sagte, mit Vertexfarben geht es auch nicht! Ich habs echt ausgiebig getestet. |
||
Übersicht


Powered by phpBB © 2001 - 2006, phpBB Group