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
er
Gnoblar
Posts: 17
Joined: Sun Aug 21, 2005 7:36 am
Location: Finland

Post by er »

Just tested new version with PLSM and modified preViewportUpdate() functions won't work (at least for me). Even if I use same setNearClipDistance(0.1).

So I'll stick with checks like this:

Code: Select all

mNode->setScale(Ogre::Vector3::UNIT_SCALE * ((cam->getFarClipDistance () == 0 ) ? 100000 : (cam->getFarClipDistance ()-0.2)));
btw 100000 is arbitrary value that OgreMain uses.

Azatoth have you tested Caelum with your client, any screenshots ?
User avatar
yzt
Halfling
Posts: 98
Joined: Wed Dec 28, 2005 7:43 am
x 2
Contact:

Problem with Shaders under Direct3D

Post by yzt »

I see other people have mentioned the same problem that I'm having with Direct3D render system and Caelum.
When using OpenGL, the program runs well enough. The only problem being the cracks in the sky. But with Direct3D 9, an exception is thrown at load time:

Code: Select all

An exception has been thrown!

-----------------------------------
Details:
-----------------------------------
Error #: -2005529767
Function: D3D9GpuProgram::loadFromSource
Description: Cannot assemble D3D9 shader LayeredCloudFP Errors:
(57): error X2005: invalid register 'r12'
(58): error X2005: invalid register 'r12'
(59): error X2005: invalid register 'r12'
(60): error X2005: invalid register 'r12'
(61): error X2005: invalid register 'r12'
(62): error X2005: invalid register 'r12'
(63): error X2005: invalid register 'r12'
(64): error X2005: invalid register 'r12'
(65): error X2005: invalid register 'r12'
(66): error X2005: invalid register 'r12'
(67): error X2005: invalid register 'r12'
(68): error X2005: invalid register 'r12'
(69): error X2005: invalid register 'r12'
(70): error X2005: invalid register 'r12'
(71): error X2005: invalid register 'r12'
(72): error X2005: invalid register 'r12'
(73): error X2005: invalid register 'r12'
(74): error X2005: invalid register 'r12'
(75): error X2005: invalid register 'r12'
(76): error X2005: invalid register 'r12'
(77): error X2005: invalid register 'r12'
(78): error X2005: invalid register 'r12'
(79): error X2005: invalid register 'r12'
(80): error X2005: invalid register 'r12'
. 
File: e:\projects\ogrecvs\branches\dagon_vc8_clean\ogrenew\rendersystems\direct3d9\src\ogred3d9gpuprogram.cpp
Line: 91
Stack unwinding: <<beginning of stack>>
For the record, I'm using Dagon SDK (1.2.3), Visual C++ 8.0 (non-Express,) Windows XP and a GeForce 7600 GS with recent drivers (91.47).

How can I fix this? I know almost nothing about debugging shaders, so _any_ pointers are welcome! Thanks.
Do not meddle in the affairs of Wizards, for they are subtle and quick to anger.
My useless rants
The company I work for (Dead Mage)
The first game we made (Garshasp: The Monster Slayer)
er
Gnoblar
Posts: 17
Joined: Sun Aug 21, 2005 7:36 am
Location: Finland

Post by er »

I commented out four last absorption addition lines from LayeredCloud.cg (lines 56-59) leaving only the first one and error changed to:

Code: Select all

Function: D3D9GpuProgram::loadFromSource
Description: Cannot assemble D3D9 shader LayeredCloudFP Errors:
(48): error X5775: Dependent tex-op sequence too long (4th order). A 1st order dependent tex-op is a tex[ld*|kill] instruction in which either: (1) an r# reg is input (NOT t# reg), or (2) output r# reg was previously written, now being written AGAIN. A 2nd order dependent tex-op occurs if: a tex-op reads OR WRITES to an r# reg whose contents, BEFORE executing the tex-op, depend (perhaps indirectly) on the outcome of a 1st order dependent tex-op. An (n)th order dependent tex-op derives from an (n-1)th order tex-op. A given tex-op may be dependent to at most 3rd order (ps_2_0/x only).
. 
Uncommenting more lines gives same error multiple times.

