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.
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.
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.
If the information is used somewhere in the shader code it might be easier to do it there.
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.
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)
Probably this:
I reckon it's kinda counterintuitive for new artists.
> 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...
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.
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?
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
I hereby license the file dummy.zip under the CC-BY license
Attachment: dummy.zip (376k)
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.
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?
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?
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.)
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.)
So just to double-check, is this how it is supposed to look?
It's basically the same object as shown here. Can you verify that the mesh does display like this in OgreMeshy?
Thanks. I don't have OgreMeshy at the moment, it only seems available for Kubuntu. I might try to build it myself later.
Got it running. Looks pretty good. Okay, thanks, I should be able to go from here.
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.
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...
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...
No, it's just about the way meshes need to be oriented in Blender when they are exported.
I pushed this to the repo. Actually it's only 4M, not 24 :)
Did you also push the python script? Because I have other meshes (not in our repository) that are now wrong.
I put it into the resources repo, here. Requires numpy and OgreXMLConverter in the PATH.
I can't get it to work. Where is it supposed to be? Just in /planet or..?
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.
Your script didn't catch the rockets from Guardians of Windmills. Probably because those are still in .xml format (could also be changed).
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?
Probably because the scenario is way too old to make use of advanced script fu.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill