Caelum - [WARNING: Screenshot intensive]

netskate · Post by **netskate** » Mon Sep 22, 2008 5:24 pm

you are god

but now light seems to be always the same

cdleonard · Post by **cdleonard** » Mon Sep 22, 2008 5:36 pm

netskate wrote:but now light seems to be always the same

There are a large number of settings for lighting. Caelum will try to autoConfigure some reasonable defaults but those don't seem to work here. Looks like ambient is always maxed out; are you sure CaelumSystem::setManageAmbientLight is set to true? If so; check out the light multipliers for the sun and moon (check out the BaseSkyLight reference).

netskate · Post by **netskate** » Mon Sep 22, 2008 5:45 pm

ok, I'll read it before post another newbye question

I use hydrax in my garbage project (is too dirt), then I code this into frame started

Code: Select all

	    mHydrax->setSunPosition(mCaelumSystem->getSun()->getMainLight()->getPosition());
		Vector3 colore_sole;
		
		colore_sole.x=mCaelumSystem->getSun()->getLightColour().r;
		colore_sole.y=mCaelumSystem->getSun()->getLightColour().g;
		colore_sole.z=mCaelumSystem->getSun()->getLightColour().b;
		mHydrax->setSunColor(colore_sole);

but don't seems that sunlight follow himself on the water, maybe for uncorrect light definition as you told?

I'm reading documentation

sorry for my bad english

netskate · Post by **netskate** » Mon Sep 22, 2008 7:43 pm

I have done some attempt.

I placed some cube in my scene, his mesh go black when night fall.
Also trees (paged geometry) become black, the farthest remain green because they are 2D impostor, I think.

So, I can setup Hydrax for the water colour. Remain only terrain, that I have no idea.

nath31337 · Post by **nath31337** » Tue Sep 23, 2008 2:16 am

i have the exact same problem as netskate, entities shows light changes, but terrain always stay the same.

I would also know how the precipitation system work, ive looked at the demos and i came up with

Code: Select all

Root::getSingletonPtr()->addFrameListener (mCaelumSystem);
		mCaelumSystem->setPrecipitationController (new PrecipitationController (sceneMgr));
		mCaelumSystem->getPrecipitationController()->setPresetType(Caelum::PRECTYPE_RAIN);
		mCaelumSystem->getPrecipitationController()->setSpeed(100);
		mCaelumSystem->getPrecipitationController()->setIntensity(100);

not sure if im doing it correctly

thanks in advance

westpointer · Post by **westpointer** » Wed Sep 24, 2008 4:34 am

How can I make Caelum work for VS 2003?

cdleonard · Post by **cdleonard** » Wed Sep 24, 2008 9:00 am

netskate, nath: Terrain lighting depends on your terrain material. If you're using the default TerrainSceneManager I think you need a custom material to get true lighting and proper day/night cycles.

There's UI for precipitation stuff in Caelum Lab. It's nothing particularly fancy; it fakes particle rain using a wrapped texture; inspired by this page. Default camera speed is too high in CaelumLab and the "movement cones" are way too strong. But there's also a slider for camera speed.

It's easiest to use as part of CaelumSystem (CAELUM_COMPONENT_PRECIPITATION); this way you don't have to do anything extra. If you want it stand-alone you need to call createPrecipitiationInstance and destroyPrecipitiationInstance for all your viewports (otherwise you don't see anything). You also need to call update every frame for it to move. The documentation could help.

westpointer: It should work just like VS2005 and VS2008. I don't have access to VS2003 and there are no project files for it. I guess one way to make project files for it would be to edit the VS2005/VS2008 files and lower the required version by hand. From what I can tell that's the only relevant difference between the VS2005 and VS2008 formats; the same could be true for VS2003.

You could also make your own project files from scratch but conversion should be easier. Caelum uses plenty of postbuild stuff to ensure it will always run on 'F5'. All you need is the OgreSDK (for VS2003 in your case).

I hope it will compile properly on VS2003 but I'm not sure. If you get any errors please post them here; they should be easy to fix.

netskate · Post by **netskate** » Wed Sep 24, 2008 10:16 am

I resolve with terrain

now, I'm looking precipitation on caelum lab but when I move the slider seems to crash.

The image is always stopped, but I can use the gui

cdleonard · Post by **cdleonard** » Wed Sep 24, 2008 10:42 am

netskate wrote:I resolve with terrain

now, I'm looking precipitation on caelum lab but when I move the slider seems to crash.

The image is always stopped, but I can use the gui

I don't know why that would happen. Could you paste the last few lines of the log? Maybe goes wrong on attaching the compositor?

netskate · Post by **netskate** » Wed Sep 24, 2008 11:06 am

here the log:

http://www.webalice.it/netskate/Ogre.log

click save as.

this is directly your caelumlab

Faxnico · Post by **Faxnico** » Thu Sep 25, 2008 10:58 am

Thanks for your replies, cdleonard.

Finally, I was able to make precipitations working.

Last question: does somebody have a Caelum-compatible cloudy sky? Or could you explain me how to change the EarthClearSky2.png?

Thank you.

netskate · Post by **netskate** » Fri Sep 26, 2008 10:33 pm

I have done some attempts.

In my laptop the latest svn release works fine, precipitation included, but in directx mode it doesn't start (I think because of terrain shader, I have a x700 that doesn't support sm3);

