Shadow maps causing mouse/key lag.

Problems building or running the engine, queries about how to use features etc.
Post Reply
User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 19

Shadow maps causing mouse/key lag.

Post by mkultra333 » Tue Jun 02, 2009 7:08 pm

I have implemented nullsquared's shadow maps into a project. I'm using windows XP, ogre 1.6.1 and have a nvidia gt7950 with 512 meg. My project is built around the Basic Ogre Framework.

I have noticed that a serious mouse and keyboard lag issue emerges as I increase the number and/or resolution of the shadow maps. It becomes very obvious at 8 shadow maps of 2048 resolution, and I found I can get it as bad at 3 x 32768, or with 16 maps of lower resolution. At more sensible levels (8 maps x 512 resolution) the problem is still there but less noticable.

The frame rate at the exaggerated levels is about 25 fps, while at the sensible levels it's about 50 fps. I know that framerate will influence lag. But going by http://www.gamasutra.com/view/feature/1 ... veness.php, even at 25fps the lag should only be about 0.15 ms. Although hard to measure, I think it might be as bad as 0.3 or more (with the very large maps), which is very bad and quite noticable. Even with sensible maps, it feels badly sluggish.

I got rid of the shadows and artificially lowered the framerate by adding a sleep(37) command after renderOneFrame. This forced the framerate down to 21 fps, yet there was only minimal mouse lag.

I should also mention that the only other processing is pretty much just standard default camera stuff.

So the critical cause of this terrible unresponsiveness seems to be the shadowmaps. What could the problem be?
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
nullsquared
Old One
Posts: 3245
Joined: Tue Apr 24, 2007 8:23 pm
Location: NY, NY, USA

Re: Shadow maps causing mouse/key lag.

Post by nullsquared » Tue Jun 02, 2009 9:16 pm

8 maps of 2048x2048 is absolutely horrible, of course it will kill your performance. I don't even know how you're doing 25 FPS instead of 1 FPS...

For systems where you need a large amount of shadowed lights with a high resolution shadow map, you need to reuse a single shadow map. Unfortunately, Ogre does not do this by default since it does not assume anything about the way you pipeline works. Generally, the light-prepass method and deferred shading methods work great for this since lights are processed one by one and therefore you can reuse a single large shadow map.
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 19

Re: Shadow maps causing mouse/key lag.

Post by mkultra333 » Wed Jun 03, 2009 2:30 am

I'm aware 8 x 2048 is extreme, that was an example to make sure of the problem. As I pointed out, the problem is still there, though subtler, at "sensible" values like 8 x 512.

Why are lightmaps special as far as causing mouse lag? If I induce 25 fps by other methods I don't get lag, but with light maps I do. I would have thought that 25 fps is 25 fps regarless of the cause, and since the GPU is supposed to be asynchronous it wouldn't matter if it happens due to cpu or gpu.

Deferred shading is out, it is incompatible with stereoscopic mode on my system. I've not heard of light pre-pass, do any of the demo' s show this?

Edit: Does everyone who uses shadow maps either only use 1 (or a few), or use deferred shading?
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 19

Re: Shadow maps causing mouse/key lag.

Post by mkultra333 » Wed Jun 03, 2009 4:20 am

You know what's weird? I got rid of the shadows and just made a shader that passes through a texture and wastes time. It's designed to run slow, even though it just applies a diffuse texture. By doing 8 passes it cuts the frame rate down from 1000 or so to just 20 fps.

This causes the lag to reappear. Yet if I do the same "time wasting" via the cpu with a sleep command, there is no mouse lag.

So why would shaders be causing input lag? I'm using buffered input I think (that's what the basic ogre framework has), I'll try unbuffered and see if there's any difference. [Edit: Nope, unbuffered is exactly as bad.]

And note that 20 fps isn' t really that terrible. It isn't uncommon for newly released games to have this kind of fps when they know that a year down the track there'll be better graphics cards. In itself, 20fps should not cause a significant lag problem.

And while the lag is terrible at 20 fps, this started because I could feel the lag at 50 fps and just exaggerated it to find the problem.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 19

Re: Shadow maps causing mouse/key lag.

Post by mkultra333 » Wed Jun 03, 2009 5:54 am

I've done two more experiments.

I tried a different Ogre framework, demo_shadows.exe, with the time waster shader. Again, there was input lag.
Then I tried the original program but converted the time waster shader to HLSL. Again. there was input lag.

When I again faked low fps by stressing the cpu instead of gpu, the lag mostly vanished.

There's a few more tests I can do. I can try a different input system than OIS, and I can try a different engine other than Ogre. I'm suspicious just because other games I play that may get low fps (20-30) don't seem as laggy as Ogre is at the moment.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 19

Re: Shadow maps causing mouse/key lag.

Post by mkultra333 » Thu Jun 04, 2009 5:42 pm

Thought I'd give an update.

The laggy input is still a mystery to me. I tested windows messages (wm_keydown stuff) for control instead of OIS, but the lag was still there. After various timing experiments it seems that it is the messages themselves which are delayed... I'm not absolutely sure, but that's the impression I get.

And here's more weirdness, and a partial solution. I'm using renderOneFrame, and I've discoved that if I add a Sleep(n) command after renderOneFrame the lag vanishes! The value of n seems to have to be a little over however long the frame took to render. This hurts the frame rate but gets rid of the control lag.

For instance, when I forced the FPS down to 20 with a material, I got really bad lag. But if I added a Sleep(50) command after renderOneFrame the FPS dropped to 16 but the lag disappeared.

Going back to shadow mapping, when I have 8 shadow maps of 256 res, I get about 55 FPS but can feel a little lag. If I add a Sleep(16) the FPS drops to 30 but the lag disappears. But Sleep(15) has no effect, the FPS stays at 55 and the lag is still there.

Any thoughts?
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
Contact:

Re: Shadow maps causing mouse/key lag.

Post by Jabberwocky » Fri Jun 05, 2009 5:36 am

On my laptop (ATI Mobility Radeon x1400), when I run in windows mode, release build, I get a similar "input lag" effect.

Actually, I only get this lag in graphically demanding portions of my game, particularly scenes with large texture memory requirements. Maybe I'm going beyond the texture memory of my video card. Because of this, my "gut feeling" is that this is solely a graphics issue, and has nothing to do with OIS. Somehow, stressing your graphics card causes either a delay in input processing, or perhaps a delay in how long it takes to display the "current" frame.

You may want to check to see if the input lag goes away when in full screen mode. I only get it in windowed mode. As such, I'm less concerned about it because I expect people to play my game in full screen mode. Plus, I don't see the issue at all on more powerful graphics cards.
0 x
Image

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

Re: Shadow maps causing mouse/key lag.

Post by Vectrex » Fri Jun 05, 2009 5:35 pm

I get that in windowed mode, not in full screen which is fine.
0 x

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 19

Re: Shadow maps causing mouse/key lag.

Post by mkultra333 » Sat Jun 06, 2009 2:02 pm

Thanks for your replies, Jabberwocky, JustBoo and Vectrex.

First up, sorry for the long post. Skim to the timing tables for some interesting data...

Regarding windowed mode verus fullscreen, I'm running fullscreen.
JustBoo: If this is a Windows machine then IIRC, Sleep() calls Yield() which allows other threads and more importantly the message-pump to run. In fact, Sleep() can be used as a cheap-trick to allow other threads and the message-pump to run.
I thought it might be something like that, but I've now discovered that any kind of cpu time-wasting fixes the issue. It doesn't have to be Sleep(). I got the same fix with a pointless "while" loop that just counted down from 800000 or so.

I tried moving the message pump to different locations within the rendering loop, but that hasn't helped. I even tried looping the message pump mulitple times, and even removing it completely. But none of these made any difference.

I've found some more interesting data though. First up, I'll just post my log so there's an complete description of my card, cpu and so on.

Code: Select all

20:12:46: Creating resource group General
20:12:46: Creating resource group Internal
20:12:46: Creating resource group Autodetect
20:12:46: SceneManagerFactory for type 'DefaultSceneManager' registered.
20:12:46: Registering ResourceManager for type Material
20:12:46: Registering ResourceManager for type Mesh
20:12:46: Registering ResourceManager for type Skeleton
20:12:46: MovableObjectFactory for type 'ParticleSystem' registered.
20:12:46: OverlayElementFactory for type Panel registered.
20:12:46: OverlayElementFactory for type BorderPanel registered.
20:12:46: OverlayElementFactory for type TextArea registered.
20:12:46: Registering ResourceManager for type Font
20:12:46: ArchiveFactory for archive type FileSystem registered.
20:12:46: ArchiveFactory for archive type Zip registered.
20:12:46: FreeImage version: 3.10.0
20:12:46: This program uses FreeImage, a free, open source image library supporting all common bitmap formats. See http://freeimage.sourceforge.net for details
20:12:46: Supported formats: bmp,ico,jpg,jif,jpeg,jpe,jng,koa,iff,lbm,mng,pbm,pbm,pcd,pcx,pgm,pgm,png,ppm,ppm,ras,tga,targa,tif,tiff,wap,wbmp,wbm,psd,cut,xbm,xpm,gif,hdr,g3,sgi,exr,j2k,j2c,jp2
20:12:46: DDS codec registering
20:12:46: Registering ResourceManager for type HighLevelGpuProgram
20:12:46: Registering ResourceManager for type Compositor
20:12:46: MovableObjectFactory for type 'Entity' registered.
20:12:46: MovableObjectFactory for type 'Light' registered.
20:12:46: MovableObjectFactory for type 'BillboardSet' registered.
20:12:46: MovableObjectFactory for type 'ManualObject' registered.
20:12:46: MovableObjectFactory for type 'BillboardChain' registered.
20:12:46: MovableObjectFactory for type 'RibbonTrail' registered.
20:12:46: Loading library .\RenderSystem_Direct3D9
20:12:46: Installing plugin: D3D9 RenderSystem
20:12:46: D3D9 : Direct3D9 Rendering Subsystem created.
20:12:46: D3D9: Driver Detection Starts
20:12:46: D3D9: Driver Detection Ends
20:12:46: Plugin successfully installed
20:12:46: Loading library .\RenderSystem_GL
20:12:47: Installing plugin: GL RenderSystem
20:12:47: OpenGL Rendering Subsystem created.
20:12:47: Plugin successfully installed
20:12:47: Loading library .\Plugin_CgProgramManager
20:12:47: Installing plugin: Cg Program Manager
20:12:47: Plugin successfully installed
20:12:47: *-*-* OGRE Initialising
20:12:47: *-*-* Version 1.6.1 (Shoggoth)
20:12:47: Registering ResourceManager for type RawFile
20:12:47: Creating resource group Raw Bsp
20:12:47: D3D9 : RenderSystem Option: Allow NVPerfHUD = No
20:12:47: D3D9 : RenderSystem Option: Anti aliasing = None
20:12:47: D3D9 : RenderSystem Option: Floating-point mode = Fastest
20:12:47: D3D9 : RenderSystem Option: Full Screen = Yes
20:12:47: D3D9 : RenderSystem Option: Rendering Device = NVIDIA GeForce 7950 GT
20:12:47: D3D9 : RenderSystem Option: VSync = No
20:12:47: D3D9 : RenderSystem Option: Video Mode = 1024 x 768 @ 32-bit colour
20:12:47: D3D9 : RenderSystem Option: sRGB Gamma Conversion = No
20:12:47: CPU Identifier & Features
20:12:47: -------------------------
20:12:47:  *   CPU ID: AuthenticAMD: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+
20:12:47:  *      SSE: yes
20:12:47:  *     SSE2: yes
20:12:47:  *     SSE3: yes
20:12:47:  *      MMX: yes
20:12:47:  *   MMXEXT: yes
20:12:47:  *    3DNOW: yes
20:12:47:  * 3DNOWEXT: yes
20:12:47:  *     CMOV: yes
20:12:47:  *      TSC: yes
20:12:47:  *      FPU: yes
20:12:47:  *      PRO: yes
20:12:47:  *       HT: no
20:12:47: -------------------------
20:12:47: D3D9 : Subsystem Initialising
20:12:47: D3D9RenderSystem::_createRenderWindow "DemoApp v1.0", 1024x768 fullscreen  miscParams: FSAA=0 FSAAQuality=0 colourDepth=32 gamma=false useNVPerfHUD=false vsync=false 
20:12:47: D3D9 : Created D3D9 Rendering Window 'DemoApp v1.0' : 1024x768, 32bpp
20:12:47: Registering ResourceManager for type Texture
20:12:47: Registering ResourceManager for type GpuProgram
20:12:47: D3D9: Vertex texture format supported - PF_FLOAT32_RGB
20:12:47: D3D9: Vertex texture format supported - PF_FLOAT32_RGBA
20:12:47: D3D9: Vertex texture format supported - PF_FLOAT32_R
20:12:47: RenderSystem capabilities
20:12:47: -------------------------
20:12:47: RenderSystem Name: Direct3D9 Rendering Subsystem
20:12:47: GPU Vendor: nvidia
20:12:47: Device Name: NVIDIA GeForce 7950 GT
20:12:47: Driver Version: 6.14.11.6375
20:12:47:  * Fixed function pipeline: yes
20:12:47:  * Hardware generation of mipmaps: yes
20:12:47:  * Texture blending: yes
20:12:47:  * Anisotropic texture filtering: yes
20:12:47:  * Dot product texture operation: yes
20:12:47:  * Cube mapping: yes
20:12:47:  * Hardware stencil buffer: yes
20:12:47:    - Stencil depth: 8
20:12:47:    - Two sided stencil support: yes
20:12:47:    - Wrap stencil values: yes
20:12:47:  * Hardware vertex / index buffers: yes
20:12:47:  * Vertex programs: yes
20:12:47:  * Fragment programs: yes
20:12:47:  * Geometry programs: no
20:12:47:  * Supported Shader Profiles: hlsl ps_1_1 ps_1_2 ps_1_3 ps_1_4 ps_2_0 ps_2_a ps_2_b ps_2_x ps_3_0 vs_1_1 vs_2_0 vs_2_a vs_2_x vs_3_0
20:12:47:  * Texture Compression: yes
20:12:47:    - DXT: yes
20:12:47:    - VTC: no
20:12:47:  * Scissor Rectangle: yes
20:12:47:  * Hardware Occlusion Query: yes
20:12:47:  * User clip planes: yes
20:12:47:  * VET_UBYTE4 vertex element type: yes
20:12:47:  * Infinite far plane projection: yes
20:12:47:  * Hardware render-to-texture: yes
20:12:47:  * Floating point textures: yes
20:12:47:  * Non-power-of-two textures: yes
20:12:47:  * Volume textures: yes
20:12:47:  * Multiple Render Targets: 4
20:12:47:    - With different bit depths: no
20:12:47:  * Point Sprites: yes
20:12:47:  * Extended point parameters: yes
20:12:47:  * Max Point Size: 8192
20:12:47:  * Vertex texture fetch: yes
20:12:47:    - Max vertex textures: 4
20:12:47:    - Vertex textures shared: no
20:12:47:  * Render to Vertex Buffer : no
20:12:47:  * DirectX per stage constants: yes
20:12:47: ***************************************
20:12:47: *** D3D9 : Subsystem Initialised OK ***
20:12:47: ***************************************
20:12:47: ResourceBackgroundQueue - threading disabled
20:12:47: Particle Renderer Type 'billboard' registered
20:12:47: Creating resource group Bootstrap
20:12:47: Added resource location 'media/packs/OgreCore.zip' of type 'Zip' to resource group 'Bootstrap'
20:12:47: Added resource location 'media' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/gui' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/maps' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/materials' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/materials/programs' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/materials/textures' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/materials/scripts' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/overlays' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/textures' of type 'FileSystem' to resource group 'General'
20:12:47: Added resource location 'media/packs/cubemapsJS.zip' of type 'Zip' to resource group 'General'
20:12:47: Added resource location 'media/packs/skybox.zip' of type 'Zip' to resource group 'General'
20:12:47: Added resource location 'media/textures/cubemap.zip' of type 'Zip' to resource group 'General'
20:12:47: Demo initialized!
20:12:47: Parsing scripts for resource group Autodetect
20:12:47: Finished parsing scripts for resource group Autodetect
20:12:47: Parsing scripts for resource group Bootstrap
20:12:47: Parsing script OgreCore.material
20:12:47: Parsing script OgreProfiler.material
20:12:47: Parsing script Ogre.fontdef
20:12:47: Parsing script OgreDebugPanel.overlay
20:12:47: Texture: New_Ogre_Border_Center.png: Loading 1 faces(PF_A8R8G8B8,256x128x1) with  hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,256x128x1.
20:12:47: Texture: New_Ogre_Border.png: Loading 1 faces(PF_A8R8G8B8,256x256x1) with  hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,256x256x1.
20:12:47: Texture: New_Ogre_Border_Break.png: Loading 1 faces(PF_A8R8G8B8,32x32x1) with  hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,32x32x1.
20:12:47: Font BlueHighwayusing texture size 512x512
20:12:47: Info: Freetype returned null for character 127 in font BlueHighway
20:12:47: Info: Freetype returned null for character 128 in font BlueHighway
20:12:47: Info: Freetype returned null for character 129 in font BlueHighway
20:12:47: Info: Freetype returned null for character 130 in font BlueHighway
20:12:47: Info: Freetype returned null for character 131 in font BlueHighway
20:12:47: Info: Freetype returned null for character 132 in font BlueHighway
20:12:47: Info: Freetype returned null for character 133 in font BlueHighway
20:12:47: Info: Freetype returned null for character 134 in font BlueHighway
20:12:47: Info: Freetype returned null for character 135 in font BlueHighway
20:12:47: Info: Freetype returned null for character 136 in font BlueHighway
20:12:47: Info: Freetype returned null for character 137 in font BlueHighway
20:12:47: Info: Freetype returned null for character 138 in font BlueHighway
20:12:47: Info: Freetype returned null for character 139 in font BlueHighway
20:12:47: Info: Freetype returned null for character 140 in font BlueHighway
20:12:47: Info: Freetype returned null for character 141 in font BlueHighway
20:12:47: Info: Freetype returned null for character 142 in font BlueHighway
20:12:47: Info: Freetype returned null for character 143 in font BlueHighway
20:12:47: Info: Freetype returned null for character 144 in font BlueHighway
20:12:47: Info: Freetype returned null for character 145 in font BlueHighway
20:12:47: Info: Freetype returned null for character 146 in font BlueHighway
20:12:47: Info: Freetype returned null for character 147 in font BlueHighway
20:12:47: Info: Freetype returned null for character 148 in font BlueHighway
20:12:47: Info: Freetype returned null for character 149 in font BlueHighway
20:12:47: Info: Freetype returned null for character 150 in font BlueHighway
20:12:47: Info: Freetype returned null for character 151 in font BlueHighway
20:12:47: Info: Freetype returned null for character 152 in font BlueHighway
20:12:47: Info: Freetype returned null for character 153 in font BlueHighway
20:12:47: Info: Freetype returned null for character 154 in font BlueHighway
20:12:47: Info: Freetype returned null for character 155 in font BlueHighway
20:12:47: Info: Freetype returned null for character 156 in font BlueHighway
20:12:47: Info: Freetype returned null for character 157 in font BlueHighway
20:12:47: Info: Freetype returned null for character 158 in font BlueHighway
20:12:47: Info: Freetype returned null for character 159 in font BlueHighway
20:12:47: Info: Freetype returned null for character 160 in font BlueHighway
20:12:47: Texture: BlueHighwayTexture: Loading 1 faces(PF_BYTE_LA,512x512x1) with 0 generated mipmaps from Image. Internal format is PF_BYTE_LA,512x512x1.
20:12:47: Texture: ogretext.png: Loading 1 faces(PF_A8R8G8B8,256x128x1) with  hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,256x128x1.
20:12:47: Parsing script OgreLoadingPanel.overlay
20:12:47: Finished parsing scripts for resource group Bootstrap
20:12:47: Parsing scripts for resource group General
20:12:47: Parsing script 00ambient.material
20:12:47: Parsing script 00diffuse.material
20:12:47: OGRE EXCEPTION(2:InvalidParametersException): Parameter called lightAtt0 does not exist.  in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1097)
20:12:47: Compiler error: invalid parameters in 00diffuse.material(33): setting of constant failed
20:12:47: OGRE EXCEPTION(2:InvalidParametersException): Parameter called invSMSize does not exist.  in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1097)
20:12:47: Compiler error: invalid parameters in 00diffuse.material(34): setting of constant failed
20:12:47: OGRE EXCEPTION(2:InvalidParametersException): Parameter called lightAtt0 does not exist.  in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1097)
20:12:47: Compiler error: invalid parameters in 00diffuse.material(54): setting of constant failed
20:12:47: OGRE EXCEPTION(2:InvalidParametersException): Parameter called invSMSize does not exist.  in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1097)
20:12:47: Compiler error: invalid parameters in 00diffuse.material(55): setting of constant failed
20:12:47: Parsing script metal.material
20:12:47: Parsing script ReliefMap.material
20:12:48: OGRE EXCEPTION(7:InternalErrorException): Unable to compile Cg program diffuse_ps: CG ERROR : The compile returned an error.
(0) : error C3001: no program defined
 in CgProgram::loadFromSource at ..\src\OgreCgProgramManagerDll.cpp (line 66)
20:12:48: High-level program diffuse_ps encountered an error during loading and is thus not supported.
OGRE EXCEPTION(7:InternalErrorException): Unable to compile Cg program diffuse_ps: CG ERROR : The compile returned an error.
(0) : error C3001: no program defined
 in CgProgram::loadFromSource at ..\src\OgreCgProgramManagerDll.cpp (line 66)
20:12:48: OGRE EXCEPTION(2:InvalidParametersException): Named constants have not been initialised, perhaps a compile error. in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1087)
20:12:48: Compiler error: invalid parameters in ReliefMap.material(79): setting of constant failed
20:12:48: OGRE EXCEPTION(2:InvalidParametersException): Named constants have not been initialised, perhaps a compile error. in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1087)
20:12:48: Compiler error: invalid parameters in ReliefMap.material(80): setting of constant failed
20:12:48: OGRE EXCEPTION(2:InvalidParametersException): Named constants have not been initialised, perhaps a compile error. in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1087)
20:12:48: Compiler error: invalid parameters in ReliefMap.material(81): setting of constant failed
20:12:48: OGRE EXCEPTION(2:InvalidParametersException): Named constants have not been initialised, perhaps a compile error. in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1087)
20:12:48: Compiler error: invalid parameters in ReliefMap.material(82): setting of constant failed
20:12:48: OGRE EXCEPTION(2:InvalidParametersException): Named constants have not been initialised, perhaps a compile error. in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1087)
20:12:48: Compiler error: invalid parameters in ReliefMap.material(83): setting of constant failed
20:12:48: OGRE EXCEPTION(2:InvalidParametersException): Named constants have not been initialised, perhaps a compile error. in GpuProgramParameters::_findNamedConstantDefinition at ..\src\OgreGpuProgram.cpp (line 1087)
20:12:48: Compiler error: invalid parameters in ReliefMap.material(84): setting of constant failed
20:12:48: Parsing script shadow_caster.material
20:12:48: Parsing script test.material
20:12:48: Parsing script Compositor.overlay
20:12:48: Parsing script DP3.overlay
20:12:48: Parsing script Example-CubeMapping.overlay
20:12:48: Parsing script Example-DynTex.overlay
20:12:48: Parsing script Example-Water.overlay
20:12:48: Parsing script Shadows.overlay
20:12:48: Finished parsing scripts for resource group General
20:12:48: Parsing scripts for resource group Internal
20:12:48: Finished parsing scripts for resource group Internal
20:12:48: Parsing scripts for resource group Raw Bsp
20:12:48: Finished parsing scripts for resource group Raw Bsp
20:12:48: LoadMap.
20:12:48: Texture: exp00.tga: Loading 1 faces(PF_R8G8B8,512x512x1) with  hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,512x512x1.
20:12:48: Texture: exp00_nbi.tga: Loading 1 faces(PF_A8R8G8B8,512x512x1) with  hardware generated mipmaps from Image. Internal format is PF_A8R8G8B8,512x512x1.
20:12:48: Start main loop...
20:12:48: Texture: spot_shadow_fade.png: Loading 1 faces(PF_R8G8B8,128x128x1) with  hardware generated mipmaps from Image. Internal format is PF_X8R8G8B8,128x128x1.
20:12:55: Main loop quit
20:12:55: Shutdown OGRE...
20:12:55: Unregistering ResourceManager for type RawFile
20:12:55: *-*-* OGRE Shutdown
20:12:55: Unregistering ResourceManager for type Compositor
20:12:55: Unregistering ResourceManager for type Font
20:12:55: Unregistering ResourceManager for type Skeleton
20:12:55: Unregistering ResourceManager for type Mesh
20:12:55: Unregistering ResourceManager for type HighLevelGpuProgram
20:12:55: Uninstalling plugin: Cg Program Manager
20:12:55: Plugin successfully uninstalled
20:12:55: Unloading library .\Plugin_CgProgramManager
20:12:55: Uninstalling plugin: GL RenderSystem
20:12:55: *** Stopping Win32GL Subsystem ***
20:12:55: Plugin successfully uninstalled
20:12:55: Unloading library .\RenderSystem_GL
20:12:55: Uninstalling plugin: D3D9 RenderSystem
20:12:56: D3D9 : Shutting down cleanly.
20:12:56: Unregistering ResourceManager for type Texture
20:12:56: Unregistering ResourceManager for type GpuProgram
20:12:56: D3D9 : Direct3D9 Rendering Subsystem destroyed.
20:12:56: Plugin successfully uninstalled
20:12:56: Unloading library .\RenderSystem_Direct3D9
20:12:56: Unregistering ResourceManager for type Material
Don't worry about the lines claiming shader errors, the shader compiler just does that when you aren't using some of the input parameters. The actual shaders I'm rendering are working fine, I've even tested it with a cut down super-simple shader and gotten the same results. Hehe, that probably sounds bad but trust me, the shaders are fine. If they weren't, I'd just be getting the raw polygons rendering and 1000 fps, no lag. :)

