Page 7 of 8

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Tue Aug 21, 2012 5:22 am
by xiaoxiangquan
masterfalcon wrote:Oh, almost forgot. Were there any patches or bugs that you addressed?
No patches addressed.

Here are some bug fixing:
0000352 should have been fixed.
It seems that page is unloaded (in main thread) when it is still in preparation(in background thread).

0000484 may have been fixed.
I have ever met this bug. After enhancing the terrain paging, it never occurs. But actually, I don't know what's the cause.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Tue Aug 21, 2012 5:50 am
by masterfalcon
Great, thanks for checking up on that. I'm working on merging it in to 1.9 right now.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Tue Aug 21, 2012 6:02 pm
by masterfalcon
Oh, I can't believe I never noticed this. Could you give me write access to your repo?

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Wed Aug 22, 2012 2:06 am
by xiaoxiangquan
masterfalcon wrote:Oh, I can't believe I never noticed this. Could you give me write access to your repo?
Sorry I didn't notice, either. Now it's done.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Thu Aug 30, 2012 3:14 am
by xiaoxiangquan
Please ignore the changes since "(bd52779d6dfe) Merge to 1.9" in my fork, as it contains new experimental code, which may be not stable enough to merge into trunk.

BTW, the merging seems paused. Is there any problem? If so please tell me, I can surely keep on working though the gsoc has ended. :D

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Thu Aug 30, 2012 3:25 am
by masterfalcon
Oh yeah, it's been merged into the 1.9 repo already.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Thu Aug 30, 2012 3:29 am
by xiaoxiangquan
Aha, I didn't noticed that. Thanks so much!

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Fri Aug 31, 2012 8:20 pm
by PacoRG
Hi Xiao,

After some days on holidays I have been integrating the new terrain in my application. I have detected some things:

First, I use the function "TerrainGroup::RayResult TerrainGroup::rayIntersects(const Ray& ray, Real distanceLimit /* = 0*/) const" in order to get the distance to the terrain in the direction which the camera point to. Depending on both the camera speed and the distance to the terrain I manage the camara movement. The problem ocurrs when, in seldom occasions, I get a crash. I guess it is related with intersection whit an terrain page no fully loaded. In other occassions the function did not crash but returned a rayResult value incoherent (ie, the hit = true when the terrain pointer do not point to a valid terrain instance).

Second, I have experienced some crash with the default AutoUpdateLodByDistance strategy, due to the the obtained vieport pointer had a null pointer to camera:

Code: Select all

		const Viewport* vp = terrain->getSceneManager()->getCurrentViewport();
		if(!vp)
			return;
		const Camera* cam = vp->getCamera()->getLodCamera();
The statement terrain->getSceneManager()->getCurrentViewport() gets the current viewport being rendered, and due to the asynchronous nature of the autoUpdateLod system could be some arbitrary conflicts, mainly if the sceneManager uses several vieports for different renders.

I solved this using a custom strategy obtaining the main camera pointer from the CameraManager of my application and both the vieport and the lodCamera from the mainCamera:

Code: Select all

		const Ogre::Viewport* vp = mainCamera->getViewport();
		if(!vp)
			return;
		const Ogre::Camera* cam = mCamera->getLodCamera();
The result is now perfectly stable. Other approach could be to add the camera pointer as an argument of the autoUpdateLodByDistance(Terrain *terrain, bool synchronous, const Real holdDistance) function.

Another problem I have experienced is related with the custom strategy implementation. It was imposible for me to derive the new strategy from a Singleton Template for second time and from a diferent dll without getting link errors. I had to modify the original code deriving directly from Ogre::Singleton only the TerrainAutoUpdateLodByDistance from which I have to derive.

Code: Select all

	class _OgreTerrainExport TerrainAutoUpdateLod   // now do not derive from Ogre::Singleton


class _OgreTerrainExport TerrainAutoUpdateLodByDistance : public TerrainAutoUpdateLod, public Singleton<TerrainAutoUpdateLodByDistance>
Best regards,

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Sat Sep 01, 2012 4:49 am
by xiaoxiangquan
PacoRG wrote:Hi Xiao,
Best regards,
Hi Paco,

Thank you for feedback. I'll try resolving them.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Sat Sep 01, 2012 8:13 am
by PacoRG
Hi Xiao,

