Ich bin endlich mal dazu gekommen das Restless Fileformat auszuprobieren. Ich finde dieses Projekt sehr gut und bin Conan, MatReno und Lord Horazont sehr dankbar.
Leider gibt es bei mir Probleme den Loader unter Linux zu benutzen. Ich habe eine libRestless.so mit dem fpc kompiliert. Dazu musste ich ausser den Delphi-Mode zu aktivieren noch die Zeile auskommentieren. Zudem bekam ich folgende Warnung:
Laut Nachforschungen sollte man das -fPIC bzw. -Cg Flag verwenden. Die Warnung blieb jedoch auch dann weiterhin bestehen. Ich bin mir jetzt nicht sicher ob sich die aktuelle Version des FPC ueberhaupt zum erstellen von shared libraries unter Linux eignet.

Da die libRestless.so aber zumindestens erstellt wurde, fuhr ich fort: Das daraufhin kompilierte erste Demoprogramm gab sofort beim Start eine "unhandled exception" von sich. Interessanterweise passiert das nicht, wenn ich statt dem Kran-Modell das Kaenguruh lade. Die Seerose funktioniert auch, nur gibt es da eine "unhandled exception", sobald man die Animation startet.
Ueberzeugt, dass die Fehler von einer fehlerhaften libRestless.so stammen, habe ich die Library in eine Unit umgemodelt und per uses in das Demoprogramm eingebunden. Leider verhaelt sich das kompilierte Ergebnis genauso wie die Variante mit der Library.
Hat jemand vielleicht einen Tipp, was ich tun koennte, um den Fehler weiter einzugrenzen?


So siehts aus, wenn der Kran geladen werden soll:

_________________
Flummi: Projektseite und Projektthread

Könnte es sein, dass das damit zusammenhängt? Ansonsten, ich habe die Lib unter Linux getestet, und fest einkompiliert gab es eigentlich keine Probleme. Da ich aber morgen für eine Woche zum DGL-Treffen fahre, wird das nichts mehr mit Debuggen.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

So, nun bin ich wieder da und MatReno hat freundlichweise Gedächtnisserweiterung gespielt und mich an diesen Thread erinnert. Hat sich da jetzt was ergeben? lag die DivZero an dem bekannten Problem in der dglOpenGL.pas oder liegt es definitiv an Restless?

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Hallo,

wie im Andorra 2D-Projektthread beschrieben, bin ich gerade dabei einen Loader für Restless zu schreiben. Dabei habe ich folgendes Problem mit dem Dateiformat:

Jede einzelne Animation wird ja in eine extra Datei ausgelagert. Mein Andorra 2D-Loader setzt allerdings voraus, dass das gesamte Mesh und alle dazugehörigen Animationen in einer Datei/Stream vorliegen. Nun könnte man ja einfach die *.rlsani Dateien an das Ende der *.rlsobj Datei kopieren. Das setzt allerdings voraus, dass es ein Tag wie "newanim [name]" gibt.

Also quasi folgende Struktur, wenn die Animation in der *.rlsobj Datei drin steht:



Ich werde das auf jeden Fall so in meinen Lader implementieren und es wäre schön, wenn ihr eure Spezifikation/Implementierung entsprechend anpassen könntet (wenn euch diese Erweiterung sinnvoll erscheint).

Außerdem habe ich vor, in meinen Lader das Mischen von Animationen einbauen, wie dies zum Beispiel in Cal3D geschieht. Mein momentaner Ansatz sieht vor die einzelnen Bone-Animationen gewichtet zu addieren. Hat jemand schon mal Erfahrungen damit gehabt? Funktioniert das so überhaupt?

_________________
http://audorra.sourceforge.net//http://andorra.sourceforge.net

Hey, klar kannste das FileFormat ändern und die rlsani an die rlsobj hängen.
Es war halt so gedacht, dass man mehreren objekten mit derselben bone struktur dieselben animationen zuweisen kann.
Alternativ kannste ja noch alles in ein selber definiertes Container format schreiben, falls dir das sinnvoll erscheint.

Ja, dasrüber haben wir auch nachgedacht, aber es ist in Restless momentan nicht möglich.

_________________
http://texelviews.delphigl.com

Hi,

also mir sind im laufe der Zeit mehrere Fragen aufgekommen, da ich Delphi Code kaum nachvollziehen kann hilft mir eure Implementierung auchnicht sonderlich weiter .

