Horde3D

Hi, I'm one of the artists working on "Plight of the Weedunks" that Stuckie has posted about in the showcase board. We're having a problem with exported models from Maya 2008 using the Collada-Maya converter from FCOLLADA.

Basically when we get a model out from Maya into Horde wherever there is a seam in the UV layout (i.e. 2 UVs per vertex) there will be a hard edge on the model even though it was set to soft in Maya. In case you don't understand what I mean by a "hard edge" (I think this may be maya specific terminology) it is basically describing whether the shading smooths over an edge or not. What I understand it to mean in technical terms is that in a "soft" edge, the vertex normals for the edge are tangent to the two faces which meet at that edge whereas in a "hard" edge each vertex normal points in the same direction as the face normal (...sorry... I did say I'm an artist didn't I? ).

So that's the problem. I have some questions that would help me work out what is going wrong if anyone would be kind enough to help.

1. Does anyone know exactly what the option "geometric tangents" does in the Collada exporter? I suspect this may be to pre-compute tangents to be used for normal mapping but I was thinking that there's a chance it could help solve my problem. However, I can't try this because exporting a model with this option or "texture tangents" checked will crash the horde converter.

2. Is it possible that either in the process of converting to Collada or in converting to Horde format vertices are added to ensure that for every UV there is one vertex? (I ask because I've heard this happens in the Unreal3 engine) If this is the case then is there a way to normalize the vertex normals across the offending edge?

I'm at a bit of loss here so any clues would be greatly appreciated.

I've got a screenshot to try and show the problem:



As you can see, there's an odd seam over the character's head which creates this "hard edge" problem.
[edit]
Image changed to show comparision between engine and Maya... trust an artist to do a better graphical job

If I remember correctly the Collada Converter does recalculate the normals and tangets itself based on the vertice order. But I'm not sure. Maybe there is a bug inside the calculation method.

There was a fix concerning this problem some time ago. Are you using the SVN version or the official release package?

I've been having a play about to see if I can get more of an idea what's going on. I've tried exporting and re-importing to maya to check what effect the "geometric tangents" flag has in the ColladaMaya exporter. My tests seem to prove that "geometric tangents" is definitely NOT the issue as with or without the flag the model always imported back into Maya with the correct normals.

I have also had a look at the Horde demos to check if this issue was present in them and it seems that it is. I checked both the Knight demo and the crowd rendering demo and in places where I would expect texture seams on the models, the edges are always "hard".

Like I said, I'm primarily an artist and have very little knowledge of the internal workings of the converter but I think that the problem is as I suggested in question 2 of my first post. That is: vertex normals on edges which correspond to UV seams are not normalized (to produce soft shading across the edge) when the model is run through the converter.

Does anyone have any ideas about how this issue might be addressed?


EDIT: Volker, Stuckie has gone home for the night now but I'll ask tomorrow morning whether he has the SVN version of the converter at the moment (I suspect we may not but I'll need to check with Stuckie). Thanks for the reply so far though

You could also try if the -noopt option of the converter may also solve the problem

I've tried with the no optimisation flag in our current version of the converter with no luck.

I'll try this again with the build from SVN in the morning probably though.

Thanks for the suggestions

We got the converter off svn this morning and the problem seems like it's fixed (both with and without the -noopt flag worked fine)

Thanks for that.

This does mean that Stuckie is now going to have to add the stuff for pulling our custom physics attributes out into lua script back into the new version of the converter... but my problems are solved