so. hab jetzt mal nen test mit C++ und OGL gefahren.

die wohl schnellste darstellungsmöglichkeit wird mit net OGLListe gefahren. ka ob es etwas noch schnelleres gibt. auf jeden fall ist der test sehr mager ausgefallen. jetzt frag ich mich erstmal ob ich hardware überhaupt aktiviert habe !?!. mach OGL das automatisch oder muss man beim init noch ein flag übergeben damit das läuft ?

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

Sollte eigentlich automatisch gehen. Schau dir mal ein Tut von NeHe (http://nehe.gamedev.net) an (falls du das noch nicht gemacht hast). Dort steht auf jeden Fall der Code, der auch den Hardware-Beschläuniger aktiviert.
Bei mir ist das Ergebnis dieses Tests (habe ich vor ca. 1 Jahr mit der VooDoo 3 gemacht) auch relativ mager ausgefallen. Danach bin ich auf D3D *fehlerinzwischenzeitbemerkthab* umgestiegen.

ja.. das isses ja... die demos laufen mit 20k polys wie ne 1... ich KRIECHE mit 20k !!!

frage: WARUM ???

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

und im übrigen: unreal2 -> 300.000 poly ... hehe

nur mit extrem guten tricks. wenn auf euren schirmen 50000 Polygone zu sehen sind dann geht die graka in die knie *fg*

1. zähle keine polys mit die von dir abgewendet sind.
2. polys die 70-90° angewendet stehen die werden komischerweise schneller gerendert ;)

ich denke unreal2 kommt auch nicht ganz mit 300000 hin. ausser sie rechnen 300000 VOR lod & co *g*

---------------------------------

SOOO: 12 (weil box) * 10000 Polys (flüssig @ 20FPS)
grund: MIPMAPPING !!!

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

Wie groß sind denn diese Polygone? Vielleicht macht das einen Unterschied von wegen Fillrate und Overdraw. Probier mal größere vs. kleinere Polygone aus.

Ansonsten gibt's bei OpenGL ne Menge Extensions, die man ausprobieren sollte... da muß man sich dann aber natürlich immer beim entsprechenden Hardwarehersteller erkundigen, und man kann's nur auf deren Grafikchips ausprobieren - wenn man die nicht hat, hat man Pech gehabt :|

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

nene... sind grosse und kleine... is landscape. hab nur immo noch nen kleenes problem mit der backclippingplane. wie stell ich die höher ??? kannste mir da helfen ?

ansonsten bin ich derzeit bei 3,5 Mio poly's pro sek. das is ja schonmal was *g*. ich will aber nicht wissen wieviel davon noch verloren geht wenn ich da collision und gravity einbaue. von der gameengine ganz zu schweigen.

also bei 30FPS komm ich auf ca. 116.000 poly's. das ist meiner meinung nach schon ganz ordentlich. wenn ich der landschaft ca. 25000 gebe ist noch genug für models da. (in delphi hatte ich mit der alten engine, die auch nochmal absolut unoptimiert war, garade mal etwas über 50000 Poly's pro sek. (also ca. 1600 @30FPS). ähnlich wie bei unreal das 100fache rausgeholt *gggggg*. nur bei unreal kam dazu das das graka-system nicht das gleiche ist *g*. und pro model 500-800 Poly's macht ca. 130 objekte auf einmal... das ist in ordnung. (+lod noch mehr *GGG*)

gehe ich aber noch davon aus das ich durch gameengine & co. noch ca. 30% verliere komme ich auf ca. 90 objekte und 17500 landschaftspoly's bei ca. 30FPS... reicht aber immernoch für ein starthegiespiel... muss halt machen das die kämfer mehr schaden anrichten und man weniger gleichzeitig haben muss *GGG*

