Dumping world mesh into .obj files - inverted X and Z axis about phoenix-studio HOT 9 OPEN

Hey! Yes that's a good point :) Do you know whether that applies to normals too?

from phoenix-studio.

Do you know whether that applies to normals too?

Normals and textures coordinates are OK the way they are now in the code.
The only line that requires a modification is the one i referenced.

from phoenix-studio.

Fun fact:
it is possible to make the mesh work properly, that is without artifacts or lighting errors, while still keeping the XYZ order of vertices. The world will ofcourse still look inverted as in mirror, but in case anyone would like to introduce hard difficulty mode to the game by mirroring the world :)

to achieve that, one must revert the order of vertices in polygon definition (the f ... ... ... line in .obj).
(This is because by default in .obj file vertices are put in clockwise order, and that defines the "front" and "back" sides of a polygon. When the X and Z axis are swapped, the polygon gets flipped in the space, and that must be reflected in its definition as well)

from phoenix-studio.

I made some additional tests with increased lighting (higher value of specular Ks in .mtl file, more intensive sun light source above the scene). Turns out the axis of normals (vn ... ... ... in .obj) should also be swapped.

Current normals look:

Seems weird that surface that is seen from angle is more lit.

Swapped axis normals look:

Seems natural that surface I'm facing directly is more lit (sun rays goes from above, vertically, no angle, vector [0, -1, 0]).
The effect is more obvious when moving the camera around.

So this line also needs modification:

Sorry for missleading you before.
I also double checked the texture coordinates, but these are fine.

from phoenix-studio.

BTW. if the glm::vec3::z in phoenix::mesh::vertices[] stores the x value, then it is actually the phoenix lib that represents the data in a wrong way... so I would consider fixing the other repo instead. Although I know it may be inconvenient since the lib is already used by people. Funny thing is that I was unable to find x/z coords swapping in Open Gothic project. I asked Try if he dealt with that issue.

from phoenix-studio.

Yea I mean that can also be solved by swapping the coordinates in a shader. Anyways, this is how it was intended in the original format so I'll load it as-is I think.

from phoenix-studio.

(...), this is how it was intended in the original format so I'll load it as-is I think.

The original format does not contain names for the values. It is the phoenix who gives names to values, so it should do this properly. Next person who will use phoenix might be confused becouse of this. I figured this out relatively soon since I remember the mirror world effect from one of the discussion over ReGoth project few years ago.

But I'm not gonna insist, just sharing my point of view, the decision is yours :)

from phoenix-studio.

I would create a pull request myself, but I'm haveing some issues with github authentication :/
So just letting you know, the proto_mesh seems to also require the fix (I just loaded HUM_BODY_NAKED0.MDM and found that out):

from phoenix-studio.

OK... so yesterday I've learnt what is the source of that issue. Previously I thought this is just Gothic being weird, storing [x,y,z] values in reverse order for no reason. That is not the case.

In general, there are different coordinates systems used in software. For example, DirectX uses left-handed coordinate system while OpenGL uses right-handed.

It seems Gothic uses left-hand coordinate system.
From phoenix lib user perspective, depending on what renderer he uses, the Gothic data will be suited for him, or it will require a coversion to another coordinate system.
In my case I needed a conversion. At first tried to swap X and Z coordinates, but now I realised a better solution is to just negate the Z coordinate (Z = -Z), as that makes it easier to deal with rotation matrix (also stored for VOBs positions in .zen files), and other things.

Conclusion:

• we should not swap X and Z coordinates

• it is up to the user to adapt Gothic data to his needs, depending on what renderer he uses.

btw. I'm sorry for missleading you with this topic :-/

from phoenix-studio.