However in OpenGL mode, it works fine (some fps too low but is always a laptop), with forced shadow terrain.

So I tried it into my desktop pc, same configuration:
ogre 1.4.9 sdk
latest svn release of caelum

in directx mode, pssm doesn't work, also forced shadow on terrain manager doesn't work. precipitation makes that bug I told you some post ago.

in opengl mode, forced shadow doesn't work. instead precipitation can be activated but when they are on I can't move the camera (move the mouse cause only move the rain O_o)

my desktop pc:
amd 4400+ x2
2x1 gb ram ddr 400 gskill
sapphire x1950pro (latest driver installed, xtremeg 8.9)
dfi lanparty ultra-d nforce 4

my laptop pc:
intel centrino m 1.7ghz
2x1 gb ram
x700 with xtremeg mobile driver 8.7
it's an hp pavillion dv4000series

If you can help me understand what kind of bug I have, it would be very wonderful.

Fish · Post by **Fish** » Tue Sep 30, 2008 1:32 am

Has anyone made Caelum function with the new PCZSceneManager in 1.6.0RC1? Caelum assets an error to the effect of, "Can't find the center of a NULL AAB." Any clues?

Caelum works with the generic TerrainSceneManager in 1.6.0RC1.

Fish · Post by **Fish** » Tue Sep 30, 2008 1:16 pm

I narrowed the issue down to the Star Field component. The other components seem to be working, except the clouds seem stretched.

cdleonard · Post by **cdleonard** » Tue Sep 30, 2008 2:14 pm

@Fish: The PointStarfield class always wants to be visible so I made it report an infinite bounding box. The other components don't do that. It could be that PCZSceneMananager doesn't properly deal with an infinite bounding box. The bounding box could also be null by mistake at some point. Maybe you could post a callstack?

@netskate: Sorry; but I don't know what's wrong. I have issues with PSSM and DirectX too but I did not look at them carefully.

@faxnico: That D3D debug runtime crash was caused by this issue. Caelum now has explicit tex_coord_set just in case.

Faxnico · Post by **Faxnico** » Tue Sep 30, 2008 4:27 pm

Thanks for your fix, cdleonard. It's really appreciated.

I've one more question. I'm trying to reproduce some bad weather conditions but, by default at some hours, the clouds layers tends to red when looking at sun (but it happens also setting sun to NULL). What's the best way to hide that effect for really cloud-covered skies but keeping the lighting on?

Thanks.
Faxnico

Fish · Post by **Fish** » Tue Sep 30, 2008 5:15 pm

cdleonard wrote:@Fish: The PointStarfield class always wants to be visible so I made it report an infinite bounding box. The other components don't do that. It could be that PCZSceneMananager doesn't properly deal with an infinite bounding box. The bounding box could also be null by mistake at some point. Maybe you could post a callstack?

Oh yes...that was the other part of the assert. It said, "Cannot find the center of an infinite or null AAB." I think I now have some direction. I'll try to get a call stack posted tonight.

Fish · Post by **Fish** » Wed Oct 01, 2008 1:36 am

cdleonard wrote:@Fish: Maybe you could post a callstack?

Here is the stack trace:

Code: Select all

assert: "Can't get center of a null or infinite AAB" Line 691

OgreMain_d.dll!Ogre::AxisAlignedBox::getCenter()  Line 691

Plugin_PCZSceneManager_d.dll!Ogre::PCZFrustum::isVisible(const Ogre::AxisAlignedBox & bound={...})  Line 83 + 0xf bytes

Plugin_PCZSceneManager_d.dll!Ogre::PCZCamera::isVisible(const Ogre::AxisAlignedBox & bound={...}, Ogre::FrustumPlane * culledBy=0x00000000)  Line 73 + 0x12 bytes

Plugin_PCZSceneManager_d.dll!Ogre::DefaultZone::findVisibleNodes(Ogre::PCZCamera * camera=0x0161d1f8, std::list<Ogre::SceneNode *,std::allocator<Ogre::SceneNode *> > & visibleNodeList=[1](0x06054cb0 {mNewPosition={...} mHomeZone=0x0161cf50 mAnchored=false ...}), Ogre::RenderQueue * queue=0x01674df0, Ogre::VisibleObjectsBoundsInfo * visibleBounds=0x0161dab8, bool onlyShadowCasters=false, bool displayNodes=false, bool showBoundingBoxes=false)  Line 483 + 0x2e bytes

Plugin_PCZSceneManager_d.dll!Ogre::PCZSceneManager::_findVisibleObjects(Ogre::Camera * cam=0x0161d1f8, Ogre::VisibleObjectsBoundsInfo * visibleBounds=0x0161dab8, bool onlyShadowCasters=false)  Line 1131 + 0x53 bytes

 OgreMain_d.dll!Ogre::SceneManager::_renderScene(Ogre::Camera * camera=0x0161d1f8, Ogre::Viewport * vp=0x0161e2f0, bool includeOverlays=true)  Line 1298 + 0x30 bytes

Plugin_PCZSceneManager_d.dll!Ogre::PCZSceneManager::_renderScene(Ogre::Camera * cam=0x0161d1f8, Ogre::Viewport * vp=0x0161e2f0, bool includeOverlays=true)  Line 409 + 0x17 bytes

OgreMain_d.dll!Ogre::Camera::_renderScene(Ogre::Viewport * vp=0x0161e2f0, bool includeOverlays=true)  Line 398 + 0x2c bytes

OgreMain_d.dll!Ogre::Viewport::update()  Line 193

OgreMain_d.dll!Ogre::RenderTarget::updateImpl()  Line 114

OgreMain_d.dll!Ogre::RenderTarget::update(bool swap=false)  Line 501 + 0x12 bytes

OgreMain_d.dll!Ogre::RenderSystem::_updateAllRenderTargets(bool swapBuffers=false)  Line 112 + 0x2a bytes

OgreMain_d.dll!Ogre::Root::_updateAllRenderTargets()  Line 1130 + 0x1c bytes	

OgreMain_d.dll!Ogre::Root::renderOneFrame()  Line 839 + 0x8 bytes

OgreMain_d.dll!Ogre::Root::startRendering()  Line 829 + 0x8 bytes

diskette · Post by **diskette** » Wed Oct 01, 2008 10:52 pm

how do I fix this problem, when night is the particles are ok, when is the day they receive very light (I believe), and shows its channel transparent.
see the pictures

Post by **Kencho** » Wed Oct 01, 2008 11:09 pm

I bet you aren't overriding the fog settings in your particle materials. So, when the fog is not-black, particles are brighter, and give a strange behavior with additive blending. The same happens with modulative blending when the fog is non-white. Alpha blending is fog-safe though.

netskate · Post by **netskate** » Thu Oct 02, 2008 3:21 pm

sorry for noob questions.

why setCloudSpeed take a Vector2?

I'm expected a Real value.

Also, when setting a cloud coverage setting it update from precedent value to final value with no transition.

there is a function to do it, or I need to code a sort of fading function?

thanks.

cdleonard · Post by **cdleonard** » Thu Oct 02, 2008 3:26 pm

netskate wrote:why setCloudSpeed take a Vector2?

Because the movement is done in a plane. The parameter is a speed vector in the plane.

netskate wrote:Also, when setting a cloud coverage setting it update from precedent value to final value with no transition.

there is a function to do it, or I need to code a sort of fading function?

You have to do your own fading here.

netskate · Post by **netskate** » Thu Oct 02, 2008 5:43 pm

the method getCloudSpeed in FlatCloudLayer.h is not defined.

I think someone should update the snv repository. it's only a little correction.

diskette · Post by **diskette** » Thu Oct 02, 2008 8:36 pm

Kencho wrote:I bet you aren't overriding the fog settings in your particle materials. So, when the fog is not-black, particles are brighter, and give a strange behavior with additive blending. The same happens with modulative blending when the fog is non-white. Alpha blending is fog-safe though.

thank you!
Obrigado pela dica!

DarkHorizon · Post by **DarkHorizon** » Sun Oct 05, 2008 4:53 am

Windows XP SP2
Ogre 1.4.9
Caelum 0.4
MS Visual Studio 2005 SP1

Caelum ate my GUI.

I downloaded Caelum 0.4 tonight from SVN, compiled without a hitch, replaced the old Caelum media files with new ones. When I link Caelum to the frame listeners, this is when the corruption becomes apparent.

Without Caelum:

With Caelum:

My scene background is sky-blue by default. I can understand the pinkish hue when Caelum takes over scene fog management. But I can't understand why the GUI graphics become corrupted.

Init code, taken directly from the examples in the SVN:

Code: Select all

	Caelum::CaelumSystem::CaelumComponent componentMask;
	componentMask = CaelumSystem::CAELUM_COMPONENTS_DEFAULT;
	m_Caelum = new Caelum::CaelumSystem (Root::getSingletonPtr(), m_SceneManager, componentMask);
	m_Caelum->getUniversalClock()->setTimeScale(512);
	m_Window->addListener(m_Caelum);
	Root::getSingletonPtr()->addFrameListener(m_Caelum);

Any ideas? I didn't note this problem for a few pages back in this thread, but I am continuing to search.

Thanks!

Ogre Forums

Caelum - [WARNING: Screenshot intensive]

Caelum + PCZSceneManager