BTW. ich habe noch keine OGLlisten angewand... vielleicht bekomme ich dadurch nen schub von 10% *freu*... das versuch ich aber erst morgen... muss leider pennen gehen :(

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

und noch etwas was ich ausser der backclippingplane wissen muss:

ich musste lesen das man particle unter OGL nur über alphageblendete kugeltexturen machen kann :(. und 2. problem ist das man jene texturen durch wände sehen kann. hintergrund dessen ist das man den depthtest ausschalten muss. also den test mit dem z buffer.

gibt es da ne lösung ? wenn man den zbuffertest an lässt ist das resultat das die sprites zwar alphageblenget sind aber weit entfernte nicht mehr gezeichnet werden, sollte sich vor ihnen ein anderes objekt befinden *heul*

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

von hinten nach vorne rendern, alpha-Kanal, Farbmischung, ..... Beschäftige dich damit mal, die Möglichkeit die du da ansprichst, verwendet man nur in Grafikdemos, bzw musst du eine Sichtbarkeitsberechnung durchführen, das ist alles gar nicht so einfach, die Effekte für sich genommen in demo´s ist ja noch nicht mal so schwer, aber das dann alles miteinander zu kombinieren ist was anderes und das du so hohe Polygonzahlen haben wirst bezweifle ich stark, btw deinem Beispiel mit Unreal2, das sind ca 50000 pro Bild und sie machen starken gebrauch einer T&L einheit um die CPU zu entlasten, doch was die meisten vergessen, wenn sie z.B. eine Sparvariante der Geforce2 oder 3 mit einem halbierten Bus besitzen, bringt die T&L einheit überhaubt nicht´s weil der Bus zum Flaschenhals wird.

ach egal, ich zitiere jetzt aus einem meiner Bücher, im inet gibt´s ja auch genug.

"
Die Schwierigkeit in der Erzielung eines transparenten Effektes liegt im damit verbundenen Rechenaufwand. Abhängig von den Brechungseigenschaften einer Grenzfläche müssen bei der Betrachtung des Objektes verschiedene dahinterliegende Objekte in die Bestimmung der Farbe mit einbezogen werden. Für das Rendering gibt es kein effizientes Verfahren, das diesen Effekt wirklich realistisch umsetzt. Nur durch Einsatz eines Strahlenverfolgungsverfahrens ist es möglich. (Raytracing, sollte dir was sagen, aber denk erst gar nich dran)
.
(ok, bis hier hin bringt dir das eigentlich gar nicht´s, egal...., aufjedenfall lernst trotzdem was über die Theorie)
.
.
Dennoch haben sich einige Annährungen der Berücksichtigung von transparenten Flächen im Rendering herausgebildet, von denen hier zwei vorgestellt werden sollen: Das erste beruht auf der Mischung von Teilbildern mit Hilfe der "alpha"-Komponente, das zweite auf einer entsprechenden Maskierung. Beide können in OpenGL mit relativ geringem Aufwand auf verschiedene Weise realisiert werden.
.
.
Die letzte Komponente aller in OpenGL angegebenen Farben ist die alpha-Komponente. Durch sie wird durch Überblenden von Objekten ein transparenter Effekt erreicht. Soll beispielsweise vor ein bereits gespeichertes, undurchsichtiges Objekt im z-Buffer ein zu 20% duchscheinendes geschrieben werden, so kann die neue Farbe wie folgt berechnet werden:
Cergeb = 0.2 * Calt + 0.8 * Cneu (eigentlich ganz simple Formel ;) )
.
.
. (so jetzt noch ein paar regeln zu schluss)
1.
Wenn transparente Objekte in den Bildspeicher geschrieben werden, sollten sie den z-Buffer nicht verändern. Würde der z-Wert angepaßt, so würden nachfolgende, dahinterliegende, opake(undurchsichtige) Objekte nicht mehr in den Speicher geschrieben.
2.
Daher sollten transparente und opake Objekte nicht in beliebiger Reihenfolge in den Speicher geschrieben werden. Empfehlenswert ist, zuerst alle opaken und anschließend alle transparenten ohne Änderung des z-Wertes zu schreiben.
Idel, aber nur aufwendig berechenbar wäre ein von hinten nach vorne sortiertes Schreiben, auch als "Maleralgorithmus" bekannt. Damit verlieren Sie allerdings auch den Vorteil, das OPenGL die Verdeckungsrechnung eigentlich automatisch für Sie erledigt.
3.
Je mehr transparente Flächen unsortiert übereinander gelegt werden, desto verfälschter wird das Ergebnis. Nur vorsortiert gesoeicherte Objekte oder solche mit konstanter halber Transparenz erscheinen einigermaßen korrekt.
4.
In Animationen fallen die oben gennanten Effekte noch störender auf. Verändert sich die Reihenfolge der geschriebenen Objekte von Bild zu Bild, so erscheinen diese im Extremfall unterschiedlich hell.

vielleicht gibt dir das ein paar einblicke und denkanstöße

ja, das mit den alphatexturen macht mir gerade noch immer kopfzerbrechen. in HL ist es volgendermassen gelöst:

das (in OGL) pseudo partikel wird nur gerendert wenn es im direkten sichkontackt zum player steht. dabei kommen auch lichteffekte die realistisch aussehen. du hast eine lichtquelle die gerade eben um die ecke zu sehen ist. diese lichtquelle hat die breite von 0 sodas es entweder sichtbar oder nicht sichtbar ist. stufen dazwischen gibt es keine. wenn der partikel gerade um die wand gesehen wird scheint er mit der anderen hälfte über die wand rüber. das ist realistisch.
ABER: verdammt rechenaufwendig wenn man bedenkt das die jedem partikel ne berechnung zwischen viewpoint und partikelmitte durchgefürt werden muss :(

wegen T&L muss ich schauen in wie fern ich das realisieren kann :-/ eine scene kann bei mir immo etwas über 100.000 poly's haben was schon recht gut ist für ein spiel. auch wen unreal2 immo noch 5x mehr schafft... ich sitze seit 2 tagen an der neuen engine... mal schauen was da noch kommt *GGG*

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

da ich keine ahnung habe, in welchen OpenGL thread ich posten soll, nehm ich mal diesen hier..
also ne rendering frage: wie geht das , dass man aber einer bestimmten entfernung alles "billiger" rendert, um performance zu sparen. so wie das bei hl auch gemacht worden ist.

thx

„Und da wir uns ja seit heute etwas näher gekommen sind, kann ich nur sagen: Mir hilft da immer Norther volle Lautstärke (so wie jetzt), sodass die ganzen unrasierten, Wasserpfeife rauchenden, alternativen Wichsstudenten aus ihren, aus Bananenschalen und Abfall gebastelten, Sitzkissen fliegen.“

erm _ in hl wurde das nicht gemacht :)
es gibt verschiedenste möglichkeiten. hier ein paar

- 3 stufen modelle
- mipmapping
- flüssiges LOD
- alpha ausblendung bei weiter entfernung
- textur weglassen bei weiter entfernung
- fog und die welt dahinter abschneiden
- (BSP)
- komplexe models in der ferne als sprites darstellen
- in der ferne spezielle effekte wie z.B. enviromentmapping weglassen
- in der ferne partikel weglassen

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

was wurde in Hl nicht gemacht, natürlich hat auch Hl Mipmapping, das ist ja wohl auch nichts besonderes.

z.B. beim Filtern.

da wird standdardmässig ein min und ein max Filter festgelegt,

der eine ist für den Fall das sich eine Texture verkleinert, der andere Filter ist für den Fall das sich die Texture vergrössert, also wenn du auf sie zugehst oder dich von ihr entfernst.

z.B. übergiebst du an eine Funktion GL_NEAREST, GL_LINEAR_MIPMAP_NEAREST, ...

schau einfach mal in die opengl Referenz,

oder auf
www.Gamedev-net.de
www.Gamedev.net
und andere

Polygone Spart man ein, indem man Bezier Patches benutzt, die sich bestens für´s Lod eignen, wie in q3 z.B. , da ist die Zuordnung aber statisch und wird beim Compilen festgelegt, man kann es leider sehr deutlich sehen, wenn zwischen den Stufen umgeschaltet wird, das trifft auch auf das normale Mipmapping zu, da kann man noch zusätzlich die einzelnen Stufen interpolieren.

_________________________________________________________________
wegen T&L muss ich schauen in wie fern ich das realisieren kann :-/ eine scene kann bei mir immo etwas über 100.000 poly's haben was schon recht gut ist für ein spiel. auch wen unreal2 immo noch 5x mehr schafft... ich sitze seit 2 tagen an der neuen engine
_________________________________________________________________

Verwechsle mal eine Grafikdemo nicht mit einer Game Engine

au man

------------------------------------
was wurde in Hl nicht gemacht, natürlich hat auch Hl Mipmapping, das ist ja wohl auch nichts besonderes.
------------------------------------

models aber nicht *g* mipmapping war sowieso idiotisch einzutragen *g* immo beschäftigt mich echt LOD. da kann man so verdammt geile sachen mit machen. ich liebe es *fg*

btw. kennt einer eine site die advanced OpenGL rendering tuorials anbietet ? (alpha & co ?)

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.

Wtf ist LOD?

achja danke für die hilfreichen antworten. (nein, keine ironie)

„Und da wir uns ja seit heute etwas näher gekommen sind, kann ich nur sagen: Mir hilft da immer Norther volle Lautstärke (so wie jetzt), sodass die ganzen unrasierten, Wasserpfeife rauchenden, alternativen Wichsstudenten aus ihren, aus Bananenschalen und Abfall gebastelten, Sitzkissen fliegen.“

lod is level of detail. d.H. wenn du eine landschaft mit hügeln und co hast wird diese in der ferne immer undetailierter. (zu sehen in tribes1&2)

*hmpf* wollt jetzt eigentlich den p-enginetest uppen... aber mein webspace reicht nicht :(

ob nun delphi, c oder java. kein programm lässt sich mit allen 3en gleichschnell entwickeln.