Caelum - [WARNING: Screenshot intensive]

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Post Reply
User avatar
Rusty6800
Gnoblar
Posts: 17
Joined: Tue Jun 12, 2007 10:01 pm

Post by Rusty6800 » Thu Sep 04, 2008 5:24 pm

cdleonard wrote:Caelum uses directional lights and those are tough for texture-based shadows. PSSM is claimed to work well; but other techniques should also work.

Caelum's components should not cast shadows. Try cutting out components one by one; maybe you can then isolate the problem?

I've been meaning to add shadows to Caelum's demos for a long time but never got around to doing it.
Ok, I've made a bit of progress. I'm setting up the shadows AFTER Caelum is created. This seems to fix most problems, i'm not using stencil shadows.. One problem I've got now; if the camera moves through the world too fast, the sky "flickers". Think this might have something to do with the shadows. I've tried removing some of the components but it doesn't make any difference. Any ideas?
0 x
Developer of Simufarm, proudly powered by Ogre3d!

User avatar
cdleonard
Goblin
Posts: 266
Joined: Thu May 31, 2007 9:45 am

Post by cdleonard » Sat Sep 06, 2008 8:15 pm

Rusty6800 wrote:Ok, I've made a bit of progress. I'm setting up the shadows AFTER Caelum is created. This seems to fix most problems, i'm not using stencil shadows.. One problem I've got now; if the camera moves through the world too fast, the sky "flickers". Think this might have something to do with the shadows. I've tried removing some of the components but it doesn't make any difference. Any ideas?
Yes; updates are probably broken somehow. I wrote a longer explanation of updating Caelum here. Flickering is probably caused by either moving the camera after CaelumSystem::notifyCameraChanged or using compositors.
0 x

Faxnico
Gnoblar
Posts: 21
Joined: Thu Sep 04, 2008 4:55 pm

Post by Faxnico » Sun Sep 07, 2008 9:31 am

Hello.

First of all congratulations for the excellent work done so far (and sorry for my bad english).
I was able to compile the 0.3.0 demo and it impressed me quite a lot.
So I took the decision to replace my ugly skydome with the last Caelum version from the SVN.
Sadly I'm experiencing some troubles including it into my Shoggoth-based project.

But before going through my problems, I'd like to understand if I did a right choice.
I've to render a pretty huge and populated static geometry terrain, also 250km long (scale 1m=100), then I've up to 200 animated actors running on the scene.
No shaders at the moment, but when I'll have more knowledges (I'm a newbie about games programming) on the subject, I plan to add some simple ones.
First question then... wouldn't the Caelum inclusion into such a "delicate context" result in a perfomances disaster?

Now, talking about my troubles... the app (debug build, not tested release one) crashes with an Ogre::RenderingAPIException on calling root->renderOneFrame() in my manual rendering loop.

