Licht/Schatten in 3d/ES

Previous topic - Next topic

kanonet

Hallo,

habe hier mal ein kleines Testprojekt um ein paar Probleme zu dokumentieren, auf die ich gestoßen bin. Das Bild zeigt was ich meine:

1. Die gesamte Szene ist zu dunkel. Der Untergrund bspw. ist eigentlich weiß! Wenn ich kein Licht erzeuge ist alles ok, d.h. hell, erzeuge ich aber ein Licht (z.B. um Schatten erzeugen zu können), ist es so dunkel wie im Bild. Vermutlich ist das kein Bug, sondern nur ein Fehler meinerseits? Bitte um Hilfe.
2. Der Schattenwurf ist vollkommen falsch, es wirkt als würde das Licht viel niedriger hängen, als es hängt. Mir ist aufgefallen, dass dies nur bei skaliertem Mesh auftritt, behalte ich die Ursprungsgröße bei, sind die Schatten korrekt.
3. Eine "Lücke" im Schatten. Ich habe keine Ahnung, wie das kommt, aber mir ist folgendes aufgefallen: importiere ich das Objekt aus .md2 oder .obj tritt diese Lücke (und andere Fehler) auf, importiere ich aus .3ds gibt es diese Lücke nicht. Möglicherweise ein Fehler im 3d-Converter?

Beispielprojekt ist angehangen.

Vielen Danke.

[attachment deleted by admin]
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

erico

My hint is that your model is not "closed" or some faces are flipped, it's a common error that 3d converting tools make. The flipped normals/surfaces are probably responsible for that shadow hole on number 3.

kanonet

Mittlerweile habe ich mich wieder mit 3D beschäftigt und kann die gemeldeten Fehler genauer beschreiben:

1. Sämtliche Objekte für die Schatten gezeichnet werden sind zu dunkel, sowohl mit, als auch ohne Textur. Ein ein helles, nahe Pplatziertes Licht ändert dies nicht, das Objekt wird nie auch nur annähernd so hell beleuchet wie eines ohne Schatten. Dieser Fehler wurde bereits durch andere vor einer ganzen Weile gemeldet. -> länger bekannter Fehler in GLBasic 3D-Engine

2. Schatten werden falsch berechnet, wenn das Modell skaliert wurde. Wird es in Originalgröße verwendet, gibt es keine Probleme. Es wurden bereits Probleme mit Kollision skalierter Objekte gemeldet, vermutlich ist dies ein verwandtes Problem. -> länger bekannter Fehler in GLBasic 3D-Engine

3. Zu diesem Fehler habe ich nichts neues zu berichten, möglicherweise liegt dies wirklich nur an meinem Objekt, wobei es dann doch verwundert, dass es beim konvertieren aus manchen Formaten nicht auftritt.


Gernot, ich ich weiß, dass sich der Fokus der GLBasic-Entwicklung immer mehr vom PC auf Mobile Devices verschiebt, aber könntest du trotzdem bitte bei Gelegenheit ein Auge auf die 3D Engine werfen? Danke. ;)
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

BumbleBee

Hmmmm ja leider geht im Moment iPhone und alles was man in die Hosentasche stecken kann vor. Ein paar deiner Probleme sind leider auch schon länger bekannt und nicht nur die. Ich trau mich nur nichts mehr zu sagen. ;) Da mußt du halt auch leider durch. Sei stark. =D

Cheers
The day will come...

CPU Intel(R) Core(TM) i5-3570k, 3.4GHz, AMD Radeon 7800 , 8 GB RAM, Windows 10 Home 64Bit

Kitty Hello

Ich hab's auf die Todo geschrieben. Ich muss mal wieder paar Nachtschichten einlegen :/

Kitty Hello

1. Die Szene ist dunkel, weil hier keine Objekte gezeichnet wurden und der Schatten das nichts überdeckt.
Wenn Du eine Szene hast, sollte hier beleuchtet sein.

2. Ist ein Bug - behoben im nächsten Update. Probleme wirst Du bei inhomogenem Skalieren (x,y,z nicht alle gleich) aber auch mit den Kollisionen und anderen Spezialeffekten haben. Wenn ich das ändere, wird GLBasic viel langsamer. Ich halte das für unötig.

3. Das Loch kommt daher, weil das Model nicht ganz geschlossen ist. Bei Schatten ist es wichtig, dass die Modelle ganz sauber modelliert sind und nur aus geschlossenen Körpern bestehen.

Sorry für die lange Zeit.

kanonet

Danke, dass du dir das angeschaut hast! :good:

1. Mir ist nicht ganz klar wie du das meinst (sorry falls ich dich nur nicht verstanden habe und die folgenden Ausführungen Blödsinn sind), aber ich kann ja meine Beobachtungen mal spezifizieren:
a) der Untergrund ("das Meer"):
Da Problem ist hier wohl einfach, dass das Objekt viel zu groß ist (5000x0x5000) und trotzdem nur aus 2 Faces besteht. Die Beleuchtung wird anscheinend an den Vertizes berechnet und deren Winkel zum Licht ist anscheinend zu spitz. Wenn ich das Licht auf extreme Höhe hänge (y=5000), dann ist es gut beleuchtet, d.h. es wird weiß dargestellt. Workaround ist es hier für mich, dass ich das Meer einfach in mehrere kleinere Faces teile, welche dann auch bei niedriger hängendem Licht korrekt beleuchtet werden. Schön wäre es, wenn die Beleutung auch bei so großen Faces (besser) funktionieren würde außerdem wäre ein Befehl CREATEPLANE() hier wohl auch nützlich. ;)
b) das Objekt ("das SCHIFF"):
Hier taucht der eigentlich von mir gemeinte Fehler auf: Objekte die einen Schatten werfen sollen sind immer zu dunkel, möglicherweise hängt dies damit zusammen, dass sie auf sich selbst keinen Schatten werfen. Wenn ich das richtig sehe, werden auf Objekte die Schatten werfen generell keine Schatten gezeichnet (bzw. sind sie so dunkel, dass Schatten auf ihnen nicht sichtbar sind). Ich habe dies bisher noch in keinem Projekt/Beispiel anders gesehen, daher wird dies wohl ein Fehler sein.? Siehe auch samples/3d/shadows und showroom/shadows (dies ist interessant, da der beschriebene Fehler in der beiliegenden exe nicht auftritt, jedoch taucht er auf, wenn ich den beiliegenden Code kompiliere; anscheinend bestand der vermutete Bug in der Schadowengine in V3 noch nicht).
2. Inhomogenes Skalieren brauche ich aber definitiv. In der Vergangenheit wurde bereits ein X_TRANSFORM Befehl vorgeschlagen, der ein Objekt dauerhaft in der Größe ändert  (müsste im VRAM arbeiten?). Würde dies das Problem lösen/umgehen und wenn ja, würdest du dies implementieren?
3. Ok, habe das Modell jetzt mal probeweise geschlossen - und siehe da die Lücke ist verschwunden. Finde ich zwar seltsam, aber denn werde ich meine Modelle eben ab jetzt schließen.

In diesem Zusammenhang wäre interessant, wenn X_Ambient_LT einen größeren Einfluss auf alle Objekte hätte, d.h. auch Licht abgewandte Objekt/Faces etwas heller beleuchtet werden würden. In der Realität werden Objekte schließlich auch nicht nur durch direktes Licht angestrahlt, sondern meistens durch mehrfach reflektiertes, indirektes Licht.
Wenn ich gerade bei "wünsch dir was" bin: es wäre sehr nützlich, wenn die normalen sprite-Befehle (rotieren, zoomen,..) auch ein Äquivalent für X_SPRITE hätten, bzw. auf dieses anwendbar wären. 8)

Vielen Dank und Grüße,
Kanonet
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Schranz0r

Du zeichnest erst die ganze Szene(ganz normal) dann setzt du das Licht(X_SPOT_LT -3, 0, x,y,z, 0,0,0, 360
) und dann zeichnest du alles was schatten wirft!


I <3 DGArray's :D

PC:
AMD Ryzen 7 3800X 16@4.5GHz, 16GB Corsair Vengeance LPX DDR4-3200 RAM, ASUS Dual GeForce RTX™ 3060 OC Edition 12GB GDDR6, Windows 11 Pro 64Bit, MSi Tomahawk B350 Mainboard

kanonet

Standardverfahren zum Erzeugen von Schatten. Sollte nicht das Problem sein, ich gehe mal davon aus, dass das ES dies korrekt umsetzt? Beschriebenes Problem tritt, soweit ich das sehe, auch bei korrekter Umsetzung auf.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Kitty Hello

Jo - das mit den großen Objekten ist ein Problem, da die Beleuchtung per vertice, nicht per pixel ist.

kanonet

#10
Aktuelle Liste der mir bekannten Bugs in der Schadowengine, das meiste wurde bereits genannt:


