I'm not sure about object normal maps. There is a matrix conversion happening in the object light shader, so I guess its corrected there.
Fixing this issue is easy, for landscape normals as least, as it's a simple inversion of the y component. However, this changes the lighting of the exisiting normal maps, and I am not even sure they are correct and work as intended. As the new textures are in the works right now, this should be clarified.
> Model on the Y/Z view-plane. Models in OpenClonk appear as they do on the Y/Z plane in blender. The X-Axis goes 'into' the screen. Make sure you model with regard to these axes (The Y/Z plane is the default side view in Blender).
I reckon it's kinda counterintuitive for new artists.
> I reckon it's kinda counterintuitive for new artists.
What would be more intuitive? The reason things are as they are is that the very first model that I had in my hands, and which I used to implement the mesh support in the engine, was oriented this way (pluto's Monster model).
I wouldn't mind changing it to something that is more intuitive. Could probably come up with a script to convert all existing meshes as well...
I hereby license the file dummy.zip under the CC-BY license
If we change the coordinate frame of meshes, then all attach transformations would need to be adapted as well if we don't want to make the situation even worse by having three different coordinate systems to deal with. In that case I would suggest to change the attach transformations such that they are in Clonk coordinates (x=right, y=down), to maximize consistency.
I could easily do that for the OpenClonk repo, and document how to do it for third party objects. But the more general question is, is this something we want to do? Another alternative could be to introduce a new AttachMesh2 function which uses the Clonk coordinate frame for the transformations. However, if we make a backwards-incompatible change with the meshes' coordinate frame already anyway, then we could just as well make a backwards-incompatible change for the attach transformations.
We could also try to somehow keep old meshes working, and provide a way to tell the engine that a given mesh is to be interpreted in the new reference frame. Any opinions on this?
I'd say, do the change. It's just a sensible change and I think we are not gaining much by providing backwards compatibility or another function in this case.
(For me, the attach transformations were always a huge guessing work - never understood how it was supposed to work until now.)
Here's the commit on github. Git does not seem to be too happy about the change of binary files. This seems to add 24M to our git history...
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill