UV-Koordinaten nachträglich ändern

Started by Lobby, December 28, 2013, 05:58:57 PM

Previous topic - Next topic

Lobby

Guten Tag,

erst einmal ein Dankeschön für diese tolle 3D-Engine, macht richtig Spaß damit ein bisschen auf Android zu programmieren.

Nun zu meinem Anliegen:
Ist es möglich, im Mesh eines Object3D-Objekts nachträglich an den UV-Koordinaten herumzupfuschen? IVertexController scheinen sich ja leider nur zum Ändern von Koordinaten und Normalen zu eignen.
Dabei stellt sich mir generell die Frage, warum z.B. Primitives.getBox() einen gedrehten Würfel ausspuckt, der soweit ich das gesehen habe noch keine sinnvollen UV-Koordinaten besitzt.

Noch etwas ganz anderes, und zwar bin ich es von anderen Engines bisher eher gewöhnt gewesen, dass alles was sich im dreidimensionalen Raum befinden kann, sich was die Positionierung/Drehung/Skalierung und Eltern-/Kindzuordnung betrifft gleich ansprechen lässt, bzw. eine gemeinsame Oberklasse besitzen. Dies scheint in jPCT leider nicht der Fall zu sein, und ich frage mich warum nicht. Insbesondere für die Positionierung von Kamera und Licht ist das Prinzip der gemeinsamen Oberklasse sehr praktisch, so lässt sich beispielsweise die Kamera einem Charakter als Kind zuordnen und schon folgt diese ihm automatisch. Vor allem die Ansteuerung der Kamera unterscheidet sich stark von der von Object3D, ohne, dass sich gleiches Verhalten nicht irgendwie simulieren ließe.
Was ich mir auch mehr Wünschen würde wären Methoden wie getAbsolutePosition() mit denen man die Position in der Welt unter Berücksichtigung der Eltern bekommen kann. Das Leben ist kein Wunschkonzert, ich weiß, aber es ist auch eher als Vorschlag gedacht (wo ich schon dabei sind, sowas wie setAbsolutePosition() und setScale mit separaten Skalierungswerten für x, y und z wären auch nett).

EgonOlsen

Ja, kann man. Das geht mit dem PolygonManager, den man von jedem Object3D holen kann. Es müssen aber einige Voraussetzungen erfüllt sein, damit das klappt:


  • strip() darf nicht auf dem Object3D ausgeführt worden sein.
  • statt build() muss build(false) verwendet werden.
  • Nach den Änderungen sollte Object3D.touch() ausgerufen werden.

Generell sollte man versuchen, diese Änderungen nicht ständig zu machen, weil sie relativ stark auf die Performance gehen. Wenn möglich, sollten uv-Änderungen über eine Texture-Matrix (Object3D.setTextureMatrix(<Matrix>)) erledigt werden.

Die Primitives-Klasse war nie dafür gedacht, mit den generierten Objekten wirklich zu arbeiten. Das sind mehr oder weniger Platzhalterobjekte und die werden all als Drehkörper erzeugt. Diese Erzeugung startet immer in der xy-Ebene und deswegen ist der Würfel gedreht. Hätte man auch anders machen können, war mir an dieser Stelle war scheinbar egal... ;)

Ja, eine gemeinsame Oberklasse wäre manchmal vermutlich praktisch. Ich wollte damals nicht zuviele Scenegraph-Elemente einfließen lassen, weil ich das Konzept dahinter zwar für naheliegend, aber letztendlich für zu umständlich und verkopft halte. Ich wollte die Entitäten lieber getrennt betrachten und wer sie verknüpfen will, der kann das eigentlich mit ein paar Codezeilen auch selber tun und zwar dann so, wie er/sie es gerne hätte. Letztendlich erbt jPCT-AE vieles von jPCT und dort ist so manches "historisch gewachsen"...

Lobby

#2
Du meinst wenn man den von getTextureUV(polyID, vertexNumber) zurückgegebenen SimpleVector modifiziert wird diese Änderung von build(0) berücksichtigt und angewendet? Das ist interessant, danke. Ich hatte ohnehin vor das nur in einer Vorverarbeitung durchführen zu lassen, passt also :) .

Ich denke die Primitiven können einem viel Arbeit abnehmen wenn sie schon ordentliche UV-Koordinaten haben (ordentlich ist sicherlich relativ aber bei einem Würfel denke ich doch noch recht eindeutig). Nachdem das erste 3ds-Modell das ich geladen habe prompt um 90° gedreht war bleibe ich vorerst auch bei dieser Meinung. Mal sehen, vielleicht schreibe ich auch mal ein paar Primitiven-Erzeuger :D .

Wie so oft: Am besten ist es, wenn man eine Funktionalität nicht nachträglich selbst hinzufrimeln muss. Object3D, Light und Camera sind sich (inzwischen?) doch schon ziemlich ähnlich, und die völlig andere Ansteuerung der Drehung und Positionierung von Camera bringt mich teilweise schon etwas aus dem Konzept.
Also: Würde mich freuen, wenn du die Engine diesbezüglich überdenken würdest. Sicherlich ist das aber kein Muss, denn einerseits kann ich mir vorstellen dass im Hintergrund damit sehr viel Arbeit verbunden wäre, und andererseits arbeite ich ja erst seit drei Tagen mit jPCT und kann mich sicherlich auch an ein anderes Konzept gewöhnen.

Nebenbei, mir ist aufgefallen, dass es in jPCT-AE in Config keine Attribute für die Anzahl der Prozessorkerne gibt. Wird das auf dem Smartphone automatisch geregelt oder beschränkt sich die Engine dort bei der Abarbeitung auf einen Thread?

So, jetzt aber erstmal wieder weiter durch die Dokus und Codes wühlen, macht richtig Spaß ;) .

EgonOlsen

Nein, das build(false) musst du nur einmal machen. Dadurch sagst du nur, dass sich die uv-Koordinaten ändern könnten. Also wenn du eine bessere Klasse zur Erzeugung von Primitives baust, dann ergänze ich das gerne. Ich kann halt eben auch nicht alles machen und dann muss ich Prioritäten setzen. Und auf der Primitives-Klasse habe ich keine.

Ja, du hast ja recht, was die gemeinsame Basisklasse angeht. Aber das hätte man vor vielen Jahren machen müssen. Jetzt werde ich das nicht mehr ändern.

Auf Android läuft das in einem Thread, deswegen keine Attribute dafür.