Comments (9)
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:
phoenix-studio/src/cli/zmodel/main.cc
Line 91 in 584e170
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):
phoenix-studio/src/cli/zmodel/main.cc
Line 40 in e075f1b
phoenix-studio/src/cli/zmodel/main.cc
Line 50 in e075f1b
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.
Related Issues (2)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from phoenix-studio.