Suche Infos zu Texture Mapping

Hi,

ich braechte das mal von der Pike auf beschrieben. Alles was Google ausspuckt bezieht sich auf OpenGL oder sonstige Fertigloesungen, die mir auf dem Arduino nichts nuetzen.

Hat jemand einen Link oder ein Einsteiger Tutorial oder C Code fuer mich?

Danke,

Helmuth

http://de.wikipedia.org/wiki/UV-Koordinaten

Ich hoffe, das hilft dir etwas, ich bin im 3D-Bereich auch "nur" Anwender, ich nutze sowas, programmiers aber nich selber.

Leider nein. Bei Wikipedia habe ich mir schon alles moegliche angesehen, was mit dem Thema auch nur entfernt zu tun hat. Leider ist da nichts konkretes dabei. Ich meine, ich erwarte ja keinen Superartikel inkl. Code wie z.B. der vorzuegliche zum Bresenham Algorithmus http://de.wikipedia.org/wiki/Bresenham-Algorithmus, aber ein bisschen handfester, als

Jeder Punkt des Polygonobjektes bekommt dabei eine eindeutige Texturposition.

sollte es schon sein. Soweit ist es mir bereits klar, aber WIE bekommt er sie?

Ich glaube, mir fehlt einfach nur der exakte Suchbegriff. Hat niemand eine Idee? 199x stand sowas in jeder Computerzeitschrift...

Gruesse

Helmuth

Wenn du texturieren willst, hast du ja ein Polygonobjekt. Wie wird dieses beschrieben (Sprachenunabhängig)? Genau: mittels der dreidimensionalen Vertex-Koordinaten.

Und genau diese werden fürs UV-Mapping auch benutzt. Mehr isses -im Prinzip*- nich... U und V beschreiben lediglich die Positionen von XYZ auf der Map.

  • teilweise werden die sich ergebenden Flächen noch weiter aufgeteilt, das Textur-Koordinaten-Netz kann also durchaus auch feiner sein aus das echte Vertex-Netz. Das wird gemacht, wenn man Texturen "verzerrt" auf eine einzige Fläche bekommen muss, ist schon ne erweiterte Methode.

Ne Anleitung dafür in C kann ich dir nicht geben, ich hab zwar öfter damit zu tun, (als Anwender), aber:

Nehmen wir an, du willst ein Dreieck mit ner UV-Map versehen. Da es sich im dreidimensionalen, virtuellen Raum befindet, ist jeder der drei Eckpunkte beschrieben:

Ayxz; Bxyz; Cxyz. Diese Punkte hast du (oder du hast gar nix). Nun erzeugst du Kopien der drei Punkte, und weist denen Positionen auf der Textur zu:

Axyz= U0,V0 -> UundV liegen auf dem Bild, sind also praktisch die Pixelpositionen Bxyz= U20,V20 Cxyz= U50,V50

Damit ist fesgelegt, wie die Textur auf dem Dreieck sitzen soll. Nun brauchst du allerdings noch nen Renderer, der das alles verwurstet. Ab hier wirds schwieriger- eventuell wirst du da in der Pov-Ray-Ecke irgendwo fündig, würd mich nicht wundern, wenn du dort entsprechende Algorithmen findest. Pov-Ray ist nen freier Renderer, der sich mittels simpler Textdateien steuern lässt. Obendrein so einigermassen (ist zugegebenermassen Jahre her, dass ich damit mal rumgespielt hab, ist mir einfach zu umständlich) gut dokumentiert. Wenn du allerdings bereits Objekte Anzeigen kannst (nich nur Drahtgitter, sondern echte Flächen) hast du ja bereits nen Renderer- dann kannst du das oben beschriebene recht einfach umsetzen. Du hast recht- früher wurd sowas ab und zu irgendwo beschrieben, aber heutzutage brauchts einfach kein Mensch mehr- Echtzeit-3D auf nem Atmel geht bestimmt, ist aber schon relativ sinnfrei. Ansonsten gibts nen paar freie Renderengines für diverse Geräte- vielleicht findest du da was quelloffenes zum abgucken?

Hi Rabenauge,

POVRAY kenne ich noch vom 386SX, hat viel Spass gemacht damals und war "state of the art".

