RiB - Reflect it Baby

[dizzy]

Angestachelt von diesem hier hab ich mich auch mal dran gemacht.
Ziel des ganzen: Reflektion/Refraktion auch an Bezier-Splines, und additives Zeichenen um den Eindruck von Licht zu verstärken. Herausgekommen ist:

RiB
Reflect it Baby

Ein kompletter Szenen-Editor der derzeit folgende Objekte kennt:

• Bezier-Spline-Segmente
• Kreise
• Emitter

Es sollen noch folgen:

• Linien
• Rechtecke
• Polygone

Ein paar Hinweise zur Bedienung:
Ein selektiertes Objekt kann mit gedrückter linker Maustaste verschoben werden. Kontrollpunkte werden nicht verschoben. Das wiederum geht nur mit zusätzlich gedrückter Ctrl-Taste (dann wird der Cursor über Kontrollpunkten auch zur Hand).
Mit gedrückter Alt-Taste werden Objekte subpixelweise (1/4 Pixel) verschoben, zum Feintuning . (Lässt sich aber nicht mit Ctrl verbinden!)
Beim Emitter-Objekt ist's etwas ander: Verschieben bleibt gleich, auch das feine Verschieben, aber der Emitter lässt sich mit zusätzlich zur linken Maustaste gedrückter Ctrl-Taste drehen, und mit Shift lässt sich der Öffnungswinkel einstellen.

Nochmal in übersichtlich...

Code:

[b]Alle Objekte[/b]
[lMaus] + Ziehen          : Verschieben
[lMaus] + [Alt] + Ziehen  : fein Verschieben

[b]Emitter-Objekte[/b]
[lMaus] + [Ctrl] + Ziehen : Drehen
[lMaus] + [Shift] + Ziehen: Öffnungswinkel

[b]Andere Objekte[/b]
[lMaus] + [Ctrl] + Ziehen : Zugriff auf Kontrollpunkte

Beim Bewegen der Maus über die Szene wird das Objekt, das mit einem Klick ausgewählt würde, markiert. Wenn man darunterliegende Objekte erreichen möchte, kann man mit Rechtsklicks durch alle an dieser Stelle liegenden Objekte durchschalten. Sobald das richtige markiert ist, wird es durch Linksklick selektiert.


Das Teil rechnet bei jeder Änderung der Szene alle Strahlen neu durch! Von daher sollte man sowohl mit der Strahltiefe, als auch mit der Anzahl der Strahlen aufpassen . (Leider zählt z.Zt. das bloße selektieren noch als Änderung der Szene, und löst somit ein Neuberechnen aus. Das wird noch gefixt.)

Bekannte Bugs:

• Die Schnittpunktberechnung der Splines hat noch Schwierigkeiten mit absolut horizontalen/vertikalen Strahlen. Das hängt mit dem zu lösenden Gleichungssystem zusammen, und wird noch überarbeitet. Da der Fall aber recht selten auftritt, hat das nicht oberste Priorität.
• Ganz selten kam es bei mir noch zu Divisionen durch Null. Deren Ursprung konnte ich noch nicht abschließend ausfindig machen, bin aber dran

Im Archiv sind Source + EXE. Viel Spaß beim Kaputttesten
Ach ja! Die Graphics32-Lib wird zum Kompilieren natürlich benötigt


Gruss,
Fabian

[NicNacMan]

jo, ich meinte jetzt eher, dass man sie garnicht erst aus m bild schieben kann.
das mit dem cursor muss ich überlesen haben, sry.

[dizzy]

Zitat von NicNacMan:

- wenn man bei den splines die roten kästen verschiebt,
sollten sich imho die grünen kreise gleich mit verschieben.

Jupp, das hab ich schon länger vor gehabt zu ändern. Ist aber eine Kleinigkeit, die ich jetzt schon öfter wieder vergessen hab .
Muss ganz klar noch rein!

Zitat von NicNacMan:

- bei einer hoffentlich noch folgenden als-bild-exportier-funktion wäre es schön,
wenn man die kreuze bei den emittern ausblenden könnte, damit man n schöneres wallpaper hat.^^

Eine wirklich gute Idee! Ich denke ich werde wohl ein paar Optionen einbauen, so dass man auf Wunsch z.B. die Objekte ausblenden kann, so dass nur noch die Strahlen sichtbar sind. Ja ich denke so wird es werden...

Zitat von NicNacMan:

- man kann die objekte außerhalb des bildschirms (wenn man das so nennen kann^^) verschieben
und bekommt sie dann nicht mehr zurück.

Ist ja halb geklärt: Nach Resize sind sie weg. Aber der Weisheit letzter Schluss ists so natürlich noch nicht. Ich kann mich nur noch nicht ganz entscheiden zwischen "kein Verschieben über'n Rand" und "bei (ganz) Verschieben übern Rand löschen".
Auch das könnte man ja wählbar machen... Mann das wird eine Propertyschlacht ^^

Zitat von NicNacMan:

- die bekannten probleme bei horizontalen linien...

Leidig, aber wichtig...

Zitat von NicNacMan:

- das mit dem "Cursor wird zur Hand" funktioniert bei mir auch nicht so richtig,
manchmal wird er zur hand, bleibt es aber dann auch.

Ich würde ja gerne die Hand wieder haben... Da muss ich aber erst nochmal schauen wie ich das am wenigsten CPU-hungrig hin bekomme, da man ja OnMouseMove eine Kollisionsprüfung ALLER Knoten ALLER Objekte machen muss. Kommt Zeit, kommt Hand

Zitat von NicNacMan:

hoffe ich bin nicht zu pingelig für ne prealpha version *g*

Nana! Das ist ja genau der Richtige Zeitpunkt für sowas! Dicken Dank dafür!

Zitat von NicNacMan:

naja, aber das prog is einfach nur "top" , hab heute echt mehrere stunden damit rumgespielt!

*freu*


Die Weiterentwicklung wird in den kommenden 3 Wochen u.U. etwas stocken, da ich 6 Klausuren vor der Nase hab, aber grad bei so viel schöner Resonanz macht das Proggen gleich noch mal so viel Spaß!


Ich geh erstmal in's Bett... wird ja schon wieder hell ^^
Fabian

[Khabarakh]

Vier Tage Skiurlaub beendet... und hier geht die Post ab .
Was soll ich zu deinem Programm sagen, perfekt ! Sieht auf den ersten Blick wie eine Mischung aus der GR32 GradLines-Demo und deinem Gravitationssimulator aus .

[EDIT] Das im Anhang sieht allerdings etwas komisch aus? Bzw. welche Art von Refraktion hast du eingebaut?

[dizzy]

Ja das ist evtl. noch nicht 100%ig. Im grunde hat man ständig Übergänge der Art: Medium1 -> Medium2, egal von wo aus. Nie Medium2 -> Medium 1. Da muss ich noch denken... ^^

[Khabarakh]

Das wars dann wohl mit der Umkehrbarkeit des Lichtweges . Hab mal auch in den Code geschaut, Hilfe, Vektoren . Die konnte ich bei meinem Programm zum Glück vermeiden . Nett fande ich, dass meine Prozedur auch haargenau ReCalc heißt.

[Dax]

Wie schon öfters gesagt, finde ich das Programm auch genial
Hab' mich jetzt auch mal dran gemacht.. (wie unser MicroKuchen )
Ergebnis: Durch konsequenten Einsatz von handgemachtem Assemblercode () ist RiB schon fast 5% schneller, bei manchen Funktionen hab' ich 10% bekommen, aber da geht noch mehr

So, genug geredet, ich hacke weiter an dizzy's Code rum

[dizzy]

Zitat von Dax:

Durch konsequenten Einsatz von handgemachtem Assemblercode

Das hab ich bisher ganz bewusst vermieden . Da das Dingen ja noch in der Entwicklung ist, wollte ich zunächst mal bei DL bleiben. Optimierung dann später. Aber ich wäre da nicht unwesentlich an deinen "Fummeleien" interessiert .
Ich hab aber auch schon wieder weitreichende Änderungen im Kopf. Wobei man die ganzen Funktionen zur Vektorrechnung sicherlich recht gefahrlos jetzt schon assemblieren kann...
(btw: Die Bildschn aus deiner PM sind )

Cheeriot,
Fabian

[Dax]

Danke für das Kompliment, die Bilder warn auch eine Fummelei ^^ (/me schenkt dizzy eine Rose zum Valentinstag *g*)

PS: Sobald alle Optimierungen fertisch sind, poste ichs mal. Zur Zeit ist es nur FPU-Code, später kommt noch SSE, falls damit schneller wird (Die VOrtho-Funktion konnte ich mit FPU-pur um 75% verschnellern..)

[jfheins]

Ich möchte diesen Thread nochmal aus der Versenkung hervorhohlen, weil das Prog mich jetzt wirklich interessiert

- Wird es noch entwickelt ?

- Kann man auch gerade Linien machen ?

- Das refrakting ist irgendwi nicht ... ganz richtig ... bei einer Linie wird das Licht gebrochen, wie bei einer Sammellinse, und manchmal wird es auch komplett ... fehlgeleitet

Kommt da noch was ?

[dizzy]

Zitat von jfheins:

- Wird es noch entwickelt ?

Es gibt keine neuere Version, nein. Ich hab das Teil nunmehr unter die Kategorie "Spielerei als Basis für größeres" abgestellt. Die Theorie mit Splines und Licht etc. war eine recht aufschlussreiche Sache für mein Fernziel. Da ich aber derzeit sehr viel beruflich Programmiere, leidet der private Codespieltrieb merklich

Zitat von jfheins:

- Kann man auch gerade Linien machen ?

Theoretisch klar, aber implementiert ist's nicht. Der Fall kam mir damals zu trivial vor, so dass ich direkt an die Splines ging, und Strecken nachbasteln wollte. Naja - so weit kam's dann nicht ^^

Zitat von jfheins:

- Das refrakting ist irgendwi nicht ... ganz richtig ... bei einer Linie wird das Licht gebrochen, wie bei einer Sammellinse, und manchmal wird es auch komplett ... fehlgeleitet

Da kommt das Problem ins Spiel, dass eine Linie aus Sicht des Programmes 1D ist, also nur einen Übergang in ein anderes Medium darstellt. In der Realität haben aber auch Linien (Scheiben z.B.) ein Volumen, so dass 2 Übergänge passieren, die sich im Normalfall nahezu aufheben (bzw. der Effekt kaum sichtbar ist, da die Übergänge sehr nah aneinander liegen). Das ist in der Tat eine Designschwäche. (Der Kreis z.B. verhält sich wie eine komplett aus einem Material bestehende Kugel ohne Hohlraum - aus eben o.g. Grund.)

Zitat von jfheins:

Kommt da noch was ?

In dieser Form wie hier vermutlich nicht. Wenn du aber irgendwo spezifische Fragen hast, dann versuch ich mich gern wieder da rein zu denken =)


Schönen Gruß,
Fabian