internes model format: wie könnte es aussehen?

krabbels

hey!
seit einiger zeit mache ich mir gedanken darüber wie ich am besten das interne modelformat meiner engine aufbaue.am einfachsten wäre natürlich, ich speichere mein model in einem vertexarray, wobei ich nacheinander die triangles rendere.das problem dabei ist aber, dass es nicht sonderlich speicherplatz-schonend ist da sich zb triangles auch vertices teilen.diese müsste ich dann zweimal speichern.bei vielen/größeren models wäre das eine erhebliche verschwendung von speicher.
welches verfahren würdet ihr anwenden?
welche tipps könnt ihr mir geben?
kennt ihr vieleicht texte über dieses thema?
hoffe ihr könnt mir mit ein paar infos behilflich sein

xindon

Wie wäre es mit einem Vertex Array und einem Index Array?
Dann brauchst du aber auch noch eine Liste mit Groups/Meshs.
Ein Mesh ist eine Sammlung von Vertices, die die gleiche Textur benutzen.

rapso

object/model
 + mesh
    + vertexarray
    + indexarray
 + material
    + textures
    + shader

wobei man das nicht immer in eine datei stecken muss, sondern jeweils auf die unteren referenzieren koennte.

DocJunioR

Kann man da auch noch Bone-Daten ranfrickeln?

object
   + mesh
   | + vertexarray
   | | + x : int
   | | + y : int
   | | + z : int
   | | + s : int (textur)
   | | + t : int (textur)
   | + trianglearray
   |   + a : int
   |   + b : int
   |   + c : int
   + bones
   | + bonearray
   | | + xa : int
   | | + ya : int
   | | + za : int
   | | + xb : int
   | | + yb : int
   | | + zb : int
   | + boneconnections
   | | + bonea : int
   | | + boneb : int
   | | + connectedat : "a : b"
   | + bone2pointarray
   |   + point : int
   |   + bone  : int
   |   + connectedat : "a : b"
   |   + strength : byte (Bindung an den Bone)
   + material
     + textures
     + shader

Bin grad dabei, mir nen simplen 3D-Editor zu bauen und brauch nen Dateiformat- sowie das gluProject endlich mal funktioniert...

Bei den Texturen weiß ich nicht, ob man die nicht einfach von hand vergeben könnte.
Shader- hmm.. da such ich immernoch nach vernünftigen Tutorials zur GLSL.

hellihjb

bones sind fuer gewoehnlich hierarchisch aufgebaut, wobei jeweils eine verbindung zwischen parent und allen childs besteht.
zusaetzlich hat jeder vertex eine liste von bone-ids mit gewichtungsfaktor.
bei der animation eines bones veraendert man nicht dessen position, sondern die rotation der parents.
warum integer-koordinaten?

DocJunioR

ich weiß, aber nen Baum abbilden ist irgendwie nicht so einfach. Habs ja in zwei Segmenten, die zusammen durchaus einen Baum ergeben können.
Najaa.. int ist kein muß- ich würd vielleicht sogar bytes nehmen. Gleitkommazahlen sind ja nun ein wenig größer, nich

TomasRiker

DocJunioR schrieb:

Najaa.. int ist kein muß- ich würd vielleicht sogar bytes nehmen. Gleitkommazahlen sind ja nun ein wenig größer, nich

int hat normalerweise 32 bits, und float ebenfalls, also da keine Einsparung.
Aber Bytes für 3D-Koordinaten?!?

DocJunioR

würde das Ganze Modell zwar recht grobgranular darstellen (maximal 256 Einheiten pro Seite, aaber es geht), aber durchaus ausreichend sein, denk ich.

@float - stimmt allerdings auch wieder.. ich hab hier noch den einen oder anderen Compiler, bei dem hat int nur 16 Bit, weshalb ich da gelegentlich verwirrt bin

hellihjb

deine grafikkarte kann sowieso keine integers als vertex-positionen verarbeiten;
opengl konvertiert also intern deine koordinaten nach float.
fuer einfache parameter wie farben macht 8bit sinn, fuer normalen und texture-koordinaten wird's aber oft nicht reichen.

rapso

da verwendet man eher 8bit-int (unsigned char), 32bit-int haette kaum vorteile gegenueber float. sowas verwendet man oft als eine art "kompression", besonders fuer normalen und texture coordinaten ist das sehr sinnvoll. fuer positionen laesst sich das ganze sehr trivial mit einer zusaetzlichen matrix (die auf die worldmatrix draufmultipliziert wird) for free entpacken.

hellihjb

nen Baum abbilden ist irgendwie nicht so einfach.
Habs ja in zwei Segmenten, die zusammen durchaus einen Baum ergeben können.

bei hierarchischen strukturen ist die transformation jedes bones ja relativ zu seinem parent zu sehen, sodass du fuer die absolute transformation alle bone-verbindungen "nach oben" durchlaufen musst - im baum ergibt sich das von selbst.

bzgl des vertexformates kann man sich folgendes ueberlegen:
gerade wenn man shader unterschiedlicher komplexitaet einsetzen moechte ist es evtl sinnvoll, die geometrie des meshes einfach an das material weiterzureichen, das dann selber die entsprechenden vertex- und indexbuffer in einem geeigneten vertexformat daraus produziert.
vorteil: zum rendering muss man nur noch die materialliste durchlaufen und sich keine weiteren gedanken um kostbare state-changes machen.