[solved] built exe+dlls vs binary distribution, differences

Jon

22-10-2005 18:39:02

I have build the source distribution with VC7.1 in my own tree, and have things "sort of" running.

However there are differences between my EXE/DLLs and the ones in the binary distribution. I'd like some help determining what I should be looking into.

My build renders the grand_canyon maps with about 4.5M triangles :shock:

This happens with either the maps split in my tree, or the maps split in the binary distribution's tree. The binary distribution renders with about 35K triangles.

Now, there are differences in the splitting based on page/tile size in the CFG files. But this isn't the source of the problem. I can copy the cfg and the split maps out of the binary tree into my tree and get the same 4.5M triangle run. I haven't tried to bring my split maps over to the binary distribution, since I am not troubleshooting map splitting at the moment.

It seems clear to me that the binary distribution's map splitting is done well enough for that EXE to run at a reasonable speed. So I'll work with those maps for a bit. And my EXEs and DLLs work equallly wierdly on either set of split maps.

One possibility is that there is something in the built EXE which causes this behaviour. To test this, I copied the EXE and DLLs into the binary distribution tree and attempted to run. I received a bunch of exceptions like:



Error #: 8

Function: ResourceGroupManager::openResource

Description: Cannot locate resource gras_02.png in resource group General.. 

File: \ogrenew\OgreMain\src\OgreResourceGroupManager.cpp

Line: 501

Stack unwinding: <<beginning of stack>>

This seems self-explanatory, except that all I did was copy over EXE and DLL files into the directory. All the cfg files and media files are as they were when running the binary distribution.

So either the binary dist didn't mind these missing resources, or my EXE+DLLs are pulling in gras_02.png. I can't believe that either of these cases are correct.

But if I copy the binary distribution's files (Dagon based) back into that folder, everything runs correctly. Yes, I've triple-checked that only DLL and EXE files are copied.

I would prefer to be using the files I've built from source.

Jon

23-10-2005 00:43:13

OK, here is what I learned (rather painfully).

The Demo application in the precompiled binaries is different from the one in the source distribution (I mean other than just being build against a different distribution). For one thing the trees and grass are turned off in the prebuilt binary, and are turned on in the source distribution.

In TerrainListener.h (around line 77) are the two booleans which turn these features on/off. Turning them off gave me a run with triangle counts in the 20-30k range. Turning them on raised this to about 4M. This results in fps dropping from 90 or so to .08 :cry:

This looks like something someone was experimenting with and committed, correct me if I'm wrong here. I can't imagine may systems that could handle polygon counts like this.

As much as I like trees and grass, I don't think we need them to be rendered so far from the camera. For the most part there would only be 2 or 3 trees in sight (not sure if I ever saw a grass blade). But they were certainly taking up resources somewhere.

I'd like to hear more from people working on this. Perhaps the day will come when I can turn this back on.

In the meantime I have everything completely built from source, and can start my own experimentation.

Oh, regarding the missing resource mystery... the executable was indeed bringing in grass and tree resources. These were hardcoded in the plugin and in TerrainListener

This means that moving the DLL resulting in resource loads, and these resources were not in the binary distribution. I cant imagine that the plugin was designed to load trees/grass onto any scene rendered.