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
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
Contact:

Post by Azatoth » Sun Dec 03, 2006 3:03 pm

Screenshots as required. :D

Image Image Image
Image Image Image
Image Image Image

These are without the absorption turned on, since it always looked a bit overexposed. Didn't fiddle too much with it though.

Btw, when using infinite far clip plane I get black and white skies with some colour poking through where the skysphere seems to interfere with the "infinte" clip plane. Hard to explain, screenshot supplied:
Image

I disabled the sun if it's below the horizon, updating Sun::update with this:

Code: Select all

	// Update the main light direction
	if (mMainLight != 0) {
		mMainLight->setDirection (dir);
		///hide the sun if it's below the horizon
		if (dir.y > 0) {
			mMainLight->setVisible(false);
		} else {
			mMainLight->setVisible(true);
		}
	}
To sum it up, great work!
0 x
Ember, GPL virtual world client.
Development blog

User avatar
Azatoth
Gnome
Posts: 327
Joined: Sat Jul 10, 2004 6:46 pm
Location: Sweden
Contact:

Post by Azatoth » Sun Dec 03, 2006 3:17 pm

I was wondering about how the CealumListener interface is meant to work. Currently, if any listener returns false on either method it will make Ogre shut down. This is because that will lead to CaelumSystem::frameStarted returning false, which makes Ogre shut down.
I think it would make more sense to make it so that if a CealumListener returns false on any method, it would result in CaelumSystem removing it from the listener queue. For instance, if the example clouds updater listener can't find the material, there's no need to call it every frame any more, and it should thus be removed.
0 x
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 1
Contact:

Post by Kencho » Sun Dec 03, 2006 4:02 pm

Thanks Azatoth, these look great! The only thing is that I would reduce the cloud sky plane tiling to 1, and curve it (see the demo and you'll understand what I mean ;))

About the infinite far clip distance, I'll take a look into it. Will add a bug to the tracker right now.

Regarding the sun colour, I'm not fond of turning it off, for a number of reasons. First, that it's below the horizon, but high objects (like clouds) can still be lit by the sun some minutes more. I think the best option is to use shadows, which is something I'll study later. I take note of this too anyways ;)

And about the listener... what you say makes perfect sense. Anyways, if the material isn't found, the application will exit, as the update function propagates the CaelumListener returned value to the FrameListener::frameStarted function, and thus exiting when the Caelum listener returns false. Anyways, suggestions are welcome (for instance, adding different policies so that the final user decides what to do if the listener returns false...)

Thanks :)
0 x
Image

User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
Contact:

Post by haffax » Sun Dec 03, 2006 4:23 pm

I am too in the process of integrating Caelum with our project. Got it basically working, screens will follow after I solve a few outstanding issued. It really looks cool already. A great project, Kencho! :D

There are nevertheless a few things that were nice to see improved:
- The line endings are messed up. Looks as if you shared the files directly between Linux/Windows or something like this. This makes it hard to create patches for project depending changes to be applied on later versions.

- The way resources are managed is a bit curious. The resource group is created and named by Caelum, but the client program is supposed to add the resources to the group itself. I'd propose that instead the client is responsible for group creation too, like it was in the first version and also that the group name to be used by Caelum is a parameter, maybe for the CaelumSystem-constructor. The problem is, that a library created resource group doesn't fit with our resource management scheme.
(One way to keep current behaviour is to default the group name to Caelum and create the group if it not already exists.)

- An additional tiny thing: SkyLightAbsorption.cg is almost a valid HLSL program, only that the texture is named texture is problematic, since texture is a reserved word in HLSL. We use HLSL instead of Cg, so we need to change the material anyway, but minimising the changes needed were nice. :)
0 x
team-pantheon programmer
creators of Rastullahs Lockenpracht

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 Dec 03, 2006 4:51 pm

haffax wrote:I am too in the process of integrating Caelum with our project. Got it basically working, screens will follow after I solve a few outstanding issued. It really looks cool already. A great project, Kencho! :D
Thanks a lot. People integrating this into their projects is really encouraging and keeps me moving as fast as I can :)
There are nevertheless a few things that were nice to see improved:
- The line endings are messed up. Looks as if you shared the files directly between Linux/Windows or something like this. This makes it hard to create patches for project depending changes to be applied on later versions.
Yes, someone already stated this before. Will solve this as soon as I can, promise :)
- The way resources are managed is a bit curious. The resource group is created and named by Caelum, but the client program is supposed to add the resources to the group itself. I'd propose that instead the client is responsible for group creation too, like it was in the first version and also that the group name to be used by Caelum is a parameter, maybe for the CaelumSystem-constructor. The problem is, that a library created resource group doesn't fit with our resource management scheme.
(One way to keep current behaviour is to default the group name to Caelum and create the group if it not already exists.)
Good point, didn't thought about this. Another high-priority task on the way.
- An additional tiny thing: SkyLightAbsorption.cg is almost a valid HLSL program, only that the texture is named texture is problematic, since texture is a reserved word in HLSL. We use HLSL instead of Cg, so we need to change the material anyway, but minimising the changes needed were nice. :)
Okay, thanks :) I'm not a shader expert, and so far the only language I understand acceptably is cg, so I wasn't aware of this. Will fix this tonight as well :)

Excellent feedback, thanks!
0 x
Image

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 Dec 03, 2006 11:56 pm

Haffax, newlines and the sky colour script should be fixed now. Next step will be to take the resource group management outside of Caelum. I'll try to keep the current API if possible by defaulting parameters.
0 x
Image

User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
Contact:

Post by haffax » Mon Dec 04, 2006 12:27 am

Thank you very much. :)
Have to look at it tomorrow, bed time. 8)
0 x
team-pantheon programmer
creators of Rastullahs Lockenpracht

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 Dec 04, 2006 3:39 am

The resource group allocation optionally outside is finished.

Now I seriously need help with this bug. I've tried anything, but don't understand why it doesn't work. There's a patch attached so that you can reproduce the bug on svn rev#16. I'm afraid it's just my low knowledge of shaders, but can't figure out why this happens :(
0 x
Image

User avatar
syedhs
Silver Sponsor
Silver Sponsor
Posts: 2702
Joined: Mon Aug 29, 2005 3:24 pm
Location: Kuala Lumpur, Malaysia
x 3

Post by syedhs » Mon Dec 04, 2006 4:38 am

Look seriously good, and undoubtedly will be a popular add-on :) I have not seen your TODO list Kencho, but are you going to implement moving clouds?
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 Dec 04, 2006 9:08 am

*nods* :D
Thanks!
0 x
Image

User avatar
haffax
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 4823
Joined: Fri Jun 18, 2004 1:40 pm
Location: Berlin, Germany
Contact:

Post by haffax » Mon Dec 04, 2006 11:30 am

I am a bit confused here regarding the bug. You set atmosphereInvHeight programatically and lightInvScattering inside the shader.
You write as a follow-up
Indeed, it works well if you define the atmosphereInvHeight through the Ogre API and not the shader source code.
Does this mean, that only lightInvScattering is the problem? That when you set it programmatically you get the transparency problem and when defining it in the shader, then not?

I am at work, so can't test it, but I can look at it.

One small unrelated thing: the addition of fp30 and vp30 to the profiles list has no effect. Since profiles are tested in order and all cards that support vp/fp30 also support arbfp/vp1, which is tested for before and thus always taken instead.
0 x
team-pantheon programmer
creators of Rastullahs Lockenpracht

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 Dec 04, 2006 2:25 pm

haffax wrote:Does this mean, that only lightInvScattering is the problem? That when you set it programmatically you get the transparency problem and when defining it in the shader, then not?
Exactly, I did that last fix this morning when I tried and worked. Thus, the diff file attached is only valid for revision #16.

About the shader profiles, I didn't know that. As I thought it might be a limitation of one of those profiles, decided to add nVidia's so that the restrictions were loosier. Will remove it now then, thanks :)
0 x
Image

User avatar
Alexander
Gremlin
Posts: 175
Joined: Sat Aug 05, 2006 3:55 am

Post by Alexander » Mon Dec 04, 2006 11:51 pm

I'm sure you've seen this Kencho, but it's certainly great reference for the possibilities of cloud systems. :D

