Not logged inOpenClonk Forum
Up Topic Development / Developer's Corner / Green channel of normal maps
- - By Matthias [de] Date 2015-08-02 13:10
To look correct ingame, the green channel of landscape texture normals has to be inverted right now. Is this intended? A typical normal map  baked from a 3D program will work incorrectly like this, but considering there are different coordinate systems at work, this might be justifiable as well.
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.
Reply
Parent - - By Matthias [de] Date 2015-08-02 13:24
Inverting existing normal maps is easy, by the way, so at least for Nachtfalters new materials I could fix them so they look the same.
Reply
Parent - By Marky [de] Date 2015-08-02 17:27
If the information is used somewhere in the shader code it might be easier to do it there.
Parent - By PeterW [gb] Date 2015-08-05 13:17
Just as a quick statement - I haven't really checked that normal directions are consistent. However, what CrazyBump produced seemed to make sense, so there might be differences between normal map generation tools? But if the consensus is that something should really be flipped, we can obviously talk about that.
Parent - - By Nachtfalter Date 2015-08-03 08:03
Maybe we should talk about the weird angle of the 3d models to work in OC, too at this point :| (the -90° in z-direction thingy)
Reply
Parent - - By Clonk-Karl Date 2015-08-04 01:13
What is the weird -90° in z direction thingie?
Reply
Parent - - By Clonkonaut [de] Date 2015-08-04 09:08
Probably this:

> 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.
Reply
Parent - - By Clonk-Karl [us] Date 2015-08-04 14:18

> 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...
Reply
Parent - - By Matthias [de] Date 2015-08-04 14:25
The problem is rather that we are using the ogre format, but to generate correct OC models, we have to export wrong ogre models. For example, just yesterday Clonkonaut told me that my wheat model was rotated sideways. That was because I checked the model with ogre meshy and changed the export orientation so that the model would be upright. I think it would be far more intuitive if the models were correct in meshy. Of course there is still the conversion form the blender coordinate system to ogre coordinates, but that could (and should?) be the default in our own exporter.
Reply
Parent - - By Clonk-Karl [us] Date 2015-08-04 15:39
So I could take care of the step of loading correct ogre models into the OC engine. Do you have such a correct ogre model that I could use to test this?
Reply
Parent - - By Matthias [de] Date 2015-08-04 19:53
As far as I read the docs and see it in meshy, this should be correct. the shield part is aligned on the yz plane, which should be the view plane in oc.

I hereby license the file dummy.zip under the CC-BY license
Attachment: dummy.zip (376k)
Reply
Parent - By Clonk-Karl Date 2015-08-11 00:13
Thanks. I'm looking into this and will try to come up with a tool to transform all existing models into this coordinate frame, if that is what most modelers would prefer.
Reply
Parent - - By Clonk-Karl [us] Date 2015-08-17 18:34
While working on this, I noticed something else that is slightly unfortunate: attach transformations (the transform parameter to AttachMesh, which includes GetCarryTransform()) are given in OGRE coordinates, not Clonk coordinates. This is actually an oversight, and somewhat unfortunate given that MeshTransformation and PictureTransformation are in Clonk coordinates.

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?
Reply
Parent - By Zapper [de] Date 2015-08-17 18:46
It's unfortunate that we have not had much community contribution in the past. But in situations like this it comes in handy.

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.)
Parent - By Sven2 [us] Date 2015-08-17 18:48
The error will just be a few models attached in wrong positions. E.g. the hats in Clonk Fest will be off. I think it'll be fine.
Parent - - By Clonk-Karl Date 2015-08-19 02:00
So just to double-check, is this how it is supposed to look?
Reply
Parent - By Matthias [de] Date 2015-08-19 21:11
No :(
Reply
Parent - - By Matthias [de] Date 2015-08-20 14:22
It's basically the same object as shown here. Can you verify that the mesh does display like this in OgreMeshy?
Reply
Parent - - By Clonk-Karl [us] Date 2015-08-21 01:16
Thanks. I don't have OgreMeshy at the moment, it only seems available for Kubuntu. I might try to build it myself later.
Reply
Parent - By Clonk-Karl [us] Date 2015-08-22 02:36
Got it running. Looks pretty good. Okay, thanks, I should be able to go from here.
Reply
Parent - - By Clonk-Karl [us] Date 2015-08-25 23:52
I'm a bit confused now on this. This model looks like expected in OgreMeshy, but has 2 90-degree rotations compared to what is used in Clonk, not just one around the Z axis like Nachtfalter mentioned. It's 90 degrees in Z and then 90 degrees around Y.
Reply
Parent - By Matthias [de] Date 2015-08-26 22:30
Argh, I seem to have made a mistake there. The shield part is in fact NOT on the YZ plane. This is actually what you should see:

Again, thats entirely my fault, didnt check the model properly, sorry.
Reply
Parent - - By Clonk-Karl [us] Date 2015-10-01 02:48 Edited 2015-10-01 02:54
So I finally got this ready with Matthi's input. This corresponds to a 90 degree rotation around Z in Clonk, or a 90 degree rotation around X in Blender. I hope that's correct. There is an engine change which changes the definition of the coordinate frame, and a python script that rotates all OGRE meshes in planet/ (but not the original blender files in the resources repository). Any last-minute objections to this?

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...
Reply
Parent - - By Zapper [de] Date 2015-10-01 09:55
This change has nothing to do with the normal maps, right?
Parent - By Clonk-Karl [us] Date 2015-10-01 14:12
No, it's just about the way meshes need to be oriented in Blender when they are exported.
Reply
Parent - - By Clonk-Karl [us] Date 2015-10-03 16:50
I pushed this to the repo. Actually it's only 4M, not 24 :)
Reply
Parent - - By Zapper [de] Date 2015-10-04 15:56
Did you also push the python script? Because I have other meshes (not in our repository) that are now wrong.
Parent - - By Clonk-Karl [us] Date 2015-10-04 16:08
I put it into the resources repo, here. Requires numpy and OgreXMLConverter in the PATH.
Reply
Parent - - By Clonkonaut Date 2015-10-18 15:12
I can't get it to work. Where is it supposed to be? Just in /planet or..?
Reply
Parent - - By Clonk-Karl [us] Date 2015-10-18 15:54
It doesn't matter where the script is. You just need to give the path(s) to the mesh file(s) to be converted as a command line parameter. If you don't get it work I can run it on a mesh for you if you give me the mesh.
Reply
Parent - By Clonkonaut Date 2015-10-18 23:19
Ooh, okay ;) Thanks, got it to work now!
Reply
Parent - - By Clonkonaut Date 2015-10-05 00:02
Your script didn't catch the rockets from Guardians of Windmills. Probably because those are still in .xml format (could also be changed).
Reply
Parent - - By Clonk-Karl [us] Date 2015-10-05 23:55
Both done, I also changed them from XML to binary. Why does the windmill scenario need a custom rocket mesh and not just a custom mesh material?
Reply
Parent - By Maikel Date 2015-10-06 06:34
It has a skull and bones drawn on it I suppose.
Parent - By Clonkonaut Date 2015-10-06 09:30
Probably because the scenario is way too old to make use of advanced script fu.
Reply
Parent - By Sven2 [us] Date 2015-10-05 00:18
You also didn't catch the Hat in Decoration.ocd (I've worked around it by rotating it in script, but rotating the model would be preferred).
Up Topic Development / Developer's Corner / Green channel of normal maps

Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill