Implementation von Vertex-Klassen

[otze]

alpha für detail?

[energyzer]

Also ich meinte mit Detailtextur eine Normalmap (vielleicht bezeichnest du
das als Relief??). Und die macht durchaus Sinn mit einer Alphamap zu
kombinieren. Z.B., wenn man will, dass nur die Steine im Terrain Risse haben
und nicht das Gras

[otze]

relief ist dafür da um einer textur durch grautöne eine plastizität zu geben.
ansonsten mein ich mit detailmap das, was du auch meinst^^

[TGGC]

@Opti: Sorry.

@illumintaor:
Von ausserhalb oder innerhalb habe ich nichts gesagt, möglich wäre alles. Es könnte z.b. einen OffsetManager geben, der Offset alle bisher nötigen Vertextypen cached...
Und Die Offsets sind doch nicht mittendrin!

Bye, TGGC \-/

[otze]

Das Problem bei der Implemation einer Vertex-Klasse ist aus meiner Sicht
folgendes: Da jedes Objekt unterschiedlich viele Textur-Schichten hat, muss
ein Vertex auch dynamisch viele Textur-Koordinaten bieten (bis zu 8).

nach längerem überlegen kam ich auf folgenden gedanken:
pack in die vertices das, was jedes objekt minimal braucht, und pack das, was objektspeziell ist, in eine andre streamsource und benutz shader.
(5 unbenutze texturschichts koordinaten pro vertex ).

[TGGC]

Das ist die andere einfache Lösung.

Bye, TGGC \-/

[spl*t]

otze schrieb:

nach längerem überlegen kam ich auf folgenden gedanken:
pack in die vertices das, was jedes objekt minimal braucht, und pack das, was objektspeziell ist, in eine andre streamsource und benutz shader.
(5 unbenutze texturschichts koordinaten pro vertex ).

Ich verstehe nicht, was extra-streamsources mit Shadern zu tun haben, kannste das bitte nochmal erklären

[otze]

ganz einfache erklärung: du hast 2 vertexbuffer a und b
buffer a enthält positionsangaben und normale der vertices.
b enthält die Texturkoordinaten.
jetzt wird ein vertexbuffern mit den angaben von a und b erstellt

das gibt aber ein problem,da man ja die angaben in einem bestimmten schema anordnen muss, dh wenn es zum kopiervorgang kommt, wird für jedes vertex ein kopiervorgang von a und b gestartet,bei 2000 vertices sind das 4000 vorgänge.
nun kann man aber einfach 2 buffer mit verschiedenen FVF werten benutzen, aber die standard T&L weis nicht, wie sie die daten verknüpfen soll,deshalb muss man einen shader kreieren, der definiert von welcher quelle er welche daten bekommt.

vorallem kann dies sehr viele resourcen sparen:
beispiel an einem strategiespiel:
4 spieler, 4 verschiedene farben, gleiche rassen, also gleiche einheiten:
jetzt brauch man rein theoretisch nur einen vertexbuffer mit den modeldaten, und 4 buffer mit den farben, das war alles. eder modelbuffer wird nur einmal geschrieben,kann also statisch sein, und die farbbuffer zu wechseln geht auch relativ schnell. Ohne shader müsste man den modelbuffer jedes mal komplett neu beschreiben,das würde keinen spaß machen,und die performance "leicht" in den Keller treiben

[spl*t]

Hmm, so richtig genau weiß ich immer noch nicht wie du das meinst, aber das könnte glaub ich daran liegen dass ich von DX keine Ahnung habe
In OGL gibts ja solche Vertexarrays, da isses sogar üblich, dass in einem Array die Positionen und in nem anderen die Texturkoordinaten stehen.
Und ich hab so dass Gefühl, dass auch die Pipline etwas anderes aussieht...

[otze]

tja, bei dx muss man da sofort mit shadern ran^^

//edit
hier der thread