Game Development Community

Rendering problems (Resolved)

by Ivan Mandzhukov · in Torque 3D Professional · 03/04/2011 (11:16 am) · 13 replies

Hello everyone,
I've been having problems with render jitterings lately. I've been searching to fix these problems and nothing seems to fix them. It's about jittering in both BL and AL at Fullscreen. No matter if I run the stock T3D or my own project these render jitterings appear randomly in time but they appear every time I start my application. It has nothing to do with the fps because in more than 100 fps jitterings still happen.
I have tested both T3D 1.0 and T3D 1.1 beta 3.
I tested that on three computers with these parameters:

PC1:
Quad Core Q9450
ATI 5670
4 GB RAM

PC2:
Core Duo 2.4 Ghz
ATI Radeon X1950XTX
4 GB RAM

PC3:
Pentium4 2.8 Ghz
ATI Radeon 9800XT
1 GB RAM

No matter of the PC these jitterings happen randomly on runtime, but they look the same on the 3 PCs.
Obviously that are not problems regarding DirectX or drivers.
I have tested that with Direct X march 2009 , feb 2010 and june 2010.

On PC2 there is even another problem - in Advanced Lighting GPU Recovery turns on.
Obviously we are talking about serious problems with rendering. I decided to start this thread because it is of great importance for me to get these problems fixed since it is unthinkable to release a game in that position.
I have tested 3D marks and other games on that computers and there are no problems with them, therefore these problems are obviously related to T3D only!

You can see these jitterings even on the stock T3D engine.
For the first time since I started making my game I decided to test T3D on several PCs at Fullscreen and the results are more than deplorable.

I would be glad to hear any thoughts regarding this.


#1
03/04/2011 (11:36 am)
Could you explain what you mean by jitterings a bit more? Or even better if you have a screenshots or a video that would help a lot.
#2
03/04/2011 (11:52 am)
by jittering I mean that during game play (let's say you are moving around with the player) at a certain moment (for a very short period of time, less than a second) the camera jitters instead of moving smoothly as espected. Of cource this happens randomly.

Moreover if you have an objects with an IFL animation you can see that jumping in the frames on it too.

It is very unpleasant during game play.
Screenshot won't explain anything for sure...

I will make a video tomorrow showing that in the FPS example (Burg scene) the wheels animation is not smooth but skipping frames.
The jittering occurs on particles too.
#3
03/04/2011 (12:02 pm)
Ivan, do you have any lights on the scene? If so, disable shadow on them and check if it helps.
We have found that rendering more than 1 light with shadows enabled can give that short-period "jitters".
#4
03/04/2011 (12:34 pm)
I would have called that "hitching" myself. Sounds like you mean your framerate drops or rendering is suspended for a short period. Have you tried it with framerate displayed to see if the frame count is affected? Does it hold frame on an exact period - say exactly every 5 seconds? Is the hold for the same length of time every time it does it?

I'm wondering because I've had an issue like this pop up intermittently. For me it would hitch every 7 seconds or so for approximately a 10th of a second - just enough to notice. It happened every time I ran that particular level, but on other projects this problem was absent. I had made no source changes, but I was playing with materials alot. It hasn't happened to me yet on beta 3, so I figured it was gone.

Might this have something to do with detail map sizes or other material map sizes possibly? If the same thing is occurring regardless of hardware perhaps there is some sort of video throughput barrier he's running into and all of his cards happen to have similar memory performance?

Now that I think about it, I was playing with lighting then, too....
#5
03/04/2011 (12:51 pm)
It's like you describe Richard.
The FPS is still high, but it looks like there are some of the frames are dropped, or takes more time to render than others.
After profiling those moments I've found this:
100.000   0.648      397   MainLoop
 52.840  52.840      397     SwapBuffers
 45.546   0.979      397     CanvasRenderControls
 42.488   0.002      397       GameRenderWorld
 42.480   0.429      397         SceneGraphRender
 22.022   0.001      397           TraverseScene
 22.021   0.004      397             RenderCurrentImages
 21.911   0.658      397               RenderPassManager_Render
 13.324   0.104      397                 AdvancedLightManager_Render
 13.026   0.002      376                   LightShadowMap_prepLightRender
 13.025  13.025      376                     GFXD3D9OcclusionQuery_getStatus
///the rest is skipped as it takes less than 0.01
When I change lights so it doesn't cast shadows, the profiler gives different stack and I don't see "jitters".

I plan to spend some time on this issue, so if/wheb I have any details I'll report.
#6
03/04/2011 (1:28 pm)
Fyodor, Richard,

it is like you describe it. The framerate is high, but I see that hitching. I don't know the reason, may be your description is the best - some frames take more time to render, i.e. the framerate is displayed to be high but in fact it is low and I get that hitching... May be the frame synchronization lacks. For example if we have 100 fps it means that every frame should happen at 10 ms exactly each. But it seems that some of the frames happen earlier/faster.

By the way I made two videos with my camera instead of Fraps, because using Fraps when I start recording the video the hitching disappears, when I stop the recording the hitching appears again. Therefore I come to use my camera to record what's happening.

The first video : www.filesonic.com/file/156692671
Look at the weapon how it jitters.

The second video: www.filesonic.com/file/156661281
It may be harder to notice , but the wheel moves not smoothly (the fps is high enough). A very short jittering can be seen.

That are just examples.

Anyway on my PC2 configuration is it impossible to play the game with Advanced lighting since my VPU recovery turns on very ofter. The last time that happened I had to turn off the PC from the button....

In addition:
Setting "cast shadows" to 0 on the light sources in my scene (where the only light casting source is the Sun) doesn't fix anything. However the game is still played better under Basic Lighting than Advanced Lighting.
#7
03/04/2011 (1:37 pm)
you probably have checked this,
but it sounds like the camera is doing this
// shake camera on ground impact
   if( bd > mDataBlock->groundImpactMinSpeed && isControlObject() )
   {
      F32 ampScale = (bd - mDataBlock->groundImpactMinSpeed) / mDataBlock->minImpactSpeed;

      CameraShake *groundImpactShake = new CameraShake;
      groundImpactShake->setDuration( mDataBlock->groundImpactShakeDuration );
      groundImpactShake->setFrequency( mDataBlock->groundImpactShakeFreq );

      VectorF shakeAmp = mDataBlock->groundImpactShakeAmp * ampScale;
      groundImpactShake->setAmplitude( shakeAmp );
      groundImpactShake->setFalloff( mDataBlock->groundImpactShakeFalloff );
      groundImpactShake->init();
      gCamFXMgr.addFX( groundImpactShake );
   }

did you change the players groundImpactMinSpeed?

#8
03/04/2011 (2:21 pm)
After watching the vid -- it's not the same issue I was talking about.
The first idea now is the same as deepscratch is talking about..

btw, how does it behave if you set $timeScale to something like 0.1 or 0.2 ? Will those hitches appear "slowly" too?
#9
03/05/2011 (12:22 am)
We are talking about different things.
It is not a camera effect,because the jittering is visible with a static camera on particle systems, animations, etc..
On my project I have more than 120 fps and there is still a jittering.When it happens, it can be seen as periodical clogs on the entire game loop - physics,animation,rendering...
I can reproduce this on all my hardware even in the stock fsp example.
Sometimes these clogs just dissapear during the game.

Fyodor,
I tried with several values of timescale (0.1. 0.2, 0.5, etc..)
Even when the game play slows up, the hitching doesn't slow up, instead it appears to be with the same speed no matter how low I set the timescale.
#10
03/06/2011 (2:30 am)
I found what's the problem, but still have no idea what is causing it.
It is a bug in the inner synchronization.

void ProcessList::advanceObjects()
{
...
   for (ProcessObject * pobj = list.mProcessLink.next; pobj != &list; pobj = list.mProcessLink.next)
   {
      pobj->plUnlink();
      pobj->plLinkBefore(&mHead);
      
      onTickObject(pobj);// <- MAIN TICKS
   }

...
}

This is the place where the process ticks happen.
In the normal case we see server and client ticks,alternating with each other.
When the jitter happens, it results in several server ticks,after that we see several client ticks on all objects.This is why the whole transformation,animation and rendering get clogged.I also checked the main loop and looks like the timing is correct.

Possible reasons:
1. the linked list process wrong ticks.
2. something happens with the network and this results in a wrong list.

By the way I have found several topics with similar issues :
http://www.garagegames.com/community/forums/viewthread/59979
http://www.garagegames.com/community/forums/viewthread/113305

It seems this is a pretty bad ancient bug.
#11
03/06/2011 (5:53 am)
Having a firewall seems to be critical for T3D.I believe some sort of UDP filtering is breaking packets,the whole process list goes wrong.
When I removed the firewall,all these problems disappeared.
This is something interesting,the other engines in this category like C4 don't have problems with firewalls.
My worries are that people are using their stock windows firewall and they don't know about this problem.
#12
03/06/2011 (4:03 pm)
so turning off your firewall totally fixed all the studdering/hitching?
#13
03/07/2011 (2:12 am)
Sean, yes.Absolutely.

I did several test,it seems that only several firewalls can break T3D.
The windows firewall is fine.
But using Sygate is critical for T3D - I get a massive packet corruption and cloging.