This is the log file:
09:57:18: Creating resource group General
09:57:18: Creating resource group Internal
09:57:18: Creating resource group Autodetect
09:57:18: SceneManagerFactory for type 'DefaultSceneManager' registered.
09:57:18: Registering ResourceManager for type Material
09:57:18: Registering ResourceManager for type Mesh
09:57:18: Registering ResourceManager for type Skeleton
09:57:18: MovableObjectFactory for type 'ParticleSystem' registered.
09:57:18: OverlayElementFactory for type Panel registered.
09:57:18: OverlayElementFactory for type BorderPanel registered.
09:57:18: OverlayElementFactory for type TextArea registered.
09:57:18: Registering ResourceManager for type Font
09:57:18: ArchiveFactory for archive type FileSystem registered.
09:57:18: ArchiveFactory for archive type Zip registered.
09:57:18: FreeImage version: 3.10.0
09:57:18: This program uses FreeImage, a free, open source image library supporting all common bitmap formats. See http://freeimage.sourceforge.net for details
09:57:18: Supported formats: bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi,exr,j2k,j2c,jp2
09:57:18: DDS codec registering
09:57:18: Registering ResourceManager for type HighLevelGpuProgram
09:57:18: Registering ResourceManager for type Compositor
09:57:18: MovableObjectFactory for type 'Entity' registered.
09:57:18: MovableObjectFactory for type 'Light' registered.
09:57:18: MovableObjectFactory for type 'BillboardSet' registered.
09:57:18: MovableObjectFactory for type 'ManualObject' registered.
09:57:18: MovableObjectFactory for type 'BillboardChain' registered.
09:57:18: MovableObjectFactory for type 'RibbonTrail' registered.
09:57:18: *-*-* OGRE Initialising
09:57:18: *-*-* Version 1.6.0RC1 (Shoggoth)
09:57:18: Loading library RenderSystem_Direct3D9_d
09:57:18: Installing plugin: D3D9 RenderSystem
09:57:18: D3D9 : Direct3D9 Rendering Subsystem created.
09:57:18: D3D9: Driver Detection Starts
09:57:18: D3D9: Driver Detection Ends
09:57:18: Plugin successfully installed
09:57:18: Loading library RenderSystem_GL_d
09:57:18: Installing plugin: GL RenderSystem
09:57:18: OpenGL Rendering Subsystem created.
09:57:18: Plugin successfully installed
09:57:18: Loading library Plugin_OctreeSceneManager_d
09:57:18: Installing plugin: Octree & Terrain Scene Manager
09:57:18: Plugin successfully installed
09:57:18: Loading library Plugin_CgProgramManager_d
09:57:18: Installing plugin: Cg Program Manager
09:57:18: Plugin successfully installed
09:57:18: Loading library Plugin_ParticleFX_d
09:57:18: Installing plugin: ParticleFX
09:57:18: Particle Emitter Type 'Point' registered
09:57:18: Particle Emitter Type 'Box' registered
09:57:18: Particle Emitter Type 'Ellipsoid' registered
09:57:18: Particle Emitter Type 'Cylinder' registered
09:57:18: Particle Emitter Type 'Ring' registered
09:57:18: Particle Emitter Type 'HollowEllipsoid' registered
09:57:18: Particle Affector Type 'LinearForce' registered
09:57:18: Particle Affector Type 'ColourFader' registered
09:57:18: Particle Affector Type 'ColourFader2' registered
09:57:18: Particle Affector Type 'ColourImage' registered
09:57:18: Particle Affector Type 'ColourInterpolator' registered
09:57:18: Particle Affector Type 'Scaler' registered
09:57:18: Particle Affector Type 'Rotator' registered
09:57:18: Particle Affector Type 'DirectionRandomiser' registered
09:57:18: Particle Affector Type 'DeflectorPlane' registered
09:57:18: Plugin successfully installed
09:57:18: CPU Identifier & Features
09:57:18: -------------------------
09:57:18: * CPU ID: AuthenticAMD: AMD Athlon(tm) 64 Processor 3500+
09:57:18: * SSE: yes
09:57:18: * SSE2: yes
09:57:18: * SSE3: yes
09:57:18: * MMX: yes
09:57:18: * MMXEXT: yes
09:57:18: * 3DNOW: yes
09:57:18: * 3DNOWEXT: yes
09:57:18: * CMOV: yes
09:57:18: * TSC: yes
09:57:18: * FPU: yes
09:57:18: * PRO: yes
09:57:18: * HT: no
09:57:18: -------------------------
09:57:18: D3D9 : Subsystem Initialising
09:57:18: D3D9RenderSystem::_createRenderWindow "Eurotour 2", 800x600 fullscreen miscParams: FSAA=0 FSAAQuality=0 colourDepth=32 gamma=false useNVPerfHUD=false vsync=true
09:57:18: D3D9 : Created D3D9 Rendering Window 'Eurotour 2' : 800x600, 32bpp
09:57:19: Registering ResourceManager for type Texture
09:57:19: Registering ResourceManager for type GpuProgram
09:57:19: D3D9: Vertex texture format supported - PF_FLOAT16_RGB
09:57:19: D3D9: Vertex texture format supported - PF_FLOAT16_RGBA
09:57:19: D3D9: Vertex texture format supported - PF_FLOAT32_RGB
09:57:19: D3D9: Vertex texture format supported - PF_FLOAT32_RGBA
09:57:19: D3D9: Vertex texture format supported - PF_FLOAT16_R
09:57:19: D3D9: Vertex texture format supported - PF_FLOAT32_R
09:57:19: D3D9: Vertex texture format supported - PF_FLOAT16_GR
09:57:19: D3D9: Vertex texture format supported - PF_FLOAT32_GR
09:57:19: RenderSystem capabilities
09:57:19: -------------------------
09:57:19: RenderSystem Name: Direct3D9 Rendering Subsystem
09:57:19: GPU Vendor: nvidia
09:57:19: Device Name: NVIDIA GeForce 9600 GT
09:57:19: Driver Version: 6.14.11.7519
09:57:19: * Fixed function pipeline: yes
09:57:19: * Hardware generation of mipmaps: yes
09:57:19: * Texture blending: yes
09:57:19: * Anisotropic texture filtering: yes
09:57:19: * Dot product texture operation: yes
09:57:19: * Cube mapping: yes
09:57:19: * Hardware stencil buffer: yes
09:57:19: - Stencil depth: 8
09:57:19: - Two sided stencil support: yes
09:57:19: - Wrap stencil values: yes
09:57:19: * Hardware vertex / index buffers: yes
09:57:19: * Vertex programs: yes
09:57:19: * Fragment programs: yes
09:57:19: * Geometry programs: no
09:57:19: * Supported Shader Profiles: hlsl ps_1_1 ps_1_2 ps_1_3 ps_1_4 ps_2_0 ps_2_a ps_2_b ps_2_x ps_3_0 vs_1_1 vs_2_0 vs_2_a vs_2_x vs_3_0
09:57:19: * Texture Compression: yes
09:57:19: - DXT: yes
09:57:19: - VTC: no
09:57:19: * Scissor Rectangle: yes
09:57:19: * Hardware Occlusion Query: yes
09:57:19: * User clip planes: yes
09:57:19: * VET_UBYTE4 vertex element type: yes
09:57:19: * Infinite far plane projection: yes
09:57:19: * Hardware render-to-texture: yes
09:57:19: * Floating point textures: yes
09:57:19: * Non-power-of-two textures: yes
09:57:19: * Volume textures: yes
09:57:19: * Multiple Render Targets: 4
09:57:19: - With different bit depths: yes
09:57:19: * Point Sprites: yes
09:57:19: * Extended point parameters: yes
09:57:19: * Max Point Size: 8192
09:57:19: * Vertex texture fetch: yes
09:57:19: - Max vertex textures: 4
09:57:19: - Vertex textures shared: no
09:57:19: * Render to Vertex Buffer : no
09:57:19: * DirectX per stage constants: yes
09:57:19: ***************************************
09:57:19: *** D3D9 : Subsystem Initialised OK ***
09:57:19: ***************************************
09:57:19: ResourceBackgroundQueue - threading disabled
09:57:19: Particle Renderer Type 'billboard' registered
09:57:19: SceneManagerFactory for type 'OctreeSceneManager' registered.
09:57:19: SceneManagerFactory for type 'TerrainSceneManager' registered.
09:57:19: !!! Direct3D Device Lost!
09:57:27: Creating resource group Textures
09:57:27: Added resource location 'gfx/textures' of type 'FileSystem' to resource group 'Textures'
09:57:27: Initialising resource group Textures
09:57:27: Parsing scripts for resource group Textures
09:57:27: Finished parsing scripts for resource group Textures
09:57:27: Creating resource group Caelum
09:57:27: Added resource location 'gfx/caelum' of type 'FileSystem' to resource group 'Caelum'
09:57:27: Creating resource group TerrMeshes
09:57:27: Added resource location 'gfx/geometries' of type 'FileSystem' to resource group 'TerrMeshes'
09:57:27: Creating resource group TerrMaterials
09:57:27: Added resource location 'gfx/geometries/materials' of type 'FileSystem' to resource group 'TerrMaterials'
09:57:27: Initialising resource group Caelum
09:57:27: Parsing scripts for resource group Caelum
09:57:27: Parsing script GroundFog.program
09:57:27: Parsing script Haze.program
09:57:27: Parsing script MinimalCompositorVP.program
09:57:27: Parsing script DepthComposer.material
09:57:27: Parsing script GroundFog.material
09:57:27: Parsing script LayeredClouds.material
09:57:27: Compiler error: unknown error in LayeredClouds.material(78): token "paran_named" is not recognized
09:57:27: Parsing script moon.material
09:57:27: Parsing script PointStarfield.material
09:57:28: Parsing script Precipitation.material
09:57:28: Parsing script SkyDome.material
09:57:28: Parsing script Starfield.material
09:57:28: Parsing script Sun.material
09:57:28: Parsing script DepthComposer.compositor
09:57:28: Parsing script Precipitation.compositor
09:57:28: Finished parsing scripts for resource group Caelum
09:57:28: Initialising resource group TerrMeshes
09:57:28: Parsing scripts for resource group TerrMeshes
09:57:28: Finished parsing scripts for resource group TerrMeshes
09:57:28: Initialising resource group TerrMaterials
09:57:28: Parsing scripts for resource group TerrMaterials
09:57:28: Parsing script ...
09:57:28: Finished parsing scripts for resource group TerrMaterials
09:57:28: TerrainSceneManager: Registered a new PageSource for type Heightmap
09:57:29: Mesh: Loading ... .mesh.
09:57:44: Caelum: Initialising Caelum system...
09:57:44: Caelum: Creating caelum sub-components.
09:57:44: Texture: EarthClearSky2.png: Loading 1 faces(PF_A8R8G8B8,64x64x1) with 0 generated mipmaps from Image. Internal format is PF_A8R8G8B8,64x64x1.
09:57:44: Texture: AtmosphereDepth.png: Loading 1 faces(PF_R8G8B8,32x1x1) with hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,32x1x1.
09:57:44: Caelum: Creating CaelumSphericDome sphere mesh resource...
09:57:44: Caelum: generateSphericDome DONE
09:57:44: Texture: sun_disc.png: Loading 1 faces(PF_A8R8G8B8,128x128x1) with 0 generated mipmaps from Image. Internal format is PF_A8R8G8B8,128x128x1.
09:57:44: D3D9 : Loading 2D Texture, image name : 'moon_disc.dds' with 2147483647 mip map levels
09:57:44: D3D9 : Loading 2D Texture, image name : 'noise1.dds' with 2147483647 mip map levels
09:57:44: D3D9 : Loading 2D Texture, image name : 'noise2.dds' with 2147483647 mip map levels
09:57:44: D3D9 : Loading 2D Texture, image name : 'noise4.dds' with 2147483647 mip map levels
09:57:44: Caelum: DONE initializing
09:57:44: Creating resource group ...
09:57:48: Caelum: Recomputing starfield geometry.
09:57:57: D3D9TextureManager released:
09:57:57: 0 unmanaged textures
09:57:57: D3D9HardwareBufferManager released:
09:57:57: 0 unmanaged vertex buffers
09:57:57: 0 unmanaged index buffers
09:57:57: Reset device ok w:800 h:600
09:57:57: !!! Direct3D Device Lost!
09:57:57: D3D9TextureManager recreated:
09:57:57: 0 unmanaged textures
09:57:57: D3D9HardwareBufferManager recreated:
09:57:57: 0 unmanaged vertex buffers
09:57:57: 0 unmanaged index buffers
09:57:57: !!! Direct3D Device successfully restored.
09:57:57: OGRE EXCEPTION(3:RenderingAPIException): Failed to DrawPrimitive : An undetermined error occurred in D3D9RenderSystem::_render at f:\codingextra\ogre\shoggoth_vc8\ogre\rendersystems\direct3d9\src\ogred3d9rendersystem.cpp (line 2908)
And a short summary on how I setup everything that could be related to Caelum:

