Porting from DirectX based system... (AdVantage Terrain)

Jon · Post by **Jon** » Mon Jun 09, 2008 3:32 am

The Apr 24 version does not build against Subversion w/VS2008. OgreNoMemoryMacros.h does not exist in the subversion tree (Shoggoth). Since the last discussion of building this plugin referred to the old CVS tree, I think it is worth a FYI.

AVTerrainRenderable does not have a visitRenderable method, and is therefore abstract. An empty implementation for AVTerrainRenderable is probably the right thing to do here.

I'm not sure I have time to look into Ogre's new memory manager to see what the right way to handle the memory management in OgreAVTerrainQuad. As it stands now a bunch of unresolved externs are reported for CatagorisedAllocPolicy::operator new and delete. Maybe if I catch a break on some other projects I can come back and look into this more.

I should add that the quick and dirty adding of undefs to OgreAVTerrainQuad made no difference.

Thieum · Post by **Thieum** » Mon Jun 09, 2008 2:01 pm

Thanks for reporting the problem

I added the missing method and now it compiles fine with ogre 1.4 and 1.6
I also removed the #include of OgreNoMemoryMacros since it is disable by default now (please correct me if it's wrong)

But the example does not run. It enters in an infinite loop in the material parser code when parsing the line with a matrix4x4 : "param_named pAdjustmentMatrix matrix4x4 1 0 0 0 0 0 1 0 0 1 0 0 0 0 0 1"
I think the bug comes from the parser, I will report it.

Anyway, the Update for the version 0.92 :
http://www.axyz-images.com/support/OGRE ... _Jun09.zip
- now compiles with Ogre 1.6

Jon · Post by **Jon** » Mon Jun 09, 2008 2:52 pm

You need to remove the "web.com" from the above URL.

Thieum · Post by **Thieum** » Mon Jun 09, 2008 3:02 pm

oops, thank you

Jon · Post by **Jon** » Mon Jun 09, 2008 3:22 pm

The plugin is still not linking for me

Which is not surprising as I tried to build without the header yesterday. The new/delete operators defined in abase.h are not being found. I don't see anything funny going on with preprocessor symbols -- ADVANTAGE_DLL is the only one defined. Also the IndexData destructor isn't being found. I need to get to work now, will try to poke at this further later today.

Jon · Post by **Jon** » Tue Jun 10, 2008 4:22 am

OK, I've had a chance to look into things, and would have preferred a nice luxurious perusal of the new custom allocator code to the "drink from the firehose" that I got. So given that I don't even know enough about the new custom allocators to be properly dangerous, here is my theory.

I believe that *part* of the AdVantageTerrainSceneManager is picking up the new allocators, and part is trying to use AdV's allocators. Specifically, OgreAVTerrainQuad.cpp is pulling in OgrePrerequisites (via OgreAVPprerequisites).

The linker complains:

Code: Select all

 __declspec(dllimport) public: static void _cdecl 
       Ogre::AllocatedObject<class Ogre::CategorisedAllocPolicy<4> > ::operator delete(void *)
       (__impl_??2?$AllocatedObject@V?$CatagorisedAllocPolicy@$03@Ogre@@@Ogre@@SAPAXI@Z)

or something very close. The actual error is on another machine, and I just retyped it. Maybe I missed an @, but the general thrust should be clear: OgreAVTerrainQuad knows about Ogre's custom allocators.

On the other hand, AdVantageWrapperWin32.cpp does not seem to have any sequence of headers which lead it to the new allocators.

On the gripping hand, adding an include for "OgrePrerequisites.h" to AdVantageWrapperWin32.cpp does not change a thing.

If I was working under Unix I could shove binaries through "nm" and get to the bottom of this. Instead I'm using the "hit it enough times with a baseball bat and something interesting will fall off" approach.

Removing OgrePrerequisites.h from OgreAVPrerequisites.h neither helped nor hurt, suggesting that it may not need to be there. The same applies to the include in OgreAVTerrainSceneManagerPrerequisites.h's inclusion of OgrePrerequisites.h: Everything in the project compiles without these includes, the final link fails. Although it is possible that stuff is coming in through some of the other includes.

I was able to remove the includes for OgreVertexIndexData.h and OgreStringConverter.h without any complaints from the compiler. I was hoping that the others could be disposed of with some forward declarations, but it looks unlikely.

Enough rambling, I'm going to sleep now.

ZZZZZZZZzzzzzzz

Thieum · Post by **Thieum** » Tue Jun 10, 2008 11:16 am

You are still compiling with Ogre 1.6 ? And which project does fail to link ? AdvantageSceneManager itself or a program using it ?

And are you trying to compile the example or did you included AV in another project ? Because everything compiles fine for me. The error could come from a header included before the advantage headers and it conflicts with the advantages memory allocators.

But I can't help you a lot, I don't have any problem with the compilation.

OgreStringConverter.h was added for a debugging purpose, i forgot to remove it.

Jon · Post by **Jon** » Tue Jun 10, 2008 2:09 pm

I'm building against the current SVN branch (1.6). Plugin_AdVantageTerrainSceneManager is the project which fails to link. The SceneManager is unmodified Jun9 code, Ogre is unmodified SVN last
synced two days ago. The compiler is VS2008.

So the only headers are the ones the scene manager brings in. No compilation errors are seen, so I don't think there is a problem with header paths. The only warning was the one regarding Wp64 being deprecated, and that switch hasn't done a thing since VS2003 if I recall correctly. The linker doesn't complain about any missing libraries.

It would be helpful if someone knowledgeable in the new custom allocation system would weigh in on what applications need to do to use it. I still suspect that the new allocators are not being used correctly/consistently.

While it compiles for you, I have to ask which compiler you are using. The supplied solution file is for VS2005. Has anyone built this under 2008?

Thieum · Post by **Thieum** » Wed Jun 11, 2008 10:39 am

I tried to compile with VC2008 and it works fine too. I also have an unmodified version of Ogre (I used ogre_vc8.sln updated to vc9)

Jon · Post by **Jon** » Sun Jun 15, 2008 11:26 pm

I can only imagine that you were not using a recent copy of the SVN tree. I'm using the 1-6 repository, but code is still being modified there. On Friday I did another SVN update, and some new files came down. Now everything links and runs.

For anyone else trying this, I ran into a problem where the Demo would hang during initialization. In particular when reading AVTerrain.material. As I mentioned in another thread, I believe an interator needed to be incremented here. Adding such an increment allowed the material to load. Another SVN update on the file in question verified that I was using the most recent copy in SVN, so I expect that anyone else attempting to run against the unmodified SVN branch today will have problems. Note that the other Ogre demos I tried ran without this fix, so it is an issue with AVTerrain.material using something which the other materials didn't.