Ich habe die Textur und ich habe das Dreieck und es geht mir ganz konkret um den Renderer. Es gibt ihn noch nicht. Den werde ich wohl selbst schreiben/adaptieren muessen. Auf logischer Ebene ist mir klar, was passieren muss - aber ich habe noch keine Idee, wie ich dass als Formel(n) ausdruecken kann. Vektorrechnung in der Schule und beim Studium ist bei mir sch eine Weile her. Frueher hat das doch jeder 14 jaehrige Demo Coder auf seinem C64, Amiga und Atari gemacht, selbst auf einem KC85/4 habe ich das mal gesehen - aber ich finde im Netz ums Verrecken kein Tutorial von damals... Heute interessiert das natuerlich keinen mehr, weil jedes Telefon sowas nebenbei in der GPU macht...

Auf AVR macht das wahrscheinlich wirklich keinen Sinn, aber ich bin ja jetzt auf einem 32 Bit ARM Cortex unterwegs und da geht im Vergleich zum ATMega wirklich einiges an Rechenpower. 8) Meine 32x32 Matrix ist unterwegs (immer noch, grrr) und ich finde da macht das dann durchaus Sinn fuer ansprechende Effekte, die weit ueber meine bisherigen Spielerein hinausgehen. Vorausgesetzt natuerlich, dass ich es hinbekomme...

Wenn irgendwer einen Link zum Code einer Low-End Render Engine hat, waere mir sehr geholfen.

Beste Gruesse

Helmuth

Raytracing auf nem C64? :fearful: Da muss dann aber jemand so richtig Zeit gehabt haben-wie lang hat da nen Bild gerendert-Monate? Ich hab einige 3D-Szenen (nix Povray, ich mach das mit Blender), wo nen heutiger Rechner (okok, ist auch nicht mehr der Jüngste) schonmal nen halben Tag an nem Einzelbild schwitzt... 8) Die Ergebnisse übertreffen allerdings dann auch alles, was ich von PovRay je gesehn hab...einfach weil man viel tiefer in diverse Trickkisten greifen kann. Das lernt man im 3D-Modelling-Bereich gleich als zweites: RECHENZEIT SPAREN. Auf Teufel-komm-raus. :roll_eyes:

Hab aber eben mal geschaut: die Quellen von PovRay sind offen, von daher kannst du dir da eventuell nen paar Sachen herausziehen. Auch die alten Versionen sind noch verfügbar....

Nachtrag: http://www.atmel.com/images/doc32100.pdf Gucks dir mal an, hab es nur schnell überflogen aber-klingt doch vielversprechend.

Nee, kein Raytracing. Sich drehende Wuerfel mit akzeptabel draufgemappten Bildern. Wenn nach Programmstart erstmal die Sinus Lookup Tabellen berechnet waren, ging es dann recht flott...

Ist das Dein Job - 3D Modelling?

Ich schau mir bei POVRAY mal an, ob ich den Code verstehe. Parallel dazu hat mir gerade jemand im FastLED Forum einen 2d mathematischen Ansatz erklaert, der sich sehr vielversprechend liest. Der verfolge ich auch weiter.

Alles morgen, wenn ich wieder wach und frisch bin.

Gruesse

Helmuth

Job-nein.

Für nen Appel und nen Ei mache ich das nicht-> und da im allgemeinen Mittelmass ausreicht, wills kaum jemand ersthaft bezahlen.
Entweder als kleine Gefälligkeit mal (nen Trinkgeld nehm ich da dann u.U.schon, klar), oder aus Spass an der Freude.
Da gibts dann auch schonmal so richtig heftige Sachen, ab Kinoqualität aufwärts-> wird aber seltener was fertig, an einigen Sachen sitz ich immer mal, über mehrere Jahre verteilt. Ist dann immer toll, ne ältere Szene mal mit dem nächsten Rechner zu rendern…:wink:

Ja, wirkliche Qualitaet wird selten nachgefragt und noch seltener auch bezahlt.

Und gut DIng will und muss Weile haben... ;)

Sowas macht man meistens, weil man einfach selber Bock darauf hat.

Hast Du irgendein Showreel von Dir online?

Nö-auch was, dass ich seit Jahren vor hab: mir endlich mal ne gescheite Webseite zulegen, bzw. die Olle zu renovieren. :wink:
Und meine Wekstatt wollt ich auch längst mal ordentlich einrichten…(die Dampfmaschine ist komplett geriggt, die kann ohne Probleme animiert werden).

Dann kann ich nämlich mal an meinem Mech weiterbauen. Der ist schon deutlich weiter, aber der rendert samt Werkhalle dann auch schon mal 20 Minuten inzwischen (grösstenteils Highpoly modelliert, und die Grundtexturen sind prozedural, da gibts bisschenwas zu rechnen). Die Beschriftungen auf dem sind übrigens per UV-Mapping aufgetragen, frag jetzt bitte nicht, wie gross die Map ist-riesig…das Ding taugt ohne weiteres auch für Nahaufnahmen.