In a nutshell, I'm running a windows XP service pack 2 on an Athlon Dual Core with 1 meg, and my graphics card is a nvidia 7950GT with 512 megs. So not cutting edge, but not an uncommon setup and respectable enough.

Here is my main rendering loop. It's a very standard affair, the basic ogre framework, http://www.ogre3d.org/wiki/index.php/Ba ... _Framework

Code: Select all

while(!m_bShutdown && !OgreFramework::getSingletonPtr()->isOgreToBeShutDown()) 
	{
		if(OgreFramework::getSingletonPtr()->m_pRenderWnd->isClosed())m_bShutdown = true;

#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
			Ogre::WindowEventUtilities::messagePump() ;
#endif	



		if(OgreFramework::getSingletonPtr()->m_pRenderWnd->isActive())
		{
			startTime = OgreFramework::getSingletonPtr()->m_pTimer->getMicroseconds();
					
			OgreFramework::getSingletonPtr()->m_pKeyboard->capture();
			OgreFramework::getSingletonPtr()->m_pMouse->capture();

			OgreFramework::getSingletonPtr()->updateOgre(timeSinceLastFrame/1000.0f);
			
			OgreFramework::getSingletonPtr()->m_pRoot->renderOneFrame();

			timeSinceLastFrame = OgreFramework::getSingletonPtr()->m_pTimer->getMicroseconds() - startTime;
			
		}
		else
		{
			Sleep(1000);
		}
	}