For ones who knows something about cg here is line that gives that error:

Code: Select all

absorption += clamp (tex2D (cloud, (uv + sunDirection * 0.2 + cloudOffset) * cloudInvScale) + tex2D (detail, (uv + sunDirection * 0.2 + detailOffset) * detailInvScale) - 1, 0, 1);
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

I told you that the cloud shader is experimental and a recovered version from a crash, and it might not work (indeed seems it doesn't work), so don't pay much attention to this...
Image
er
Gnoblar
Posts: 17
Joined: Sun Aug 21, 2005 7:36 am
Location: Finland

Post by er »

I was just curious as it works for OpenGL and fails with DX :)
User avatar
gerds
Goblin
Posts: 260
Joined: Mon Sep 01, 2003 3:59 am
Location: London, United Kingdom
x 1

Post by gerds »

Just wondering if you could please add "safe startup and shutdown" to the "to do" list.

I originally had problems running on some machines which didn't support the shader versions - which caused ogre to crash. If you delay registering the frame listener until the end of the constructor then the constructor can "throw" and "fail-safe" without crashing ogre.

I've tried myself to modify caelum to shut-down without crashing ogre but I can't get it worked out. I need to be able to start-up and shut-down caelum many times during execution. For example, start up on menu (without caelum), load level 1 (init caelum), select config menu (shutdown caelum), re-load level with different settings (init caelum again).

Thanks, keep up the good work :)
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

Okay gerds, write down your suggestion :)
Image
User avatar
gerds
Goblin
Posts: 260
Joined: Mon Sep 01, 2003 3:59 am
Location: London, United Kingdom
x 1

Post by gerds »

Oh, sorry I wasn't a bit clearer :oops:

What I require is:

- If the constructor fails (ie: throws an exception) that ogre can continue on fine (and not leak any memory). What I usually do is have the constructor just init everything to null pointers etc, and have an Initialise method that actually loads the shaders etc, and just returns false on failure. But its up to you as to how you do it ;)

- I need to be able to call delete on the CaelumSystem class and have it clean up everything ok. At the moment if I call delete on the CaelumSystem pointer ogre always crashes.

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

Post by Kencho »

Okay :) Haven't revisited this yet, so I'm pretty sure there's a lot of leaks and bugs here and there. I'll test it strongly as soon as I can :)
Image
User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
x 4
Contact:

Post by Azatoth »

er wrote:Azatoth have you tested Caelum with your client, any screenshots ?
I've integrated the caelum code into Ember. Some screenshots:
Image Image Image
Image Image Image

It's basically using the default media.
I've made some changes to caelum too. A diff:

Code: Select all

diff -U 3 -dHbrN -- /home/erik/ember/var/Caelum/include/CaelumPrerequisites.h ./include/CaelumPrerequisites.h
--- /home/erik/ember/var/Caelum/include/CaelumPrerequisites.h	2006-10-22 15:57:32.000000000 +0200
+++ ./include/CaelumPrerequisites.h	2006-11-06 23:47:49.000000000 +0100
@@ -2,18 +2,18 @@
 #define CAELUMPREREQUISITES_H
 
 // Include external headers
-#include "Ogre.h"
+#include <Ogre.h>
 
 // Define the dll export qualifier if compiling for Windows
-#ifdef OGRE_PLATFORM_WIN32
+#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
 	#define DllExport __declspec (dllexport)
 #else
 	#define DllExport
 #endif
 
 // Define the version code
-#define VERSION 0
-#define SUBVERSION 2
+#define CAELUM_VERSION 0
+#define CAELUM_SUBVERSION 2
 
 /* Set a global camera distances modifier for the clipping distance. 
    This threshold will be substracted from the far clipping distance if applicable, else it will be 
diff -U 3 -dHbrN -- /home/erik/ember/var/Caelum/include/Sun.h ./include/Sun.h
--- /home/erik/ember/var/Caelum/include/Sun.h	2006-10-10 21:50:12.000000000 +0200
+++ ./include/Sun.h	2006-11-05 23:10:31.000000000 +0100
@@ -93,12 +93,22 @@
 		 */
 		Ogre::ColourValue getSunColour ();
 
