Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zum Artikel "HSR: Hidden Surface Removal"
Leonidas
2002-11-14, 23:12:16
Hier isser. (http://www.3dcenter.org/artikel/2002/11-14_a.php)
AlfredENeumann
2002-11-15, 00:00:03
netter Artikel. Hätte mir im ersten Teil ein wenig beispielgrafik gewünscht.
Unregistered
2002-11-15, 00:45:51
"Mit steigender Polygonzahl wird dieses Verfahren sehr ineffektiv, für kleine und einfache Körper wird es in Verbindung mit Backface Culling aber noch heute eingesetzt, zum Beispiel bei Java-Software-Renderen."
Bei Renderen fehlt ein "r"....
Exxtreme
2002-11-15, 00:59:14
Seite 2:
"Die Radeon 8500 kombiniert übrigens den vorgezogenen Z-Test mit HyperZ, was eine sehr effektive Lösung darstellt."
Sicher? AFAIK kann das nur die R9700. Die R8500 hatte AFAIK nur ein leicht verbessertes HyperZ1 implementiert. Erst die R9700 hat zusätzliche Z-Occ-Units.
Leonidas
2002-11-15, 01:00:20
Originally posted by Unregistered
"Mit steigender Polygonzahl wird dieses Verfahren sehr ineffektiv, für kleine und einfache Körper wird es in Verbindung mit Backface Culling aber noch heute eingesetzt, zum Beispiel bei Java-Software-Renderen."
Bei Renderen fehlt ein "r"....
Gefixt. Thx.
Quasar
2002-11-15, 01:04:21
Originally posted by Exxtreme
Seite 2:
"Die Radeon 8500 kombiniert übrigens den vorgezogenen Z-Test mit HyperZ, was eine sehr effektive Lösung darstellt."
Sicher? AFAIK kann das nur die R9700. Die R8500 hatte AFAIK nur ein leicht verbessertes HyperZ1 implementiert. Erst die R9700 hat zusätzliche Z-Occ-Units.
AFAIK kommt das schon so hin, wie's im Artikel steht, mehr noch, IMO culled der R200 sogar noch vor dem Blending, was GeForce's nicht können.
edit:
Wo ich sehe, dass du grad am korrigieren bist, Leo:
Am besten wäre es natürlich, ohnehin nicht sichtbare Objekte gar nicht erst zu Rendern. Eine oft eingesetzte Methode verwendet dafür "Portale". Steht man in einem fensterlosen Raum mit geschlossenen Türen, müssen die anderen Räume gar nicht erst gerendert werden.
Das letzte Wort im ersten Satz ist ein Tu-Wort (hiess bei uns inner Grundschule noch so) und wird demzufolge kleingeschrieben...
edit2:
Ach ja, ich vergass: Wie immer, sehr guter Artikel, aths. Technisch, soweit ich das beurteilen kann, sehr gut und auch für einfache Geister wie mich leicht verständlich.
Ich vermisse nur etwas den Wortwitz, bis auf die "guten" und die (leider fehlenden) "bösen" Engines war da wenig.... ;)
Leonidas
2002-11-15, 03:04:01
Originally posted by Quasar
Das letzte Wort im ersten Satz ist ein Tu-Wort (hiess bei uns inner Grundschule noch so) und wird demzufolge kleingeschrieben...[/i]
Gefixt. Thx.
Voodoo3Killer
2002-11-15, 19:05:31
Schöner Artikel!
Vorallem die Beispiele auf der vorletzten Seite fand ich sehr anschaulich, wohingegen das Bild auf der letzten Seite für mich unverständlich ist (ich les es noch mal genau durch).
Ein kleiner Fehler, den ich noch gefunden habe (Seite 3):
"Dann wurde das Bild aus der Tiefe heraus bis in den Vordergrund aufgebaut, wobei neue Dreiecke (die also weiter vorne stehen) die alten (die im Hintergrund stehen) einfach übermalten haben."
"Übermalt haben" oder "übermalten" - bitte für eines entscheiden! ;)
Zur Seite 2:
Die Kyro-Chips waren doch von ST oder? Also ich komm da auch jedesmal durcheinander. Auf meinem Kyro Chip steht jedenfalls groß ST drauf... ;)
StefanV
2002-11-15, 19:15:16
Originally posted by Voodoo3Killer
Zur Seite 2:
Die Kyro-Chips waren doch von ST oder? Also ich komm da auch jedesmal durcheinander. Auf meinem Kyro Chip steht jedenfalls groß ST drauf... ;)
Nein, das Design ist von PowerVR, ST Micro hat die nur 'fertiggemacht' und hat für die Produktion gesorgt.
Originally posted by Voodoo3Killer
Ein kleiner Fehler, den ich noch gefunden habe (Seite 3):Grrr, Leo, diese Sache stand auch in der Korrektur-Liste die ich dir gestern noch schickte.
Leonidas
2002-11-15, 20:10:08
Originally posted by Voodoo3Killer
"Dann wurde das Bild aus der Tiefe heraus bis in den Vordergrund aufgebaut, wobei neue Dreiecke (die also weiter vorne stehen) die alten (die im Hintergrund stehen) einfach übermalten haben."
"Übermalt haben" oder "übermalten" - bitte für eines entscheiden! ;)
Gefixt. Thx.
Leonidas
2002-11-15, 20:10:38
Originally posted by aths
Grrr, Leo, diese Sache stand auch in der Korrektur-Liste die ich dir gestern noch schickte.
Tja, schlicht übersehen.
Originally posted by Quasar
AFAIK kommt das schon so hin, wie's im Artikel steht, mehr noch, IMO culled der R200 sogar noch vor dem Blending, was GeForce's nicht können.
Wie, was, vor dem Blending? Early-Z sorgt dafür dass der entsprechende Pixel gar nicht erst in die Pipeline kommt, sprich keine Texturzugriffe, keine Framebufferzugriffe, keine Z-Writes.
Unreal Soldier
2002-11-16, 11:22:47
Obwohl ich vom Artikel nach dreimal durchlesen wirklich nicht alles kapiert hab denk ich dass es ein guter Artikel ist. ImHO werde es wieder lesen um alles zu kapieren, denn solches Wissen über HSR ist goldwert.
Wie immer hat uns Aths wieder mit seiner hervorrragenden Arbeit fasziniert.
MfG
Unreal soldier
Piffan
2002-11-16, 17:31:01
Interessanter Artikel, habe auch fast alles kapiert. Nur was mich nervt ist der Einsatz des Wortes "Kachel" und der Satz, dass der z- Buffer gekachelt wird.... Also so ganz verstehe ich das nicht, imho kann ich doch wohl nur ein Bild oder ne Fläche kacheln....
Also wie ich es verstehe: Es werden die jeweil größten und kleinsten Z- Werte einer Kachel des Hauptbildes(Bildschirms) gespeichert, und diese Werte bleiben im Cache des Chips. So wird also erst eine Grobprüfung ohne Griff zum z- Buffer möglich, nur wenn diese schnelle Prüfung unentschieden ist, wird der Griff zum den exakten z- Buffer erforderlich.....
Wenn ich also richtig liege, dann sind die Radeons "Tiler", aber als Immediat- Renderer? Wobei sich die Dinge ja nicht ausschließen müssen.
Da fällt mir ein kleiner Fehler im Text auf: Imm e diat muß es heißen, nicht imm i diat...
Irgendwie wurde es auch mal Zeit für nen neuen Artikel :D
Laboryeti
2002-11-16, 18:02:12
Die im Artikel beschriebene Methode, per LZW o.ä. zu komprimieren, finde ich bedenklich. Will man etwa 64 Z-Werte derartig auf 25% komprimieren, müßte die Kachel schon fast parallel zum Bildschirm liegen, damit das Ziel erreicht wird (sprich: nur die untersten 5-6 Bits dürften variieren).
Ich hab eine andere Idee, wie die Kompression des Z-Buffers funktionieren könnte. Diese bedient sich der arithmetischen Abhängigkeit benachbarter Werte (hat nichts mit der patentierten arithmetischer Entropie-Kodierung zu tun):
Der Z-Buffer-Wert (also 1/Entfernung) ist linear abhängig von den Bildschirmkoordinaten (wer schonmal einen Softwarerenderer geschrieben hat, müßte das mitgekriegt haben).
Also:
1/Entfernung = a + b * X + c * Y
X,Y sind die Bildschirmkoordinaten des aktuellen Pixels.
a, b, c sind abhängig vom Dreieck (genauer gesagt der Lage der Ebene, auf der das Dreieck liegt), dessen Pixel gerade gerendert werden.
Da der Z-Buffer nun mal eine begrenzte Genauigkeit hat, wird gerundet:
IZ = [Minimaldistanz/Entfernung * Maximaler-Z-Buffer-Wert]
Minimaldistanz ist auch als "front clipping plane" bekannt. Je weiter diese von der Kamera entfernt ist, desto mehr Genauigkeit hat man (weil die Rundung sich weniger stark bemerkbar macht), aber naturgemäß auch umso mehr Clippingfehler (da das was näher als Minimaldistanz an der Kamera dran ist nicht mehr gerendert wird.)
Maximaler-Z-Buffer-Wert ist bei 24-Bit-Z-Buffer 16777215.
Betrachten wir nun einige horizontal nebeneinanderliegende Pixel, die alle auf dem selben Dreieck liegen.
Der erste habe den Z-Buffer-Wert IZ0. Der zweite hat nun den Wert IZ1 = IZ0+D. Welchen Wert hat nun der dritte Pixel? Es gibt genau 3 Möglichkeiten: IZ2 = IZ1+D+0, IZ2 = IZ1+D-1, IZ2 = IZ1+D+1 (vorausgesetzt die Rundung arbeitet zuverlässig).
Für den vierten Pixel gibt's wiederum diese 3 Möglichkeiten: IZ3 = IZ2+D+0, IZ3 = IZ2+D-1, IZ3 = IZ2+D+1
Es läßt sich leicht beweisen, dass hier niemals sowohl +1 als auch -1 in einer Punkteserie auf einmal vorkommen können. Folglich kann man sofern -1 vorkommt einfach D um 1 vermindern, so dass aus -1 +0 wird und aus +0 +1 wird.
So kann man eine Pixelserie mit wenigen Bits speichern:
24 Bits für ZB0 (erster Pixel)
24 Bits für D (Differenzwert)
(evtl. 24 weitere Bits für einen weiteren Differenzwert, falls der zu komprimierende Block vertikal größer als 1 ist)
1 Korrektur-Bit für alle außer dem ersten Pixel (ob nun +0 oder +1)
Allerdings ist es -insbesondere bei modernen Spielen mit massenhaft kleinen Dreiecken- sehr wahrscheinlich, dass sich mehrere Dreiecke einen Block teilen und damit die Kompression ins Wasser fällt (es sei denn, die Dreiecke auf einer Ebene). Eine mögliche Lösung ist die Aufteilung des Blocks in 2 Bereiche, hier exemplarisch ein Block mit 16x1 Pixeln:
Es gibt 15 Möglichkeiten der Aufteilung. Falls keine Aufteilung erforderlich ist, wird in diesem Beispiel trotzdem aufgeteilt (z.B. einfach den letzten Pixel in einen eigenen Bereich stecken), um einen Sonderfall zu sparen.
Bei der Größe 16x1 und einem Kompressionsziel von 4:1 stehen 16*8=128 Bits zur Verfügung.
1 Bit als Flag, ob sich der Bereich komprimieren ließ
4 Bits für die Aufteilungsgrenze
2*24 Bits für den "ersten Pixel"
2*24-3 Bits für den Differenzwert (es läßt sich stets sparen, da große Werte zum "Umklappen" führen würden)
14*1 Korrekturbit
2*8 Bits für Stencil (ein Stencil-Wert für jeden Bereich; sinnvoll, falls Stencil-Buffer-Tricks wie Schatten oder Spiegelungen verwendet werden)
Macht genau 128 Bits.
Originally posted by Laboryeti
Die im Artikel beschriebene Methode, per LZW o.ä. zu komprimieren, finde ich bedenklich. Will man etwa 64 Z-Werte derartig auf 25% komprimieren, müßte die Kachel schon fast parallel zum Bildschirm liegen, damit das Ziel erreicht wird (sprich: nur die untersten 5-6 Bits dürften variieren).Wieso das? LWZ komprimiert sich wiederholende Bit-Folgen. Diese Folgen dürfen dabei unterschiedliche Längen aufweisen. Es ist also egal, wo Bits variieren dürfen.
Die LZW-Vermutung ist aber in der Tat falsch, das wird noch geändert werden.
Originally posted by Piffan
Wenn ich also richtig liege, dann sind die Radeons "Tiler", aber als Immediat- Renderer? Wobei sich die Dinge ja nicht ausschließen müssen.Der Übergang zwischen SGI-IR und Tiler sind fließen. Man könnte ja auch "Voll-Tiler" bauen, die nach wie vor IR sind.
Danke für den Hinweis auf den Schreibfehler.
Laboryeti
2002-11-16, 19:01:53
Originally posted by aths
Wieso das? LWZ komprimiert sich wiederholende Bit-Folgen. Diese Folgen dürfen dabei unterschiedliche Längen aufweisen. Es ist also egal, wo Bits variieren dürfen.
Es ist schon egal, wo Bits variieren dürfen... zu bedenken ist aber, dass die Angabe des Ortes (also wo was gleich ist bzw. variiert) zusätzlich Speicherplatz verschlingt.
Guter Artikel, aths. Schwerer Stoff wie immer excellent verständlich ausgeführt. Jeder, der ein bisschen Zeit in diesem Forum verbracht hat, sollte locker dahintersteigen. Wäre nur noch die Sache mit der LZW-Vermutung zu klären ...
@Leo
Da ist noch ein kleiner Tippfehler auf Seite 3 / 5.Absatz / 2. Zeile -> dort steht "Backfase Culling"
Originally posted by Laboryeti
Es ist schon egal, wo Bits variieren dürfen... zu bedenken ist aber, dass die Angabe des Ortes (also wo was gleich ist bzw. variiert) zusätzlich Speicherplatz verschlingt. Ich möchte nicht vorlaut erscheinen, aber kennst du die Prinzipien des LZW-Algorithmus' (der allerdings bei der Z-Compression nun nicht angewendet wird, wie der Artikel im Moment noch vermutet)?
Originally posted by Ikon
Da ist noch ein kleiner Tippfehler auf Seite 3 / 5.Absatz / 2. Zeile -> dort steht "Backfase Culling" Kommt in die nächst Korrektkur-Mail an Leo :)
Originally posted by Unregistered
Ich denke, es war eine bewusste Designentscheidung von NV, um bei 16Bit zusätzliche Reserven zu haben.
Das ganze ist bei den TNT Chips ja schon genauso und zu deren Zeit war 16Bit Performance noch wichtig. Mit "zusätzlichen" Reserven hat das wenig zu tun. Die Füllrate liegt bei 32 Bit klar unter den Möglichkeiten, die die Pipelines an und für sich bieten.
Habe die Sache zur GF2-Füllrate mal abgesplittet: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=40857
csjunkie
2002-11-17, 19:03:24
Haben die WickedGL Treiber für 3dfx Karten auch treiberseitiges HSR implementiert?
Schliesslich bringen diese im Vergleich zu den Standart-OPENGL-Treibern von 3dfx Performancesteigerungen von bis zu 100% und teilweise sogar noch mehr. :o
Gegenueber den letzten 3dfx OGL Treibern bringen die WickedGL praktisch kaum einen Performance-Vorteil.
Nein, SW-HSR ist AFAIK nicht in WickedGL drin.
Und da SW-HSR eh nicht vernuenftig funktionierte ist das auch gut so.
csjunkie
2002-11-18, 21:02:42
Also auf ner Vodoo 3000 habe ich schon Steigerungen von ~100% beobachten können.
Bei OPENGL Speilen sind WICKEDGLtreiber ein MUSS! =)
Bei voyager elite force konnte ich sogar Bildqualitätssteigerungen feststellen.
Zum Beispiel waren manche Powerups auf einmal transparent dargestellt.
Damals (ach das waren noch Zeiten) ham die WickedglTreiber geownt. ;) :D
Auf ner Vodoo 5 5500 sind die Leistungsvorteile nicht mehr so extrem. :)
Hier der Test ^^:
http://www.3dcenter.de/artikel/voodoo5-wickedgl/2.php
(bei unreal und UT merkwürdigerweise kein Vergleich mit glide... ??? )
Leonidas
2002-11-20, 02:26:26
Originally posted by Ikon
Da ist noch ein kleiner Tippfehler auf Seite 3 / 5.Absatz / 2. Zeile -> dort steht "Backfase Culling"
Gefixt.
Leonidas
2002-11-20, 02:28:11
Originally posted by csjunkie
http://www.3dcenter.de/artikel/voodoo5-wickedgl/2.php
(bei unreal und UT merkwürdigerweise kein Vergleich mit glide... ??? )
Weil der Vergleich unter 32 Bit gemacht wurde und dies Glide nicht beherrscht.
csjunkie
2002-11-20, 13:45:10
Originally posted by Leonidas
Weil der Vergleich unter 32 Bit gemacht wurde und dies Glide nicht beherrscht.
Den Vergleich in 16 bit müsste Glide dann aber gewinnen... :)
Frank
2002-11-20, 14:21:13
Originally posted by aths
Ich möchte nicht vorlaut erscheinen, aber kennst du die Prinzipien des LZW-Algorithmus' (der allerdings bei der Z-Compression nun nicht angewendet wird, wie der Artikel im Moment noch vermutet)?
Huffman kommt dafür aber glaub ich auch nicht in Frage.
Leonidas
2002-11-20, 18:31:36
Originally posted by csjunkie
Den Vergleich in 16 bit müsste Glide dann aber gewinnen... :)
Mag sein, aber was wollten wir zu dieser Zeit noch mit 16 Bit?
Originally posted by Frank
Huffman kommt dafür aber glaub ich auch nicht in Frage. ATI spricht von einem "Entropy Encoder", da gibts ja diverse Möglichkeiten.
Originally posted by Leonidas
Mag sein, aber was wollten wir zu dieser Zeit noch mit 16 Bit? Allerdings muss man auch sagen, dass 16 Bit Glide in der Regel deutlich besser als 16 Bit OpenGL oder D3D aussieht. Btw, man kann auf VSA auch 32-Bit-Rendering mit Glide erzwingen.
Frank
2002-11-20, 19:59:20
Originally posted by aths
ATI spricht von einem "Entropy Encoder", da gibts ja diverse Möglichkeiten.
muss ja sein, sonst wär es ja mit Verlusst.
Originally posted by ow
Gegenueber den letzten 3dfx OGL Treibern bringen die WickedGL praktisch kaum einen Performance-Vorteil.
Nein, SW-HSR ist AFAIK nicht in WickedGL drin. WickedGL bringt auf Voodoo4/5 bei den meisten Spielen keinen Vorteil, das stimmt. Allerdings ist WickedGL eine Möglichkeit, auch unter WinXP noch OpenGL-Spiele vernünftig zum Laufen zu bewegen.
Originally posted by ow
Und da SW-HSR eh nicht vernuenftig funktionierte ist das auch gut so. Meiner Meinung nach hätte man bei Spielen mit einem recht geringem Komplexitätsgrad (wie UT1 oder Q3) das Treiber-HSR durchaus brauchbar kriegen können. Problematisch ist nur, dass man dafür erstens eine sehr schnelle CPU braucht, und zweitens diese Methode spätestens mit Geometriedetails die heute modern sind, nicht mehr zurecht kommen kann. Weiterentwicklungen in diese Richtung halte ich deshalb auch für nutzlos.
Demirug
2002-11-20, 20:07:02
Originally posted by aths
Meiner Meinung nach hätte man bei Spielen mit einem recht geringem Komplexitätsgrad (wie UT1 oder Q3) das Treiber-HSR durchaus brauchbar kriegen können. Problematisch ist nur, dass man dafür erstens eine sehr schnelle CPU braucht, und zweitens diese Methode spätestens mit Geometriedetails die heute modern sind, nicht mehr zurecht kommen kann. Weiterentwicklungen in diese Richtung halte ich deshalb auch für nutzlos.
Dazu kommt ja noch das die engültige Geometrie verstärkt ja erst im VS der Grafikkarte entsteht.
csjunkie
2002-11-21, 17:48:39
Originally posted by Leonidas
Mag sein, aber was wollten wir zu dieser Zeit noch mit 16 Bit?
Um allzu starkes Ruckeln zu vermeiden, muss ich es sogar heute noch mit 16 Bit aushalten. :( http://broodwar.ingame.de/bwforum/images/smilies/azcrying.gif
Originally posted by Demirug
Dazu kommt ja noch das die engültige Geometrie verstärkt ja erst im VS der Grafikkarte entsteht. Man weiß ja, was ich von T&L halte :D
Cleric
2002-11-22, 12:40:35
also
a) ich meine es nur gut und verkrafte auch kritik
b) bin ich schon müde und kann quasi garnichts für den müll den ich hier schreibe..
c) tuts trotzdem not
>der Begriff "Hidden Surface Removal" (im Kontext >sinngemäß "verdeckte Flächen unsichtbar halten"), abgekürzt mit HSR, >wird für vielfältige Methoden gebraucht. Jede 3D-Grafikkarte und so >gut wie jede 3D-Engine hat HSR-Mechanismen. Diese unterscheiden sich >jedoch erheblich. Wir möchten in diesem Artikel wesentliche HSR->Techniken vorstellen.
Hidden Surface Removal würde ich sinngemäss mit
"nicht sichtbare flächen vermeiden"
überseten...
wie dem auch sei...
>Eine sehr alte Methode für HSR in Software wäre das "Backface >Culling". Hat man einen geschlossenen, konvexen Körper, kann man ja >nur auf die Vorderseite der Oberfläche sehen. Beispielsweise die >Kugel-Innenfläche ist nicht sichtbar. Werden die Dreiecks->Koordinaten im Uhrzeigersinn angegeben und sind sie nach der >Transformation im entgegengesetzten Uhrzeigersinn ausgerichtet, so >bedeutet dies, das man die "Rückseite" vor sich hat, die man wie >gesagt ohnehin nicht sieht. Damit kann das gesamte Dreieck >rausfliegen. Backface Culling kann übrigens auch in Hardware gemacht >werden. Man spart also bei einzelnen Objekten rund 50% >Dreiecksfläche.
daraus könnte ich nicht schliessen was backface culling ist.
also man sollte hier erwähnen das die RÜCKEITE eines polygons nie gerendert wird (ausser man gibt es explizit an)
und backface culling unter HSR zu packen gillet nischt ;P
das ganze wird anhand der ?normalen? getestet... ?isst lange her das ich sowas gemacht habe...?
>Allerdings bedeutet Dreiecks-Sortierung gerade bei heutigen >Polygonzahlen erhebliche CPU-Rechenzeit. Außerdem muss >berücksichtigt werden, dass jeder Textur-Wechsel das Rendering für >eine kurze Zeit stocken lässt. Unnötige Textur-Wechsel zu vermeiden >kann sinnvoller sein, als Füllrate zu sparen. Aus diesem Grunde ist >es eher üblich, dass nur jeweils die Rendering-Reihenfolge ganzer >Objekte sortiert wird. Aber das ist noch nicht alles, was die 3D->Engine fürs HSR tun kann.
ich glaube kaum das die cpu irgendwelche sortierungen bei HW T&L vornimmt... das können die auch ganz gut alleine (die grakas)
und die kompimierung... ich weiss zwar nischt wieviel zeit die graka hat um solche sachen zu entpacken.. aber bei dem aktuellen takt und der tatsache dass wenn die verdammte textur/zkomprimierte daten nicht ganz fix rüberwachsen die pipline stillliegt würd ich annehmen das es ein sehr einfacher algo ist den man in hardware mit ein zwei verschiebungen entpacken kann.. ich denke mal die latency ist ehr bei z abfragen wichtiger als die datenmenge... andererseits passt so viel mehr in den cache... naja bla laber laber k.a. habe ;)
was übrigens bei zu geringer / schlecht gewählter z tiefe herauskommt muss seine graka (nvidia) mal auf 16 bit schalten und sieht an vielen polygonkanten "sägezähne" die durch eine zu geringe z auflösung zeugen
hm nochmal backfaceculling
es gibt wohl kein spiel was diese option _nicht_ benutzt
ach ja.. schonmal gefragt warum q3 einen so hohen poly durchsatz hat und ut nicht?? naja ut handelt von der alten unreal egine noch alle world polys per hand .. das macht q3 nischt (und trotzdem bfc krass was? ;)
naja
und nu noch ne frage.. was hat portal rendering oder bsp mit hsr zu tun?
also hidden [surface] removal ...
und nicht hidden objcect removal
wer mir übrigens einen wirklichen hsr algo nennen kann, der es schafft dynamisch und ohne stundenlanges überlegen(rechenzeit) zu arbeiten... nur her damit und wer mir mit einem octree kommt wird erschossen ;)
mir gehts um hor hidden object removal surface geht eh nicht wegen t&l (jedenfalls nicht in software)
bla bla me ist müde.. ich geh jetzt pennen
cleric
2002-11-22, 12:42:34
wie bescheurt ist es bei so einem artikel auf rechtschreibfehler in einem forum hinzuweissssneuinisnfidsfnßafjükoadüakd
boah hier gehts doch um die tech und nicht um die rechte schreibweise ;) vorallem wenn das eh son mischmasch is...
Cleric
2002-11-22, 12:45:44
hmpf
Originally posted by cleric
boah hier gehts doch um die tech und nicht um die rechte schreibweise ;) vorallem wenn das eh son mischmasch is... Ich achte gerne auf korrekte Schreibweise und finde es gut, auf Fehler in der Rechtschreibung oder Grammatik hingewiesen zu werden. Deinen Kommentar zum Thema begrüße ich natürlich nicht minder.
Der HSR-Artikel ist durchweg "un-technisch" geschrieben :) und nimmt es in der Theorie nicht immer so genau. (Dafür stimmt nun wenigstens die Rechtschreibung, hehe.)
Dass bei Backface Culling ein Polygon nicht gerendert wird, wenn es die Rückseite zeigt, ist hoffentlich trotzdem so beim Leser angekommen.
zeckensack
2002-11-23, 16:11:54
Tach, Cleric :)
Zwei Anmerkungen:
Originally posted by Cleric
daraus könnte ich nicht schliessen was backface culling ist.
also man sollte hier erwähnen das die RÜCKEITE eines polygons nie gerendert wird (ausser man gibt es explizit an)
und backface culling unter HSR zu packen gillet nischt ;P
das ganze wird anhand der ?normalen? getestet... ?isst lange her das ich sowas gemacht habe...?Backface Culling wird mit dem Kreuzprodukt zweier Dreieckskanten gemacht. Dazu muß man einfach das Vorzeichen testen.
Das Kreuzprodukt ist ja auch ein Vektor, der von der Dreiecksfläche weg zeigt. Es ist nicht garantiert normalisiert (Länge=1), deswegen ist es schonmal nicht die Normale, außerdem kann das Spiel selbst Normalen übergeben, die auch in ganz andere Richtungen zeigen können (praktisch für smooth shading).
ich glaube kaum das die cpu irgendwelche sortierungen bei HW T&L vornimmt... das können die auch ganz gut alleine (die grakas)Nö. Mit Ausnahme der Deferred Renderer ala Kyro sortieren Grakas überhaupt nichts ;)
Z-Buffer und -Test zählen nicht als Sortieren.
Cleric
2002-11-24, 16:01:29
a) stimmt :) hab gestern wieder ein bissel was gemacht und mein altes wissen (das was noch übrig ist) freigekratzt ;)
(das stimmt musste sein ;)
b) hmmmm
c) hattest du nicht aber... wenn ich mir mal deinen pappkarton anschaue, stelle ich fest das du kasser underclocker bist ???
ne 1533Mhz cpu bei 1150mhz laufen lassen...
öhm
Taktfrequenz (MHz) 1533 MHz @ 1150 MHz
Prozessor FSB 133.0 MHz @ 100.0 MHz
isser dir zu schnell oder haste die zahlen vor und hinter dem @ zeichen vertauscht? ;)
Voodoo3Killer
2002-11-24, 18:10:38
...Stromsparer...
zeckensack
2002-11-25, 08:09:01
Leisetreter. Die Angaben bei Nethands stimmen schon so :)
Vor allem die dadurch möglichen 1,475 Volt Corespannung bringen Ruhe in die Wohnung =)
Leonidas
2002-11-25, 08:57:15
Originally posted by zeckensack
Vor allem die dadurch möglichen 1,475 Volt Corespannung bringen Ruhe in die Wohnung =)
:-)
Mein neuer P4 2.53 GHz B0-Core. Der schafft übertaktet ca. 2850 MHz - auf default VCore. Selbst wenn man ihn auf 1,8 Volt hochprügelt, wird es nicht besser. Und der Gag: Sein aktuelles Mainboard untersteuert sowieso, anstatt 1,5 Volt liefert es nur 1,44 Volt :-).
zeckensack
2002-11-25, 10:20:02
Boah :)
Nujo, ich bin momentan bei ca 30Watt. Mit unlocken ginge es sicher noch besser, aber dafür bin ich irgendwie zu ungeschickt :|
Vielleicht doch noch den leckeren C3 kaufen ... ?-)
csjunkie
2002-11-25, 13:33:28
Originally posted by zeckensack
Boah :)
Nujo, ich bin momentan bei ca 30Watt. Mit unlocken ginge es sicher noch besser, aber dafür bin ich irgendwie zu ungeschickt
Pech für dich zeckensack, Leonidas hat eindeutig den längeren... ;D ;)
:lol:
StefanV
2002-11-25, 14:35:11
Originally posted by csjunkie
Pech für dich zeckensack, Leonidas hat eindeutig den längeren... :lol:
Dafür hat Zeckie den Kühleren ;D ;D
Jetzt mal 'ne Frage an euch beide (Leo und Zecke):
Wielange läuft eure CPU ohne Lüfter??? :naughty:
zeckensack
2002-11-25, 14:54:29
Bis sie erbricht ???
Frank
2002-11-25, 17:18:10
Originally posted by Stefan Payne
Dafür hat Zeckie den Kühleren ;D ;D
Jetzt mal 'ne Frage an euch beide (Leo und Zecke):
Wielange läuft eure CPU ohne Lüfter??? :naughty:
na los beglücke uns mit deiner CPU-ohne-Lüfter Zeit oder sag schon, das ein P4 abräuchern kann
:zzz:
Originally posted by zeckensack
Nö. Mit Ausnahme der Deferred Renderer ala Kyro sortieren Grakas überhaupt nichts ;)
Auch Kyro sortiert nix. ;)
Leonidas
2002-11-27, 08:36:46
Originally posted by Stefan Payne
Jetzt mal 'ne Frage an euch beide (Leo und Zecke):
Wielange läuft eure CPU ohne Lüfter??? :naughty:
Keine Ahnung, hat bei mir aber auch keine wirkliche Relevanz. Der Arbeitsrechner ist mordsleise und der Testrechner nicht immer an.
EgonOlsen
2002-11-28, 01:05:03
Diese Methode leidet aber an einer Reihe von Nachteilen. Zunächst kostet das Sammeln der Dreiecke Speicherplatz und das Sortieren Rechenzeit. Je nach Lage der Dreiecke ist eine exakte Sortierung, die Überdeckungsfehler immer ausschließt, praktisch nicht möglich. Mit steigender Polygonzahl wird dieses Verfahren sehr ineffektiv, für kleine und einfache Körper wird es in Verbindung mit Backface Culling aber noch heute eingesetzt, zum Beispiel bei Java-Software-Renderern.
Jaaaaa...das kann ich nicht unkommentiert lassen, wo Java-Software-Renderer doch mein liebstes Kind sind. Also was hier steht ist sicher im wesentlichen richtig, aber die Polygonanzahl ist in einem solchen Renderer sowieso begrenzt und ein Sortieren daher nicht sehr aufwendig. Und das mit dem Speicher ist nun wirklich kein Argument, sorry. Ansonsten ist ein zBuffer auch für solch einen Renderer sinnvoll, da er nicht viel Performance kostet. Früher war das anders (früher war ja alles anders und Blaubeeren so groß wie Kirschen), aber gerade bei Java ist es meiner Erfahrung nach nicht besonders tragisch, einen ZBuffer zu verwenden. Liegt wohl daran das die VM selber im Vergleich zu den zusätzlichen Speicherzugriffen des Buffers recht langsam ist und diese somit fast nicht "auffallen". Aber auch dann ist ein Sortieren weiterhin sinnvoll, nur das man die Reihenfolge umkehrt (Zeichnen von vorne nach hinten). Sinnvoll deswegen, weil man dann sehr flott einen Early-Z-Test machen kann; ein Feature, welches (wie im Artikel erwähnt) nun auch bei den Hardware-Renderern angekommen ist....in Software ist es seit Jahr und Tag üblich...alles andere wäre hier schlicht "bescheuert".
Ich persönlich kombiniere in meinem Java-Renderer Backface-Culling, Sortierung (von vorne nach hinten), Early-Z-Check, Portale, eine Art heuristischen Spanbuffer und ein paar kleinere Tricks mit dem ZBuffer und so sieht das dann aus:
www.jpct.net (http://www.jpct.net) oder direkt die Offline-Demo zum Download hier: jPCT-Demo (http://www.jpct.net/download/jpctdemo.zip)
Ansonsten: Schöner Artikel, der sich angenehm von den Halbwissen verbreitenden "Artikeln" anderer Sites zu diesem Thema abhebt.
Im Artikel wurde erwähnt das HSR unter Glide bis auf ein Bildruckeln dann und wann funktioniert. Ich habe die neusten (letzten) Glide2x und 3x aber mit welcher Variable schaltet man HSR ein? Die Variable FX_GL_HSR gilt nur für 3dfxogl (opengl). Selbst bei den Third Party Treibern wie X3dfx, Mikepedo und Amigamerlin habe ich keine Option zum einschalten von HSR für Glide gefunden. Auch die Readme's zu Koolsmoky's und Colorless's Glide's schweigen sich darüber aus.
Viele Grüße,
Andreas
mapel110
2003-06-15, 13:10:29
hm, ich konnte soweit ich mich zurückerinner das HSR auch nur unter opengl einschalten.
Zumindest der Glide Sourcecode ist OpenSource was man ja an den beiden neuen Glides erkennt. Aber darin sind im moment wohl hauptsächlich mmx, 3dnow etc. Optimierungen eingeflossen. Die beiden Coder haben sich ja zusammengetan. Ob solch komplexe Funktionen wie HSR da noch eingebaut werde weiß ich aber nicht.
Viele Grüße,
Andreas
Falls das doch nochmal jemanden interessiert, ich hab das noch was gefunden:
Seite 2, Absatz 7:
Weil immer gleich ganze Kacheln in den Framebuffer geschrieben werden, ließe sich solche Hardware sogar mit Single Buffering betreiben, was die Render-Verzögerung wieder ausgleicht. Denn um den Bildaufbau "im Hintergrund" zu gewährleisten, ist herkömmliche Hardeware auf Double Buffering angewiesen, was ebenfalls eine Bildverzögerung bedeutet.
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.