(Edit: I see that this hang was reported earlier by Thieum, the fix is to
add a "++i" after the return in ScriptTranslator::getMatrix4 (OgreScriptTranslator.cpp).

I am seeing a problem with some of the normals pointing in the wrong direction (this may have been noted earler, I cannot scroll back that far while editing). I see this on puget.apak as well as output.apak. Once again I'm not sure when I'll be able to dig into this, but I am curious if others are seeing this.

Thieum · Post by **Thieum** » Mon Jun 16, 2008 10:31 am

Hi Jon

I updated my svn copy this morning and it still compliles fine. I have no idea why there is a difference with your copy. I am using this svn adress, maybe we are not using the same branch ? https://svn.ogre3d.org/svnroot/ogre/trunk

(Edit: I see that this hang was reported earlier by Thieum, the fix is to
add a "++i" after the return in ScriptTranslator::getMatrix4 (OgreScriptTranslator.cpp).

yeah, I reported it in this topic, but I forgot to report it to sinbad

I sent him a PM
i confirm that your fix works fine

And about the normals inverted, just remove the lines with cull_hardware anticlockwise in AVTerrain.material
I needed that with ogre 1.4 because the triangles streamed by advantage where ordered in the Directx way and by default ogre orders them in the other way. Something has changed here

Post by **sinbad** » Mon Jun 16, 2008 11:21 am

This is a prime example of why you should use the patch submission procedure instead of posting fixes in the forum. Things get buried in the forum, the patch system is the place to submit fixes.

There's a missing '++n' in that method too. I'll fix both bugs.

Jon · Post by **Jon** » Mon Jun 16, 2008 3:44 pm

Its sort of a damned if you do, damned if you don't system. Either one is criticized for submitting a patch for something which isn't broke, or for not submitting a patch. I try to keep a sense of humor about things, but it seems that most of what I hear from the Ogre team is critisism

@sinbad: Thanks for looking at this, I wasn't going to call this a bug until
at least one knowledgeable person agreed.

@Thieum: We are indeed using different branches. I have been pulling from https://svn.ogre3d.org/svnroot/ogre/branches/v1-6, which sort of looked like a 1.6 repository. I assumed /trunk was the 1.8 working files. Thanks for the suggestion on the normals, hopefully I can find time soon to try it. I figure I'll be spending a large chunk of time taking the APAK files apart. Since I'm working on automated content generation problems, it pays to have a system setup to stream content into the viewer with as little intervention as possible.

Edit: No time like the present I guess, the removing the culling did indeed fix the normals. I am seeing an annoying flicker of entire quads,
even some close to the camera. This is using the DirectX renderer and the most recent ForceWare. Now that all of the triangles are being drawn I can confirm that performance is what I hoped it would be. Shoving a larger batch of terrain at it is still in order.

Edit2: (I should be doing other things...) The puget.apak terrain file does not exhibit the flickering, suggesting that something with output.apak is the cause. I'll try rebuilding the apak. Under puget I see white lines separating quads at a distance, suggesting an LOD issue. These flickering white lines move away as the camera flys forward, the distance depends on camera height -- the lower the camera the closer the white lines.

Thieum · Post by **Thieum** » Mon Jun 16, 2008 5:33 pm

It also compiles fine with the 1-6 branch. Do you still have the linking error ?

The morphing between the LOD levels seems broken with ogre 1.6.
It would explain why you see white lines between the tiles. I will try to fix that.
But the good news is that the demo seems to run in openGL mode, it crashed with ogre 1.4. Of course the lighting does not work, but it does not crash.
Can you take a screenshot of a tile flickering ?I don't really see what is happening here.

Jon · Post by **Jon** » Mon Jun 16, 2008 6:48 pm

As I mentioned on Sunday, it compiles and runs fine on the current 1-6 branch (but it did not before Sunday). Something must have been broken in the Ogre base, because a few files came down with the most recent sync and things started to work. And it was a subtle thing, since the Ogre demos ran fine before and after the sync. The new allocator system seems worth the trouble though.

I wouldn't spend any time worrying about the flickering until I confirm that it happens on a fresh output.apak. I believe I am using one downloaded from a prior link in this thread, and it is possible that something changed. The fact that the current puget.apak (from Filip's site) runs without flicker supports this. I cannot take a screenshot at the moment, since I'm in the lab. But it looks like a few quads are rendered white, and this changes as the camera moves. But again, since this doesn't happen on puget there is no need to get concerned.

I think it is worth mentioning the flicker since others might run into it, if they follow the same route as I. Knowing that some apaks run without the flicker will hopefully make people feel better.

Regarding the morphing between LOD levels, even with the white lines it is much better than PLSM (sorry Tuan). The constant, extreme popping forced me to turn off LODs on PLSM. Otherwise one would be walking around and a hill would pop up next to you. Where is the morphing being done? At some point I'd like to take a look at it.

Thieum · Post by **Thieum** » Tue Jun 17, 2008 10:11 am

Oh, sorry I missed the sentence where you said it compiled right

The morphing is done in the cg program. The height of the vertices for the higher LOD level is saved in the .w component of the position. It is blended with the .z component (the height for the current LOD) by a factor depending on the distance to the camera. there is also the pMorphConsts parameter which define if the quad must be partially, completely or not morphed.

And about the flicker, I doubt that the problem comes from the APAK file. I had a lot of problem with the loading of textures, maybe there is still some bugs. (depending on the visibility distance, the tiles visible from the starting position, etc...)

leonardoaraujo.santos · Sat Jun 28, 2008 2:54 pm

Hi guys one question... does this scene manager implements the scene querys like others Ogre Scene Managers? (RayQuery for example)

Thieum · Post by **Thieum** » Mon Jun 30, 2008 9:31 am

Yes, it implements a RaySceneQuery that returns the intersection with the terrain as a world fragment (WFT_SINGLE_INTERSECTION).

There is a function in advantage that return the all triangles from the terrain contained in a box or a sphere. I tried to implement it as a AABB Scene Query but I don't think it was what Ogre's AABB Scene Queries were intended to do

leonardoaraujo.santos · Thu Jul 03, 2008 6:48 am

Thieum how did you create the *.apak files... IÂ´ve expanded the SDK.zip file included in the SDK and tried to open it on Visual C# 2005 Express edition but could not compile WorldMakerConsole (IÂ´m not a pro in C#). There is another step to create the *.apak files?

If you have the compiled version of WorldMakerConsole could you send it to me?

leonardoaraujo.santos · Thu Jul 03, 2008 6:59 am

Thieum sorry IÂ´ve found the wmc (WorldMakerConsole) it was on BIN directory....

Do you use some other terrain editor do create the heighmaps and texture?

Thieum · Post by **Thieum** » Thu Jul 03, 2008 8:44 am

I use the elevation data available from the NASA website and I converted them to TIFF with http://www.gdal.org/. I didn't need to use any editor.
(btw, the fact we live on a spherical planet and not on a disc planet really sucks)

leonardoaraujo.santos · Fri Jul 18, 2008 4:21 pm

Hi Thieum. Do you ever tried to connect the Advantage Scene manager with some Phisics library (ie: NxOgre). I've asked in another topic the "kenshi game" that also uses AdvantageScene manager but it uses a heighmap to deliver to NxOgre.

In PLSM it has an Listener for pages.

Does AdvantageScene manager has a similar feature?

Thanks man!

Thieum · Post by **Thieum** » Mon Jul 21, 2008 9:08 am

No, there isn't such feature. I don't think delivering a heightmap to the physics engine would be feasible because the terrain can be arbitrarily large and will never be fully loaded in memory.
Advantage provides some collision data (raycasting and triangles present in a sphere or a box)

But I looked in the examples provided with Advantage SDK and it seems that the openGL example is using Bullet (a physics engine). I did not looked in details how it was integrated

syedhs · Post by **syedhs** » Sat Aug 30, 2008 5:06 pm

Thieum wrote:I use the elevation data available from the NASA website and I converted them to TIFF with http://www.gdal.org/.

Thieum,

Where did you get to download the corresponding texture?

Thieum · Post by **Thieum** » Mon Sep 01, 2008 4:57 pm

I used google map and a program that download the tiles automatically (gmapmaker)
but the texture from google map and in Mercator projection and the tiles from the NASA are in "Lat-Long" projection (one tile is 1Â°*1Â°, the data is sampled with a fixed angle increment). You have to transform the tiles to make them in the same projection system.

(

Thieum wrote:(btw, the fact we live on a spherical planet and not on a disc planet really sucks)

I have to correct my statement : If the earth was a perfect sphere, it would be easier
)