Code: Select all

- LoadPlugin : RenderSystem_Direct3D9_d, Plugin_OctreeSceneManager_d, Plugin_CgProgramManager_d, Plugin_ParticleFX_d (is it needed?)
- RenderSystem : Direct3D9 Rendering Subsystem
- rgm->addResourceLocation("gfx/caelum", "FileSystem", Caelum::RESOURCE_GROUP_NAME);
- rgm->initialiseResourceGroup(Caelum::RESOURCE_GROUP_NAME);
- Create TerrainSceneManager
- Fill and build Static Geometry (Terrain)
- m_CaelumSystem = new Caelum::CaelumSystem(root, sceneMgr, Caelum::CaelumSystem::CAELUM_COMPONENTS_DEFAULT);
- Create Camera
- Create Actors
- Init AI
- Render Loop :
  - m_CaelumSystem->updateSubcomponents(elapsedTime); (in msecs?)
  - Update AI
  - Update Actors
  - Update Camera
  - root->renderOneFrame()
  - Ogre::WindowEventUtilities::messagePump();
- Cleaning operations
Any help is welcome.

Thank you in advance.
Nicolò
0 x

User avatar
Zeal
Ogre Magi
Posts: 1260
Joined: Mon Aug 07, 2006 6:16 am
Location: Colorado Springs, CO USA

