View Full Version : [Frage] bsp5: screenshots
hi,
ich hab einmal ein paar screenshots von den geshadeten und mit Sichtbarkeitskontrolle gezeichneten Objekten gemacht:
An den zwei Bildern vom Teapot kann man gut erkennen, warum ich in einem vorherigen Post mehrmals darauf hingewiesen habe, dass Backface Culling beim "bodenlosen" Teapot nicht gut ausschaut, aber laut CG1 Newsgroup sollen wir dennoch mit dem Culling arbeiten....
schaut bei mir genau gleich aus, ih hab aber dass problöem, dass z.b.: bei der kugel der obere teil einfach abgeflacht ist. weis aber net recht was der fehler is, hast du sowas auch ghabt?
www.bimbo.at.tf/bilder/sphere.jpg (http://www.bimbo.at.tf/bilder/sphere.jpg)
jup, kann dir helfen: du nimmst wahrscheinlich als "Aufhängepunkt" (also den Punkt, auf dem du die Intensität misst) für die Vektoren den ersten Vertex des Polygons -> bei den "Polen" der Sphere ist dieser erste Vertex aber genau der Punkt, an dem alle Polygone des Poles "zusammenhängen", also dort, wo die Kugelachse durchgeht -> alle Polygone kriegen die gleiche Farbe...
Lösung: Nimm fürs Belichtungsmodell lieber einen Punkt auf dem Polygon, nicht einen Vertex: ich nehm im Moment den Schwerpunkt, der Mittelpunkt des Polys wäre ideal, ich weiß aber dafür leider keine Formel...
Formel für Schwerpunkt eines Dreickes:
1/3*(a+b+c)
wobei a,b,c die Punkte des Dreicks im Raum oder auf der Ebene sind.
Jedes Polygon ist zumindest ein Dreieck, also kannst du "blind" mit den ersten drei Punkten den Schwerpunkt dieses Dreiecks ausrechnen: Hauptsache, der Punkt fürs Belichten ist nicht ein Vertex...
--------------
Btw, wo hast du denn deine Lichtquelle platziert: mir gefällt der Einfallswinkel des Lichts bei dir irgendwie besser als bei mir :)
Deep Thought
10-12-2002, 17:45
Ich hab' mir das dadurch leichter gemacht, dass mein Licht nicht von einem Punkt ausgeht, sondern aus einer Richtung, die der Blickrichtung entspricht. Als Intensitätsfaktor erhalte ich demnach den Z-Wert des normierten und transformierten Normalvektors.
Geht wunderbar... außer der Normalvektor zeigt in die falsche Richtung... daran arbeite ich noch... und: ja ich weiß dass es dafür schon einen Thread gibt!
Deep Thought
10-12-2002, 19:30
So schaut das bei mir aus.
Da ich es sinnlos finde, einen z-Buffer für ein Objekt zu machen hab' ich eine Unterstützung für mehrere Objekte eingebaut.
tschurlo
10-12-2002, 19:55
Hilfe!
Ich komme gerade bei den Mindestanforderungen bei diesem Bsp ueber die Runden und dann baut da wer an die Kugel noch ein paar Objekte an! :eek:
Wenn du einfach mehrere Objekte testen willst, dann kannst dir ja das System.atoff nochmal anschauen - ganz ohne Zusatzimplementierung, aber mit viel Geduld.
wer's noch nicht hat:
http://stud4.tuwien.ac.at/~e0125924/big_atoffs.zip
Bin allerdings noch nicht mit meiner Beleuchtung zufrieden...
Original geschrieben von tschurlo
Hilfe!
Ich komme gerade bei den Mindestanforderungen bei diesem Bsp ueber die Runden und dann baut da wer an die Kugel noch ein paar Objekte an! :eek:
naja, du kannst ja einfach mehrere Instanzen von CG1Object verwenden, dann brauchst du in CG1mainFrame noch ein paar kleinere Änderungen, und das ist es im Großen und Ganzen schon, denke ich mal...
schaut aber lustig aus, vielleicht bau ich das später auch noch mal ein, hehe
Deep Thought
10-12-2002, 22:48
Ist wirklich nicht schwer, das schwerste war der zusätzliche "Add" Button ;)
Ich hab' eine Liste aus Objekten gemacht somit zeichnet jedes Objekt das nächste in der Liste. Bei neuen Objekten übergebe ich die alte Liste als Parameter. Sehr simpel!
Andere Frage:
System schaut ja schön aus, aber die Normalvektoren stimmen bei mir nicht, also invertiere ich sie...
wunderbar, aber jetzt stimmt Indy nicht mehr...
Ich stelle folgende Theorie auf...
es gibt 2 Typen von atoffs, deren Polygone jeweils in unterschiedlichem Drehsinn gespeichert sind.
Gruppe 1:
Sphere, System, Bee?
Gruppe 2:
Würfel, Indy, Teapot, F4, U-Boot
Wenn ich also das Programm auf eine Gruppe abstimme stimmt die andere nicht mehr.
Stimmt diese Theorie und wenn ja, was kann man dagegen tun?
danke!
@Deep Thought
ich habs genauso wie du. einfach den normierten normalvektor mit der originalfarbe multiplizieren, und man hat das flat shading.
tortzdem diesen fehler. wo kann die ursache liegen, ich find einfach nix, hab den deppaten code schon x-mal durchgschaut, und auf etwaige 1er statt 0er bei einem array untersucht, aber da find ich nix
@gck
Lösung: Nimm fürs Belichtungsmodell lieber einen Punkt auf dem Polygon, nicht einen Vertex: ich nehm im Moment den Schwerpunkt, der Mittelpunkt des Polys wäre ideal, ich weiß aber dafür leider keine Formel...
für den mittelpunkt eines polygons gibts auch keine formel, denk nur mal an ein dreieck, das hat, inkeirsmittelpunkt, umkreismittelpunkt, ... die alle "mittelpunkte" sind, aber net der gleiche punkt sind. am besten wär glaub ich inkreismittelpunkt, da der sicher innerhalb jedes polygons(dreiecks liegt), was für schwerpunkt, umkreismittelpunkt nicht gelten muss.
kommando zurück ich hab das problem gefunden!
durch den tip vom gck, mit dem ich zerst überhaupt nix angfangen hab, weil die ja die spere schon fürs phongshading gmacht haben, sind im "transNormals" die normalen pro polygon gespeichert, und ich hab die gnommen, daher haben die polys in den polen die gleiche schattierung, ich _depp_ ich
@deep thought: hmm, ich weiß nicht, deine Theorie scheint nicht ganz zu stimmen: ich hab jetzt meine FlatShadedPolygon klasse so erweitert, dass ich deine "simplifizierte" Flatshading Art durchführe, wenn dem Konstruktor "null" als punkt für die Lichtquelle übergeben wird.
-> es funktioniert mit den Normalvektoren aber alles prächtig, ich kann keine Darstellungsfehler in irgendeinem Atoff erkennen (außer dem "offenen" Teapot, aber des hamma ja schon geklärt)...
Kannst du vielleicht screenshots von den Darstellungsfehlern im Shading machen, die bei dir auftreten?
@ gck, du macht die da glaub ich bissal viel arbeit.
bei mir ist der einzige unterschied zwischen flatshading und scanlinefilled, der:
double ambient = .2;
double z = Math.abs(tn[2])*0.7;
red = (int)(ambient*col.getRed()+(1-ambient)*z*col.getRed());
green = ...
...
aus den red/green/blue werten wird eine neue farbe erzeugt, und das wars grob-gsagt schon.
hehe, ja, ich hab mir mehr arbeit gemacht, das war aber Absicht... wenn in der Angabe steht "simplifizierte Version" von irgendwas, packt das sofort meinen Ehrgeiz und ich muss unbedingt auch eine allgemeine Version erstellen...
das hat schon beim 1. Eprog Beispiel angefangen, als es heißt, ich muss 3 Gleichungen mit 3 Variablen lösen, da fühlte ich mich sofort veranlasst, stattdessen n Gleichungen mit n Variablen zu lösen...
In der "final" version von meinem FlatShading Programm werd ich aber auch das "simplifizierte" System abgeben, da ja auch die Lichtquelle im Blickpunkt verlangt war...
Deep Thought
11-12-2002, 18:20
@gck
na gut, ich werde dich überzeugen! :ausheck:
Lade den Würfel lass ihn um Y rotieren.
Lade die Kugel oder Erde und lass sie in die gleiche Richtung um Y rotieren.
Wetten wir, dass sie sich in die andere Richtung dreht!
Warum ist das so?:idea:
Weil du in einem Fall die Polygone der Rückseite siehst, die Vorderseite wird brav durch backface culling eliminiert der Rest wie immer geshaded. Unterschied sieht man praktisch nicht, obwohl er vorhanden sein müsste (Projektion).
Die Rückseite dreht sich klarerweise in die andere Richtung.
Und bitte sag' jetzt nicht, dass deine Kugel sich gleich, wie dein Würfel dreht!
Im Anhang das Problem dabei: der Würfel dürfte nicht sichtbar sein! Da aber die Rückseite der Kugel gezeichnet wird, sieht man auch den Würfel!
Deep Thought
11-12-2002, 18:56
Wie auch immer...
Ich hab jetzt einen neuen button "invert normals", der einmal auf Sphere angewandt den gewünschten Effekt erzielt.
Hi,
ich habe das gleiche Problem wie bimbo, bei mir wird die Sphere auch vorne abgeschnitten.
TODO 5: hier kann man mit einer einfachen Abfrage backface culling machen...
genauso einfach kann man jetzt auch flat shaden..
wie löst ihr die zwei, irgendwo habe ich den Wurn drinnen.
lg
@asterix.
schau dir mal den post #12 an, da steht der fehler.
backface-culling einfach, mit abfrage ob der z-wert vom normalvektor wegschaut vom betrachter, und flatshading, hab ich eigentlich auch schon erklärt wie man das einfach machen kann.
tschurlo
11-12-2002, 22:47
@ bimbo: double ambient = .2; ..... etc.
Okay, das habe ich verstanden, aber sonst muss man auszer der
Berechnung der Normalvektoren nichts mehr machen?
Wo flieszt denn da der Blickpunkt ein, bzw. der Punkt von dem die Intenstitaet berechnet wird?
wenn blickrichtung = lichtrichtung, dann is es das, und in der angabe steht ja , dass man das vereinfachte modell wählen kann. denn dann is der winkel zw normalvektor und blickrichtung uninteressant.
...Punkt von dem die Intenstitaet berechnet...
diese fragestellung hab ich in den bisherigen posts auch net verstanden. was meinst du damit? welcher Punkt?
ich weis soviel zum flatshading: die lichintensität wird für das GANZE polygon berechnet, e.g.: es is egal welchen punkt eines polygons du betrachtest, er hat immer die gleiche intensität. also reicht das.
@deep thought: ok, sorry, du hast recht, die Normalen sind bei der Sphere echt verkehrt rum... naja, vielleicht fällt mir noch was ein, wie man die richtige Orientierung für die Vertices findet, damit der Normalvektor immer in die richtige Richtung zeigt... also, wie findet man heraus, ob drei Vertices im Uhrzeigersinn liegen, das muss ma sich also überlegen...
2) Das mit dem Punkt ist folgendes: Wenn du allgemeines Flatshading machst, also mit einer Point-Light-Source, dann musst du den Vektor zwischen der Lichtquelle und einem Punkt auf dem Polygon ausrechnen, diesen Vektor normalisieren und mit der normalisierten Normale das Skalarprodukt bilden, dann kriegst du den cosinus des Winkels zwischen den beiden und damit den Faktor für die Intensität: aber je nachdem, WELCHEN punkt du auf dem Polygon gewählt hast, wird auch ein anderer Winkel zwischen dem "Lichtvektor" und dem Normalvektor entstehen und du kriegst eine andere Intensität für das gesamte Polygon: eigentlich hat ja jeder Punkt des Polygons eine ganz eigene Intensität (vgl. Phong Shading), beim Flatshading musst du dich für eine entscheiden und sie dem ganzen Polygon aufdrücken...
Da ich am Anfang in der Angabe überlesen habe, dass die Lichtquelle im Blickpunkt sein soll, wollte ich halt wissen, wo eine "gute" Position für die Lichtquelle ist und was eine guter Punkt auf dem Polygon zum Lichtvektor berechnen ist -> hat sich jetzt aber eh erledigt, da eh in der Angabe steht, dass das Licht aus Blickrichtung kommt...
@gck
Ich würd mal sagen, das zu berechnen würde ungefähr gleich lang dauern, wie wenn du auf das Back-Face Culling gleich verzichtest. Es ist unmöglich in 3D festzustellen, ob drei Punkt im oder gegen den Uhrzeigersinn angeordnet sind, nachdem man ja von beiden Seiten "draufschauen" kann...
Du müsstest dir die Normalen von einigen (oder allen?) Faces ausrechnen und dann überprüfen, ob sie sich mit den anderen Polygonen schneiden. Falls ja, schauen die Normalvektoren in die falsche Richtung.
Approximieren könntest du das bei unseren einfachen Objekten, indem du dir den Mittelpunkt des ganzen Objekts ausrechnest und alle Normalvektoren sollten davon wegzeigen.
Oder du machst dir einen eigenen Knopf [Normalvektoren umdrehen] oder eine einfache Abfrage
if filename.indexOf("sphere")>0 then NV=-NV; :)
tschurlo
12-12-2002, 10:07
@ gck: Aha, also wenn das Licht aus der Blickrichtung kommt, und meine Blickrichtung ist ja die entgegen der z-Achse, dann nehme ich als Punkt sowas wie Hausnummer (0,0,500), stimmt das jetzt?
Frage zu flatshading:
d.h. ihr rechnet jetzt nicht den cos aus, sondern nehmt Werte für
die Intensität?
@bimbo
double ambient = .2;
double z = Math.abs(tn[2])*0.7;
red = (int)(ambient*col.getRed()+(1-ambient)*z*col.getRed());
green = ...
...
aber ganz verstehe ich hier nicht was du da machst.
wiso (1-ambient)*z...)?
lg
so wie es jetzt da steht, mach das ambient folgendes:
20% der beleuchtung kommen vom umgebungslicht(ist nicht vom normalvektor abhängig) und 80% vom "normalen". musst aber nicht machen. einfacher gehts so:
red = z*col.getRed();
z hat den normierten z-wert vom normalvektor(zwischen 0 und 1), nur der is interessant für die beleuchtung. kannst dir ja anschauen, waie es ausschut, wennst nicht den z-wert nimmst
hat irgendwer das problem wenn er den teapot "richtig" dreht dass dann so eine art feher auftritt ?
ist das normal oder ist da ein fehler drin
Deep Thought
12-12-2002, 14:59
Original geschrieben von Filz
@gck
Du müsstest dir die Normalen von einigen (oder allen?) Faces ausrechnen und dann überprüfen, ob sie sich mit den anderen Polygonen schneiden. Falls ja, schauen die Normalvektoren in die falsche Richtung.
Approximieren könntest du das bei unseren einfachen Objekten, indem du dir den Mittelpunkt des ganzen Objekts ausrechnest und alle Normalvektoren sollten davon wegzeigen.
:)
Habe ich versucht...
mit dem Ergebnis, dass die Reifen (und anderes) bei Indy nicht funktionieren.
Da aber bei der Sphere die Normalen in den Punkten gegeben sind, kann ich sie als Referenz verwenden, damit müsste es gehen und wenn's die auch nicht gibt, hab' ich noch immer den Button...
@wolk: schätze du hast einen Vorzeichenfehler bei z-Buffer oder Backface culling
@wolk: nope, das ist ein Programmierfehler -> der einzige Fehler beim Teapot, für den wir nichts können, ist das Loch im Boden und im Schnabel..
@verkehrte Normalen:
ja, das mit dem "sind sie im Uhrzeigersinn" berechenen hab ich jetzt aufgegeben, habe aber eine andere Lösung gefunden:
das am nächsten zur Kamera befindliche Polygon ist auf jeden Fall sichtbar (bzw. der Normalvektor muss zumindest positives Z haben, theoretisch könnte ja ein anderes Objekt noch davor sein), d.h.:
man berechne das nächste Polygon zum Betrachter, z.b. indem man sich das Polygon ausrechnet, das vom durchschnittlichen Z-Wert pro Vertex am nächsten zur Kamera ist.
dann berechne man auf dieses Polygon den Normalvektor: ist dess Z-Wert negativ, so müssen die Normalen im folgenden immer invertiert werden, ansonsten nicht...
diese funktion ruft man am besten direkt nach dem Laden des Objekts auf (wird also insgesamt nur einmal aufgerufen, nicht in jedem Durchgang der Viewing Pipeline) -> kaum mehr Aufwand, und jetzt klappts auch mit der Sphere...
wäre mal zumindest meine Idee dazu, vielleicht fällt noch wem was besseres ein!
EDIT: habs vergessen, dazuzuschreiben, aber große Z-Werte sind näher bei der Kamera... d.h. wir brauchen das Polygon mit maximalem durchschnittlichen Z pro Vertex, darauf den Normalvektor, etc..
@bimbo
Danke, jetzt habe ich es verstanden.
Nur eine Frage noch, sind die 20% von dir frei gewählt, oder steht das irgendwo im Buch?
lg
@atserix, die 20 sind frei gewählt.
@gck
ich würd sagen, es gibt keine verkehrten normal vektoren, das is reine modellierungssache, und wenn es so modelliert is, dass die polygone tw nicht in der richtigen richtung gemacht sind, dann is das nicht mein problem. ausserdem muss das polygon, dass am nähesten zum betrachter liegt nicht unbedingt sichtbar sein, stell dir vor du bist IN einer kugel, dann stimmen die normalvektoren, aber man sieht trotzdem nichts.
doch, das stimmt in unserem Programm schon immer, weil du ohnehin nicht "in" einer Kugel sein kannst, da wir kein Viewplaneclipping implementiert haben: sobald die Viewplane innerhalb der Kugel wäre (von den Koordinaten her), sehen wir die Vorderseite, die eigentlich hinter uns sein müsste, nur total verzerrt....
probiers einfach aus: (am besten multiplizierst du den Translationfaktor der Z-Achse nochmals mit 10 oder 20, damit es schnell geht): jetzt hol dir die Kugel immer näher an die Kamera heran, du wirst es aber nicht schaffen, "hineinzukommen"...
Es ist schon klar, dass das mit den Normalen Modellierungssache ist, aber wenn die schon so uneinheitlich gegeben sind und man das relativ leicht beheben kann, warum soll mans nicht einfach tun?
das, man nicht in die objekte hineinkommt, hab ich schon getestet. war auch nur ein beispiel. ich machs trotzdem nicht, da es 1. nicht teil der aufgabe ist, und 2. wer weis schon die die objekte "wirklich" ausschauen sollen, vielleicht is es bei manchen gedacht, dass man hineinschauen kann( is zwar blöd, aber wer weis)
@bimbo
double z = Math.abs(tn[2])*0.7;
warum mulitplizierst du hier mit 0,7?
lg
naja, selbst wenn man hineinschauen könnte, dann nimmt man halt nicht das Polygon mit dem größten durchschnittlichen Z-Wert, sondern eins, das den größten Z-Wert hat UND vor der Viewplane ist, dann passt es wieder...
Und ich kann mir nicht vorstellen, dass man von der Kugel nur den hinteren Teil sehen soll: die Normalvektoren pro Vertex, die im atoff stehen, zeigen ja auch nach außen und nicht nach innen...
Außerdem steht in der angabe schon, dass man die Normalvektoren selbst berechnen soll und das impliziert, dass sie auch in die richtige Richtung schauen müssen: bei der Kugel merkst du es halt nicht am ersten Blick, aber wenn du z.b. beim Teapot verkehrte Normalen verwenden würdest, dann gebe das sicher ordentlich Punkteabzüge (brauchst nur schauen, wie der dann nämlich aussieht)...
@ asterix
is ein abschreibfehler von mir, ändert aber nix wesentliches, die szene is halt nmma gnz so hell.
@gck
hast schon recht, ich wär aber net auf die idee gekommen, die normalvektoren, wenn sie schon gegeben sind trotzdem neu zu berechnen.
naja, du musst sie auch bei der Kugel selbst berechnen, denn im Atoff sind sie pro Vertex und nicht pro Polygon gegeben, und zwar deshalb, weil man bei einer Kugel sehr leicht die Normalen auf den Vertices berechnen kann, ohne dabei interpolieren zu müssen -> wird beim Gouraud- und Phong Shading in Runde 6 besser ausschauen...
Uebungsleitung
14-12-2002, 15:18
In der Angabe steht übrigens, "Sie können annehmen, daß sich die Lichtquelle im Blickpunkt befindet", nicht "Sie müssen annehmen"...
@gck
[QUOTE]naja, du musst sie auch bei der Kugel selbst berechnen, denn im Atoff sind sie pro Vertex und nicht pro Polygon gegeben, und zwar deshalb, weil man bei einer Kugel sehr leicht die Normalen auf den Vertices berechnen kann, ohne dabei interpolieren zu müssen -> wird beim Gouraud- und Phong Shading in Runde 6 besser ausschauen...
QUOTE]
ich hab bei der kugel ja auch die normalen pro polygon aus den normalen pro vertex berechnet, pastt das ncht so?
Achso, das kannst du dann natürlich auch machen! Kamma allerdings nicht wirklich sagen, was jetzt die besseren Ergebnisse liefert, also ob man die Normalen jetzt einfach mittels Kreuzprodukt oder Interpolation aus den Vertexnormalen berechnet, ich würd sagen, beides ist schon gleichwertig...
ich tät das an deiner Stelle auf jeden Fall jetzt so lassen!
und ich hab glaubt, du machst dir den ganzen aufwand, obwohlst as eh so berechnest wie ich!
@Uebungsleitung:
wie soll man das verstehen?In der Angabe steht übrigens, "Sie...
leobasil
14-12-2002, 21:23
bimbo was is da unverständlich dran ?
du kannst wenn du willst, musst aber nicht :)
naja, ich schätze mal, dass das so gemeint ist:
entweder
das man die "ganze Viewplane sendet zu ihrer Z-Achse parallele Lichtstrahlen aufs Objekt aus" - Methode vom Flatshading machen darf, so wie wir sie hier diskutieren (also einfach über den Z-Wert des normalisierten Normalvektors berechnen),
oder
ein "richtiges" Flatshading mit der Lichtquelle in einem beliebig setzbaren Punkt im Viewingkoordinatensystem machen kann, sofern man diesen Punkt so wählt, dass man dann auch was sehen kann (also das Objekt z.b. nicht von hinten bestrahlt wird...)
Der erste Fall ist ein "simplifiziertes" System, also muss man das im Abgabegespräch vermütlich auc begründen können und u.U. erklären, was bei allgemeinem FlatShading anders wäre...
so interpretier ich das...
vBulletin® v3.7.1, Copyright ©2000-2008, Jelsoft Enterprises Ltd.