Exception in GrassLoader (possible bug?) [solved]

Therein

24-06-2009 12:36:13

Hello everybody! I'm new to PagedGeometry, and almost new to Ogre too, but I'm having a lot of fun in learning these powerful technologies, for which I must congratulate the people behind :D

Well, the problem I'm having is this: I'm writing a cartographic application that represents vegetation layers using the GrassLoader, but obviously the size of the plants is affected by the terrain scale. This has lead me to the fact that, if I want to preserve the aspect of the layer independent from the scale, I must add a square scale factor to the density, so if the scale is very big the density is increased several times. So, while trying this, I got to an Exception which, after many hours of investigation, I came to the conclusion that must be related with the number of grass elements that can be contained in one single grass page.

I tried to reproduce it in the PagedGeometry Example 4 - GrassLoader, and I found that there is a limit to the density, either it is set in a layer, in the GrassLoader, or in a combination of them. I tried with different values, and the maximum values I could set for the layer density were these, depending on the page size parameter:

  1. size 120 --> density 4.50[/*:m]
  2. size 60 --> density 18.00[/*:m]
  3. size 240 --> density 1.377[/*:m]
  4. size 80 --> density 238[/*:m][/list:u]

    So, this is how I concluded that the problem has to do with the number of grass elements per page, as there seems to be a relationship betwee the page area and the density, approximately represented by:

    max_density = 64800 / (page_size)^2

    The exception I get seems to be related with a memory leackage, or similar, it says:

    Excepción no controlada en 0x00404d08 en Example 4 - GrassLoader.exe: 0xC0000005: Infracción de acceso al escribir en la ubicación 0x0548a000.

    In english, more or less:

    Unhandled exception in 0x00404d08 in Example 4 - GrassLoader.exe: 0xC0000005: Access violation writing in location 0x0548a000.

    And I've found that it is thrown in grassloader.cpp, line 269.

    So, is it a bug, or maybe the problem is with my computer or some sort of configuration? Has it happened to anyone else, or are you able to reproduce it?

    Thank you very much in advance!

tdev

29-06-2009 11:09:23

could you please provide the call trace / back trace or any other more information you have?

praetor

02-07-2009 16:58:56

Almost definitely this has to do with the indices. The speed things up the system is no doubt using 16-bit indices and when you increase the density you eventually overflow the limit and the driver is complaining. The solution is either to split up your grass into several layers, or to change PagedGeometry to detect high grass densities and switch to 32-bit indices.

garvek

01-08-2009 22:47:15

I confirm I have the same bug, I was trying to get high density grass (value 15 instead of 1.5) because my unit scales are 1:1. It's good to know, I thing that I will probably overcome the issue by changing my scales.

Therein

18-12-2009 11:23:04

Hello, I'm sorry I haven't replied all this time. I thought I would get a notification automatically, but apparently I had to subscribe. I had completely forgotten this issue, and it wasn't until I had to deal with it again that I searched for this post :)

Well, thank you anyway for the replies, as tdev asked me, here is the call stack:

> Example 4 - GrassLoader.exe!Forests::GrassLoader::generateGrass_QUAD(Forests::PageInfo & page={...}, Forests::GrassLayer * layer=0x00d2fd10, float * grassPositions=0x04ba0040, unsigned int grassCount=65920) Línea 269 + 0xf bytes C++
Example 4 - GrassLoader.exe!Forests::GrassLoader::loadPage(Forests::PageInfo & page={...}) Línea 156 + 0x1b bytes C++
Example 4 - GrassLoader.exe!Forests::GeometryPageManager::_loadPage(Forests::GeometryPage * page=0x00d2bfe0) Línea 704 + 0x28 bytes C++
Example 4 - GrassLoader.exe!Forests::GeometryPageManager::update(unsigned long deltaTime=27398, Ogre::Vector3 & camPos={...}, Ogre::Vector3 & camSpeed={...}, bool & enableCache=true, Forests::GeometryPageManager * prevManager=0x00000000) Línea 404 C++
Example 4 - GrassLoader.exe!Forests::PagedGeometry::update() Línea 223 C++
Example 4 - GrassLoader.exe!World::render() Línea 266 C++
Example 4 - GrassLoader.exe!World::run() Línea 255 C++
Example 4 - GrassLoader.exe!WinMain(HINSTANCE__ * hInst=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * strCmdLine=0x00151f3b, int nCmdShow=1) Línea 122 C++
Example 4 - GrassLoader.exe!__tmainCRTStartup() Línea 574 + 0x35 bytes C
Example 4 - GrassLoader.exe!WinMainCRTStartup() Línea 399 C
kernel32.dll!7c817077()
[Los marcos siguientes pueden no ser correctos o faltar, no se han cargado símbolos para kernel32.dll]


I think it's fairly clear, if there are any doubts (e.g. Spanish language issues) let me know and I'll try to make it clearer for you.

For the indices stuff that praetor suggested, I'm dealing with it right now, I'll post further inquiries.

Therein

08-01-2010 10:38:26

As praetor said, I confirm that the problem has to do with the indices. Actually, the maximum value for (layer density) * (page size)^2 is exactly 65535, that is, the maximum for a 16-bit index. By the way, I hadn't realised that reducing the page size actually increases the represented density (quite noobie heheh), so that's the solution.
In any case, some sort of exception handling should be added to check the maximum density value, I believe.

Thanks for your help!

tdev

27-03-2010 16:35:20

thanks for heads up on this problem, i added some checking into the latest SVN, please test ;)

the change:
http://redmine.rigsofrods.org/projects/ ... Loader.cpp