PLSM3 Design

TODO V3:
----------

- Use a specific namespace

- doxygen doc on everything.

- Logo and icons

- generate, use a more complex terrain folder with subfolder (height, texture, coverage, alpha each inside a order of magnitude of terrain (see recursive PLSM2)) with memory (roughness cache, option, best pool option, etc...)

- Paging

* Make PLSM3 recursive each page being tile of a bigger terrain (smaller heightmap bu bigger scale)
* Make Data source being providable by user directly using delegates.
* Threaded page, texture Loading
* Add dynamic registering system for Data Source Objects, so that user could register new datasource from client side.

- Refactor all getTiles, getPosition, GetPage into a "Global Positionning System".

- LOD:
* Add multiple LOD scheme (least distance-only and distance + tile roughness)
* Check if use the Binary Triangle Trees for Terrain Tile Index Buffer. (half less index buffer needed, as well as 1 more LOD possible.) can be optionnally activated where LOD scheme allows it (Can only link to 1 LOD away.)
* Using Lod Listener delegates, Give plugin user the ability to implements its own LOD scheme.

- Visibility
*Octree horizon culling using horizon rasterisation (considering use of quadtree and least square plane, see game programming gems 4)
* use that least square plane optimisation for terrain intersection ray queries (iterating over "quadtree planes..." hierarchy should be several order of magnitude order faster)
* separation of Occlusion octree scene manager into its onw .lib, which will results into a Occlusion octree scene manager.dll and plsm3.dll linked to that static lib.
* make occlusion demo/test case without any terrain.

- GetOption/setOption use an Option class that handle Option directly, using a std::map that contains 'value/descritption/valuetype/delegates' as well as a default map (loaded/loadable from user file too) which option mechanisme reverts to if it cannot find a value from map loaded from user config file.
- config files using sections : lod, paging, material, etc...

Octree horizon culling using horizon rasterisation (considering use of quadtree and least square plane, see game programming gems 4)



- Texturing

* Atmospheric scattering (with and without pixel shaders)
* user getshadowat point to "shadow" its own objects if in mountains penumbra.

- Deformations/painting
* Make any deformation/painting/texturing use filter classes :generic filter system that can be used from mapsplit/ deformation and painting.
* Make a filter that generation any number of coverage/alpha using max/min slope for each splat, as well as min height/max height
* update pages data when painting/deforming terrain at end of session. (or thread ?)

- Mapsplitter
* Use of Paging in mapsplitter, as memory is the main problem of mapsplitter when operating on maps (erosions, smooth, infinitize, normal, splats, horizon, etc...) So that we can effectively handles 16183*16183 png heightmap

- Add More Demos. (forest, water, selection, minimap, deformation, painting, etc..)

- Add a MapWizard.
- Add a automatic mapsplit mode inside plsm3 runtime if not already mapsplitter and .gen.fg is missing. (implies merging of .gen.cfg and .cfg)

- Add Poolset usage Log (a Debug help to calibrate finely the initial pool value by map usage.)

Refactor into multiple projects :

- occlusion octree library : octree, CHC occlusion
- paging library : page, tiles, queues
- terrain library : filters

That will be linked to by :

- Occlusion Octree Scene Manager
- Paging Scene Manager (only paging and occlusion octree, no terrain)
- Paging Landscape Scene Manager (paging, terrain and occlusion octree)
- Mapsplitter : (paging, terrain)

Rerefence and must read:
Overall Design of a terrain engine

(please post here any desgin/request/desire, it will added to todo and post will be deleted for clarity afterwards)

Is the recursive terrain somewhat similar to Hoppe's aproach from GPU Gems 2 (at least as far as layout, but possibly not on the GPU)?
http://research.microsoft.com/~hoppe/

Wow, nice list.

I'd like to see the mapsplitter turned into a set of classes and functions in a lib/dll, and then create an exe which uses that lib. The reason is that the old MapEditor and the new GOOF PLM terrain editor both include the .cpp and have special #ifdefs which is very messy.

It'd also be nice to be able to call functionality of the mapsplitter in nicer discreet functions. An example is in a terrain editor - if the user modifies some terrain using deformation, they may want to re-run the coverage map generation on the whole terrain, or even on a few specific pages.

Clay

With reference to my post 11http://www.ogre3d.org/phpBB2addons/viewtopic.php?p=11106

- I would like to see more "levels of controls" on the the tesselation/render levels.

- Is it possible to implement a plugin oriented interface for LOD/choosing RenderLevels. So a user can easily control how, which, when tiles/pages gets loaded and implement thier custom alogrithms for controlling render levels.

I can understand if noone listens to me on this as I am relatively new as being active on this particular plugin, but alot of what I am currently trying to do before digging into the infinitizer centers around 2 basic concepts:

1. Trying to give the user program the ability to take a more active role in the terrain generated ... ala Callbacks as I have been posting about in another thread...
2. Trying to make the amount of necessary options for the simplest possible implementation less than current. At the moment, coming into PLSM2 from a new user perspective is quite daunting. Basically you are told to get these maps, run this utility, watch it go, and then you get to back and figure out what is happening afterward... I would like to make it so that you can run with very few options, but of course your output milage will vary with the work you put into creating/specifying the terrain.

All this being said, I am all for new options and interfaces; however, where ever it can be done in a way that does not introduce unneeded conditionals into the main loop, I would like to keep new options so that they are only setup on an as-need basis.

I hope I justify my comments with many needed good patches in the months to come, but for now I guess I will have to hope you can take them at face value and hope I didn't come out sounding like the newb that I am while trying to express this.

- generate, use a more complex terrain folder with subfolder (height, texture, coverage, alpha each inside a order of magnitude of terrain (see recursive PLSM2))
Please make sure there's no reliance of any kind on actual disk file loading. I would never load any files. Ogre in general has this strange and widespread "we think you want to load files from your hard drive" thing going on.

Please make sure there's no reliance of any kind on actual disk file loading. I would never load any files. Ogre in general has this strange and widespread "we think you want to load files from your hard drive" thing going on.


I don't think so. You can create your own archive type that loads files from anywhere, including memory. It's just the default implementation that includes simple file system and zip file archives. If you don't like it, create your own archive implementation.

Yeah, it seems a bit odd to ask for a feature that you are the only one that wants it. I am sure others will too, but not the majority. You have to remember how the open-source community works, they design and program what is best, and then others who want custom implementations get to make it themselves. It is not so strange because it is widespread. That is a contradiction in terms.

I think that the following would be great as one of the goals for PLSM3: PLSM needs cleaning.

I asked on the #Ogre3d irc channel why PLSM is not a part of the core Ogre distribution, and was told "word is, it's just too messy to be up to Ogre standards. so it stays in addons." I think with a little work, PLSM3 could be up to everyone's standards.

I've been exploring PLSM2's code, and I find that the implementation is pretty messy. Looking back at PLSM1, it seems we inherited this mess and it never really got cleaned up, that things were added on top of the original mess, without ever going back and streamlining the whole thing; a kind of hack-on-top approach.

Just on the surface level: when you compile PLSM2, you'll get more compiler warnings than any other part of Ogre. I get a flood-- pages and pages of warnings scrolling by. It's got some extremely hackish ways of passing data around. Example:

unsigned int requestPageX = *static_cast<unsigned int *>((*static_cast<std::vector<void*>*>(pDestValue))[0]);
Ack!

I think this is a fairly common phenomenon, to have code that does wonderful things, but whose implementation is rough. Fixing this up would also make it easier for new developers to contribute to the PLSM.

I'm not saying that every part of PLSM2 is messy. Only certain key areas need work.

- Zola

I asked on the #Ogre3d irc channel why PLSM is not a part of the core Ogre distribution, and was told "word is, it's just too messy to be up to Ogre standards. so it stays in addons." I think with a little work, PLSM3 could be up to everyone's standards.


That's a load of bull. While I agree that the PLM code could use a lot of cleanup, no matter how clean it is it won't end up in the core of Ogre since it is a community maintained addon. The only things that go in the core of Ogre are projects that are created and maintained by the Ogre team. The reason you see things like OctreeSceneManager, TerrainSceneManager, etc. is because they were written by Sinbad and he is willing to support them.

I am very expecting the water demo in plsm, thanks!

Modified First Post.

@Kentamanos: Yes. but possibly not using clipmapping.

@Falagard : mapsplitter turned into a set of classes and functions in a lib/dll

That's the idea behind what I called "filters". a filter have a heighfield in input and can returns either a heightfield or a texture. (user deformation, crater deformation, flattening, coverage computation are filters.)
(see the above first post about new linking scheme)

@ahmedali : I added Multiple LOD schemes to the above first post

@Zola : PLSM needs cleaning...
Indeed that the why of PLSM3 which will be my take at designing it from the beginning instead of working on someone else basis (spoke is initial author of plsm and plsm2)
when you compile PLSM2, you'll get more compiler warnings than any other part of Ogre
That's the exact contrary here using VS2005 not a single warning. Please make a new Post about warning you get (and what compiler gives them)
It's got some extremely hackish ways of passing data around
That's because of Ogre Scene Manager setOption/getOption Mechanism, and I cannot change. See http://www.ogre3d.org/phpBB2/viewtopic.php?t=20553 and try to make some point overthere.

Too messy, ROFL! Who cares. It works. A common truth forgotten often in game programming, the end users NEVER, EVER see the code. first and last 25 pages are sent in for copyright and the rest is archived to never be seen again.

I have been doing this a really long time. My first computer I made games on had 3K of RAM and it was state of the art that only a select few could afford. I have found over the years that cleaner code tends to run slower. So much so that at the major entertainment software companies I have worked at tend to write a function in clean code that is commented out just so the other team members understand what the faster "messy" code does.

Yes it is harder to understand if it isn't clean but this is a plug-in library and the majority of users only compile it.

Back on the actual topic:

Mapsplitter - I hope this happens. I couldn't use it for more than splitting the height map, every other option crashed it do to memory use and my map was only 8192x8192. Ultimately I had to create all the textures myself and have mapsplitter only split them so that I got a working map.

PLSM3 - I would like to see a way to have holes in the terrain. Faking them is kinda hard.

PLSM3 - Better support for water. The easiest way to do water is to put a plane where the water goes. However this seems to cause problems with the LOD system. The landscape polygons at the water edge flicker due to different LOD choices each frame. Can't really tell that it actually does this everywhere but you can actually see it at the water edges in a large landscape.

PLSM3 - Support for trees and grass. In PLSM2 you have to do it yourself. Realistically if you're using a terrain scene manager you're going to have trees or rocks and things.

Too messy, ROFL! Who cares. It works. A common truth forgotten often in game programming, the end users NEVER, EVER see the code. first and last 25 pages are sent in for copyright and the rest is archived to never be seen again.

I have been doing this a really long time. My first computer I made games on had 3K of RAM and it was state of the art that only a select few could afford. I have found over the years that cleaner code tends to run slower. So much so that at the major entertainment software companies I have worked at tend to write a function in clean code that is commented out just so the other team members understand what the faster "messy" code does.

Yes it is harder to understand if it isn't clean but this is a plug-in library and the majority of users only compile it.


Glad I'm not working with you on your project.

PLSM3 - I would like to see a way to have holes in the terrain. Faking them is kinda hard.

PLSM3 - Better support for water. The easiest way to do water is to put a plane where the water goes. However this seems to cause problems with the LOD system. The landscape polygons at the water edge flicker due to different LOD choices each frame. Can't really tell that it actually does this everywhere but you can actually see it at the water edges in a large landscape.

PLSM3 - Support for trees and grass. In PLSM2 you have to do it yourself. Realistically if you're using a terrain scene manager you're going to have trees or rocks and things.

A built-in water system (including shores, of course ) and perhaps also rivers (which are not that easy atm) would be great and could -in my mind- also be part of a landscape engine, same applies for the grass, etc.

Nevertheless I would consider these as long-time targets, for now they can also be implemented in more complete engines as GOOF.

I would like to see those things inside PLSM3 and not in a game engine, as there are many game engines in the works, and if effort is going to spent on it, it would be awesome if the progress of trees, oceans, rivers, etc could all be in the scene manager

And different kinds of fog. Even the underwater kind.

I would like to see those things inside PLSM3 and not in a game engine, as there are many game engines in the works, and if effort is going to spent on it, it would be awesome if the progress of trees, oceans, rivers, etc could all be in the scene manager


Actually, I don't think they need to be done in the scene manager. I'm not saying they should be done in a specific game engine either (such as GOOF) but instead done in such a way that they can be used in any scene manager.

For example, trees done in a SpeedTree way can be done either as a new type of MovableObject, or as a combination of regular Entities plus a type of manager that handles updating them. This way they aren't tied directly to PLM2 or a game engine, they can be used by either.

Oceans are the same sort of thing - create reusable code that isn't tied to the SceneManager. Perhaps it'd be necessary to have something specifically in the PLM2 to handle shore waves that crash against the terrain, so I can see that, but for the most part water code is mostly a fancy shader or two.

Rivers... well they're interesting. The typical way to do them would be to have a combination of different effects. Geometry for the river water, geometry for the banks, particle effects for the splashing, perhaps ripple effects around rocks in the stream and the shore. That's a tall order for a terrain scene manager to handle, and seems like it is pretty much custom.

Sure, it'd be great if trees, rivers and oceans were included as samples that come with PLM2 - in the demo for example. It could show how they are used or what tricks are employed to make them look good, I just can't see Tuan including all of them directly into PLM2. I could be wrong

I've seen what he's done with the Imposter system for example, as well as the fact that he's planning on pulling the OctreeSceneManager with hardware occlusion queries into a separate scene manager which is inherited by the paging scene manager. Tuan usually seems to create code that can be used by projects other than just the PLM2 users, which is great.

As Falagard said, I really would prefer to design components reusable in broader way than just PLSM, and I feel all those should go outside.

That's the aim of scene manager listener/option thing, permit precise handle on Terrain.

I'd work on anything on PLSM3 that would help support of these, even give serious hand on all those, as active developer

I'm all for a Vegetation Plugin (impostor/instancing/placement based on height/slope/terrain typ), A Atmoshpehre (day/night/fog/volum light+ scatterint) Plugin, An Ocean/River Plugin, etc ?
(Like the very neat FXplugin from spookyboo)

But all those may be too much work for only 1 coder/maintainer/forummoderator.

For now I'm flooded under work and cannot even advance as I would like on PLSM3 design papers.

This is a feature that may not apply to everybody, but I'm planning on integrating PLSM with OgreOpcode, and would like to use caves and such in my terrain.

I don't know how painting works, as I'm very new to PLSM, but I'm hoping there is an easy way to paint certain terrain parts transparent.

That, or a way to punch holes into the terrain.

I guess the idea is to model a mesh cave for example, and place it in the side of a hill. The hill part that intersects the cave would need to be transparent or non-existant, otherwise things might look funny.

@ PatrickB3:
That doesn't sound like a good mentality. Cleaner code means easy to maintain, easy to add new features, and easier to encourage people to help. I usually try to comment my code before or as a write it, but I do find rare occasions when I have to stop and scratch my head =X.

KungFooMasta

Painting transparent is possible and a nice idea, even better than page/tile hiding that was proposed before. (but you'll have to handle that "transparency" in opcode as well.)

I prefer doing it by tiles/pages rather then transparent land due to that the model that would enclose the hole can fill in the remaining area as well...

UT2k4 does it like that with its terrain... As well as BZ2 and so on...

Wouldn't that take a lot of tailoring of the mesh to appear like a tile? I was thinking it would be easier to place the mesh, deform the land to fit the mesh (cave for example) and then texture the terrain appropriately so that the cave looks like its supposed to be there. Of course I am 100% new to PLSM and have not tried this, but this is what I would be doing in my mind.

KungFooMasta

That would be costly because plsm2 aligns verts on a perfect grid.

Is that implying that deforming the terrain is costly?

KungFooMasta

Up/down is not rather costly, any other direction is, and would require a little rewriting in a good part of the code.

Any updates on the status of PLSM3?

Still lots of work before first commit/alpha state. Didn't worked on it for a month at least. Even Not sure it will make Eihort release Date...

Well, still very interested in seeing what you've come up with! Keep up the good work.

Hi,
the last info is long time ago. Any news update ?

Just as long as documentation improves, I'll be VERY happy. No offense, but PLSM2 has the worst documentation of all open source libraries/etc. that I've ever used in my entire life. I've spent hours upon hours trying to make sense of it and I've searched for help on this message board with a lot of different keywords and all I get is "Read the wiki". That'd be fine if the wiki wasn't so darn confusing. I am sorry if I offend anybody, I really am trying to keep my criticism constructive. I'd volunteer to help with it if I had a grasp on PLSM2 (which I don't).

What I'd like to see is a tutorial type thing where every step from getting your heightmap image split to setting up your filesystem (what needs to be in ./Media, etc.) and then using it. I know enough to write it, I just don't trust myself to make a good one. If you ask "what is there to explain that the wiki does not cover?" That's not what I'm getting at. It's the fact that it took me many hours and a headache to make sense of the "documentation". I realize that it wasn't meant as a finished work, but it was still frustrating on my part.

Again, sorry if I offended anybody.

Just a small suggestion concerning Ray Scene Queries, I've just been going over the code in PLSM2 and it seems it returns Vector3( -1, -1, -1 ) when no terrain is hit, wouldn't it be better to return NULL in this case, so that the Result Set is empty or the WorldFragment pointer itself is NULL.
I'm pretty sure this how TSM handles it ( if I remember correctly from the tutorials ).

Any news on this? it seems the more i delve into plsm2 the more problems i find.

a *FULL* build solution for Linux !

I travel for many hours in the wiki and forums that are not in my language and its very frustrating to dont make this powerful library working after those efforts.
So Please make that PLSM3 can work easily in my linux system

bye !

Thanks for the post. Hi guys, Im a newbie. Nice to join this forum.

__________________
watch movies online free

hi all

is again running as project plsm3?

Wow, nice list.

I'd like to see the mapsplitter turned into a set of classes and functions in a lib/dll, and then create an exe which uses that lib. The reason is that the old MapEditor and the new GOOF PLM terrain editor both include the .cpp and have special #ifdefs which is very messy.

It'd also be nice to be able to call functionality of the mapsplitter in nicer discreet functions. An example is in a terrain editor - if the user modifies some terrain using deformation, they may want to re-run the coverage map generation on the whole terrain, or even on a few specific pages.

Is it still alive?

it seems not