6 replies to this topic

[rincewind]

Hi,

I thought I would also start writing about what I'm currently doing on the project. Hopefully I can keep the updates coming steadily and not as technical as this one.

Here we go:

just had a pretty long discussion with guyver6 on how to fix the artifacts and seams on the globe when using the bumpmapping. We think we found a solution, it will require some modification to the icosahedron-tool so we haven't tried it yet.
Here's why it looks messed up and you get artifacts in the non-technical explanation:
Basicly, the problem is that the in order to evenly apply the texture to the globe, the icosahedron mapping mirrors parts of it in the texture images and mirrors it back when applying the texture. This works well for the usual earth texture but not for the normal map. In short, the normals get messed up and you can see this when a mirrored and a non-mirrored texture meet (the seams).

For those more into graphics programming who want to get all the details, here it is (this section is not a must read, so if you get bored or don't understand a word of this geek-talk, just skip it )
As already stated, the icosahedron-mapping assigns some more or less weird uv-coordinates to the vertices in order to apply the texture evenly across the globe. The texture-image is being streched, rotated and mirrored so that it works with those coordinates.
The bumpmapping in the shaders works by transforming all lighting parameters into tangent-space and then using the normal from the normalmap together with the transformed parameters to produce the lighting result (the normal already being in surface-local or tangent-space).
Tangent space is constructed from the vertex normals and tangents. The tangents get calculated by Ogre from the uv-coordinates of the vertices.

The following problem arises now: The tangent space is calculated from the icosahedron-mapping coordinates and the shader assumes that the normals from the normalmap are also in this space. But as those normals have been created for a spherical mapping, they are in tangent-space for a sphere (or also a plane pointing straight up).

So, what we are now trying to do is create a proper tangent for spherical mapping together with the uv's for icosahedron-mapping in the icosahedron preprocessor.

So long,

Rincewind

Edited by rincewind, 07 January 2005 - 01:08 PM.

[mamutas]

I am still a novice to 3D programming, and I hope I understood your problem explanation well.
I was thinking a bit about it, and I am curious, if the problem will decrease its appeareance or go away completely, if the number icosahedron will be increased? You know, so it is closer to the sphere shape?

*Note: I know it is your thread and I am not supposed to post here. Feel free to delete it, but answer first, please.

[rincewind]

I am still a novice to 3D programming, and I hope I understood your problem explanation well.
I was thinking a bit about it, and I am curious, if the problem will decrease its appeareance or go away completely, if the number icosahedron will be increased? You know, so it is closer to the sphere shape?

*Note: I know it is your thread and I am not supposed to post here. Feel free to delete it, but answer first, please.

<{POST_SNAPBACK}>

I'll just use the reply to post a log-update as well. More discussion in the globe thread in programming though, please.

Here's the update:
So yes, implementing this stuff helped, but not in the seams in the GL render but on the triangles shining through in the Dx render.
Also, I had a stupid mistake in how the shaders did the specular and fixed that. Specular should now work correctly.

So here's the answer:
Tesselating the icosahedron more will not help this problem. We could probably even go with the very coarse mesh and still get the same result. This works because we are simply interpolating the vertex normals (and renormalizing them) which makes them change smoothly so we get teh sphere appearance. If you take a look at the old renders without bumpmapping or earth texture that are posted in the globe-thread you can see that it looks like a perfect sphere without the triangles appearing.
If you have more questions, feel also free to contact me on ICQ.

Grettings, Rincewind

Edited by rincewind, 03 January 2005 - 01:51 AM.

[rincewind]

Todays summary:

- Beetle fixed the scrollbar for the XNet-Texts. Now there's also a nice little thumb to move the text.

- Vaaish got us a new cursor, take a look.

- Looks like programming department still has lots of cleanup to do before the release. Fixing memory leaks and adding proper error handling and logging will have to be tackled.
Edit: at least I got the startscreen plus the GUI-Framework leak-free now (at least thats what Ogre's MemoryManager is telling me). More work to come though...

- I cleaned up up the shader code and tested if the other techniques for older cards work as expected. Somehow, the Radeon 8500 (and 92xx) path still has issues under OpenGL. The colors look very much "washed out". No idea why. DirectX works fine, it's even the same shader code. Ogre translates to DirectX pixel shader assembly to the proper OpenGL calls. I guess for now, thats just the way it is. We'll probably set the release to DirectX renderer anyway as that seems to be better supported in Ogre right now.
Still looking for someone to confirm that it works under OpenGL with a Geforce 3/4 (not MX) card as I can't test that path here (please post any findings in the globe-thread in the programming forum). Thanks

- mamutas posted some more artefacts on the poles. for the OpenGL-path in the globe-thread in the programming forum. While not as visible there are also issues in the DirectX version there. Basicly the tangent generation is failing there (again). So we will have to find a workaround for those special cases.

Thats it for today,

Rincewind

Edited by rincewind, 06 January 2005 - 05:19 PM.

[rincewind]

Todays update:

- fixed memory leaks for XNet and Planetscape. No more errors in OgreLeaks.log. There's still some being reported by the Microsoft leak detection but I think they are false positives caused by some interference between Ogre's Memory Manager and the one from CRT.

- guiver6 has had an interesting thought about the OpenGl problems and how to avoid them. So hopefully that should be fixed soon, too.

- Micah reported error on the DirectX path for the Globe on his Geforce 4. Actually it crashed to a bluescreen. Investigation is pending....

[rincewind]

- Programming Department has a new member: Beetle has been promoted to Xenocide Member. Congratulations Beetle

- The internal testing release has brought with it loads of graphical issues, some of them only appearing on OpenGL, some of them under DirectX, so there's lots of debugging ahead...

[rincewind]

- We have a new public release, hopefully this will get us a lot of new recruits and also let the project keep it's current momentum

- meanwhile development is going on:

- guiver6 is working on an ingame-console that should ease debugging and testing of GUI features, gameplay, etc.

- Beetle is working on getting audio-playback to work (this should give us finally the entire alpah 4 feature-set plus all that we added since then)

- I'm currently moving the GUI system's state handling to boost::fsm, as our current implementation (yakeState) is no longer maintained and also not suitable for our requirements anymore. The new system will for example feature automatic fade-in/-out background-music per screen and a lot less coding for people implementing new screens or dialogs.

- Additionally, I'm doing some research on writing a converter form dotXSI format to Ogre's format. This would allow us to use Softimage's free modtool as modeller for our art department.

Edited by rincewind, 18 January 2005 - 07:50 AM.