After a nerve wrecking couple of weeks, the school administration finally accepted my choice of B.S. thesis. Though originally there wouldn't be a problem, since the project was listed as available projects for the B.S., the doubt surfaced when I was the only one showing any interest in the project (and they do prefer group work).

Due to what the school said was an extra effort and interest in the field by me during the last semester, they accepted it. Hurray!

The project actually started last semester when we had an introductory course in OpenGL. Our last assignment was to create a simmulation of our Solar System. Quickly running out of things to implement from the assignment paper, I started to implement additional features, and this was noticed, thankfully.

Every year the school writes an article about a project that stands out, and use it for promotion. Lucky me, they chose my project!


Note that some last minute features was photoshopped in (the text that is)

Right now I'm in a stage where I'm collecting information and articles that might be of interest to the assignment, and if anyone has any tips to come with, I'd be greatful!

Whether I'll be using Ogre3D or Coin3D is difficult to tell at this point. The school contacted SGI about OpenGL Performer too, but I don't have my hopes high that this will work out.

Myself I would prefer to go with Ogre3D at this point I think, generally because of it's community and the rich feature-set. Coin3D doesn't have shader language support integrated, though I'm sure it wouldn't be too hard to implement. My school has a really good conversation going with SIM though, the creators behind Coin3D, and with future job search in mind, going with Coin3D might give me an advantage... currently I'm of the mindset that either I work with Ogre3D or Coin3D won't really matter that much though, since they are both object oriented and using scene graphs. That's only a fraction of what makes a rendering engine of course, but if I'm familiar with working in such an environment through one engine, adopting to another similar one should be smooth as butter.

I'll need double precision coordinates and move scene to camera space before rendering (which I have already managed to implement in Ogre3D).

I'll do the cube to sphere trick for planets and moons, and will be looking for a good LOD algorithm to add detail to the sphere as I get closer. I do not plan to go into the atmosphere though, so no need for any heightmap-deformation of terrain. Thus I plan on going with a sphere lodding technique that eventually becomes a billboard until it's too far away to be rendered at all. Any tip on which LOD technique would be practical is received in grattitude. I'm not sure if I'll need anything fancy at all, since I'm not deforming terrain... but I want something efficient so that I can spend processing on other details too.

I've already looked a bit on Atmospheric Scattering, both in GPU Gems 2 and Texturing and Modelling: A Procedural Approach, as well as on the net (been a couple of good discussions here on the gamedev forum too). I think I'll be going with the Sean O'Neil way.

Thanks to Flavien's ultimate collection of links related to space, I've got the elliptic formula covered in 3D. Currently I have it implemented in 2D using the formula presented on wikipedia.

I also hope to be able to make procedural cloud textures using multifractals for earth and venus, though time will tell if the schedule will be big enough for me to do so. Again Texturing and Modelling: A Procedural Approach has some really good examples which has made me quite confident that I'll be able to make these.

Here is how the project looks like right now (using Irrlicht engine):