Messages

Also aktuell wird es mal beleuchtet und mal nicht, je nachdem wo das Licht steht. Wohin das Sprite dabei gedreht ist, hat keinen Einfluss. Siehe Codebeispiel.

Wie es idealerweise sein sollte? Hmm, bin mir nicht ganz sicher es gibt Fälle in denen es als normales Objekt behandelt (also auch beleuchtet)  werden sollte (z.B. Laub, Partikel) und es gibt Fälle in denen die Beleuchtung keine Rolle spielen sollte (z.B. Explosionen). Ist also nicht ganz einfach zu beantworten. Ideal wäre da wohl eine Wahlmöglichkeit, wobei ich dem keine hohe Priorität geben würde, da wäre eine Rotationsmöglichkeit des X_Sprites schon wichtiger. Aber auch hier hat das Bugfixing eine höhere Priorität als die Implementierung neuer Features.
So ungefähr sollte X_SPRITE auch funktionieren:

Code (glbasic) Select Expand

FUNCTION CreateBillboard: num, sz
sz=sz/2
X_AUTONORMALS 1
X_OBJSTART num
X_OBJADDVERTEX  sz, -sz,  sz, 1, 1, RGB(255,255,255)
X_OBJADDVERTEX -sz, -sz,  sz, 0, 1, RGB(255,255,255)
X_OBJADDVERTEX  sz,  sz,  sz, 1, 0, RGB(255,255,255)
X_OBJADDVERTEX -sz,  sz,  sz, 0, 0, RGB(255,255,255)
X_OBJEND
ENDFUNCTION

FUNCTION DrawBillboard: num, x,y,z, cx,cy,cz, scale, rotation
X_MOVEMENT x, y, z
X_SCALING scale, scale, scale
X_ROTATION rotation, 0,0,1
z=cz-z
IF NOT z THEN INC z, 0.0000000000001
X_ROTATION -ATAN((cy-y)*COS(ATAN(cx-x, ABS(z))), ABS(z)), 1,0,0
X_ROTATION ATAN(cx-x, z), 0,1,0
X_DRAWOBJ num, 0
ENDFUNCTION

Übrigens verhält sich X_LINE seltsam, es [...] färbt die ganze Szene entsprechend der eigenen Farbe [...], siehe Code.

Tritt vor allem im Releasemodus auf, im Debugmodus jedoch kaum.

No, its a normal behavior. Foreach defines a local variable (for das it the same way) that existis only in the for-next loop, you dont have to define it before. At least, i think its intended, 'cuz it works this way for a long time.

Schau dir mal DIMDATA an.

Nochetwas aufgefallen:

5. X_SPRITE wird nicht korrekt beleuchtet. Die Beleuchtung scheint berechnet zu werden, als ob das Sprite sich nicht zur Kamera gedreht hätte, sondern noch in die "ursprüngliche" Richtung schaut.

Ich habe den Beispielcode in meinen vorherigen Post um ein X_SPRITE erweitert um dies zu demonstrieren. Siehe bitte dort.
Grüße.

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.

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 Expand

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.

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.

Same here, new compiled Programms crash.

You found the .app folder? then store your sprite there.

now you just have to switch the PRINT and the DRAWSPRITE command:

Code (glbasic) Select Expand

LOADSPRITE "Sprite.bmp", 0
DRAWSPRITE 0, 100, 100
PRINT "Hello World", 100, 100
SHOWSCREEN
MOUSEWAIT

To make the Text larger, you have to create an other font and use it. Check the tool fontcreator (is this the proper english name?) and the help for LOADFONT.

In your project folder, there is a "project.app"-folder. This is the folder, which your Programm use. You can switch to another folder with SETCURRENTDIR().

If you put the DRAWSPRITE after the PRINT, the sprite will draw over the text and you will see just the sprite, but no text. So better switch both.

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.

Danke, dass du dir das angeschaut hast!

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.

Vielen Dank und Grüße,
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.

Happy Birthday/ alles gute zum Geburtstag!

Again, thank you for all the testing work!
Nice to see, if everything works like it should do.

@Moru: I implemented what you asked for, but maybe in a different way... You will get the information not from RETURN, but its stored in TKey.state and of cause it only works, if you use DOWN() in your loop. I hope this will help you anyways? But RETURN and .state can get changed easiely, if you want that... Update is in first Post.

@Ragaril: Interessting information. But i think this is to big and to special to implement it in my functions. But i think it should be possible to use both together, if someone needs this, i can look into the code again.

Thank you very much for your imput, Ragaril.
There was one line of code missing... no idea how this happend... Buttons should work now.
Too bad that there are problems with gamepads, if this is really 'cuz of GLB please let Kitty know about that. Can you please test if there are problems, if there is more than one joystick/gamepad in use?

----------------------------------


Updated code in first post; bugfix and new feature:
For one "key" you can now set two controls. Sometimes players like to switch between two setups.
You need two calls to define both [SET(1) and SET(2)] but both will get checked with one call of DOWN(). Look at code/comments for details.