Caelum - [WARNING: Screenshot intensive]

Post by **Kencho** » Sat Jan 20, 2007 2:02 pm

Well, I'm afraid I can't help with RenderMonkey, but sure I take note of each error instance. Could you just disable the clouds and try only with sky?

Post by **Praetor** » Sat Jan 20, 2007 5:10 pm

I suggest you just disable the clouds while working on the problem. My tests showed that actually, the black flecks happen regardless of clouds or even scattering shaders. Something even more sinister is going on, I just haven't found where yet.

ahmedismaiel · Post by **ahmedismaiel** » Sun Jan 21, 2007 1:09 am

I compiled the code on dagon but when i run i get exception in the compilation of the shaders
i have ATI x800 256 MB ,please help

Code: Select all

00:41:29: Parsing script Altocumulus.material
00:41:29: An exception has been thrown!

-----------------------------------
Details:
-----------------------------------
Error #: 7
Function: GpuProgramParameters::getParamIndex
Description: Cannot find a parameter named time. 
File: ..\src\OgreGpuProgram.cpp
Line: 773
Stack unwinding: <<beginning of stack>>
00:41:29: Error at line 27 of Altocumulus.material: Invalid param_named_auto attribute - An exception has been thrown!

-----------------------------------
Details:
-----------------------------------
Error #: 7
Function: GpuProgramParameters::getParamIndex
Description: Cannot find a parameter named time. 
File: ..\src\OgreGpuProgram.cpp
Line: 773
Stack unwinding: <<beginning of stack>>

00:41:29: 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: ..\src\OgreD3D9GpuProgram.cpp
Line: 91
Stack unwinding: <<beginning of stack>>

Post by **Kencho** » Sun Jan 21, 2007 2:11 am

What revision are you using? Latest should work fine...
In any case, don't pay attention to the clouds support at this moment, as the current implementation is a test.

ahmedismaiel · Post by **ahmedismaiel** » Sun Jan 21, 2007 3:13 am

i use the compressed file Caelum-2006-11-09 that was on the first post .is there a cvs or svn so i can check the latest version?

Post by **Kencho** » Sun Jan 21, 2007 3:27 am

Yup, you have most of the useful info in the Ogre wiki here

You just need to call

Code: Select all

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

to get the latest, and

Code: Select all

svn update

to keep up to date

ahmedismaiel · Post by **ahmedismaiel** » Mon Jan 22, 2007 6:37 am

i checked out the latest version and compiled it with dagon and also with latest eithort .
the error still exist in the cloud layer shader ,but the weird thingit only happens in D3D plugin but opengl works but with some artifacts (black polygons flickering at random positions when moving)
as in the following screen

help!!!

Post by **Praetor** » Mon Jan 22, 2007 7:55 am

Yeah this is the problem I've been looking into. Well, at least the problem I had been looking into until recently. Anyway, it appears as though in D3D the sky polygons will sometimes go completely transparent and the starfield dome behind it shows through. It happen regardless of cloud material, or even scattering. Perhaps something that D3D does not like about the dome geometry itself.

Post by **Kencho** » Mon Jan 22, 2007 8:37 am

There's something strange with that screenshot, if you look at the rightmost side... The top edge doesn't look to be aligned.
Ahmedismael, could you reproduce this error and take the same screenshot but in wireframe mode?

ahmedismaiel · Post by **ahmedismaiel** » Mon Jan 22, 2007 10:32 am

here you are

i'm really not sure what that is ,but it doesn't look like a depth race
also the texture of the moon exist in side the lost polygons

Post by **Praetor** » Mon Jan 22, 2007 5:02 pm

Looks like a polygon problem. The weird thing is, it isn't always visible for me. That is, it seems to depend someone on viewing angles and such. Perhaps just that often, the position of everything comes together to hide the problem. Do you notice the same behavior? These holes seem to flicker in and out of existence, and only once in a while can you find a consistent viewing angle to make them appear permanently?

Azatoth · Post by **Azatoth** » Mon Jan 22, 2007 5:08 pm

This might perhaps help, or it's something that only appears in Ember:
When I move sideways the sun "staggers", i.e. it appears to be updated one frame after the actual movement. If you're getting the same effect, that might have something to do with this, i.e. that the position of the skydome is updated out of sync with the camera, causing it to in some instances when moving get beyond the clipping range.

Post by **Kencho** » Mon Jan 22, 2007 8:29 pm

Azatoth wrote:This might perhaps help, or it's something that only appears in Ember:
When I move sideways the sun "staggers", i.e. it appears to be updated one frame after the actual movement. If you're getting the same effect, that might have something to do with this, i.e. that the position of the skydome is updated out of sync with the camera, causing it to in some instances when moving get beyond the clipping range.

