roadplan / questions

since i will spend some time helping JohnJ with his great addon, i would like to know your ideas about my current roadplan and how we should modify it to fit your needs.

The steps i planned to do with the current version:
a) fix remaining bugs (scattered over the forum)
b) integrate reasonable feature patches from you (need to collect, review and merge them)
c) improve the buildsystem: i recently added the cmake buildsystem to MyGUI, will do this here as well to ease the development
d) release a new version that covers the current featureset

So far about the current code.
I would also like to code on an experimental version that integrates fully into the new terrain and paged components that are currently written by sinbad.

My rough ideas for that version:
- remove all 'paging' code from the addon - we use the component for that (not ready yet)
- reuse the imposter / static geometry code partly.
- new steps for reducing the LOD: billboard clouds? (any more ideas from you?)
- lighting integration: the current version lacks of a solution for any lighting aspects. We should try to aim for lightning support in every component.
- terrain component integration: not sure about this yet, but at least provide useful example code
- custom configuration, so you can save and load grass/tree configurations. Also proper integration into the paging streaming component.

any further ideas from you? any requirements i missed?

One more feature that should be somehow integrated into the new version:
- Collision page-loader integration, which is loaded/unloaded based on active bounding boxes rather than view ranges

It would be fabulous if it was easier to specify custom shaders without having to use a specific name for the shader or modify the source.

-Fish

thanks for the ideas
i merged already some patches, hopefully more to come.
The next short term goal is to finish the integration of the demos in the cmake buildsystem and release the whole thing.

Sounds like a good plan you have for this plugin. Concerning CMake, it would be nice if an install capability was added. That was the one thing that annoyed me the most about PG as I basically had to guess where the lib should be located.

Threading would be a nice feature. I hate the slowdons due to impostor / batched geometry generation.

Hi tdev, are you still working on this or is this project dead? If you are, any idea on when you might be releasing an updated version?

Hi tdev, are you still working on this or is this project dead? If you are, any idea on when you might be releasing an updated version?
still working on it, when i got time

i have some bugfixes in the pipeline. Hopefully i can start working on the new goals in the new year.

Hi.
In file ImpostorPage.cpp, line -353-358:

Real tmp;
entityRadius = boundingBox.getMaximum().x - boundingBox.getCenter().x;
tmp = boundingBox.getMaximum().y - boundingBox.getCenter().y;
if (tmp > entityRadius) entityRadius = tmp;
tmp = boundingBox.getMaximum().z - boundingBox.getCenter().z;
if (tmp > entityRadius) entityRadius = tmp;

I get problem with houses to be added to PG: they looks cutting by corners on Impostors. I find, so better:

entityRadius = Math::boundingRadiusFromAABB(boundingBox);


Bye.

i hope Integrate dynamic shadow,thanks.

Hi.
In file ImpostorPage.cpp, line -353-358:

Real tmp;
entityRadius = boundingBox.getMaximum().x - boundingBox.getCenter().x;
tmp = boundingBox.getMaximum().y - boundingBox.getCenter().y;
if (tmp > entityRadius) entityRadius = tmp;
tmp = boundingBox.getMaximum().z - boundingBox.getCenter().z;
if (tmp > entityRadius) entityRadius = tmp;

I get problem with houses to be added to PG: they looks cutting by corners on Impostors. I find, so better:

entityRadius = Math::boundingRadiusFromAABB(boundingBox);


Bye.
merged, thanks

Is there a new release planned ?

Hi, tdev. My compliments for your work.
I have some questions (proposals for the development ).

I have top PC (Intel Core i7 + GeForce 480GTX + 8 GB RAM) and to slowly rendering. This is largely due to the use of Ogre in debug.
STL in visual studio 2005/2008 very slowly. I compile Ogre in debug with _HAS_ITERATOR_DEBUGGING=0 and _SECURE_SCL=0.
But 800 batches for rendering trees and terrain is to cool (it`s not for Ogre), I have ~15 FPS on Example 11.
What can I do to speed up this????

And second, I can`t use my SceneManager implementation directly derived from Ogre::SceneManager, because Paged Geometry using TerrainSceneMnager from Octree Plugin.
Any plan`s to improve this????
Terrain Scene Manager used only in examples to load and render terrain. It is possible to use any type of SceneManager, but you need to implement your own rendering algorithm for terrain and tell PagedGeometry height function

I'm thinking about the release of version 1.2. But it will be possible implement only after the release of Ogre3D 1.8 (http://www.ogre3d.org/forums/viewtopic.php?f=4&t=59902).
Until then, perhaps another interim release is not breaking the API and not laying an restrictions on the version of the Ogre.

Where I can read Tutorial1.odt, Tutorial2.odt, Tutorial3.odt, Tutorial4.odt without having to install OpenOffice? I'm currently reading through http://www.viewdocsonline.com/ . Tutorial3.odt needs clarification of that grass type you gonna use - it's flat image strained on quad. So there should be note like this "You can use TreeLoader, if you are going to use other type of grass, for examples, non animated bush-like grass".

Also I haven't found popular descriptions of mechanisms of making 100x faster. I think it must be first thing to mention. I found through code and tutorials two mechanisms: batching and imposters, need explanations, refrences to PDFs, there a lot of good PDFs about imposters. Also how about visual quality? I can distincly see both borders (batching and imposters). Is it because the parameters was choosen for maximal perfomance or the algorithms have not yet finished? I think that trees in examples must be scaled much more and camera shifted some upwards too, but it's my personal perception, maybe because I got used to big rare density fantasy trees in most games I play.

In Tutorial3.odt there is outdated information. Example 3 doesn't use GrassLoader, it should be Example 4.

Would be nice to see additional tutorials about integrating with other plugins Ogre::Terrain (Example 12), SkyX/Caelum (24 hour linear blending lightmaps, but blending on CPU each frame is high cost, how to solve?), Hydrax (underwater vegetation).

p.s. привет, m2codegen. русские рулят!

Also I haven't found popular descriptions of mechanisms of making 100x faster. I think it must be first thing to mention. I found through code and tutorials two mechanisms: batching and imposters, need explanations, refrences to PDFs, there a lot of good PDFs about imposters. Also how about visual quality? I can distincly see both borders (batching and imposters). Is it because the parameters was choosen for maximal perfomance or the algorithms have not yet finished?

Indeed, to increase the number of drawing geometry it is necessary to go on maneuvers. Paged Geometry allows to simplify these actions. There are implemented 2 techniques:
1) automatic assembling static geometry from entities (http://origin-developer.nvidia.com/docs ... hBatch.pdf)
2) automatic building imposters of this entities. (http://http.developer.nvidia.com/GPUGem ... _ch21.html)

To improve the visual quality You can remove the border crossings between the levels far away from camera.

p.s. привет, m2codegen. русские рулят!
Специально для русских друзей

http://software.intel.com/ru-ru/article ... made-easy/

Библиотечка неплохая (код получше чем Ogre::StaticGeometry), но не хватает еще инстансинга и многопоточности.
По поводу семплов с другими плагинами Hydrax, Calendum, etc. Пока в деталях и всех тонкостях не разберешся со всеми библотечками наврядли получится что, то хорошее.
А я на 99% уверен, что возникнут проблемы интеграции и потребуется модифицировать Paged Geometry или другую билиотеку. Но может быть я выложу такой семп, но не раньше осени это точно.

i agree that we need to update the documentation and add better examples


2) automatic building imposters of this entities. (http://http.developer.nvidia.com/GPUGem ... _ch21.html)

ha, i wish our imposters would be that good

we should really improve the imposters in some way, maybe through this or billboard clouds or such :-/

I was thinking about why we can't batch from distance=0. Is it because batching makes geometry static? Like disabling wind, animation? But there is WindBatchPage for trees?

Example8.cpp and Example9.cpp needs to change "factorX" to "windFactorX" and "factorY" to "windFactorY":

#ifdef WIND
bushes->setCustomParam(fern->getName(), "windFactorX", 1);
bushes->setCustomParam(fern->getName(), "windFactorY", 0.01);

bushes->setCustomParam(plant->getName(), "windFactorX", 0.6);
bushes->setCustomParam(plant->getName(), "windFactorY", 0.02);
#endif


Example4.cpp, I feel it is strange for this cross passing parameters, I thought OOP is hierarchical...

//Create a GrassLoader object
grassLoader = new GrassLoader(grass);
grass->setPageLoader(grassLoader);


Imposters positioning bug. Showning on Example1:

[flash=480,390]http://www.youtube.com/v/vrq8Yr64p9s?version=3[/flash]

Imposters cutted wrong. Is it because model's center is wrong in .mesh or because of bug in the code?



I'm sure those wrong cutted imposters are used in application:



There are shadow coloring bugs in Example9 and Example10.

Grass Example4 depth bug (seen not on every hill):



OgrePlant has bug with PagedGeometry http://www.ogre3d.org/tikiwiki/OgrePlant

A lot of work to do

I have two ideas about grass LOD. Currently grass fades to none using (Grow, Alpha, AlphaGrow). The idea to use one of the following approaches:
1) make an alpha textured heightfield mesh offseted by small Y above current terrain, if terrain is not heightfield we can offset by normal?
2) make a similar to projected grid concept used in Hydrax, if shaders unsupported fallback to multitexturing which is very rough approximation

Camera with smooth falling down (based on gravity constant = 0.098)

Add new variable to the World class;

//Variables used to keep track of the camera's rotation, falling velocity, etc.
Radian camPitch, camYaw;
Real camFallVelocity;


Add variable initialization to constructor of the World class

//Reset camera orientation and falling velocity
camPitch = 0;
camYaw = 0;
camFallVelocity = 0;


Modify camera Y positioning code

//Make sure the camera doesn't go under the terrain and smooth falling down then Space key released
Ogre::Vector3 camPos = camera->getPosition();
float terrY = HeightFunction::getTerrainHeight(camPos.x, camPos.z);
if (camPos.y < terrY + 1.5){
camPos.y = terrY + 1.5;
camera->setPosition(camPos);
}
else if(!keyboard->isKeyDown(KC_SPACE)){ //Space = walk
camFallVelocity = camFallVelocity + 0.098;
camPos.y = camPos.y - camFallVelocity;
if (camPos.y < terrY + 1.5)
camPos.y = terrY + 1.5;
camera->setPosition(camPos);
}
else
camFallVelocity = 0;


Thanks uelkfr!
I have deadline on my main work and no time to improve this bugs now, but as soon as I have free time I will try to improve the system of impostor rendering.

Thank you in advance. Also I have noted that Example11 is running very slow, maybe because of shadows?

wanted to implement this for some time now: http://kevinboulanger.net/grass.html