Forum > Texturing and 2D Art

[QUESTION] Textur Problem?

<< < (4/6) > >>

Magnus:
Ja, das hab ich hier mal so gelesen, bei ADT übergreifenden Objekten.

Aber hier habe ich eben relative kleine Objekte gesehen, eben wie Bäume, die definitiv nicht zellübergreifend waren. Sie waren auch nicht mehrfach gespeichert, sondern einfach nur in der 'falschen' Zelle.

In der Praxis hab ich auch noch nicht wirklich Probleme gesehen wenn übergreifende kleine Objekte (m2 Modelle) nur 1x gespeichert werden. Das soll ja was mit der Sichtbarkeit zu tun haben.

wmo Modelle hab ich nicht getestet, grössere schon gar nicht.


Die ganzen Tests haben auch noch einen kleinen Hintergrund. Auf unserem Server können Spieler selber Welten in Spielerzonen bauen, indem sie sie serverseitig spawnen. Irgendwann hat das natürlich technisch seine Grenzen und ich dachte, ich nehme die Koordinaten der Objekte aus der Serverdatenbank, rechne aus in welche ADT sie gehören und manipuliere mit meinen selbstgebastelten Programm die ADT. Kopiere also die Objekte vom Server schlussendlich in einen Patch.

Dabei bin ich auf 2 Hindernisse gestossen:
- Ich hätte Probleme zu berechnen ob ein Objekt zellübergreifend ist.
- Und ich hab noch nicht so durchschaut, wie die guids der Objekte berechnet werden. Die sollen ja unique pro Map sein. Geht vielleicht noch relativ einfach bei einer reinen custom Map. Ist die Spielerzone aber z.B. in den östlichen Königreichen, müsste ich ja erst alle ADTs der Map einlesen.

schlumpf:
Dafür gibt es in M2s VertexBox und BoundingBox (bitte das maximum der beiden nehmen), und in WMOs (C3Vector  bounding_box[2];)  Informationen dafür. Die Boxen abhängig der rotation drehen und auf die Position drauf addieren. Alle ADTs die in der Box liegen müssen es bekommen.

Wenn du die ADTs von irgendwo anders bekommst, musst du alle einmal einlesen. Wenn du die einzige Person bist, die die ADTs veränderst, hilft eine Datei in der die derzeit höchste unique ID steht. Am besten in einem repository, damit man Konflikte erkennt.

Wenn Objekte auf falschen ADTs sind, und nicht auf der richtigen, resultiert das in undefiniertem Verhalten. Wenn es auf beiden ist, ist es okay.

Magnus:
Das mit den Bounding Boxen hätte ich auch so gesehehen, würde dann in meine Falle heissen, ich müsste noch mehr programmieren um die Modell Files auch noch in ihre Bestandteile zu zerlegen. (ADT klappt ja jetzt)

Das mit der Guid hätte ich auch selber drauf kommen können, es reicht einmal die höchste zu haben ^^ Eher ein Problem mit den guids wird es dann werden, wenn ich z.B. mit Noggit und meinem eigenen Kram unabhängig drauf zugreife.

Wenn ich das also alles so überlege, ist es wohl besser ich schau mir die Source vom 1.2 an. Da müssten ja alle benötigten Funktionen für mein Vorhaben drin sind. Letztendlich ist es möglicherweise einfacher dort Anpassungen zu machen, als viele Teile nochmals selber zu schreiben.

Vielleicht kann man daraus sogar noch einen sonstigen Mehrwert draus ziehen  ;)

Is'n Hobby für den nächsten Winter  :D

Magnus:
Hmm, der Link zur Source vom 1.2 scheint aber gut versteckt zu sein. Ich hab ihn nicht gefunden  :(

Nur der vom 1.3

schlumpf:
Dafür gibt es die history.. https://bitbucket.org/berndloerwald/noggit3/commits/all

Wann genau "1.2" war, kann ich dir aber nicht sagen. Das ist der Grund, wieso ich von vorneherein gegen diese dummen Versionsnummern war. Die haben nie jemandem geholfen. Davor hatten wir die genaue Revision im Namen. Vielleicht ist es einfach die erste Version auf dem sdl branch. Ansonsten gibt es irgendwo ein STRPRODUCTVER oder so, in dem die "version" drin steht. Kann auch sein, dass das mittlerweile hardcoded ist.. Ich habe mittlerweile aufgegeben, da durchzublicken. Es ist einfach nur noch ein riesiges Chaos mit verschiedenen Branches und Versionen die komplett zufällig von verschiedenen Menschen erzeugt wurden. Vielleicht frag am besten einfach die Person, die die "1.2" version gemacht hat, welche Revision es war.

Navigation

[0] Message Index

[#] Next page

[*] Previous page