Paging as a core feature - design notes

[sinbad]

The intention is to make the format friendly to pulling data from existing image formats, as external files from the resource system if required. Obviously once in memory it would be saved out in our packed format but there's no reason why it can't be pulled in from images as is done with most systems now.

Do you mean heightmap images? This would be used in the very special cases of "not overhanging" terrains, wouldn´t it?
As far as I understand your notes the goal of your approach is a generic concept for paged data in general. Do you have an idea how generic paged data would/could be described outside of the code. *squinting to the new StreamSerializer class*

The TerrainPageContent class I'll be providing will only deal in heightmaps - in practice this is what the vast majority of people need anyway. If you want to add overhang terrain support, or indeed any other kind of PageContent, that's entirely possible but outside the content types I'll be working on initially.

PageContent will read data from its own chunk, which can be of any structure (StreamSerialiser just helps you out) so that's entirely extensible. You can embed any data you like so long as you have a PageContent subclass that knows how to interpret it.

[Nauk]

Do all pages have to be of the same content type or can you mix content types, e.g. Page 0,0 being a mesh, Page 0,1 being heightmap based, Page 1,1 overhang?

[sinbad]

Do all pages have to be of the same content type or can you mix content types, e.g. Page 0,0 being a mesh, Page 0,1 being heightmap based, Page 1,1 overhang?

I tried to cover this in my last diagram, but what's intended is that each Page can contain 1 or more PageContentCollection instances, which are just a logical grouping of PageContent - the most obvious example is LOD.

Each PageContentCollection can contain multiple PageContent instances. There's nothing in the design that says that content type has to be the same, either at the Page level or even at the PageContentCollection level. For example, you might want to do LOD using PageContentCollection, but each LOD level might have a mixture of content types in it.

The simplest setup though would be that a Page has one PageContentCollection which simply contains a number of PageContent instances (so no page LOD, but that doesn't mean each content instance can't do it's own internal LOD, like Mesh LOD or terrain LOD, but this is on already loaded page data). But again, those PageContent instances might be of different types (some terrain, some objects, something else etc).

[Lee04]

10. In general, paging support must not require major changes to SceneManager, those are still reserved for 2.0

I think if you can take the over all design well of Scene manager 2.0 in account, the paging system will beniffit perhaps and you want get any uggly suprices.
In fact scene manager 2.0 would just hock in aand boost paging support further.

Is this paging from hard drive and from server? Or hard drive only?

What about virtual texture paging for large landscapes, is that going to be a part of this?

L.

[sinbad]

10. In general, paging support must not require major changes to SceneManager, those are still reserved for 2.0

I think if you can take the over all design well of Scene manager 2.0 in account, the paging system will beniffit perhaps and you want get any uggly suprices.
In fact scene manager 2.0 would just hock in aand boost paging support further.

Well, that's a good principle but not entirely practical because of the fact that I'm keeping the SM interfaces generally stable for this step. But what it does do is expose a few areas where improvements would be useful. In fact, I've been relatively surprised with how easy it's been to retrofit - the main issue generally remains large co-ordinate precision, which is impossible to deal with completely without the 2.0 redesign. However, the camera-relative rendering we added in 1.6 does a pretty good job of coping with most cases.

Is this paging from hard drive and from server? Or hard drive only?

Paging from anywhere you like - anywhere that can support a DataStream, or procedural paging.

What about virtual texture paging for large landscapes, is that going to be a part of this?

If you mean megatextures, no. But that's something that could be bolted on if someone chose to do so.

[KungFooMasta]

This is a question more about the Terrain side of things. Has work begun on that project? I'm wondering how difficult it would be to allow spherical terrain, such as planets. Not really large planets, basically the same size as the TSM example, just wrapped into a sphere. I saw a havok demo that allowed objects to pull other objects closer to it (mini planet), and was tempted to trying out this feature as a possible game idea.

Either way a thread on the Ogre supported Terrain, or any information would be cool.

[sinbad]

See SVN trunk, Components/Paging and Components/Terrain. All my thoughts are going in there with copious comments so I won't repeat them here unless there is a specific question.

I won't be supporting spherical terrains with the first cut of classes, because they overcomplicate things when most people just want flat terrain. However since the paging system is highly extensible there's nothing to stop you using 6 terrain pages around a 'blown up' cube as a spherical terrain (as SPT allowed), you just would likely need to subclass to create an appropriate page strategy and refined content class to go with it.

[Nauk]

I just started compiling the latest trunk and dig into the sources, I really like what I see there, very clean and straight forward - good work - might be premature to say, but what I can judge this is going to be a pleasure to implement into artifex.

[sparkprime]

I almost finished a general paging scene manager for ogre where the idea was you built an immense scene graph but the vast majority of entities (and resources) were unloaded, despite being present in the tree. As the camera moved around, it would load things in the background, and things would be pushed out of the GPU using a cheap LRU policy. The context was a GTA-like game, I was rendering the (copyright) San Andreas world.

However I realised that I was making a big mistake. It wasn't just graphics that needed to be paged out but game objects, sounds, physics meshes, etc. Thus by hiding the paging in the graphics engine I was forcing myself to implement independent paging strategies in every subsystem.

So I rewrote the whole thing from scratch, based around paging scripted game objects, and driving the paging of graphics resources externally to ogre, by creating / destroying entities dynamically. Likewise for physics, etc. The game object gets paged in as you approach it, and this triggers (via the execution of a script) various resources to be background loaded in the physics and graphics subsystems. Likewise, LOD is done at the game object level, with one game object replaced with another game object (overlapped and faded with alpha blending).

The design also ended up being simpler, not because paging was central to the game engine, but because i didn't have to worry about multiple cameras (shadow cameras, etc). I just pick one point (the player location) and load things based on their distance from that point. The algorithm is just a brute force iteration through all the (50000) objects in the world, looking for objects that are close enough to page in. This is very fast thanks to prefetching and SSE, and can also be spread over several frames. I was expecting to have to use a spatial datastructure to determine the objects to page in, but this turned out to be unnecessary.

http://www.youtube.com/watch?v=54onrl8fJJw

In summary, trying to do paging within the graphics engine was the biggest mistake i've made on this project, it cost me about 3 months of developer time. Given that I haven't been able to work on it properly for about 6 months due to work and other commitments, this was quite annoying.

And that is my heavily biased 2 cents.

[Lee04]

Good, real experince is nice. Good of you to step forward.

I think we will be hearing next that: "Ogre is just a rendering engine, not a game engine"

[xadhoom]

AFAIK its possible to do in the page classes whatever you want if you derive from it, isn´t it? So Ogres paging feature could be used as general paging system in an application. But yes, it does not seem to be a very clean cut between an application paging system and the rendering engine then...

xad

[steven]

Ogres paging feature could be used as general paging system in an application.

I may be mistaken but if your engine is multithreaded (graphics in one thread, audio in another, physics another, ...)
I am not sure it will be possible or very clean.

[reptor]

Well, it comes down to the "resource system should be separated from the graphics engine" argument which I've seen a couple of times I believe.

[xadhoom]

I am not sure it will be possible or very clean.

Yep, as I said. And yes, its a similar issue with the resource system...

[jacmoe]

I think you are getting too carried away.
You can hook into this system if you want. It seems to be accessible and flexible. And should handle background loading, etc.
It is not hidden in any way, and it's not interwoven with the new terrain scenemanager, but a separate component(?).
Lots of people have used the paging callbacks in PLSM2 for their own game specific stuff. I really don't see anything wrong with it.
Of course, it doesn't matter how good the tools are if you cannot use them.

[Praetor]

This exactly why the paging system will not be part of OgreMain, just part of the core distribution. You can choose to use it or not. However, it certainly extends Ogre's functionality out of "just graphics" area.

[joew]

I can comment a little on this. The reason my company wanted the paging more integrated with Ogre was for a few reasons actually.

One was the fact that it was built to work extremely well with Ogre, have the same coding style, and integrate extremely closely and very well, but at the same time was abstract and separated enough that we could use it with our existing paging system for physics, etc. Of course we will be modifying our existing system to work closely with the Ogre paging system but overall the design is extremely well thought out and easy to use and I see absolutely no problems with this. Another commercial engine I had previously worked on actually had the paging system even more tied into the graphics component of the engine and was much less flexible than the design Steve has proposed, and it worked perfectly fine for all our needs.

I had this discussion with the other co-founder of my company before embarking on this, and talked about whether we wanted the paging system completely separated from Ogre or if we should talk about doing something more integrated. Our core engine uses Ogre for all rendering and quite frankly that is never going to change, so that was not a reason for us. Sure you could have a system completely abstracted out but that is not something that would affect our end goals.

Based on the design so far and code in the SVN I have already put together the design on how we will be changing our existing paging to work with this new system, and I don't see any hurdles or problems at all quite frankly. Praetor actually mentioned a view on the system in his last post and it is exactly what my company was thinking when deciding on this. We look at this as a separate piece of functionality that plugs into Ogre and is usable throughout the system. Considering we also wanted a nice terrain implementation to go along with this functionality we decided on talking to the person who knows the engine best and whos code we regard as the highest quality

[sinbad]

I'm fully aware that paging is not just about graphics, that's why the PageContent class makes no assumption that it's actually a graphics object that it's dealing with (it just allows for it). As I've mentioned already in the thread, there's nothing to stop you from paging absolutely anything in and out in one of these classes. Or, if you don't want to implement it as a dependency injected specialisation, then use the listener hooks (these still need more development). Or, don't use it at all - it's entirely your choice, since it's not in the default OgreMain, but an optional component that you can take or leave. The paging structure isn't embedded in the Scene Graph at aall, it's an orthogonal structure (this is required for different paging strategies) which just populates the scene graph via certain PageContent classes. So it's actually probably very much like what you ended up with the second time around.

For what it's worth, we allow multiple cameras to be tracked for paging purposes, but only track cameras you tell us to. The union of what all tracked cameras need is kept in memory. I also have a concept of 'load' and 'hold' when it comes to pages - ie for a grid distance strategy, you would 'load' a page at distance A, and 'hold' a page at distance B, which is typically slightly larger than A. 'hold' means 'keep the page in memory if I already have it', as opposed to 'load' which means 'actively load it'. This is a buffer zone which makes sure pages aren't loaded and unloaded in a thrashy manner on boundaries.

I'm merely providing a framework for those that do want to have paging without inventing their own subsystem. They can piggy-back on ours for non-graphical stuff if they want, it may very well save people time. But by all means, ignore it if you have a different way.

[Nauk]

I think you created a good platform that will sparc many new interesting addons all being able to be attached to the same backbone / spine, the paging system.

[Beauty]

Does the new terrain manager has a (static) name?
If yes, I can create a wiki page for it.

[sinbad]

It's rather unimaginatively called 'OgreTerrain' at the moment.

[stealth977]

I think there is a problem with the following code in OgreTerrain.cpp, where HeightMap is always zero even though importData.inputFloat is specified.

Problem:
heightmap is loaded from importData.inputFloat but after that it checks importData.inputImage, if it doesnt exist "the else statement" zeroes out the heightmap!!! I guessit should be "else if(importData.inputImage)", this also makes sure that if both are specified, importData.inputFloat has the priority.

Code: Select all

	bool Terrain::prepare(const ImportData& importData)
	{
          -------------------------------------------------
          -------------------------------------------------
          -------------------------------------------------
		if (importData.inputFloat)
		{
			if (Math::RealEqual(importData.inputBias, 0.0) && Math::RealEqual(importData.inputScale, 1.0))
			{
				// straight copy
				memcpy(mHeightData, importData.inputFloat, sizeof(float) * numVertices);
			}
			else
			{
				// scale & bias
				float* src = importData.inputFloat;
				float* dst = mHeightData;
				for (size_t i = 0; i < numVertices; ++i)
					*dst++ = (*src++ * importData.inputScale) + importData.inputBias;
			}
		}
		if (importData.inputImage) // THIS SHOULD BE "else if(importData.inputImage)"
		{
			Image* img = importData.inputImage;

			if (img->getWidth() != mSize || img->getHeight() != mSize)
				img->resize(mSize, mSize);

			// convert image data to floats
			PixelBox destBox(mSize, mSize, 1, PF_FLOAT32_R, mHeightData);
			PixelUtil::bulkPixelConversion(img->getPixelBox(), destBox);

			if (!Math::RealEqual(importData.inputBias, 0.0) || !Math::RealEqual(importData.inputScale, 1.0))
			{
				float* pAdj = mHeightData;
				for (size_t i = 0; i < numVertices; ++i)
					*pAdj++ = (*pAdj * importData.inputScale) + importData.inputBias;

			}

		}
		else
		{
			// start with flat terrain
			memset(mHeightData, 0, sizeof(float) * mSize * mSize);
		}

[sinbad]

Yep, thanks for spotting.

[syedhs]

Sinbad,

I notice that this particular codes (terrain and paging stuff) are very actively updated in SVN - I am wondering what is your estimation date for the code ready for testing? (alpha, beta release)

[sinbad]

Er, when it's done? I'm hoping later this month for beta.