+		/** Gets the sun node.
+			@return The sun node.
+		 */
+		inline Ogre::SceneNode* getNode() const;
+
 	private:
 		/** Creates the sun material.
 		 */
 		void createSunMaterial ();
 };
 
+Ogre::SceneNode* Sun::getNode() const
+{
+	return mSunNode;
+}
+
 } // namespace caelum
 
 #endif //SUN_H
diff -U 3 -dHbrN -- /home/erik/ember/var/Caelum/src/CaelumSystem.cpp ./src/CaelumSystem.cpp
--- /home/erik/ember/var/Caelum/src/CaelumSystem.cpp	2006-10-22 15:45:20.000000000 +0200
+++ ./src/CaelumSystem.cpp	2006-11-03 00:17:03.000000000 +0100
@@ -10,7 +10,6 @@
 	mOgreRoot = root;
 	mSceneMgr = sceneMgr;
 
-	mOgreRoot->addFrameListener (this);
 
 	createSkyDomeMaterial ();
 	createStarfieldMaterial ();
@@ -28,6 +27,8 @@
 
 	mStarfield = 0;
 
+	///add ourselves as frame listener last, since if there's a problem here. there will be no valid object
+	mOgreRoot->addFrameListener (this);
 	LOG ("DONE");
 }
 
diff -U 3 -dHbrN -- /home/erik/ember/var/Caelum/src/StoredImageSkyColourModel.cpp ./src/StoredImageSkyColourModel.cpp
--- /home/erik/ember/var/Caelum/src/StoredImageSkyColourModel.cpp	2006-10-22 16:17:45.000000000 +0200
+++ ./src/StoredImageSkyColourModel.cpp	2006-10-25 23:15:15.000000000 +0200
@@ -10,7 +10,7 @@
 void StoredImageSkyColourModel::setSkyGradientsImage (const Ogre::String &gradients) {
 	if (mSkyGradientsTextureUnitState) {
 		// Dagon and Eihort compatibility
-		#if OGRE_VERSION < 0x130
+		#if OGRE_VERSION <  ((1 << 16) | (3 << 8) | 0)
 			mSkyGradientsTextureUnitState->setTextureName (gradients, Ogre::TEX_TYPE_2D, -1, true);
 		#else
 			mSkyGradientsTextureUnitState->setTextureName (gradients, Ogre::TEX_TYPE_2D);
Ember, GPL virtual world client.
Development blog
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

Hey, those screenies look pretty neat! Thanks for posting! :)
Oh, and I write down these changes for my to-do list :) Thanks
Image
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

Update, see the first post for the download.
Just did some bugfixes suggested by Azatoth, so don't expect nothing spectacular :?
Image
User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
x 4
Contact:

Post by Azatoth »

Sweet! I forgot to mention that I also added some validity checks to the CloudsUpdater to avoid segfaults if the materials weren't completely supported etc.

Code: Select all

class CloudsUpdater : public caelum::CaelumListener {
	public:
		bool caelumStarted (const Ogre::FrameEvent &e, caelum::CaelumSystem *sys) {
			Ogre::MaterialPtr mat = static_cast<Ogre::MaterialPtr >(Ogre::MaterialManager::getSingleton ().getByName ("Altocumulus"));
			if (!mat.isNull()) {
				Ogre::Technique* tech = mat->getBestTechnique ();
				if (tech) {
					Ogre::Pass* pass = tech->getPass(0);
					if (pass) {
						pass->getVertexProgramParameters ()->setNamedConstant ("sunDirection", sys->getSun ()->getSunDirection ());
						pass->getFragmentProgramParameters ()->setNamedConstant ("sunDirection", sys->getSun ()->getSunDirection ());
					}
				}
			}
			return true;
		}
};
Ember, GPL virtual world client.
Development blog
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

Thanks, though I plan to discard all that code, as it's actually a test/prototype, not a final version :)

By the way, I've just uploaded caelum to sourceforge, and there's a Subversion (svn) repository up and running.
The URL is http://sourceforge.net/projects/caelum/
To get the a working copy you can use

Code: Select all

svn checkout https://svn.sourceforge.net/svnroot/caelum caelum
and use