The only thing I've changed now is to use getMicroseconds() instead of getMillisecondsCPU(). I only just changed this because I needed more accurate timing for the following tests, up until now I've been using getMillisecondsCPU().

That above loop is the one that lags at low FPS. 55 FPS you can feel it, down around 20-30 and it's really bad. So I did some timings. This table shows the time taken for the "physics" (which is input plus moving the camera), how long for the "render" (which is the time from the start to the end of renderOneFrame), and the total time for the entire frame. The times are in microseconds.

Code: Select all

Original timings. Physics + Render. 26.4 FPS, Bad input lag.

19:50:11:    Microsecs:   Physics    Render     Total
19:50:11:    ----------------------------------------
19:50:11:    Frame   0:       192     99241     99434
19:50:11:    Frame   1:       194      3729      3925
19:50:11:    Frame   2:       191      3040      3233
19:50:11:    Frame   3:       185     24324     24511
19:50:11:    Frame   4:       188      8566      8756
19:50:11:    Frame   5:       188     19793     19983
19:50:11:    Frame   6:       190     37473     37754
19:50:11:    Frame   7:       264     37234     37500
19:50:11:    Frame   8:       189     37655     37846
19:50:11:    Frame   9:       187     37623     37812
19:50:11:    Frame  10:       189     37460     37652
19:50:11:    Frame  11:       191     37677     37869
19:50:11:    Frame  12:       191     37646     37839
19:50:11:    Frame  13:       188     37593     37783
19:50:11:    Frame  14:       192     37676     37870
19:50:11:    Frame  15:       188     37651     37842
19:50:11:    Frame  16:       190     37653     37845
19:50:11:    Frame  17:       189     37616     37807
19:50:11:    Frame  18:       190     38172     38365
19:50:11:    Frame  19:       190     37663     37855
19:50:11:    Frame  20:       188     37664     37855
19:50:11:    Frame  21:       188     37655     37845
19:50:11:    Frame  22:       191     37650     37844
19:50:11:    Frame  23:       192     37676     37870
19:50:11:    Frame  24:       191     37655     37848
19:50:11:    Frame  25:       189     37588     37779
19:50:11:    Frame  26:       191     37608     37801
19:50:11:    Frame  27:       188     37590     37781
19:50:11:    Frame  28:       228     37636     37866
19:50:11:    Frame  29:       189     37595     37787
Notice that after the first few frames it falls into a pattern of taking approximately 37 milliseconds for renderOneFrame to run, and just a bit more for the entire frame (because of adding on the physics).

