viewing pipeline lösungsvorschlage

[RECeiver]

hallo, hat sich schon jemand das 3te bsp überlegt? ich hab mir die kapitel im buch angeschaut, aber ich check überhaupt ned was wir da alles machen sollen, bzw. wie wir das dann programmieren sollen.
[RECeiver]

[bimbo]

meine funktionierende Version vom CG1Object gibts auf meiner homepage, im download bereich.

BITTE NICHT ABSCHREIBEN, SONDERN NUR ALS DENKANSATZ VERWENDEN!!!

http://bimbo.at.tf (bimbo.at.tf)

[bimbo]

auf bitte von herrn wimemr hab ich die lösung wieder vom server genommen. sorry aber des bsp is net besonders heay, das kann ich sagen

[RECeiver]

nur sollt der hr. wimmer nächstes mal eine verständlichere Angabe schreiben, so dass man sich a bissl besser auskennt. ich hab echt ned gwusst, was genau verlangt wird. und nur auf das buch zu verweisen is a bissl schwach.
[RECeiver]

[RECeiver]

braucht man eigentlich die 3*3 matrizen für das bsp.
4*4 ist doch viel sinnvoller oder?
[RECeiver]

[gck]

ich habs zwar schon fertig, aber auch keine 3x3 Matrizen verwendet, ich wüsste nicht, wofür...

meine Fragen im Moment sind aber noch:

1) was ist in diesem normalTable[] (nur die Sphere fügt da was ein...)

2) wie genau funkt die Viewing -> Device Coordinates Transformation...

[bimbo]

die 3x3 matrizen hab ich auch nicht verwendet, geht anscheinend auch ohne die.

im normalTable[] müssten die normalvektoren für die polygone gespiechert sein, die brauch man für die sichtbarkeitsberechnung, und das schattieren der objekte.

nach der transformation in weltkoordinaten müssten adie x/y koordinaten aller punkte im bereich -1/+1 , die z z eigentlich auch aber das müssen wir (noch) nicht machen. bei der umwandlung in device koordinaten wird jetzt dieses intervall so "aufgeblasen" dass es von [0,canvas.getWidth()] geht, das kann man so machen:

X = Width/2 + X *Width/2;

analog für die Y werte.

aber jetzt eine frage:

1.bei mir wird bei den rotationen auch immer um die achse skaliert, um die ich rotiere. hat da wer eine ahnung???

2. sind die berechnungen (bei mir) net ganz ok.
z.b.: wenn ihc ein objekt um 90° nach rechts um die Z-achse rotiere und anschließend wieder zurück um -90°, dann ist das ganze leicht parallel verschoben. wo kann da der fehler liegen?

[wjsus]

@ bimbo:

ich versteh nicht ganz, wieso man die x bzw. y koordinaten bei der umwandlung nach weltkoordinaten in dieses intervall transformieren soll, dachte, diese umwandlung ins weltkoordinatensystem hat den zweck, verschiedene objekte aus verschiedenen systemen in einem globalen system, eben den weltkoordinaten darzustellen. da man eh immer nur ein objekt hat, wär das ja meines erachtens überflüssig, habs auch so gemacht und die punkte aus dem vertexTable direkt übernommen, was auch komischerweise funzt.... vielleicht kannst du das mal kurz erläutern, von wegen x,y transformation nach [-1,1] intervall....

danke

[Uebungsleitung]

Bezüglich 3x3 und 4x4-Matrizen:

Was kann man mit einer 4x4-Matrix transformieren, was mit einer 3x3-Matrix?

Bezüglich "schlechter" Angabe:

Ich bin jederzeit für konstruktive Kritik offen. Dieses Beispiel ist jedoch, wie in der Angabe erwähnt, (durchaus absichtlich) etwas komplexer. Das Ziel ist die selbständige Erarbeitung und Umsetzung des Themas Viewing-Pipeline, wozu man wirklich das Buch etwas genauer studieren muß. Wäre die Angabe wesentlich genauer, würde das Beispiel wahrscheinlich in Trivialität verfallen, was dann niemandem etwas bringen würde.