Folgendes:
1. Einem Material können 0-n Texturen zugewiesen werden, korrekt? Wenn ja wie werden die Textur Koordinaten der einzelnen Texturen angegeben? Oder sind diese grundsätzlich für jede Textur gleich?
2. Dieser block bereitet mir immer wieder Kopfschmerzen:



Dieser Block kann mehrfach vorkommen, mir ist allerdings nicht ganz klar wieso der Block dann so aufgebaut ist. Folgendes:

Scheinbar wird für jedes Objekt im Model dieser Block benutzt, soweit so logisch. Aber wieso stehen die Vertizes nicht einmal gesammelt für alle Objekte in dem File? Wieso stehen über jedem Objekt Block die Vertizes für ebendieses?

So wie es jetzt ist könnte man meinen das jedes Objekt seine eigenen Vertizes hat, aber so muss es ja garnicht sein, da die Vertizes nicht für jedes Objekt neu indiziert werden, sondern einfach fortlaufend nummeriert sind.

Beispiel (ist):



Es gäbe meiner Meinung nach 2 Sinnvolle Lösungen um diese Logischen inkonsistenz aufzulösen:

1. Vertizes einmal gesammelt für alle Objekte aufzählen: Sinnvoll da doppelte Vertizes vermieden werden können.
Beispiel:


2. Vertizes weiterhin für jedes einzelne Objekt aufzählen, dann allerdings unter dem Eintrag "o ..." damit die Zugehörigkeit sichtbar wird und die Indizes für jedes Objekt wieder bei 0 beginnen lassen.
Beispiel:



Bei den UV Koordinaten bin ich mir nicht sicher wie das da läuft, wenn es intuitiv wäre würden die für jedes Objekt wieder bei 0 beginnen, da diese unter dem "o ..." Eintrag stehen.
Ist aus den Beispielen jedoch nicht nachzuvollziehen, da es kein Model mit mehreren Objekten und Texturen gibt.

Mein Vorschlag auch hier: UV Koordinaten einmal in einem Block definieren und bei den Objekten nurnoch die Faces mit Vertex- und Texturkoordinaten-ids definieren.



Allerdings kann es natürlich auch sein, dass ich einfach nur Unsinn schreib, für den Fall hätte ich gerne Erklärungen wieso der Block so aufgebaut ist wie er aufgebaut ist .

Grüße,
Skeptiker

Ich kann mir gut vorstellen, dass das einfach Bequemlichkeit ist. So ist es doch ziehmlich einfach zu laden: Die Vertices sind garantiert in der Datei vorhanden (also schon darüber, vor der Referenz), sobald auf sie in einem Face referenziert wird. Und es kann dennoch platz gespart werden, indem doppelte nicht vorkommen (?).

Zu den UV-Koordinaten kann ich dir jetzt nichts sagen ...

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Es wäre aber doch beispielsweise deutlich leichter, wenn alle Vertizes einmal am Anfang der Datei stehen, und darunter nurnoch die Objekte mit der Referenz auf die Vertizes, und nicht für jedes Objekt ein eigener Vertex Block, auf den dann doch wieder alle Objekte zugreifen können.



s.o. so wie es da beschrieben ist sind die Vertizes auch auf jedenfall vorhanden, sogar schön Zentral an einer Stelle, und nicht so wie jetzt quer durch die Datei verteilt .

Klar funktioniert es so wies jetzt ist, aber logisch ist es irgendwie nicht, alles ist verteilt durch das Objektfile verstreut, was spräche gegen den Aufbau:



Dieser Aufbau würde das laden sogar noch weiter vereinfachen, da ich nicht immer zwischen den verschiedenen States wechseln muss: Mal Vertizes, mal Objekte, Mal UV, mal Faces, ... sondern immer alles schön am Stück hätte.

Mhm, auf der Loaderseite ist das so richtig. Aber beim Schreiben ist es ein deutlich größerer Aufwand, da man erst alle Vertices schreiben, dann wieder alle Objekte durchgehen für die UV-Koordinaten und dann nochmal alle Objekte durchgehen müsste für all die anderen Informationen.