Now below is the same again, only now I've changed the render loop so that it always takes 20 ms. The main thing I've added is the following time delay based on the physics and render times. This gets executed just after renderOneFrame.

Code: Select all

			Time_Delay=50000-(Time_Physics+Time_Render) ;

			// clamp the value so we don't get anything too long or weird.
			if(Time_Delay<1) 
				Time_Delay=1 ;
			else
				if(Time_Delay>100000)
					Time_Delay=100000 ;

			Time_Delay=OgreFramework::getSingletonPtr()->m_pTimer->getMicroseconds()+Time_Delay ;

			// now wait...
			while(OgreFramework::getSingletonPtr()->m_pTimer->getMicroseconds()<Time_Delay) ;
This forces the FPS to drop from 26.4 down to exactly 20.0 and gives the following timing results.

Code: Select all

Modified timings (Forced 50ms per frame).  Physics + Render + Delay.  20.0 FPS, No input lag.

20:02:20:    Microsecs:   Physics    Render     Total
20:02:20:    ----------------------------------------
20:02:20:    Frame   0:       193    100056    200251
20:02:20:    Frame   1:       194      3726     50002
20:02:20:    Frame   2:       192      3095     50003
20:02:20:    Frame   3:       189      3773     50003
20:02:20:    Frame   4:       190      3075     50003
20:02:20:    Frame   5:       189      3057     50003
20:02:20:    Frame   6:       190      3075     50001
20:02:20:    Frame   7:       189      3024     50003
20:02:20:    Frame   8:       189      3143     50003
20:02:20:    Frame   9:       186      3087     50003
20:02:20:    Frame  10:       191      3045     50003
20:02:20:    Frame  11:       189      3123     50005
20:02:20:    Frame  12:       191      3060     50002
20:02:20:    Frame  13:       188      3229     50003
20:02:20:    Frame  14:       188      3044     50002
20:02:20:    Frame  15:       190      3095     50004
20:02:20:    Frame  16:       190      3059     50002
20:02:20:    Frame  17:       190      3064     50004
20:02:20:    Frame  18:       211      3736     50002
20:02:20:    Frame  19:       206      3072     50002
20:02:20:    Frame  20:       206      3073     50003
20:02:20:    Frame  21:       205      3074     50001
20:02:20:    Frame  22:       205      3067     50004
20:02:20:    Frame  23:       207      3275     50002
20:02:20:    Frame  24:       207      3079     50004
20:02:20:    Frame  25:       205      3036     50003
20:02:20:    Frame  26:       205      3087     50003
20:02:20:    Frame  27:       207      3078     50005
20:02:20:    Frame  28:       206      3584     50003
20:02:20:    Frame  29:       205      3075     50004
What's really interesting about this is that the time taken for renderOneFrame has dropped from over 37000 to about 3000. And the input lag has disappeared.