Ich habe mich durchaus bemüht, die Unklarheiten, die letztes Jahr aufgetreten sind, in der Angabe auszuräumen, es kann aber natürlich sein, daß das nicht überall gelungen ist...

Michael Wimmer
CG1LU Übungsleitung

[bimbo]

@ bimbo:

ich versteh nicht ganz, wieso man die x bzw. y koordinaten bei der umwandlung nach weltkoordinaten in dieses intervall transformieren soll, dachte, diese umwandlung ins weltkoordinatensystem hat den zweck, verschiedene objekte aus verschiedenen systemen in einem globalen system, eben den weltkoordinaten darzustellen. da man eh immer nur ein objekt hat, wär das ja meines erachtens überflüssig, habs auch so gemacht und die punkte aus dem vertexTable direkt übernommen, was auch komischerweise funzt.... vielleicht kannst du das mal kurz erläutern, von wegen x,y transformation nach [-1,1] intervall....

danke


ich hab mich vertippt: also: nach der umwandlung von WELT in PROJEKTIONSKOORDINATEN liegen die Koordinaten allerpunkte im intervall von[-1;+1] (zumindest ist das bei mir so) diese muss man dann in device-koordinaten umwandeln, und dazu braucht man natürlich die dimanesion des anzeigefensters.

ad WELTKOORDINATEN:

das stimmt natülich, was du schreibst, in diesem fall is es egal, weil 1.nur 1objekt angezeigt werden muss, und 2. die objekte "schön" gegeben sind.

[gck]

Wenn ich die Normalen aus dem NormalTable erst für das Shading brauche, muss ich da dann auch schon jetzt transformieren?

Wenn ja, was sind diese Normalen genau i.e. wo stehen sie drauf, und wie berechne ich sie, wenn sie nicht im ATOFF File gespeichert sind...

@bimbo:
wieso müssen nach der Projektion die Koord. im Bereich von -1,1 liegen? Aus der Formel auf Seite 444 ff. im Buch geht das (meines Erachtens) nicht hervor...

Bei mir läuft die Device Koord. Umrechnung im Moment so:

1) ich definier ein Window auf meiner Viewplane mit xv, yv Länge, Breite

2) ich dividier alle x, y Koordinaten durch die Länge/Breite des Window (jetzt liegen alle auf dem Viewport sichtbaren in (-1,1))

3) ich multiplizier sie jetzt mit der Länge/Breite des Canvas i.e. meinem Viewport und hab jetzt die Koordinaten auf dem Viewport: das View-Window kann dabei auch größer oder kleiner als der Viewport sein, allerdings müssen die Proportionen ident sein (werden ggfs. programm-intern errechnet)...

So hab ich das verstanden, aber in der CG1 Newsgroup heißt es, das wär nicht richtig oder so...

kann mir das wer vielleicht noch ein bisserl eindringlicher erklären? tnx

[bimbo]

zuerst ein anliegen meinerseits:


ICH HAB DAS BEISPIEL NICHT OHNE GRUND VOM SERVER GENOMMEN! WENN JEMAND FRAGEN HAT BITTE ICH DEN/DIE DIESE IM FORUM ZU POSTEN, UND NICHT MICH MIT MAILS WIE" ICH KANN NICHT GUT PROGRAMMIEREN SCHICKST DU MIR DEINE LÖSUNG ZU BELÄSTIGEN.
DAS MAG VILLEICHT HAT KLINGEN ABER MEINE LÖSUNG AUCH NET GANZ KORREKT, GENAUGENOMMENHAT SIE ZIMELICH VIELE FEHLER AN DENEN ICH NOCH IMMER ARBEITE
DANKE FÜR EUER VERSTÄNDNIS





Wenn ich die Normalen aus dem NormalTable erst für das Shading brauche, muss ich da dann auch schon jetzt transformieren?

Wenn ja, was sind diese Normalen genau i.e. wo stehen sie drauf, und wie berechne ich sie, wenn sie nicht im ATOFF File gespeichert sind...