Excuse me, I did not explain correctly how the the custom strategy was implemented.

I had to derive from TerrainAutoUptateLod class but this abstract class do not derive from the template OgreSingleton in my case. My custom AutoLodUpdateByDistanceApp derives from TerrainAutoUpdateLod and I forced it to be a Singleton deriving from Ogre::Singleton too:

Code: Select all

    class _BC_TERRAIN_EXPORT TerrainAutoUpdateLodByDistanceApp : public Ogre::TerrainAutoUpdateLod,  public Ogre::Singleton<TerrainAutoUpdateLodByDistanceApp>
I underestand this approach do not force the custom strategy to be a Singleton. I have forced it to be a Singleton, however, IMHO I think here is not necesary to do a Singleton due to Ogre::TerrainGroup::setAutoUpdateLodStrategy(uint32 strategy) forces to use a only strategy.
(My terrain integration is a dll because I have divided in dlls all my application components).

Best regards,

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Sat Sep 01, 2012 8:35 am
by xiaoxiangquan
PacoRG wrote:Hi Xiao,
I underestand this approach do not force the custom strategy to be a Singleton. I have forced it to be a Singleton, however, IMHO I think here is not necesary to do a Singleton due to Ogre::TerrainGroup::setAutoUpdateLodStrategy(uint32 strategy) forces to use a only strategy.
(My terrain integration is a dll because I have divided in dlls all my application components).
Best regards,
I agree. Actually in TerrainPagedWorldSection there's a similar situation. I need a TerrainDefiner (just like a strategy), then I make it a pointer. Just remember to release it and everything goes fine.
I ever thought doing the same thing to AutoUpdateLodStrategy, too. The only difference is that we need to store and restore the strategy in TerrainGroup::save/loadGroupDefinition(). Of course we cannot store a pointer. That makes me give up the plan.

It's easy to find a way out. I can make another factory and avoid using singleton, If you wish :D

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Sat Sep 01, 2012 8:44 am
by PacoRG
Thanks Xiao. It will be better for the user.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Mon Sep 03, 2012 6:30 am
by xiaoxiangquan
PacoRG wrote:Thanks Xiao. It will be better for the user.
I have removed the inheritance relationship with singleton from the TerrainAutoUpdateLod (in my personal fork).

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Wed Sep 05, 2012 1:27 pm
by PacoRG
Hi Xiao,

Related with the TerrainGroup::rayIntersects function, I have detected other issue more frequently. Althougt there are no crashes, in some circunstances the function returns no correct values (the previous problems detected was very rare and could not occur in a work session of 15 or 20 minutes). The new problem is well detected. I can reproduce the problem in my application and in the terrain sample when I try to edit the terrain previously saved and load it again. The secuence of events that leads to the problem is the following:


-I set blankTerrain = true in the "SampleTerrain".
-Once it was recompiled, I created a flat terrain page and selected the "Edit Mode Elevation" and deformed it doing a high paraboloide.
-After that I saved the terrain page and exited the example.

So far all seems OK, Posteriory:

-I set blankTerrain = false and recompiled the example again.
-When started the example, the saved terrain page was loaded, the parabolide was perfectly visible but the terrain::intersecction function does not work correctly.
-If I select the edit mode elevation function It is posible to visualize the problem: the semispheric cursor is not posible to put it on the high part of the paraboloide due to the terrain::intersecction function fails here. The fuction fails only in the pointed shapes of the terrain.

After that, If a new edition accion is forced then the intersection function become to work correctly.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Wed Sep 05, 2012 1:41 pm
by xiaoxiangquan
PacoRG wrote:Hi Xiao,
I set blankTerrain = false and recompiled the example again.
When started the example, the saved terrain page was loaded, the parabolide was perfectly visible but the terrain::intersecction function does not work correctly.
If I select the edit mode elevation function It is posible to visualize the problem: the semispheric cursor is not posible to put it on the high part of the paraboloide due to the terrain::intersecction function fails here. The fuction fails only in the pointed shaped of the terrain.