Post by Zeal » Sun Sep 07, 2008 8:31 pm

I read your paper, and I really like the simplicity of this technique. I have not had much luck with 'real' atmospheric scattering shaders, they are just too hard to tweak, so I would LOVE to be able to use something like this. However, my terrain is spherical, is there anyway to adapt things to work with a spherical terrain? How would things look if rendered from OUTSIDE the atmosphere?
0 x

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 1
Contact:

Post by Kencho » Sun Sep 07, 2008 8:45 pm

Uhhh, this method was designed mainly to "locally" rendered scenes. I mean, placed on the surface in a relatively large planet. As for scenes viewed from the space... I'm guessing a different yet similar approach might be used. I would make the gradients map a 3D texture, taking the inputs as height from the surface, and two angles, probably the sun incidence angle and the camera angle relative to the planet and the sunlight... Just some quick guess though :|
0 x
Image

User avatar
Zeal
Ogre Magi
Posts: 1260
Joined: Mon Aug 07, 2006 6:16 am
Location: Colorado Springs, CO USA

Post by Zeal » Sun Sep 07, 2008 10:31 pm

I would make the gradients map a 3D texture
Hrmm I just cant visualize what the texture would like like. Would each slice look like the traditional 2d gradient map? What would change between slices? And then how could you use the 'distance from surface' and 'camera to sun angle' to lookup values in this texture?