also: nach meinem wissenstand braucht man die normalen "nur" um zu schattieren, und den rendering algorithmus zu beschleunigen.

was sind die normalen und wozu brauch ich die:
jedes polygon ist eine ebene ( ich hab mind. 3 punkte, die spannen im raum eine ebene auf) und jede ebene hat einen normalvektor. (bild: buch seite 471, rechts unten), benötigt wird der normal-vektor, um die sichtbarkeits berechnung zu beschleunigen. angenommen wir haben einen würfel den wir rendern wollen, dann sind doch immer nur maximal 3 seiten sichtbar, und zwar die 3 bei denen der winkel zwischen normalvektor und blickvektor < 90° ist. die anderen kann man vom rendering-vorgang ausschließen.

wie man aus 3 punkten die eine ebene bilden den normalvektor berechnte müsste doch jeder können.

die koordinaten liegen deshalb zwischen -1 und +1 weil... das hab ich selber nichtmehr ganz heraussen, ich hab das aus einem anderen buch, nahc dem ich mein inf. spezialgebiet geschrieben hab, und da is des um einiges besser drinne als in dem, aber leider weis ich nimma wie das heißt.

[gck]

1) ja, mir auch bitte keine Mails mehr schicken, ob ich euch meine Lösung schicken kann, selber Grund wie oben, hehe

2) Hmm, könntest du vielleicht so nett sein, in dem Buch nochmal nachzuschauen, wie das genau mit dem -1,1 Intervall ist... oder die Seiten scannen und posten.. Ich will dich nicht stressen, aber ich hab schon viele Leute gefragt und niemand findet sich mit der Device Umrechnung wirklich zurecht...

@bei Rotation wird auch skaliert:
eigentlich keine Ahnung, warum das passieren kann, aber bist du sicher, dass die Matrix des Scaling auch tatsächlich nur *einmal* auf die Punkte angewandt wird, und nicht in jedem Durchgang mehrmals (hoff du verstehst, was ich meine)

@Parallelverschiebung:
hmm, könnte sein, dass es damit zusammenhängt, dass der Objektkoord. Mittelpunkt nicht immer genau in der Mitte der Objekte liegt (deshalb schauen manche Rotation schlecht aus, zb. Teapot).
Andererseits könnte es auch deshalb passieren, weil du ja in deiner Rotationsmatrix insgesamt dann zuerst eine Rotation um 90 nach rechts, dann um 90 nach links gespeichert hat, i.e. es könnten Rundungsfehler oder Ähnliches passieren... ist aber unwahrscheinlich, hehe

ANDERE FRAGEN:

1) Übungsleitung: meint ihr, wir sollen die 3x3 Matrizen für Rotation und Scaling, die 4x4 nur für Translation verwenden oder so? Ich sehe nämlich sonst keinen Grund, 3x3 Matrizen zu verwenden...

2) Wie transformiere ich dann die Normalen? Reicht es, die Normalvektoren mit den entsprechenden Matrizen zu multiplizieren, so wie die Vertices?

[bimbo]

ich werd mich bemühen, dass mit den device koordinaten noch verständlich zu machen, ich evrsprechs.