1. Update 9.014 hat kaum Verbesserungen gebrach, möglicherweise sogar Verschlechterungen, da sogar unskalierte Objekte falsche Schatten (zu kleine = wirkt als würde Licht weiter oben hängen als angezeigt) werfen. Hier ein Screenshot eines einfachen unscalierten Würfels (EntityCreateCube()), bei einer so niedrigen Lichtquelle sollte der Schatten deutlich größer sein.

Der Schatten scheint generell zu klein zu sein, bzw. hat er auch bei größerer Entfernung von Lichtquelle zu Objekt und von Objekt zur Projektionsfläche immer noch die Größe des Objektes, wird also nicht ausreichend hochskaliert. Eine kleinere Skalierung des Objekts erzeugt daher die Illusion, der Schatten würde korrekt berechnet werden, wobei dies nicht der Fall ist. Hier ein einfacher, nicht skalierter Würfel:



2. Objekte, die Schatten werfen sollen, sind immer noch zu dunkel. Ich gehe davon aus, dass sie berechnet werden, als ob sie selbst komplett im Schatten stehen. Hier zwei identische Würfel, wobei einer Schatten werfen soll und deshalb komplett zu dunkel ist:



3. Schatten werden nicht durch Nebel beeinträchtigt, d.h. ein Schatten ist auch dann deutlich zu sehen, wenn alle anderen Objekte im Nebel verschwunden sind. Dies betrifft nicht nur die "falschen Schatten" (gemeint ist die Verdunklung der Objekte, siehe Punkt 2), sondern auch die korrekt geworfenen Schatten auf anderen Objekten. Hier zwei identische Würfel, einmal mit und einmal ohne Schatten:



4. Die Schatten inhomogen skalierter Objekte werden an die völlig falsche Stelle projiziert und bewegen sich folglich auch bei gleichmäßiger Bewegung von Objekt oder Lichtquelle sprunghaft. Wer das sehen will sollte einfach den Donut in samples/shadows mit einem x_scaling 3,1,1 bearbeiten... Hier ein skalierter Würfel (3,1,1):



Zu den Problemen mit Schatten+Skalierung (also Punkte 1+4): neben der Parallele zu den Problemen mit Kollision+Skalierung (über die habe ich nur gelesen, es jedoch nicht getestet, wurden die mittlerweile behoben?), ist mir vor allem eines aufgefallen: ich muss die Objekte, welche Schatten werfen sollen noch einmal rotieren und an ihre Position bewegen, jedoch muss ich sie nicht skalieren! Egal ob ich an dieser Stelle ein x_scaling setze oder nicht und egal mit welchen Werten ich dies füttere - auf den Schatten hat dies überhaupt keinen Einfluss. Ich vermute daher, dass das skalieren für den Schatten versehentlich gar nicht durchgeführt wird und die beschriebenen Probleme möglicherweise daher rühren.

Außerdem verweise ich noch mal auf meinem Post vom 16.02. 6:17 Uhr in diesem Thread.
Es wäre schön wenn diese Bugs behoben werden könnten und/oder es zumindest eine kurze Stellungnahme à la "gelesen, schaue ich mir an / wird in nächster Zeit nicht behoben werden." gibt.
Grüße und vielen Dank.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

erico

my guesses...

1 - on code, can you cast the shadows after you re escale the objects? may be recreate the light source for such?

2 - try keep the 3d world you are shadowing as small as possible to the original scale, maybe ambient light can help? Beware that your sea polygon may be touching or overlapping the ship.
It sure helps if your sea has more polygons but beware when positioning them for shadows,
you should have them slightly under the ship, never touching it.

I hope it helps, you can always find turn around to known bugs if you can re-think your scene according to your final output. Final output is what matters.

Most 3d programs displaying open gl graphics have these problems too.

Can someone translate this in german in a proper way?

Kitty Hello

Hallo,

kannst Du bitte ganz kleine Projekte machen, die die Fehler eindeutlig beschreiben? Dann ist das leichter das zu testen.
Sorry.

kanonet

#13
Quote from: kanonet on 2011-Feb-27ich muss die Objekte, welche Schatten werfen sollen noch einmal rotieren und an ihre Position bewegen, jedoch muss ich sie nicht skalieren! Egal ob ich an dieser Stelle ein x_scaling setze oder nicht und egal mit welchen Werten ich dies füttere - auf den Schatten hat dies überhaupt keinen Einfluss.
Aus irgendeinem Grund kann ich dies gerade nicht mehr reproduzieren... Aber alle der beschriebenen Fehler können in diesem kurzen Projekt gesehen werden:
Code (glbasic) Select
SETSCREEN 800,600,0

SETCURRENTDIR("..")
LOADSPRITE "icon.png", 0

LOCAL skybox=0, box1=1, box2=2, phi, lx, ly, lz, mx, my=600, mz=15, scale=3

// Objekte erzeugen
CreateCube  (skybox, -100, RGB(255, 255, 255))
CreateCube  (box1, 5, RGB(255,255,255))
CreateCube  (box2, 5, RGB(255,255,255))

// Hauptschleife
WHILE TRUE
// Eingaben abfragen
mx = mx + MOUSEAXIS(0) // Maus X-Achse -> Kamera drehen
my = my + MOUSEAXIS(1) // Maus Y-Achse -> Kamera zoomen
mz = mz + MOUSEAXIS(2) // Mausrad -> Licht bewegen
IF KEY(27) THEN INC scale, 0.1 // + gedrückt -> Quader strecken
IF KEY(53) THEN DEC scale, 0.1 // - gedrückt -> Quader stauchen

// Bewegung des Lichts berechnen
phi = GETTIMERALL() / 250
lx = SIN(-phi*3)*mz*2
ly = (SIN(3*phi)-COS(4*phi)) // bitte auch konstanten Wert ausprobieren, z.B. ly=2
lz = COS(-phi*3)*mz*2

// 3D Szene zeichnen
X_MAKE3D 1, 500, 45
X_CULLMODE 1
X_FOG RGB(180,180,200), FALSE, 250,270

// Kamera
X_CAMERA my*COS(mx)/10,14,my*SIN(mx)/10, 0,0,0

// zeigt uns wo der Schatten liegen und wie er aussehen sollte (siehe Hinweise bei der Funktionsdefinition)
ShadowLines(box1, lx,ly,lz)

// Lichtquelle
X_SPOT_LT   0, RGB(255,255,255), lx,ly,lz, -lx,-ly,-lz, 360

// Skybox
X_DRAWOBJ skybox, 0

// Box1 (mit Schatten)
X_MOVEMENT 0,0,0
X_SCALING scale,1,1 // spiele mal etwas damit rum, das Verhalten der Schatten ist interessant ;)
X_DRAWOBJ box1,0

// Box2 (ohne Schatten)
X_MOVEMENT 0,-7,0
X_SCALING scale,1,1
X_DRAWOBJ box2, 0

// Billboard
X_SPRITE 0, 0,7,0, 0.03

// Lichtquelle für Schatten setzen
X_SPOT_LT  -3, RGB(255,255,255), lx,ly,lz, -lx,-ly,-lz, 360

// schattenwerfenden Würfel zeichnen
X_MOVEMENT 0,0,0
X_SCALING scale,1,1
X_DRAWOBJ box1,0

// etwas Text ausgeben
X_MAKE2D
DRAWRECT 0,0,800,20,RGB(0,0,0)
PRINT "KAMERASTEUERUNG: MAUS BEWEGEN    |    LICHTQUELLE BEWEGEN: MAUSRAD    |    QUADER SKALIEREN: +/-", 0,0

// und alles auf den Bildschirm bringen
SHOWSCREEN
WEND


// zeichnet eine Linie von der Lichtquelle durch jeden Vertex des Objekts und bietet somit eine Orientierung wie der Schatten aussehen sollte
// ignoriert GLBasic-bedingt sämtliche Drehungen, Skalierungen und Bewegungen des Objekts
FUNCTION ShadowLines: obj, x,y,z
LOCAL face[], count = X_NUMFACES( obj )
X_CULLMODE 0 // X_DOT und X_LINE funktionieren nur bei X_CULLMODE 0
FOR i = 0 TO count - 1
X_GETFACE obj , 0 , i , face[]
X_LINE x,y,z, 4*face[0][0]-3*x, 4*face[0][1]-3*y, 4*face[0][2]-3*z, 3, RGB(255,255,0)
X_LINE x,y,z, 4*face[1][0]-3*x, 4*face[1][1]-3*y, 4*face[1][2]-3*z, 3, RGB(255,255,0)
X_LINE x,y,z, 4*face[2][0]-3*x, 4*face[2][1]-3*y, 4*face[2][2]-3*z, 3, RGB(255,255,0)
NEXT
X_CULLMODE 1
ENDFUNCTION

Übrigens verhält sich X_LINE seltsam, es funktioniert nur mit X_CULLMODE 0 und färbt die ganze Szene entsprechend der eigenen Farbe (und die eigene Farbe ist auch nicht immer konstant...), siehe Code.
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

Marmor

x_line win funzt hier  falls es hilft