I hope it is possible.. I would really love to be able to use a 'texture/lookup' style technique, since I have had such rotten luck with other methods.
0 x

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 1
Contact:

Post by Kencho » Sun Sep 07, 2008 11:28 pm

The point is that, when viewed from space, there's no "local time" variable in the game. Instead, you have a different variable. Imagine watching the planet from a top down view. One side of the planet is lit, the other isn't. Speaking in latitude/longitude, you'd see the direct relationship between local time and longitude. So 180 degrees are daytime and 180 degrees are nighttime. It's sort of what the gradients map looks like. However, if you look from the sun position, everything is lit, and thus the whole atmosphere is rendered like in daytime. It's kind of hard to explain. I'm visualizing the concept in my mind, but can't express in words :(
0 x
Image

User avatar
Zeal
Ogre Magi
Posts: 1260
Joined: Mon Aug 07, 2006 6:16 am
Location: Colorado Springs, CO USA

Post by Zeal » Sun Sep 07, 2008 11:52 pm

Hrmm I think I can 'see' what youre getting at.. So visualizing a top down view of the planet (looking down on the north pole), while the sun orbits around the equator... you can map the 'time of day' scale to the suns angle. I suppose maybe you could construct a volume gradient texture for this (still cant quite visualize it though).. and I am still a little confused as to how to do the lookups..

You sound pretty confident its possible (I am glad). Have you actually tried imlementing something like this before?
0 x

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 1
Contact:

Post by Kencho » Mon Sep 08, 2008 12:00 am

Actually... not. All this is just a quick'n'dirty thought on this issue. Maybe I could try an implementation in a couple weeks or so, when I can get more spare time.

But yes, I'm confident this is realizable indeed :)
0 x
Image

User avatar
Zeal
Ogre Magi
Posts: 1260
Joined: Mon Aug 07, 2006 6:16 am
Location: Colorado Springs, CO USA

Post by Zeal » Mon Sep 08, 2008 12:58 am

But yes, I'm confident this is realizable indeed
Wohoo your confidence inspires me! I will try and run some tests this week.

I will let you know how it goes.
0 x

Penut
Gnoblar
Posts: 14
Joined: Fri Jul 11, 2008 3:09 am

Post by Penut » Tue Sep 09, 2008 11:10 am

alright, finally got it working :D...thanks for the suggestions!

now if I render nothing but caelum I get 28000+ polys rendering at on avg 40fps. Soon as I add the model ninja from the examples my frame rate drops down to 13-14 fps (33000+ polycount)

Any tips on optimizing?
0 x

User avatar
Zeal
Ogre Magi
Posts: 1260
Joined: Mon Aug 07, 2006 6:16 am
Location: Colorado Springs, CO USA

Post by Zeal » Tue Sep 09, 2008 2:56 pm

Ok here is what I have got so far (in regards to mapping the gradient texture to a sphere)...

*The mapping in the picture is a little off, the top of the sphere should map to the 'noon collum' of the texture. You get the idea though...
Image

We first start with a inside out sphere, this is our atmosphere. Then we map the gradient texture to the sphere assuming the sun is directly above the sphere (see picture). So the x axis on the texture represets the color of the atmosphere at the 'top' (assuming the camera is directly below it). Remember at this point we only care about mapping the top row of the texture to the y axis on the sphere, this one thin strip will wrap around the entire sphere symetrically.

When the sun moves, you can scroll the x axis by taking the dot product of the up vector (0,1,0) and the sun. This would tell you how much to scroll along the x axis. This assumes the sun stays on the xy plane, if it leaves the xy plane you would also need to rotate the sphere mesh.

So if you imagine standing on the surface of a planet with the sun directly above you (as in the picture) you would see the correct color if you looked straight up (at the sun), but you would NOT see any gradient towards the horizon. This is where the y axis on the texture comes in. The y axis on the texture represents thickness, or in otherwords how the color changes based on the distance light travels through the atmosphere. So by calculating the distance from the eye to the sphere, you can calculate a 'thickness' of the atmosphere, and scroll the y axis accordingly (giving you the correct gradients along the horizon).


The gradient texture would have to be modified slightly (made taller) so the alpha fades to 0 at the top (so when viewed from space the atmosphere would fade out along the edges).

There is also a problem with sunrise/sunset - since the mapping is symetrical, youll get the same colors at dusk/dawn. This makes sense, since when you think about it the atmosphere is the same thickness in both cases, so why are the colors different in real life? The answer is (correct me if I am wrong) temperature. When the sun sets the atmosphere is warm, so you get bright oranges/reds. When the sun rises, the atmosphere is cool, so you get different colors. I THINK I could simulate this by mapping some kind of 'temperature' texture to the sphere, and using it to blend between two gradient textures (one hot, one cool)...

Would appreciate any feedback!
0 x

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 1
Contact:

Post by Kencho » Tue Sep 09, 2008 9:20 pm

Most of what you say here is basically what I was thinking :) Just some notes/thoughts.

The geometry to render the atmosphere as seen from the space should be a ring, always oriented to the camera (sort of a billboard) and centered in the planet center. Think of it as glow geometry. The inner radius would be the planet radius, and the outer radius would be the atmosphere's radius.

Regarding the map, I would use a different map for this case. Firstly, because of the decreasing atmosphere density. Secondly, because the gradients map used in the surface reflects effects like in/out scattering, that behave differently when viewed from outside (as a quick draft this map might work with some changes though). And lastly, because there should be effects like the earth shadow cast on the atmosphere when viewed from the space.

As for the different colour at sunrise/sunset, I'm not an expert, but I think it's related not to temperature (or not very directly), but to air composition. At sunset there's usually more humidity in the air, and thus the light is scattered differently. That's why the sunset colours cover a wider spectrum of tones than the sunrise's.

Hope that helps :)
0 x
Image

User avatar
Zeal
Ogre Magi
Posts: 1260
Joined: Mon Aug 07, 2006 6:16 am
Location: Colorado Springs, CO USA

Post by Zeal » Thu Sep 11, 2008 1:43 am

the atmosphere as seen from the space should be a ring
Seems like that would make it difficult to get smooth transitions from sphere to billboard. A insideout sphere has been working fine for me so far. If you map the texture like I described in the picture you DO get 'self shadowing' where the atmosphere appears black on the backside of the planet.

Everything works great in my initial tests. The only real problem I have is that I need a better gradient texture. Currently I am using the 'old' gradient texture and it is very difficult to map the y axis to 'atmosphere thickness'. Set the scale too low or too high and you wont get the desired gradients on the surface. I need a gradient texture that alpha fades to 0 at the top (0 thickness) and has a large range of colors to handle cases where you view the atmosphere from shallow angles (large thickness).

Here are a couple screenshots (the planet itself is missing, but you get the idea).

Image

Image

One nice thing is that at sunrise/sunset you dont have to do any extra work to darken the opposite side of the sky. Due to the way the texture is mapped, this is done for you already.

All in all I am pretty happy with the results, I just need a new gradient texture I think. Then it will just be a matter of tweaking the way it is sampled based on the thickness of the atmosphere.
0 x

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 1
Contact:

Post by Kencho » Thu Sep 11, 2008 9:17 am

Though I'm still supporting the idea of using a ring geometry, the results you got are really neat! Congratulations! :D
0 x
Image

User avatar
Zeal
Ogre Magi
Posts: 1260
Joined: Mon Aug 07, 2006 6:16 am
Location: Colorado Springs, CO USA

Post by Zeal » Thu Sep 11, 2008 3:11 pm

Well I am getting some minor errors relating to the atmospheres thickness. The problem is, the thickness calculations are done in the vertex shader, so the accuracey depends on the tesselaion of the mesh. I figure I could get more accurate results (at the cost of a slight performance hit) if I moved these calculations to the fragment shader. However I cant quite figure out how to do a proper 'ray to sphere' intersection calculation from inside the sphere. If your math is up to snuff, please take a look at this thread and help a brother out.

http://www.ogre3d.org/phpBB2/viewtopic. ... 805#304805

If I can get that working, then I was thinking about switching from a sphere, to a dome that always faces the camera (should result in a mesh thats half as complex). This way youll see a disk from outerspace, and a highly tesselated dome from inside the atmosphere.

I will look into rendering a billboard from outerspace instead of a sphere/dome. I still think it will be more trouble than its worth to get a seamless transition though.
0 x

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 1
Contact:

Post by Kencho » Thu Sep 11, 2008 3:15 pm

Yes, it's hard you achieve to make it seamless, though it's rather easy to get nice and good-looking results :)
0 x
Image

User avatar
Zeal
Ogre Magi
Posts: 1260
Joined: Mon Aug 07, 2006 6:16 am
Location: Colorado Springs, CO USA

Post by Zeal » Thu Sep 11, 2008 3:21 pm

I am sure the billboard itself will look fine, I am just worried about transitioning between the 3d sphere/dome and the billboard. Seems like there will be some popping.

But then again, if I can get that ray/sphere intersection calculation to work on the fragment level, maybe there wont be any popping at all...
0 x

User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 1
Contact:

Post by Kencho » Thu Sep 11, 2008 3:33 pm

You can take advantage of the existing Caelum sky dome, as it's already alpha-blended, and add an extra alpha factor to it so that it becomes more visible as you enter the atmosphere. Indeed, that factor can be calculated easily as Altitude = (CameraToPlanetCoreDistance - PlanetRadius) / (AtmosphereRadius - PlanetRadius).

...

Okay, now I see what you're talking about... The billboard popping when the camera flies through half the planet, right? Like flying from the south hemisphere to the north one. Then your method sounds quite fine to me. You've convinced me :)
0 x
Image

Faxnico
Gnoblar
Posts: 21
Joined: Thu Sep 04, 2008 4:55 pm

Post by Faxnico » Fri Sep 12, 2008 3:33 pm

Hello again...

I don't know why but I solved my problem by switching to Dx9 runtimes retail version.

I'd like to know now, if and how the Caelum's precipitation system works... a smart example would be welcome.

Thank you in advance.
Nicolò
0 x

nath31337
Kobold
Posts: 25
Joined: Sun Jul 27, 2008 2:42 am
Location: Canada

Post by nath31337 » Fri Sep 19, 2008 2:24 am

Hello, sorry for another noob question but, i cant get caelum to work, i got a pretty basic code that compiles but i get an error :

21:16:59: OGRE EXCEPTION(6:FileNotFoundException): Cannot locate resource EarthClearSky2.png in resource group Caelum or any other group. in ResourceGroupManager::openResource at ..\src\OgreResourceGroupManager.cpp (line 753)

i guess i need a resource group but i dont know, do i have to create something or i only need to copy the resources files somewhere?

Code: Select all

#include "ExampleApplication.h"
#include "Caelum.h"
using namespace Caelum;

class TutorialFrameListener : public ExampleFrameListener
{
public:

	Caelum::CaelumSystem *mCaelumSystem;

    TutorialFrameListener(RenderWindow* win, Camera* cam, SceneManager *sceneMgr)
        : ExampleFrameListener(win, cam, false, false)
    {
		mCaelumSystem = new Caelum::CaelumSystem (Root::getSingletonPtr(), sceneMgr, CaelumSystem::CAELUM_COMPONENTS_DEFAULT);
		mWindow->addListener (mCaelumSystem);
		Root::getSingletonPtr()->addFrameListener (mCaelumSystem);
    }

    bool frameStarted(const FrameEvent &evt)
    {
        return ExampleFrameListener::frameStarted(evt);
    }
};

class TutorialApplication : public ExampleApplication
{
public:
    TutorialApplication()
    {}

    ~TutorialApplication() 
    {}
protected:
    void chooseSceneManager(void)
    {
		mSceneMgr = mRoot->createSceneManager(ST_EXTERIOR_CLOSE);
    }
    void createScene(void)
    {
		mSceneMgr->setWorldGeometry("terrain.cfg");
    }
	void createFrameListener(void)
    {
		mFrameListener = new TutorialFrameListener(mWindow, mCamera, mSceneMgr);
        mRoot->addFrameListener(mFrameListener);
    }
};
0 x

nath31337
Kobold
Posts: 25
Joined: Sun Jul 27, 2008 2:42 am
Location: Canada

Post by nath31337 » Mon Sep 22, 2008 2:34 pm

i still didnt find it, im curious also about what faxnico is asking
0 x

User avatar
cdleonard
Goblin
Posts: 266
Joined: Thu May 31, 2007 9:45 am

Post by cdleonard » Mon Sep 22, 2008 2:50 pm

Sorry; I've been very busy. I should post here more often.

nath31337: You need to add Caelum's resources (main/resources from svn) in your ogre resource paths somehow. The group does not matter. Caelum will create it's own runtime resources in the hardcoded "Caelum" group but it can load stuff like EarthClearSky2.png from any group.

Faxnico: Yes; Direct3D debug runtime will complain about the skydome material. I have known about this for a while but I did not solve it.

Unrelated: I added PSSM shadows to CaelumLab (as long as you build with Ogre 1.6). If you're looking for a shadow example with Caelum this should work.

Caelum's demos still use Ogre's defaul TerrainSceneManager which does not seem to officially support shadows. I added a miserable hack to force it's internal TerrainRenderables to cast texture shadows but sometimes it seems to generate various artifacts.
0 x

User avatar
netskate
Greenskin
Posts: 120
Joined: Fri Sep 05, 2008 3:10 pm

Post by netskate » Mon Sep 22, 2008 5:07 pm

Hi, I know this will be surely a newbie question, but I had to ask for it.

I integrated caelum into my project, but the result is this:

ImageImage

Maybe I forgot something...

I use:
Ogre 1.4.9 sdk
caelum svn rev 327
0 x
-- N3tsk4t3 --

User avatar
cdleonard
Goblin
Posts: 266
Joined: Thu May 31, 2007 9:45 am

Post by cdleonard » Mon Sep 22, 2008 5:16 pm

netskate: Check for too much fogging? CaelumSystem's controls scene fog by default and it might be too intense. Try mCaelumSystem->setManageSceneFog(false).
0 x

Post Reply