That seems to be a matter of the updating sequence: The Caelum objects being placed and then the camera being moved. Are you updating the positions during frameEnded or frameStarted?

About the holes... are you using infinite far clipping or not? If so, what settings have you tried? I would have bet this was a polygon problem, but the first shot from Ahmedismael made me suspect and the last one almost confirmed my theory that this is a z-fighting problem. If it were a polygon problem, the edges should be rendered as well, but they aren't! My question is: Why they are appearing in the sky dome and not in the starfield?

ahmedismaiel · Post by **ahmedismaiel** » Tue Jan 23, 2007 1:32 am

i use the sample that is in the svn ,no changes from me
it doesnt set the far ,it setsonly the near clip

Code: Select all

			mCamera->setNearClipDistance (0.01);
//			mCamera->setFarClipDistance (0);

not sure what is the default
is there a normal way to disable the layered clouds and their shaders so i can try it on directx?

Post by **Kencho** » Tue Jan 23, 2007 2:10 am

Hmm, then it's not using the infinite far clipping feature...

ahmedismaiel wrote:is there a normal way to disable the layered clouds and their shaders so i can try it on directx?

Yes, commenting the mSceneMgr->setSkyPlane(...) line (line #167 in the latest version --Eihort) should do the work.

ahmedismaiel · Post by **ahmedismaiel** » Tue Jan 23, 2007 5:39 am

i checked it after disabling the layered clouds
the flickering doesn't happen at all on directx
it only happen on opengl
i love the results ,but i'm expecting more ,glaring (HDR) sun ,lens flare with occlusion query callbacks (i love that)

i have a question in eithort that might be relative ,on openGL all the sample applications including yours crash at the end on the program ,does eithort use other dependencies (.h ,lib) for opengl

the old dagon was very fine with me

thanks guys

Post by **Kencho** » Tue Jan 23, 2007 11:12 am

It's okay here in Linux. I haven't experienced any crash in Eihort yet. However, I would suggest you to update any drivers and dependencies. You can read about them in the Eihort roadmap at the wiki.

Bob · Post by **Bob** » Sat Jan 27, 2007 5:07 pm

Hi I'm new here

I tried to use Caelum in my Application but i do not know how to link the lib

so I get link errors

So please can anyone help me?

I use Dagon 1.2.5 and nxOgre and VC 2005 pro

Post by **Kencho** » Sat Jan 27, 2007 5:21 pm

Just link it the way you linked ogremain. It's actually that easy

Bob · Post by **Bob** » Sat Jan 27, 2007 7:50 pm

Ok i did it right before but i forgot to compile Caelum with ogre 1.2.5 so I get

a error of missing entrypoint and I thought the way of linking was wrong.

But now it works fine.

ps. : Thanks for the great Work!

Post by **Kencho** » Sun Jan 28, 2007 1:39 am

You're welcome. Thanks for using it!
Not to mention that all feedback will be handy and useful

HexiDave · Post by **HexiDave** » Sun Jan 28, 2007 8:40 am

I just had some luck adjusting the radius of the skydome/starfield (or perhaps just the distance away from the camera) to stop the flickering from the near-plane:

Code: Select all

		mCaelumSystem->getSkyDome()->setFarRadius(10000);
		mCaelumSystem->getStarfield()->setFarRadius(10000);

My guess is that the radius away from the camera was quite small and was getting clipped first, then rendered before the rest of the scene, giving it the appearance of being much further away.

Post by **Kencho** » Sun Jan 28, 2007 9:22 am

Yes, that's a possible cause. However, the holes in the mesh are quite regular in some cases, and it only affects the sky dome, not the starfield

Anyways, if that worked for you, I think we should take a look into it.

HexiDave · Post by **HexiDave** » Sun Jan 28, 2007 10:39 am

Ya, I had that same problem affecting me, it's because the clipping plane is JUST nipping at the skydome, right before it hits the starfield. That code should probably put the starfield a bit further out, in retrospect. Basically, if you were to set near-clip to 1 without that code, you get a nice gun-barrel view of the sky.

I could be mistaken, but after perusing the code for about an hour, that seemed to be the only thing that made any sense.

Despite that, this is a great addition to my project - thanks for the hard work

Post by **Kencho** » Sun Jan 28, 2007 11:42 am

Hmm... that sounds pretty promising then

I need you to try something. Instead of using the manual far distance feature, could you try adjusting the CAMERA_DISTANCE_MODIFIER define in CaelumPrerequisites.h from 0.1 to 1 or 10 for instance? (don't forget to recompile) If the problem is with the clipping planes, that should do the work...

PS: As soon as you can, post some nice shots here

PS2: Hmm... seems that I should change the license to Screenshotware or something similar