I can force it further than that. The original code was taking about 37ms per frame and lagging. If I change the delay from 50ms to 38ms I get almost the original frame rate, but the lag disappears and again I get low 3000 renderOneFrame times.

Code: Select all

  
Modified timings (Forced 38ms per frame).  Physics + Render + Delay.  26.3 FPS, No input lag.

20:09:57:    Microsecs:   Physics    Render     Total
20:09:57:    ----------------------------------------
20:09:57:    Frame   0:       196     99131    199328
20:09:57:    Frame   1:       193      3746     38002
20:09:57:    Frame   2:       192      3060     38003
20:09:57:    Frame   3:       187      3075     38003
20:09:57:    Frame   4:       190      3250     38003
20:09:57:    Frame   5:       190      3079     38003
20:09:57:    Frame   6:       189      3215     38003
20:09:57:    Frame   7:       186      3084     38004
20:09:57:    Frame   8:       191      3132     38002
20:09:57:    Frame   9:       187      3070     38004
20:09:57:    Frame  10:       190      3053     38004
20:09:57:    Frame  11:       190      3056     38005
20:09:57:    Frame  12:       190      3140     38002
20:09:57:    Frame  13:       226      3252     38002
20:09:57:    Frame  14:       188      3055     38003
20:09:57:    Frame  15:       191      3059     38002
20:09:57:    Frame  16:       190      3051     38003
20:09:57:    Frame  17:       189      3064     38004
20:09:57:    Frame  18:       190      3061     38004
20:09:57:    Frame  19:       188      3059     38002
20:09:57:    Frame  20:       190      3248     38003
20:09:57:    Frame  21:       187      3152     38002
20:09:57:    Frame  22:       190      3018     38004
20:09:57:    Frame  23:       211      3630     38001
20:09:57:    Frame  24:       205      3072     38002
20:09:57:    Frame  25:       204      3145     38003
20:09:57:    Frame  26:       242      3072     38003
20:09:57:    Frame  27:       205      3169     38004
20:09:57:    Frame  28:       205      3073     38003
20:09:57:    Frame  29:       203      3358     38003
So the trigger for the lag seems to be recalling renderOneFrame before it has really finished rendering the prior one. Now I just need to work out how to compensate for that... my first few naive attempts have been jumpy, but hopefully I'll have something soon.
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

User avatar
Jabberwocky
OGRE Moderator
OGRE Moderator
Posts: 2819
Joined: Mon Mar 05, 2007 11:17 pm
Location: Canada
Contact:

Re: Shadow maps causing mouse/key lag.

Post by Jabberwocky » Sat Jun 06, 2009 9:11 pm

So the immediately interesting thing here is the faster renderOneFrame call where you've clamped the FPS to 50ms.

I'm not overly familiar with the low level workings of DirectX or graphics code in general. But one explanation is that the majority of the 37000 renderOneFrame time is actually due to waiting on some kind of blocking call to DirectX or some other external system call. When you add the busy loop, this allows external system call to process, eliminating the wait time from Ogre3D's renderOneFrame time. This causes renderOneFrame to process much more quickly (to about 3000), as it no longer has any hang time.

What is still a mystery is the exact mechanism behind what causes the input lag, and the best way to eliminate it in a manner that will work on different computer hardware.
0 x
Image

User avatar
mkultra333
Gold Sponsor
Gold Sponsor
Posts: 1869
Joined: Sun Mar 08, 2009 5:25 am
x 19

Re: Shadow maps causing mouse/key lag.

Post by mkultra333 » Sun Jun 07, 2009 1:44 pm

What is still a mystery is the exact mechanism behind what causes the input lag, and the best way to eliminate it in a manner that will work on different computer hardware.
After many failed attempts to used timings and delays to fix the issue, I found a solution, at least for DirectX. It's kind of extreme, and requires recompiling the Ogre D3D9 render dll, but it should be ok on different systems.

Since this problem has ended up a long way from where I started (nothing to do with shadowmaps per se) and requires the attention of someone who knows Ogre inside-out, I've posted the solution over here: http://www.ogre3d.org/forums/viewtopic.php?f=5&t=50486. Hopefully it will get some attention and no one will slap me for cross posting. :)
0 x
"In theory there is no difference between practice and theory. In practice, there is." - Psychology Textbook.

Post Reply