Da denke ich, dass der eher weniger aufwendige Statewechsel [eigentlich ist es keiner, da jede Zeile für sich betrachtet werden kann, sieht man von der Zugehörigkeit von Faces und Materials zu einem Objekt ab, und die wechselt nicht dauernd] keine Zumutung ist... Allerdings würde ich langsam auch gerne mal eine Meinung von den eigentlichen Entwicklern dieses Formats lesen ...

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Hallo, also erstmal: ich (wir) leben noch. Jedoch ist privates programmieren leider aus Zeitgründen stark vernachlässigt worden. Daher auch meine lange Abwesenheit im Forum hier. Hab's nur zufällig entdeckt.

Also, wenn es noch interessiert, kann ich gerne schreiben, was wir uns dabei gedacht haben, wenn ich mich noch richtig erinnere...

Das ist tatsächlich der Hauptgrund gewesen. Es war auch im python Exporter wesentlich einfacher.
Da es absehbarer Zeit Blender 2.6 geben wird, und sich bei der Python-Blender Schnittstelle einiges ändert, muss sowieso "demnächst" ein neuer Exporter geschrieben werden.

Ich darf nochmal daran erinnern, dass Restless für uns ein Pilot-Projekt gewesen ist. Das heisst, wir haben durch Restless hauptsächlich gelernt Animationen zu implementieren. Daher ist auch das FileFormat nicht besonders ausgeklügelt. Aber es besteht die Möglichkeit UV Koordinaten pro Objekt zu minimieren, d.h. doppelte Koordinaten zu entfernen.

Natürlich wäre es auch denkbar gewesen, dass alle Vertices untereinander stehen und ebenso alle UV Koordinaten.
Damit müsste der Loader auch klar kommen, denke ich, jedoch ist es im Exporter mehr Arbeit.
Aber wie gesagt, ein Neuschreiben des Exporters ist wohl die einzige Möglichkeit um mit der neuen Blender version mitzuhalten. Dann kann man diese Trivialität mit erledigen.

Ich hoffe, dieser Beitrag ist noch von Relevanz für Skeptiker.

_________________
http://texelviews.delphigl.com

Hi,
Wunderbar zu hören, dass es einen Exporter für Blender 2.6 geben wird . Ich fände es natürlich super, wenn am Dateiformat ein wenig nachgebessert wird, ihr habt euch ja mit der Versionsnummer im Header alle Freiheiten der Welt gelassen, ich hab selbst schon darüber nachgedacht ein wenig rumzubasteln, aber Python ist mir nicht ganz geheuer, und in Blender kenn ich mich auchnicht wirklich aus , deswegen hab ich meinen Loader erstmal soweit implementiert, dass er mit dem jetzigen Format klarkommt, dass Laden könnte man durch optimieren der Filespezifikationen zwar noch deutlich beschleunigen (Ich Prüfe bei jedem Face ob die zugehörigen Vertizes schon existieren, wenn nein wird ein neues Vertex angelegt und mit einem Index versehen, wenn ja wird der index des bereits vorhandenen Vertex genutzt). So habe ich mit Sicherheit mein VBO maximal minimiert. Bei dem "kang.rlsobj" Model sieht das bei mir dann so aus: "Vertices: 3546, Indices: 21264".

Ich wäre außerdem Froh wenn die Frage mit den Texturen noch beantwortet werden würde:
"1. Einem Material können 0-n Texturen zugewiesen werden, korrekt? Wenn ja wie werden die Textur Koordinaten der einzelnen Texturen angegeben? Oder sind diese grundsätzlich für jede Textur gleich?"

Viele Grüße,
Skeptiker

Soweit ich das richtig sehe, kann man einem Material mehrere Texturen zuweisen, so wie sie in Blender definiert sind. Das geht also. Nachteil: die Texturkoordinaten sind die von der ersten Textur. D.h. Alle Texturen haben die gleichen Texturkoordinaten, was ja für viele Fälle auch ausreicht (Colormap, Bumpmap, Specularmap).
Aber mit dem neuen Exporter werde ich das berücksichtigen, und es wird zu Änderungen an der FileSpec kommen.
Restless anschließend wieder upzudaten wird ne qual.

_________________
http://texelviews.delphigl.com

Hier brauch wohl jemand euren Support: Link

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Gibt es eigentlich noch eine Möglichkeit an den Restless Quellcode heranzukommen? Die Links hier im Forum sind tot und auf meinem Rechner finde ich leider nichts mehr.

_________________
Flummi: Projektseite und Projektthread

Hab ne alte Version rumliegen. Werde die hier nicht hochladen, aber auf anfrage per PM mit Mailadresse gerne.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb