[BUG] Crash after switching cameras
Samir
05-11-2005 09:36:33
Hi,
I'm having trouble after calling Viewport::setCamera.
Three days ago, I was using PLSM2, which I downloaded two weeks before that, with the Ogre SDK 1.0.4. Everything was fine when changing the current active camera with a call to setCamera.
Two days ago, I downloaded Ogre from CVS HEAD and downloaded all the add-ons again (so I have a new PLSM2), now it crashes.
After letting the debugger break on the crash, it seems that the mLastViewport member of the camera was zero. So I made a call to Camera::_notifyViewport to fix that. But now I have an assertion failure (or a crash in case I'm in release).
File: ..\src\OgrePagingLandscapeOcclusionElement.cpp
Line: 41
Expression: nodeDataPerCam[cam->getId()]
After trying all day to figure out what is wrong, all I can understand is that there seem to be some data related to entities and nodes that the new camera is not being updated upon. I only vaguely know how PLSM2 works so I don't think I'm equipped to solve that problem at this stage.
Also, I've tried starting my application with the second camera first, and it works fine. So there is nothing wrong with the camera I use, its just when I switch to another camera, there is a crash (not on the actual call to setCamera, but after). When I remove the call to setCamera, everything works fine, so its definitely the switching of cameras that is causing the problem.
tuan kuranes
05-11-2005 10:13:15
Camera to node data should only exist if using a special culling mode, which isn't the default (or using _VISIBILITYDEBUG define)
Do you Viewport::setCamera() on init, during a frame::started or outside ogre loop ?
Best would be that you reproduce the bug using demo code, so that I can reproduce it.
Samir
05-11-2005 14:52:37
Do you Viewport::setCamera() on init, during a frame::started or outside ogre loop ?
During frame::started. I switch the camera in response to a key pressed event.
Best would be that you reproduce the bug using demo code, so that I can reproduce it.
After hours of trying, I could only partially reproduce the error in the demo. I mean I could reproduce the crash before adding the call to _notifyViewport, but after adding that call, there is no assertion like there is in my application. But I still consider this a bug since before I switched to Ogre CVS HEAD and downloaded the latest PLSM2 source, there was no need for a call to _notifyViewport, and there is no need to call it in any other scene manager I used. Plus, it has an underscore at the beginning, so I don't think I'm supposed to call it anyways, so I think fixing this will fix the other bug too.
Also, there is another thing wrong with the Demo and my application, I can only see parts of the terrain (that is only some tiles show up), and each time its a different tile. I know the terrain exists because I can execute a terrain height query and get the right results. First I though this was caused by my application, but when I tried the demo like you asked, it had the same problem there too. Maybe I have something wrong with the terrain files (I'm using the ones from your website). Although, I have tried the ones I used before, and the one I downloaded today, same problem. I have noticed that after the demo (and my application) runs, there is these errors reported in the Ogre log file.
15:14:12: Parsing script IPLSM_Image.material
15:14:12: Error in material IPLSM_Image at line 23 of IPLSM_Image.material: Bad colour_op_ex attribute, wrong number of parameters (expected 3 to 10)
15:14:12: Parsing script IPLSM_Splatting1.material
15:14:12: Error in material IPLSM_Splatting1 at line 36 of IPLSM_Splatting1.material: Unrecognised command: alpha_rejection
15:14:12: Error in material IPLSM_Splatting1 at line 62 of IPLSM_Splatting1.material: Unrecognised command: alpha_rejection
15:14:12: Error in material IPLSM_Splatting1 at line 88 of IPLSM_Splatting1.material: Unrecognised command: alpha_rejection
15:14:12: Error in material IPLSM_Splatting1 at line 113 of IPLSM_Splatting1.material: Unrecognised command: alpha_rejection
15:14:12: Parsing script IPLSM_Splatting2.material
15:14:12: Error in material IPLSM_Splatting2 at line 36 of IPLSM_Splatting2.material: Unrecognised command: alpha_rejection
15:14:12: Error in material IPLSM_Splatting2 at line 62 of IPLSM_Splatting2.material: Unrecognised command: alpha_rejection
15:14:12: Error in material IPLSM_Splatting2 at line 88 of IPLSM_Splatting2.material: Unrecognised command: alpha_rejection
15:14:12: Error in material IPLSM_Splatting2 at line 113 of IPLSM_Splatting2.material: Unrecognised command: alpha_rejection
15:14:12: Parsing script IPLSM_Splatting3.material
15:14:12: Parsing script PagingLandScape.material
15:14:12: Parsing script PagingLandScapeTemplate.material
15:14:12: Parsing script Splatting.material
15:14:12: Parsing script Splatting2.material
15:14:12: Parsing script Splatting3.material
15:14:12: Parsing script Splatting4.material
15:14:12: Parsing script Splatting5.material
15:14:12: Error in material SplattingMaterial5 at line 75 of Splatting5.material: Invalid vertex_program_ref entry - vertex program Splatcg/VP has not been defined.
15:14:12: Error in material SplattingMaterial5 at line 97 of Splatting5.material: Invalid fragment_program_ref entry - fragment program Splatcg/FP has not been defined.
I tried commenting out the specified lines in the material files. The errors are gone but my problem was not solved.
Anyways, here is how I partially reproduced the bug in the demo.
I have added a Camera * camera2 member to the class PagingLandScapeFrameListener and I added the following lines in its constructor:
camera2 = mScnMgr->createCamera("MyNewCamera");
Then in its frameStarted member function, I added the lines inside the "if (!mUseBufferedInputKeys)" block (where you test for key presses):
if(mInputDevice->isKeyDown(KC_Q)) {
mWindow->getViewport(0)->setCamera(camera2);
}
Now if you run the demo and press Q to change the camera, it crashes (because mLastViewport of the Camera is zero).
If you substitue the above lines with:
if(mInputDevice->isKeyDown(KC_Q)) {
mWindow->getViewport(0)->setCamera(camera2);
camera2->_notifyViewport(mWindow->getViewport(0));
}
The demo doesn't crash anymore, but my application gets an assertion failure.
I don't think I'm supposed to call _notifyViewport here, and I think mLastViewport not being initialized properly is only part of a bigger initialization of many more parameters. So my call to _notifyViewport only fixed the initialization of mLastViewport and not some other things that need initialization (which the demo happens not to be using). So maybe making setCamera work without a call to _notifyViewport will fix my application too.
I will try a little more to reproduce the problem fully in the demo if I have some more ideas to try out.
Thank you for your troubles.
tuan kuranes
06-11-2005 10:48:50
thanks, i'll look at that tomorrow.
Heh I've been seeing the IPLSM splatting errors on my runs (1.0.5) as well. Hasn't been a big deal for me yet.
fiesch
07-11-2005 07:44:45
Hi.
I happen to have the same assertion failure.
I'm using 2 cameras as well, one being the normal scene cam and one for a RTT preview window.
Crashes when i try to add a new Element to the scene,
same assertion/line/file
both cams are registered with the scene Manager and attached to the scene tree.
tuan kuranes
07-11-2005 13:04:02
using notifyViewport seems ok.
what assertion do you get afterwards ?
Seems an Ogre CVS HEAD bug/design problem, as mLastviewport is never updated, but
Get the last viewport which was attached to this camera.
@note This is not guaranteed to be the only viewport which is
using this camera, just the last once which was created referring
to it.
So either comment or code is wrong, no ?
Maybe we should make a thread in ogre forums.
Samir
07-11-2005 14:14:07
using notifyViewport seems ok.
But it was not needed before, so I don't see why I should use it now, especially when it causes an assertion (or and error in a release build) in my app (did not manage to reproduce that in the Demo).
what assertion do you get afterwards ?
I posted it before:
File: ..\src\OgrePagingLandscapeOcclusionElement.cpp
Line: 41
Expression: nodeDataPerCam[cam->getId()]
It has to do with the Paging Landscape manager, and this is why I posted the bug here and not in the Ogre forum.
So either comment or code is wrong, no ?
Probably the code is wrong since this function worked as stated in the comments in previous versions.
Maybe we should make a thread in ogre forums.
Maybe...I don't know...I'm not sure where the role of PLSM ends and Ogre takes over. But fiesch seems to have the same problem so I don't think there's anything wrong with my code. And again, the assertion is coming from PLSM.
tuan kuranes
07-11-2005 14:23:56
there's 2 separated problem :
1) notify viewport. (cam->getviewport() being null just after a setviewport)
2) 2 camera handling in plsm2.(nodeDataPerCam[cam->getId()])
I'm working on 2, but meanwhile you can avoid it undefining the _VISIBILITYDEBUG and not using CHC.
But First one really seems to be ogre related.
Samir
07-11-2005 15:17:41
I'm working on 2, but meanwhile you can avoid it undefining the _VISIBILITYDEBUG and not using CHC.
I undefined _VISIBILITYDEBUG and I did not set any option in PLSM, so assume that means I'm not using CHC. And still, the assertion persists.
But First one really seems to be ogre related.
OK, at least I have a temporary solution for this one.
BTW, I'm also not seeing all the terrain neither in the Demo nor in my app. Only parts of the terrain show. And debug and release builds result in different parts of the terrain showing. Do you know what might be the cause of that and if it has anything to do with my problem?...I know it has nothing to do with my code and I'm using the same terrain I was using before I downloaded the new PLSM (doesn't work with new terrains either).
tuan kuranes
07-11-2005 15:31:56
Just saw undefineing _VISIBILITYDEBUG won't prevent the bug, that Im still trying to fix. Somewhat mode complicated that I thought.
Only parts of the terrain show. And debug and release builds result in different parts of the terrain showing
Tthere's holes in the terrain or upon a certain distance, tiles are missing ?
Samir
07-11-2005 15:44:51
Just saw undefineing _VISIBILITYDEBUG won't prevent the bug, that Im still trying to fix. Somewhat more complicated that I thought.
I thought the problem might be more then just a simple initialization problem. Good luck fixing that, I wish I was knowledgeable enough at this stage to help you
There's holes in the terrain or upon a certain distance, tiles are missing ?
Tiles are missing. Its like 1/4 of the terrain shows up, and all the tiles around it don't. But the tiles that show up are next to each other. So there is no missing tile in the middle of many others (so its not a hole). But a percentage of them show up to form a larger tile, and everything around them doesn't show up. And sometimes, in release builds, nothing shows up at all.
tuan kuranes
07-11-2005 16:02:15
To limit memory and gpu load, we use "visiblerenderables" that is the radius of tiles visibles at once. You can make this value bigger if you wish.
But that shouldn't be release or debug related, they just should be longer to show up. (interval between loading is using frames number, so huge fps means fast loading.)
Release no showing up at all could be related to last CVS commit, specially if you get huge fps numbers.
try tweaking "TileInvisibleUnloadFrames" and "PageInvisibleUnloadFrames" values to higher values than default in cfg files. if you get 400 FPS try at least TileInvisibleUnloadFrames=1200
Samir
07-11-2005 16:50:04
To limit memory and gpu load, we use "visiblerenderables" that is the radius of tiles visibles at once. You can make this value bigger if you wish.
But that shouldn't be release or debug related, they just should be longer to show up. (interval between loading is using frames number, so huge fps means fast loading.)
Yes, I'm aware of that. But I'm sure my problem has nothing to do with that cause it did not exists before, and the tiles don't show up even up close. So even if I'm zoomed in on one tile, the one next to it does not show up as seen in the screenshot.
Release no showing up at all could be related to last CVS commit, specially if you get huge fps numbers.
Yes probably. And of course I get a higher fps number when there is no terrain
try tweaking "TileInvisibleUnloadFrames" and "PageInvisibleUnloadFrames" values to higher values than default in cfg files. if you get 400 FPS try at least TileInvisibleUnloadFrames=1200
I couldn't find these parameters in any cfg file. I added them to ps_height_1k.cfg but they did not fix the problem. I think its because, as I said above, I don't think this problem is caused by the feature of only showing some tiles at a time, there's either something wrong with terrain or with the code.
Here is another screenshot which might help you understand the problem more:
tuan kuranes
07-11-2005 17:01:38
Strange... seems a page problem.
do MaxAdjacentPages and MaxPreloadedPages are big enough to see more than one page at once (like 3 and 4 ) ?
Samir
07-11-2005 17:10:30
Yes they are.
#
# WINDOWING AROUND CAMERA
#
# Num of adjacent loaded landscape pages.
MaxAdjacentPages=3
#
# Num of adjacent preloaded landscape pages.
# Must be bigger than MaxAdjacentPages + 1, the textures are loaded in a separate thread.
MaxPreloadedPages=4
So I tried 4 and 5, then 5 and 6. Nothing changed.
tuan kuranes
07-11-2005 17:56:18
either try next version from cvs (5 hours til anon cvs get it) or/and try with _VISIBILITYDEBUG and using Demo, hit home key and look on right up of screen if it seems correct.(gray == frustum culled, green == visible)
Samir
08-11-2005 19:29:27
Yey...It worked
... I downloaded the new version from CVS and the assertion disappeared. The tiles not showing issue is still not solved, but I think that's trivial and I can find its solution myself.
Thank you very much for your help. I really appreciate it.
fiesch
10-11-2005 11:02:22
hm the current cvs makes things worse for me - the assertion gets thrown right on startup now, not just when adding new entities...
I'm using the version from today, sth like 4 hours ago
tuan kuranes
10-11-2005 11:12:26
you'll have to disable _VISIBILITYDEBUG define til I fix it.
fiesch
10-11-2005 11:23:31
ah ok, thx