http://windwardmark.net/products.php?pa ... technology
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 Dec 05, 2006 12:37 am

Yes, I was aware of it, someone else already posted that when I was starting Caelum ;)
I've been thinking deeply on this, but still have things at a higher priority in my tasks' list ;)
0 x
Image

User avatar
Alexander
Gremlin
Posts: 175
Joined: Sat Aug 05, 2006 3:55 am

Post by Alexander » Tue Dec 05, 2006 1:10 am

Agreed. :D
Definitely interesting to study though.
0 x

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
Contact:

Post by Praetor » Tue Dec 05, 2006 3:51 am

Agreed kencho. Clouds are lower in the queue. A fully working sky system is best for now. Clouds are something that can be tinkered in later.
0 x

Vectrex
Ogre Magi
Posts: 1266
Joined: Tue Aug 12, 2003 1:53 am
Location: Melbourne, Australia
Contact:

Post by Vectrex » Tue Dec 05, 2006 9:30 am

Kencho wrote:Yes, I was aware of it, someone else already posted that when I was starting Caelum ;)
I've been thinking deeply on this, but still have things at a higher priority in my tasks' list ;)
that link is a brand new thing sinbad just finished working on, not the other link I posted a while ago. Fully volumetric clouds.
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 Dec 05, 2006 9:34 am

Better said: I was aware of both ;) Why else would I have congrat'd both Sinbad and ChocoboInbreeder in the forums and blog? :?
0 x
Image

Captain Nemo
Greenskin
Posts: 134
Joined: Sun May 02, 2004 5:06 pm
Location: Kassel, Germany
Contact:

Post by Captain Nemo » Tue Dec 05, 2006 10:42 am

Vectrex wrote: that link is a brand new thing sinbad just finished working on, not the other link I posted a while ago. Fully volumetric clouds.
I am confused. Which link are you talking about now? Something sinbad is working on?
0 x
http://www.aridocean.com
The Marine Life Simulation

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 Dec 05, 2006 10:59 am

0 x
Image

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 Dec 05, 2006 12:37 pm

I've done some refactorings and enhancements. Most of them aren't interface-breaking, but some are, so keep an eye on the demo source.
The most interesting one is possibly the SunPositionModel base class, which allows you to define your own methods to calculate sun position (for those of you who wanted to add their implementations of sun position calculations ;))
0 x
Image

User avatar
Lee04
Minaton
Posts: 944
Joined: Mon Jul 05, 2004 4:06 pm
Location: Sweden

Two or more suns?

Post by Lee04 » Tue Dec 05, 2006 12:46 pm

Great job!

Question: How about if you want several suns like in the Starwars scene?
Does that work out with this technique?



cheers

Lee04
0 x
Ph.D. student in game development

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 Dec 05, 2006 12:53 pm

Not really right now. As I've aimed for inexpensive ways to render things (though the layered clouds are quite expensive to look fine), multiple light sources complicate things much more. For now, I prefer to provide at least basic functionality for as much elements as possible (this includes even lightnings), and then working on these other subjects.
0 x
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
Contact:

Post by Praetor » Tue Dec 05, 2006 5:23 pm

Also, as far as I know sky colorings like that use equations specifically designed for our situation on earth. I'm not sure how easily it can be extended to multiple suns.

I haven't looked at the source, are you using a custom sky coloring technique, or a math-based one kencho?
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 Dec 05, 2006 10:00 pm

None of them, and both. The idea is to store all the image gradients on a single map. Theorethically it's having the results of a function f(azimuth,time)=(r,g,b) or f(azimuth,sunElevation)=(r,g,b) stored in the map, kinda complex wave spectrums. So the whole sky is sharing a coordinate, say U, while its other coordinate, V, depends on the vertex height. This way, moving the map left/right changes the whole sky gradient. It's less exact and has many drawbacks, but works on very old hardware, it's fast, intuitive, and allows for easy artistic results (dramatic sky colours and such). A shader then modifies its aspect per-vertex or per-pixel, to add glow around the sun, light absorption...
That's why multiple light sources (suns and moons) aren't trivial to add here :(
0 x
Image

Post Reply