[Solved] Ogre at fixed frame rate

[phoenix_64]

Hi,
we are currently thinking about a png sequence output of our render window. The png sequence should be at a fixed frame rate (currently 25 fps), which in all cases should be made sure, even if the real frame rate drops below this (which surely will happen, because we are loading big meshes at runtime, and want to render really big videos of really excellent quality).

My first thought was to ensure a maximum/fixed fps in our render loop. But this wouldn't work when the real frame rate drops below the fixed frame rate.
My second thougt was to exchange the main Ogre timer by overloading Ogre::Root. This would be the best solution theoretically. But I think, in practice this won't work, since Ogre::Timer is not a factory class, and so the classes, which use Ogre's root timer, will only see the base class, am I right? And Root::getTimer() is not virtual, so changing getTimer() wouldn't work either.

Any Ideas how to do this without modifying Ogre?

[madmarx]

The png sequence should be at a fixed frame rate (currently 25 fps), which in all cases should be made sure, even if the real frame rate drops below this

This sounds impossible to display faster than what the graphic card is able to. Did I misunderstood?

In the case you just want to 'read' (and not display) at a fixe frame rate, you can roll your own rendering loop (which sounds the most simple).
You can read your video in RAM at fixe frame frame (in a thread) and just pick the current frame and update its dynamic GPU texture when a change is detected ... You can have a time counter bind to your video that is increased at each instant, and when time to render comes, you just need to divide per 25 and pick the corresponding image...

Does it sounds ok for you ?

[phoenix_64]

Thank you for your answer.

We don't want to read, but in fact write PNGs.
And I don't think that this is impossible.

Think of an offline renderer like you have in Blender or 3ds max. Each frame takes a long time to render. Nevertheless the output files (and this is what matters in this case) are at an exactly proper frame rate. Of course, what you see on your screen during rendering, the real rendering frame rate, is much less than your needed frame rate.
We just want to do the same thing in Ogre. Each frame may last as long as it needs - even at an extremely low real frame rate. The handling is no problem, because we've got an animated camera path in that case.

Our only problem is, to tell all animations, skeletons, particles, scripts etc. about the "virtual" time of the current frame. The last frame might have taken even a second or so, as long as animations dont't know that it took so long. If they knew about the slow real frame rate, the animations would be much too fast and not properly timed in the PNG sequence, because the normal and wanted behaviour of the engine is to drop animation frames in that case. Instead, they should think that the last rendering exactly lasted 1/25s and play their animations accordingly.

Every timing in Ogre relies on Root::getTimer(). So I think it would be the best, easiest, and most elegant way of approach, to replace this timer by a manual one. We render each frame, and after the rendering, we simply tell the timer: "Next frame". And it would always deliver our "virtual" frame time, so that all animations are properly timed.

The only problem I see with that is that it might be impossible without modifying Ogre, because neither Ogre::Root::getTimer() nor the Ogre::Timer methods itself are virtual, so that it is a problem to overload this timer. So we thought if there's another way to reach this.

[jacmoe]

OGRE is a REAL TIME rendering engine.
You can do this, but why not just pick one of the dedicated off-line renderers out there?

[stealth977]

use

Ogre::Root:renderOneFrame(your_fixed_time_interval)

[phoenix_64]

Of course, we do use it mainly as a real time engine.

The "offline renderer" is just an additional task. We want to show our already created work (scenes, animations etc.) in an excellent HD movie for people who don't want to install our application, or people who doesn't meet the hardware requirements for extensive shaders, shadowmaps etc.
And showing it in other offline renderers would be much, much additional work, since we would have to convert our materials etc. to this offline renderer. And it wouldn't be our real Ogre output

@stealth977: thank you, but as far as I can see in the API doc and the header, there is no renderOneFrame() with parameters, only renderOneFrame (void) is declared. Or am I wrong?

[stealth977]

you are wrong there is, just try it...

[stealth977]

Code: Select all

        /** Render one frame. 
        @remarks
            Updates all the render targets automatically and then returns,
            raising frame events before and after.
        */
        bool renderOneFrame(void);

		/** Render one frame, with custom frame time information. 
		@remarks
		Updates all the render targets automatically and then returns,
		raising frame events before and after - all per-frame times are based on
		the time value you pass in.
		*/
		bool renderOneFrame(Real timeSinceLastFrame);

[phoenix_64]

Ah great, thats it, just have missed it... How easy, thank you very much

[stealth977]

you are welcome

[prathap]

hi ,
I cont find the method
bool renderOneFrame(Real timeSinceLastFrame);

iam using 1.6 version,can you please help me how can i achieve how to restrict to a specified fixed FPS

Regards,
Prathap.

[phoenix_64]

Upgrade to 1.7.1. There it is.

If this is not possible currently for you, you will have to modify Ogre.
We tried this it in our first attempt and this works too.
- Edit OgreRoot.h and make getTimer() virtual
- Edit OgreTimerImp.h (of the os you use) and make all functions virtual
These are the small Ogre modifications you need.

You then will have to overload Ogre::Timer with your own fixed timer implementation and then overload Ogre::Root and deliver your Timer class via overloaded getTimer().

Since solving this problem I've been thinking, if making the timer virtual could be a good idea generally? Probably there could be more reasons to exchange a timer?