das mit der "skalierung" beid er rotation hab ihc schon, ich hab mein ganzes programm neu geschrieben, und jetzt den fehler nicht mehr.
trotzdem tänx( somit hat sich auch das problem mit der parallel verschiebung erübrigt.


@gck, wie hast du die rotation berechnet?
ich hab zuerst eine funktion geschrieben, die mir den mittelpunkt des jeweiligen objektes liefert, und dann zuerst das objekt in den ursprung verschoben, dann rotiert, und dann wieder zurück. trotzdem geht nur die rotation um Z, und ich weis net warum.


zu den 3x3 matrizen hab ich mir auch was überlegt (aber nicht genau in den code der matrizenrechnungen geschaut): vielleicht sind die drinnen für die transformation von 2D objekten(mit homogeneer coordinate)??? aber wie gesagt ios nur eine überlegung.

[Deep Thought]

Original geschrieben von bimbo
zu den 3x3 matrizen hab ich mir auch was überlegt (aber nicht genau in den code der matrizenrechnungen geschaut): vielleicht sind die drinnen für die transformation von 2D objekten(mit homogeneer coordinate)??? aber wie gesagt ios nur eine überlegung.
Dann schau mal in den Code, denn ich habe genauso wie du überlegt, aber die Methode RotateZ innerhalb Matrix3x3 ist eindeutig!
Ich glaube, dass wir Rotationen und Scalierungen mit der 3x3 Matrix machen sollen, sofern keine Translationen innerhalb der Gesamttransformation vorkommen. Allerdings frage ich mich wann das der Fall ist?

[12gauge]

Original geschrieben von bimbo
@gck, wie hast du die rotation berechnet?
ich hab zuerst eine funktion geschrieben, die mir den mittelpunkt des jeweiligen objektes liefert, und dann zuerst das objekt in den ursprung verschoben, dann rotiert, und dann wieder zurück. trotzdem geht nur die rotation um Z, und ich weis net warum.


Da ihn der Angabe steht, das der Mittelpunkt der Objekte im Ursprung liegt, hab ich mir gedacht, dass man einfach die Position dieses Mittelpunktes in einem 1-dimensionalen Array speichern kann - bei jeder Translation werden die Werte, um die verschoben wird zum Array addiert bzw. subtrahiert.
Bei der Rotation mache ich erstmal eine Translation in den Mittelpunkt (mittels der gespeicherten Koordinaten - einfach invertieren), dann Rotiere ich , zum schluss wird die Translation noch mal mit den Werten ausgeführt, um das Objekt an die ursprüngliche Stelle zu bekommen - funktioniert bei mir ohne Probleme

[gck]

einfachste Lösung:
Rotation und Scaling in Objektkoordinaten machen, d.h.
1) Punkte aus vertexTable in transformed kopieren
2) auf transformed die Rotations- und Scaling Matrizen anwenden
3) jetzt erst Weltkoordinanten und u.U. Kamerakoordinaten Transformationen machen
4) jetzt Translation (ist sinnvoller in Kamerakoordinaten, meiner Meinung nach, da der User ja in Kamerakoordinaten "denkt", was die Translation angeht zumindest
5) Projektion und device umrechnung machen

Vorteil: da wir laut Angabe davon ausgehen können (obwohls nicht stimmt, hehe), dass in den Objektkoords. der Ursprung in der Mitte des Objekts liegt, brauchen wir keinen Mittelpunkt für die Rotation/Scaling ausrechnen!

[bimbo]

@gck
Rotation und Scaling in Objektkoordinaten machen

hab ich mir zuerst auch gedacht, aber: da man ALLE transformationen mit einer matrix berechnen kann( wurde in der vorlesung gesagt, und ist auch tatsächlich so) is es vielleicht besser möglichst alle transformationen in eine matrix zu schreiben, da das vielleicht effizienter ist als das onjekt 2,3mal mit matrizen zu multipliziern, falsch is meiner meinung nach nicht es so wie du zu machen.

[gck]

ich glaub, was sie in der VO gemeint haben, war nicht, dass man nur eine Matrix verwendet, sondern dass man die Matrizen durch Multiplikation in eine Matrix umformen kann und dann nur diese eine Matrix auf die Punkte anwendet...

Bsp.

translate(x,y,z)
rotateX(0,5)

ergibt (wenn x != 0) was anderes als

rotateX(0.5)
translate(x,y,z)

Deshalb kann man nicht einfach nur eine Matrix verwenden, man kann aber alle eben zu einer "cat"en, indem man sie in der richtigen Reihenfolge miteinander multipliziert, also

Mgesamt = Mscale * Mrot * Mtrans

(Mscale und Mrot beeinflussen den Mittelpunkt nicht undk können vertauscht werden)

Mgesamt kann man dann auf die Punkte anwenden...

[Uebungsleitung]

Ein kleiner Tip: mit 3x3-Matrizen kann man Vektoren transformieren, z.B. auch "Normal"-Vektoren...

Michael Wimmer