Hi,

ich hab noch nen kleines problem mit meinen Schattenberechnungen, btw nicht direkt nen problem... das dauert einfach unendlich lange bei ner komplexen Scene..

Deswegen dachte ich mir, das ich ja erstmal jede Linie mit jedem Triangle als AABB testen kann ob sie sich überhaupt überschneiden können, und erst dann wirklich genau teste ob eine überschneidung vorliegt... sollte ja wesentlich schneller werden dadurch

Nur, da ich nochnie etwas mit AABBs gemacht habe, hab ich leider auchnet so viel ahnung von

Deswegen... kann mir wer verraten wie ich ne AABB um ne Linie bekomme???

Zwar könnte ich PunktA von der Linie als linke obere ecke der AABB und PunktB als untere rechte benutzen.. aber dann wär es nur ne BB, keine AABB *g*

Au'revoir,
Aya~

Das geht so ähnlich wie du geschrieben hast.
aabb wäre die AABB mit den 2 Punkten min und max
Punkt1 und Punkt2 sind die Endpunkte der Linien.



Aber ich denke es würde viel mehr bringen, wenn du zuerst den Octree/BSPtree/AABBTree oder was du für die Szene für eine Baumstruktur verwendest, aufbaust und dann auch für die Beschleunigung der Lichtberechnung verwendest.

Schon.. aber ich möchte nicht jedes mal erst nen Octree berechnen müßen, da der ja auch ne halbe ewigkeit braucht *g*

Ich bin grad dabei in meinem Lightmapper auch ne Optimierung einzubauen um die Sache mit den Schatten zu beschleunigen und hab folgendes vor :

Meine Szene ist in Meshes unterteilt (halt ganz genau wie in 3DS/im ASE-Format) und ich erstell mir von diesen Meshes ne AABB (auch zum Cullen), und jetzt hab ich vor, erstmal zu prüfen ob ein Lichtstrahl bei der Schattenberechnung überhaupt diese AABB schneidet, und das ist mathematisch nicht aufwendig.Wenn er dies nicht tut, dann muss ich auch gar nicht auf eine etwaige Kollision zwischen dem Strahl un den Polygonen des Meshes testen.
Das ist recht einfach zu implementieren und dürfte auf jeden Fall ne Menge an Geschwindigkeit bei der Schattenberechnung bringen.

Edit : Was soll das hier : http://www.gamedev.net/community/forums ... _id=173698 ?Traust du uns die Antwort auf deine Frage nicht zu?

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi,

ich hab dieselbe frage vor langer Zeit hier bereits schoneinmal gestellt.
(Sogar mehrmals, hab des öffteren mal gefragt ob jemand ne gute schnelle Methode hat ob ne Line/Triangle Intersection da ist hat)

Ich poste des öffteren in dem Forum dinge die ich hier genauso frage.. hat nix damit zu tun das ich euch nix zutraue, im gegenteil... sondern dient einfach dazu das ich mehrere antworten bekomme
und evtl hat da mal einer ne blitzidee die hier niemand hat und umgekehrt..

Au'revoir,
Aya~

OK...ich hatte schon fast das Gefühl du würdest an der Kompetenz des Forums zweifeln und war schon fast dabei ne Vodoo-Puppe zu basteln

Nichtsdestotrotz dürfte die Sache mit den Boundingboxes die einzige brauchbare Methode sein um die Schattenberechnung zu beschleunigen, und die Routine zur Ray-Triangle-Intersektion an sich bietet wohl kaum viel Optimierungsspielraum, mal davon abgesehen das man die Vektorberechnungen durch 3DNow!-Beschleunigte Routinen ersetzen könnten.Dazu hab ich mir auch mal die entsprechende 3DNow!-Matheunit runtergeladen und bin jetzt am Überlegen ob ich das machen soll, sprich ob sich der Aufwand überhaupt lohnt...

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Mh.. ja, das mit den BBs bau ich grad ein bei mir...

Ich werd's aber so machen, das ich sofern der Octree bereits berechnet ist den noch zur unterstützung benutze..

Wenn mir nochnen geistesblitz kommt, sag ich bescheid *g*

Au'revoir,
Aya~

Wie wäre es eigentlich mit den Occlusion Queries um zu prüfen, ob ein Punkt sichtbar ist? Wenn man die Geometrie von der Lichtquelle aus rendert ist das ja auch eine Art Sichtlinienberechnung. Das dürfte eigentlich eine enorme Geschwindigkeitssteigerung geben.

Soweit ich mich erinnere geht das auf meiner GraKa nicht
(GeForce2 GTS2/Pro)

Rein theoretisch würde das gehen, aber da Aya ja nur ne GeForce2 hat fällt diese Möglichkeit total flach, da die ja die GL_NV_OCCLUSION_QUERY-Extension nicht unterstützt.
Ausserdem bin ich mir realtiv sicher, das es kaum was bringen würde für jeden Lichtstrahl die Szene aus der Sicht des Lichtes zu zeichnen, was man ja rein theoretisch bei einem Punktlicht machen müsste.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Man muß es ja nicht für jeden Lichtstrahl machen, sondern man muß nur alle Richtungen abdecken, so daß alle Flächen die Chance haben einmal sichtbar zu sein. Zusätzlich könnte man dann auch testen wieviel von der Teilfläche die dem Pixel auf der Lightmap entspricht sichtbar ist. Wenn man z.B. 6 mal in alle Richtungen rendert mit einer Linse von 1 und einem Seitenverhältnis von 90°, dann sollte das gehen. Eventuell könnte man auch eine andere Linse benutzen, um dadurch mehr Flächen abdecken zu können.

Auf einer GF2 bringt das vermutlich nicht so viel. Die Frage ist nur was langsamer ist, den Schnittpunkt zu testen oder mit dem Software Renderer einen Pixel mehrmals zu zeichnen und natürlich auch auf den Tiefenbuffer zuzugreifen.

Ich weiß ja nun nicht, wie aktuell dieser Thread noch ist und ich habe von der MAtherie auch kaum Ahnung, baer ist eine AABB um eine Linie nicht leicht wiedersinnig? Eine BB könnte ich ja noch verstehen, aber eine AABB soll doch so sein, dass sie Quasie ein Objekt komplett umschließt und (weil halt AA) optimal gekippt ist, oder? Demnach wäre doch eine AABB für eine Linie dasselbe wie die Linie selber!!??!! Ein kasten halt, welcher am einen ende anfängt, am anderen Aufhört und eine Optimale Breite (1 Pixel) hat, womit wir genau wieder die Linie rausbekämen... oder irre ich mich nun?

_________________
Es sind immer die guten,
welche zu früh von uns gehen müssen...
Meine bislang 13 Open Gl - Tuts findet ihr auf www.dcw-group.net
Neu! Ein großer Teil der Demos nach Kylix übersetzt!

Ja, rein theoretisch hast du recht, und eine AABB einer Linie ist prinzipiell die Linie selbst.Weshlb man deshalb sowas verwenden sollte ist mir auch schleierhaft, allerdings hat sich das Problem AFAIK bereits auf andere Weise gelöst.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hi,

mh.. kleine verständniss frage

AABB = Axis Aligned Bounding Box
OOBB = Object Orientated Bounding Box

oder??

Sprich, eine AABB ist immer den Weltkoordinaten nach ausgerichtet, eine OOBB ist so gedreht und gewendet das sie den Objekt rotationen entspricht.... also wäre eine OOBB bei einer Linie das was ihr eben angesprochen habt, eine AABB wäre aber ein würfel in welchem sich die Linie befindet und welcher weder gedreht noch sonstwas ist...

oder irre ich mich da jetzt?? *guckt unsicher*

Au'revoir,
Aya~

Ja, ne OOBB (Object Oriented Bounding Box) ist eine Boundingbox die quasi mit dem Objekt mitrotiert, während ne AABB (Axis Aligned Bounding Box) eine von der Objektrotation unabhängige Boundingbox ist die ihre Größe mit der Rotation des Objekts verändert...die Begriffe kann man schonmal in der Hitze des Gefechts durcheinander bringen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)