Code: Select all

svn update
from your working copy to update to the latest version (if I recall correctly -I'm not an svn expert (yet))
Image
User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
x 4
Contact:

Post by Azatoth »

That's great, I'll check it out.
Ember, GPL virtual world client.
Development blog
User avatar
pricorde
Greenskin
Posts: 114
Joined: Thu Aug 11, 2005 9:28 pm
Location: France
Contact:

Post by pricorde »

Hi!

I just added a Caelum sky to Rigs of Rods and the result is marvelous.
Great plugin, very easy to use, it took me a couple hour to get it, compile and add to my crufty code!

Image

The only problem I got was from the SkyDome::preViewportUpdate scaling code : the skydome was clipped. To fix it I had to set its size to the right constant size corresponding to my environment.

Now I'll have to figure how to have decent and correct terrain shadows (I use the TerrainSceneManager that uses a static shadowed texture).

Great work, thanks!
Pierre-Michel
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

Wow, this looks great! Glad you find it easy and useful. I'm dying to put my hands on it again to add more and more features (as well as fixing some problems ;))
Image
User avatar
Praetor
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 3335
Joined: Tue Jun 21, 2005 8:26 pm
Location: Rochester, New York, US
x 3
Contact:

Post by Praetor »

Looks really good!

Maybe a patch might be useful pricorde that makes the sky dome size an easy-to-set parameter so people with different size environments can use it easily.

As for your terrain shadows, you could think about baking out a dozen or so terrain shadow maps for different times of the day and interpolating between them in a shader.
oldfox
Halfling
Posts: 57
Joined: Mon Apr 18, 2005 5:46 pm

Post by oldfox »

Yes good idea as I'm also pretty interested in that sky!! I'm probably not the only one :)

Should it be easy to link with my own calculated sun position?
User avatar
pricorde
Greenskin
Posts: 114
Joined: Thu Aug 11, 2005 9:28 pm
Location: France
Contact:

Post by pricorde »

Praetor wrote: Maybe a patch might be useful pricorde that makes the sky dome size an easy-to-set parameter so people with different size environments can use it easily.
Here we go: this patch allows to set the size of the skydome and starfield to a manual size.

Code: Select all

Index: include/SkyDome.h
===================================================================
--- include/SkyDome.h	(revision 1)
+++ include/SkyDome.h	(working copy)
@@ -20,6 +20,10 @@
 		 */
 		static const Ogre::String mSphericDomeResourceName;
 
+		/** Definces if the dome radius is automatically set or not.
+		 */
+		bool autoRadius;
+
 // Methods --------------------------------------------------------------------
 	public:
 		/** Constructor (DO NOT USE! Use CaelumSystem::createSkyDome instead).
@@ -31,6 +35,12 @@
 		 */
 		~SkyDome ();
 
+		/** Forces the size of the skydome to a specific radius.
+			If the parameter is negative, the radius is set automatically.
+			@param size The size of the skydome, or a negative value.
+		 */
+		void setSize (float size);
+
 		/** Event trigger called just before rendering a viewport in a render target this dome is attached to.
 			Useful to make the dome follow every camera that renders a viewport in a certain render target.
 			@param e The viewport event, containing the viewport (and camera) to be rendered right now.
Index: include/Starfield.h
===================================================================
--- include/Starfield.h	(revision 1)
+++ include/Starfield.h	(working copy)
@@ -24,6 +24,10 @@
 		 */
 		Ogre::Degree mInclination;
 
+		/** Defines if the dome radius is automatically set or not.
+		 */
+		bool autoRadius;
+
 // Methods --------------------------------------------------------------------
 	public:
 		/** Constructor.
@@ -41,6 +45,12 @@
 		 */
 		void preViewportUpdate (const Ogre::RenderTargetViewportEvent &e);
 
+		/** Forces the size of the starfield to a specific radius.
+			If the parameter is negative, the radius is set automatically.
+			@param size The size of the starfiels, or a negative value.
+		 */
+		void setSize (float size);
+
 		/** Sets the starfield inclination.
 			@param inc The starfield inclination in degrees.
 		 */
Index: src/SkyDome.cpp
===================================================================
--- src/SkyDome.cpp	(revision 1)
+++ src/SkyDome.cpp	(working copy)
@@ -14,6 +14,7 @@
 	ent->setRenderQueueGroup (Ogre::RENDER_QUEUE_SKIES_EARLY + 2);
 	ent->setCastShadows (false);
 	mNode->attachObject (ent);
+	autoRadius=true;
 }
 
 SkyDome::~SkyDome () {
@@ -21,13 +22,25 @@
 	static_cast<Ogre::SceneNode *>(mNode->getParent ())->removeAndDestroyChild (mNode->getName ());
 }
 
+void SkyDome::setSize(float size) {
+	if (size>0)
+	{
+		mNode->setScale(Ogre::Vector3::UNIT_SCALE*size);
+		autoRadius=false;
+	}
+	else autoRadius=true; //size will be updated at the next viewport update
+}
+
 void SkyDome::preViewportUpdate (const Ogre::RenderTargetViewportEvent &e) {
 	Ogre::Camera *cam = e.source->getCamera ();
 	mNode->setPosition (cam->getRealPosition ());
-	if (cam->getFarClipDistance () > 0)
-		mNode->setScale (Ogre::Vector3::UNIT_SCALE * (cam->getFarClipDistance () - CAMERA_DISTANCE_MODIFIER));
-	else
-		mNode->setScale (Ogre::Vector3::UNIT_SCALE * (cam->getNearClipDistance () + CAMERA_DISTANCE_MODIFIER));
+	if (autoRadius)
+	{
+		if (cam->getFarClipDistance () > 0)
+			mNode->setScale (Ogre::Vector3::UNIT_SCALE * (cam->getFarClipDistance () - CAMERA_DISTANCE_MODIFIER));
+		else
+			mNode->setScale (Ogre::Vector3::UNIT_SCALE * (cam->getNearClipDistance () + CAMERA_DISTANCE_MODIFIER));
+	}
 }
 
 } // namespace caelum
Index: src/Starfield.cpp
===================================================================
--- src/Starfield.cpp	(revision 1)
+++ src/Starfield.cpp	(working copy)
@@ -14,6 +14,7 @@
 	ent->setRenderQueueGroup (Ogre::RENDER_QUEUE_SKIES_EARLY + 1);
 	ent->setCastShadows (false);
 	mNode->attachObject (ent);
+	autoRadius=true;
 
 	mInclination = Ogre::Degree (0);
 }
@@ -23,13 +24,26 @@
 	static_cast<Ogre::SceneNode *>(mNode->getParent ())->removeAndDestroyChild (mNode->getName ());
 }
 
+void Starfield::setSize(float size) {
+	if (size>0)
+	{
+		mNode->setScale(Ogre::Vector3::UNIT_SCALE*size);
+		autoRadius=false;
+	}
+	else autoRadius=true; //size will be updated at the next viewport update
+}
+
+
 void Starfield::preViewportUpdate (const Ogre::RenderTargetViewportEvent &e) {
 	Ogre::Camera *cam = e.source->getCamera ();
 	mNode->setPosition (cam->getRealPosition ());
-	if (cam->getFarClipDistance () > 0)
-		mNode->setScale (Ogre::Vector3::UNIT_SCALE * (cam->getFarClipDistance () - CAMERA_DISTANCE_MODIFIER));
-	else
-		mNode->setScale (Ogre::Vector3::UNIT_SCALE * (cam->getNearClipDistance () + CAMERA_DISTANCE_MODIFIER));
+	if (autoRadius)
+	{
+		if (cam->getFarClipDistance () > 0)
+			mNode->setScale (Ogre::Vector3::UNIT_SCALE * (cam->getFarClipDistance () - CAMERA_DISTANCE_MODIFIER));
+		else
+			mNode->setScale (Ogre::Vector3::UNIT_SCALE * (cam->getNearClipDistance () + CAMERA_DISTANCE_MODIFIER));
+	}
 }
 
 void Starfield::setInclination (Ogre::Degree inc) {
Praetor wrote: As for your terrain shadows, you could think about baking out a dozen or so terrain shadow maps for different times of the day and interpolating between them in a shader.
Yes, thought about that too. It is also a good opportunity to look how I can light the terrain with vehicles lights and make a nice night mode 8)

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