After that, If a new edition accion is forced then the intersection function become to work correctly.
It seems to be related to the stream-in-LOD feature. The particially-loaded terrain affects on almost all aspects.
I'll reproduce the bug and try to fix it.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Thu Sep 13, 2012 7:39 am
by xiaoxiangquan
Ahh, totally stucked by new semester affairs. I'll deal with the bug this weekend.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Mon Sep 17, 2012 3:48 am
by xiaoxiangquan
It seems that the AABB is not updated correctly.
Terrain::getMaxHeight doesn't get the right value (which I get by iterating over the mHeightData).

I'll fix this.
xiaoxiangquan wrote:Ahh, totally stucked by new semester affairs. I'll deal with the bug this weekend.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Mon Sep 17, 2012 6:57 am
by xiaoxiangquan
PacoRG wrote:Hi Xiao,
After that, If a new edition accion is forced then the intersection function become to work correctly.
Seems fixed. Please have another try.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Wed Sep 19, 2012 10:16 pm
by PacoRG
Hi Xiao,

I have checked the Terrain sample and the bug is fixed. However, the EndlessWorld sample now crashes at the starting in "TerrainQuadTreeNode::updateVertexData" function. It could be related with the autoLodUpdated system because of the Terrain_sample have this feature disabled.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Thu Sep 20, 2012 10:12 am
by xiaoxiangquan
PacoRG wrote:Hi Xiao,

I have checked the Terrain sample and the bug is fixed. However, the EndlessWorld sample now crashes at the starting in "TerrainQuadTreeNode::updateVertexData" function. It could be related with the autoLodUpdated system because of the Terrain_sample have this feature disabled.
Ah, sorry I didn't check the EndlessWorld sample.
Let me take a look.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Mon Sep 24, 2012 3:35 am
by xiaoxiangquan
PacoRG wrote:Hi Xiao,

I have checked the Terrain sample and the bug is fixed. However, the EndlessWorld sample now crashes at the starting in "TerrainQuadTreeNode::updateVertexData" function. It could be related with the autoLodUpdated system because of the Terrain_sample have this feature disabled.
Fixed.
I remember a crash happened once, but I just cannot reproduce it. I'll keep on trying.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Mon Sep 24, 2012 1:01 pm
by Shtuka
I've downloaded this work from the repository. How do I use it?

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Mon Sep 24, 2012 1:12 pm
by xiaoxiangquan
Shtuka wrote:I've downloaded this work from the repository. How do I use it?
You can see some HowTos here: http://www.ogre3d.org/tikiwiki/tiki-ind ... _for_Users
Please let me know if you have other questions.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Mon Sep 24, 2012 6:41 pm
by scrawl
I have a really large world, with about 40x40 blocks of terrain. Would it be possible, or rather efficient, to load the whole world at once with this page manager? Does it always handle every terrain block as one batch regardless of LOD, or does it also handle merging them together if they are far, to render them more efficiently?

Or should I simply load, say, 4x4 blocks in one page (that is, merging them together manually)? Then the near terrain would still be detailed because of the paging, and the further away terrain could be displayed efficiently by using one batch for 4x4 blocks?

As a matter of fact, each block is only 65x65 verts.

Re: [GSoC 2012 - Accepted] Improve and Demo the Terrain Syst

Posted: Mon Sep 24, 2012 7:25 pm
by PacoRG
xiaoxiangquan wrote:
PacoRG wrote:Hi Xiao,

I have checked the Terrain sample and the bug is fixed. However, the EndlessWorld sample now crashes at the starting in "TerrainQuadTreeNode::updateVertexData" function. It could be related with the autoLodUpdated system because of the Terrain_sample have this feature disabled.
Fixed.
I remember a crash happened once, but I just cannot reproduce it. I'll keep on trying.
Thanks, Xiao.

Related with the TerrainGroup::rayIntersects bug, I did not reproduce it again in my case. However, previously, the frequency of occurrence was very very low. I am remembering that, when the bug happened, the ray intersected to the (0,0) point in the terrain space (or (0,0) vertex). In that moment I did not bother because I thought that that point was (0,0) due to the bug. However, right now I am thinking It could be the cause instead the consequence, this is, in the normal use of the terrain, the probability the ray intersect the (0,0) vertex or very near to it is very very low. If this is true, could it be a singularity in the "rayintersects" function when this particular (0,0) vertex of a far terrain is intersected? In this case, makes it sense that the "rayIntersects" function returns a successful intersection but without a valid terrain instance?