OBD talk:M3GM

Incoming from my talk page. Could do with further trimming once the talk is over.

M3GM

First off, a little rant: try to be more careful with the "done" label on Oni Stuff

(how can you say M3GM is "done" when you have no idea how the VCRA and IDXA are interpreted in that specific case?)

geyser

M3GM contains only links, so it's done. (I don't look to the hierarchy.)

VCRA and IDXA ==> http://www6.fh-eberswalde.de/user/dkriesch/oni/werte.htm Any ideas?

ssg

IDXA and VCRA (and PNTA, even) are generic: they get interpreted in different ways depending on where they're linked to from.

In particular, the parsing of the first IDXA is non-trivial and highly specific (see the source for Pierre's OniRip).

(when you say "That's clear.", could you be more precise? are you sure you understand what face goes where and why?)

Actually, the high bit denotes, in this specific case, the first vertex of a "strip": they're not triangles.

(and in other cases, the high bit will mean something completely different)

Knowledge about IDXA etc should be detailed specifically to the resources that link to them: for example, the M3GM.

Look at your site http://www6.fh-eberswalde.de/user/dkriesch/oni/werte.htm again. See how all the generic sub-resources of an M3GM are connected? They simply don't make the same sense when considered out of the M3GM's context...

That's why I say M3GM is not "done": because http://www6.fh-eberswalde.de/user/dkriesch/oni/werte.htm is missing knowledge relative to M3GM, not VCRA or IDXA...

Sometimes the hierarchy is crucial, i.e., you have to consider a file together with its children/parents.

M3GM: Again, they contain only links, so it's done. I know that there're different IDXA and VCRA files, so they are not done, because there is still no differentiation between the different files.

ssg

Parsing of the VCRA and IDXA is specific to the M3GM and whatever other file they belong to. Their meaning is specific to the M3GM, in a way.

Obviously, I don't want to argue about this forever. I'll just detail the format of all M3GM-specific stuff on the M3GM page and that's it ^^

One question to you, though. What other files (apart from the M3GM) use PNTA, TXCA, VCRA and IDXA resources? AKEV? Anything else?

geyser 19:30, 30 January 2007 (CET)

---

Most of the stuff is as ssg says here: http://www6.fh-eberswalde.de/user/dkriesch/oni/werte.htm.

• PNTA, TXCA, first VCRA: vertex map (XYZ, UV, vertex normals). Vertex normals used for Gouraud shading.
• Second VCRA: face normals, for flat shading (not sure the engine ever switches from Gouraud to flat) and specular effects.
• First IDXA: polygon strips. Vertices are listed this way:

0-2-4-6-...-2n
 \|\|\|\...\|
  1-3-5-...-2n-1

the oriented faces are (0,1,2), (1,3,2), (2,3,4), (3,5,4) etc

Strips refer to vertex IDs (those in the PNTA/TXCA/VCRA1). The first vertex of a strip is flagged with a high bit.

• Second IDXA: normal groups. The triangles (listed in the order in which they appear in strips) are assigned to a face normal (VCRA2).

geyser 00:33, 28 January 2007 (CET)

PNTA and TXCA and 1st VCRA

I'm surprised your page doesn't include a listing of the TXCA. How can you be sure it's irrelevant? (ah, OK, it's parallel to the PNTA...)

1st IDXA

door example: I don't agree with you, that they are "strips".

Biturn says, that they're triangles and you have to read the first IDXA in this way:

http://www6.fh-eberswalde.de/user/dkriesch/oni/doorcode.gif

grey = high bit, red = same as the first column, yellow = same as the first row column but first and second value switched

If you read it step by step (I used Rhino3D), you get this:

http://www6.fh-eberswalde.de/user/dkriesch/oni/door.gif

ssg

That's exactly what strips look like. I couldn't have illustrated them better myself. Thanks. ^^

geyser 19:30, 30 January 2007 (CET)

Seriously, Biturn and I/Pierre are saying the same thing. Look at the Rhino3D screenshots again.

The first 5 faces are all connected and form a strip that wraps around the mesh.

Same for the next 3, and the next 2, and the last 2 taken separately.

If I unwrap those strips and make them go left to right with the outside facing you, I get:

a-c-e-g h-j-l m-o   q-s t-v
 \|\|\|  \|\|  \|\   \|  \|
  b-d-f   i-k   n-p   r   u

(I used letters to refer to IDXA elements, to avoid confusion with vertex IDs)

The triangles are then (a,b,c),(d,c,b),(c,d,e),(f,e,d),(e,f,g),(h,i,j),(k,j,i), etc...

(compare with Biturn, and with what I said earlier: note that (d,c,b) is the same as (b,d,c))

(i.e., swapping 1st and 2nd vertex IDs is the same as swapping any two vertices! )

Storing triangles that way (as strips) saves some space (the IDXA has 22 elements instead of 36).

It requires (at store-time) an algorithm that decomposes the mesh into strips rather than triangles.

So no, it's not the same thing. "Triangles" stored "in this way" is what we call "strips". OK? ^^

geyser 19:30, 30 January 2007 (CET)

2nd IDXA

The second IDXA contains the normal for every triangle.

ssg

I.e. the ID of a normal stored in the 2nd VCRA.

geyser 19:30, 30 January 2007 (CET)

2nd VCRA

And IMO the normals aren't used for shading, but for the textures, to say to the texture:

look with your front side to the same direction as the normal.

ssg

The outside and inside of every triangle are already defined in a discrete way by the first IDXA.

If you look at a triangle, and the vertices cycle counter-clockwise, then it's facing towards you.

The face normals are redundant of that information. Pierre says they're not used for rendering a priori.

A very simple way to check is to swap a few IDs in the second IDXA, and see what happens ^^

geyser 19:30, 30 January 2007 (CET)

1st VCRA

I only don't understand why there are 16 points and normals for them.

ssg

Because of vertex shading. I told you before.

geyser 19:30, 30 January 2007 (CET)

As for the first VCRA: they are vertex normals (basically, averages of the face normals for the adjacent faces). Normalized.

Oni (OpenGL) uses them for Gouraud shading.

geyser

I'm not sure why so many entries are necessary for the PNTA and the first VCRA. To fix vertex lighting?

Gouraud will only look nice for rather smooth objects, such as a head; err, for Konoko's head, actually, it's rather ugly.

And it's totally unadapted for box-shaped objects, which are supposed to appear square, not smooth.

I'd expect there to be a flag somewhere that turns Gouraud on and off.

If there's none, then vertex shading will indeed have to be "fixed" for angular geometry.

Which means more PNTA and VCRA for a door than "needed" for a smooth "cube"... Almost stupid, but "c'est la vie".

geyser

Regardless of technical issues, they have to duplicate PNTA entries because a vertex can have different UV and normals depending on what face it belongs to. And since all 3 arrays run alongside each other (indexed by the same ID in the first IDXA), PNTA has to be extended accordingly.

geyser 19:30, 30 January 2007 (CET)