Paging as a core feature - design notes

[syedhs]

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

That sounds like a date estimation to me

[Rhynedahll]

I have read the other posts but one thing is not exactly clear to me. (Sorry in advance if I failed to understand a previous answer.)

Will the new paging feature replace the functionality of PLSM2 and ETM/ETL completely or will it be necessary to write code that references the new feature to replace the mechanisms of these two?

Thanks

[jacmoe]

Those are addons.
PLSM2 stands for Paging Landscape, so that will probably be obsoleted by this component.
ETL is probably going to be rewritten. It's not going to be replaced because it's a terrain editing library.

[sinbad]

What you use is entirely up to you - as is common in open source, nothing is 'obsoleted' as such; the new paging and terrain components are merely my take on the features. You're free to use or not use them (they're optional), and to use other alternative implementations from the community if that serves your needs better.

The new terrain system is inherently editable though, that was one of the core design points that TSM didn't cover before. Other enhancements over TSM will include:

- hierarchical geometry batching; batch counts reduce at lower LODs as well as vertex count. At the lowest level of detail, the entire terrain page is a single batch.
- LOD now adapts in real-time to camera settings (viewport sizes & LOD bias) so you can use the same terrain with multiple views efficiently
- related to this, more detailed geometry can be loaded / unloaded to save GPU memory when the terrain is in the distance
- skirts are used rather than stitching to avoid cracks in geometry; this means fewer indexing arrangements & lower overall index buffer usage
- saving & loading of terrain built in, including loading / processing in a background thread
- in-built support for splatting layers, configurable sampler inputs and pluggable material generators (WIP)
- support for generating global normal maps, shadow maps and horizon maps (TODO)

I'm hoping it'll be a useful option for people once it's finished. I'm still working on it, the hierarchical batching caused me a few headaches, but it's coming along quite nicely. I'll post more when I have something nice to show instead of just debug output

[Wolfmanfx]

Nice feature list
But you do not plan any terrain morph features like flatten, smoothing and so on?

[CABAListic]

As of now the terrain's heightmap can be modified via array access. This is all you need to edit terrain, but at the same time it's a very low-level way to do it. For editors and similar applications you'll probably want some kind of brushes for terrain editing (including the techniques you mentioned) built on top of the low level edits. I'm not sure what sinbad's current plan involves in that regard, but whatever of these features is not covered by the core terrain component, I'll cover in the new "ETL" version

[sinbad]

I may add some 'helpers' for that kind of thing later, but really that's an editor feature rather than a core terrain library feature IMO. As CABAListic says, you have everything you need to efficiently edit the terrain at a heightmap-array level anyway, everything else is just icing and syntactic sugar on top of that.

[KungFooMasta]

- in-built support for splatting layers, configurable sampler inputs and pluggable material generators (WIP)

Sweet! What is the workflow/interface going to be like? Can users add/remove splatting textures and the underlying material is managed automagically?

[sinbad]

Yes. The user can define a 'LayerDeclaration' which describes what sampler inputs go into a 'layer' - you can choose between elements of albedo, normal, height, and specular, then add a chosen number of layers with specific texture bindings to those inputs. That information is passed to the material generator which is then in charge of creating material based on those inputs, and also on terrain-global inputs like the overall normal map, ligthing map, or horizon map (which ones are needed is up to the generator to indicate and the terrain will generate them). Each generator can define a set of 'profiles' which can be used to provide hardware fallbacks and selectable detail levels (e.g. to trade performance for quality, or for an editor to test how the terrain will look on lower-end hardware).

I'll be providing a default generator which can deal with albedo, normal & specular mapping per layer initially, and will add support for lightmapping and horizon mapping later on. But, anyone else can plug in their own generators to do things differently, defining their own materials or opting for deferred shading / light pre-pass shading etc. I don't want to write all those options in initially, but the extension points are there to do it.

[Tony Richards]

Thanks, sinbad. This is awesome. I can't wait to use it.

Do you have this located in a branch in SVN, or are you working on it offline? I'd like to watch the progress in hopes that I may learn a little more about the guts of Ogre. (I speak C++ a whole lot better than English )

[stealth977]

it is in the SVN /components subdirectory

[tdev]

awesome work!

i tried to couple your new Terrain with this paging, and noticed that quite some parts are still missing. (or did i miss something)
Is there anywhere a more improved Demo_Paged that actually loads something, so i can see the whole architecture working (not just debug display, skipping everything)

[sinbad]

Not yet. TerrainPageContent will the be glue between the two but as noted in my terrain thread, this is not fully implemented / tested yet. The debug test was just to prove that the core paging system worked as expected, hooking it up to the terrain requires that the terrain is finished first.

[lulolean]

I stumbled across this thread while looking for a way to implement an earth-size paging system with multiple types of content. I'm excited you are finally addressing paging in a such broad and generic manner! Your last ETA said end of May. What's your latest estimate for completing the paging system with terrain?

[lulolean]

I finally found the "New Terrain Early Shots" thread where you said you're swamped and would rather not provide estimates, so I'm looking forward to the terrain component whenever you get it done.

[akilar]

HI! all：
sorry, my english is very bad.
i want to project object's shadow on the new ogre terrain, how to do?

[sinbad]

You edit the shaders generated in TerrainMaterialGeneratorA or wait for me to do it. It's on my list.

[Beauty]

I didn't read all the thread now.
One question: Is the new scene manger ready?

Nice would be to fill out the open description points on the wiki page SceneManagersFAQ.
There I added a section for the new scene manager 6 months ago.


Here I has an idea:
On an increasing terrain the Terrain Scene Manager creates many little ramps.
Maybe it would be more nice to have a continuous (smoth) ramp instead.
Or an option to enable this possibility.

Here I created an example how it could be (see black line)

[sinbad]

It's not a SceneManager, just a component that can be used with any other SM. The basic Grid paging strategy is implemented, I'll be working on integrating that with the new terrain component.

Stepping is entirely down to your input data, not the renderer. Usually it's because you've used a low-precision input format like 8-bit greyscale. The new terrain component allows you to use images of any precision or direct float input format for maximum precision. Personally I've seen no stepping in the new terrain component with properly crafted input data.

[shanefarris]

The design image links are broken, anyone know where I can find them? Also, I want to learn more about creating my own page strategy, is the best way to learn this system to just go through the code still? I don't see any other documentation on this.

[unsane]

(Sorry for my english)
I've a question about OgrePaging Component(pagecontent loading and read).

Code: Select all

bool Page::prepareImpl(StreamSerialiser& stream, PageData* dataToPopulate)
{
....//some code
     PageContentCollection* collInst = collFact->createInstance();
     if (collInst->prepare(stream)) // read type-specific data
     {
	dataToPopulate->collectionsToAdd.push_back(collInst);
     }
....//some code
}
//this function will call next function
bool SimplePageContentCollection::prepare(StreamSerialiser& stream)
{
    if (!stream.readChunkBegin(SUBCLASS_CHUNK_ID, SUBCLASS_CHUNK_VERSION, "SimplePageContentCollection"))
	return false;

     bool ret = true;
    for (ContentList::iterator i = mContentList.begin(); i != mContentList.end(); ++i)
	ret = (*i)->prepare(stream) && ret;

     stream.readChunkEnd(SUBCLASS_CHUNK_ID);

     return ret;
}

so, the collinst is new, in this funciton :SimplePageContentCollection::prepare(StreamSerialiser& stream)
the SimplePageContentCollection::mContentList will always is empty , isn't it?Hence all world1_section10000000x will not be read....