Post by Kencho »

Thanks for the patch. Have you submitted the patch to sourceforge? If so, I'll take a look and apply it later :) I think it's pretty useful, as I simply thought this wouldn't produce any errors, but instead this can even enhance performance while letting the user to delegate this to Caelum if he doesn't want to lose time with this :)
Image
User avatar
Wretched_Wyx
Orc
Posts: 498
Joined: Thu Mar 16, 2006 5:27 pm
Contact:

Post by Wretched_Wyx »

Hey Kencho,

Just wanted to pop in and say keep up the good work. Also to apologize for not setting up the Caelum wiki page like I said I would :oops:. When I finally remembered I was going to do that, I saw you already had. Shame on me for that.

I also had a question/suggestion (perhaps several if my mind spits some more out at my fingers): Any chance you could fix the night sky dome? You know, the bit with the nasty texture stretching? I went ahead and just made a nice smooth sphere in Blender, and replaced the part in the code that generates one, to reference the one I made. It looked good, but if I remember correctly it caused some slowdown or some other strange error (I haven't had my hands on my engine in some time, been quite busy). Something tells me that generating the sphere mesh in code, is faster than loading a mesh resource- but I could be wrong?

Okay, so I did end up having two questions. Out of curiosity, what new features do you have planned for Caelum? I know right now everything is probably bug-fixes and what not, but I'm sure you have some sort of list of future features, some of which perhaps you'd be willing to share :wink:.

Anyways, keep up the great work on this. It's cool to see it being added to some already great looking projects (particularly in reference to Ember and Rigs of Rods), and how much it can boost the eye candy and realism.
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

Thanks :)

I don't think loading the mesh from the file will be any more expensive than manually creating it. Maybe the first time you create/load one, but not the rest (unless it's eventually unloaded). In any case, you can play with the CaelumListener and the getLocalTime methods to implement your own prototypes if you don't want to play with the core itself. Also, someone suggested to do it with point rendering, creating the vertices where the stars would be (of course, not very populated starfields) and render only the points. Again, prototyping with the CaelumListener would be the best solution in my opinion.

About future plans, in the top of my list are many refactorings to make things more stable and well-designed. Also, a variation of my method that will have some nice extras and will link with the real sun position calculations (also in my list, but lower). Clouds, fog, moon, and other weather effects go next, but not as top-priority tasks.

I want to apologise as I'm not working on it right now, but will try to get my hands dirty as soon as I have a chance, promise.
Image
User avatar
Kencho
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4011
Joined: Fri Sep 19, 2003 6:28 pm
Location: Burgos, Spain
x 2
Contact:

Post by Kencho »

PS: I've uploaded your screenshots to my blog. Hope you don't mind :)
Image
User avatar
pricorde
Greenskin
Posts: 114
Joined: Thu Aug 11, 2005 9:28 pm
Location: France
Contact:

Post by pricorde »

Kencho wrote:PS: I've uploaded your screenshots to my blog. Hope you don't mind :)
Of course not! I've seen you have also a nice caelum logo - another good one for my credits screen :wink:

About my patch: I could not submit it to sourceforge (I've never used it... maybe my login is too "new") so all you have is the patch in this forum...

As a user, if I had a few features requests it would be:
-better sun positionning (and I wonder if there is not a bug around midnight, it looked like the day was 23h or 25h - I did not investigate, maybe it is a bug from me)
-shutdown sun light source when it is under the horizon
-ambient lightning management (or did I missed it? at least, the ambient light is too high during the night)
-better starfield : I think point stars are the solution - and moon too ;-)

...and of course, volumetric clouds, rain, snow, lighting, rainbows and so on... :roll:

Maybe I'll submit patches for some of these.

One problematic thing is that the fog does not blend well with the horizon color. So in the sunset, which has lot of fog (haze) you see mountain crests very sharply over the sky, even if they are very very far. I don't know if there is an easy fix...

But again, this is a great package, and even in its current state, it is a very powerfull addition to Ogre.

Cheers,
Pierre-Michel
Post Reply