[Solved] Plugin_BSPSceneManager.dll not found

Hi Folks,

After all of the 1.2 SDK / VS 2005 / Swig 1329 issues, I'm finally getting a console window like I used to over a month ago !!!

Next issue: despite the fact that all of the DLL's are in my project's bin folder (having been copied from the 1.2 SDK \bin\debug folder, along with the seven newly compiled OgreDotNet ones, for a total of 25 DLL's, OGRE dies whilst accessing Plugin_BSPSceneManager.dll

This is weird, because the other 3 Plugin_*.dll's are right there with the BSP one, and they load perfectly (if I change the loading order in Plugin.cfg to prevent the crash caused by BSP).

The actual log error reads as follows:



...other unrelated stuff, then ....

18:45:21: Loading library .\Plugin_ParticleFX
18:45:21: Particle Emitter Type 'Point' registered
18:45:21: Particle Emitter Type 'Box' registered
18:45:21: Particle Emitter Type 'Ellipsoid' registered
18:45:21: Particle Emitter Type 'Cylinder' registered
18:45:21: Particle Emitter Type 'Ring' registered
18:45:21: Particle Emitter Type 'HollowEllipsoid' registered
18:45:21: Particle Affector Type 'LinearForce' registered
18:45:21: Particle Affector Type 'ColourFader' registered
18:45:21: Particle Affector Type 'ColourFader2' registered
18:45:21: Particle Affector Type 'ColourImage' registered
18:45:21: Particle Affector Type 'ColourInterpolator' registered
18:45:21: Particle Affector Type 'Scaler' registered
18:45:21: Particle Affector Type 'Rotator' registered
18:45:21: Particle Affector Type 'DirectionRandomiser' registered
18:45:21: Particle Affector Type 'DeflectorPlane' registered
18:45:21: Loading library .\Plugin_OctreeSceneManager
18:45:21: Loading library .\Plugin_CgProgramManager
18:45:21: Loading library .\Plugin_BSPSceneManager
18:45:21: An exception has been thrown!

-----------------------------------
Details:
-----------------------------------
Error #: 9
Function: DynLib::load
Description: Could not load dynamic library .\Plugin_BSPSceneManager. System Error: The specified module could not be found.

.
File: e:\projects\ogrecvs\branches\dagon_vc8_clean\ogrenew\ogremain\src\ogredynlib.cpp
Line: 82
Stack unwinding: <<beginning of stack>>




Instinct tells me the "The specified module could not be found." message isn't the actual cause, because, as I said the plugin is right there with the others that actually *do* load.

Perhaps it's a corrupt file or incompatible version? This file was compiled on the same day (12th March 2006) as the other Plugin_*.dll files, and is a component of the formal SDK.

Please tell me someone else has hit this problem !!!

Cheers,

GregH.

PS/ Does anyone out there know how to use an Iterator for getting AnimationStateSet info ?

Hi Greg,

Yep, that's exactly where I'm at too…

This only seems to occur when trying to use the debug version of the dlls.

The only way I’ve gotten it to work, so far, is with the release version of the dlls. The error you’ve listed here is exactly the same error I am getting.

EagleEye and I have gone ‘round with it and we just can’t figure it out. I think it’s what you’re thinking too… that the error is just runnin-home-to-mamma because the file *is there*.

I’ve been working on this for the last couple of days and still no joy.

When you finally get around to trying the release version of the dlls you’re going to find the next challenge, the dreaded “AccessViolationException was unhandled” error.

This only seems to occur when exiting a FullScreen instance of the app.

The error goes on to read, “Attempted to read or write protected memory. This is often an indication that other memory is corrupt.”

Strangely enough when I remove the [STAThread] attribute from main it seems to exit fine. i.e.:

//[STAThread]
static void Main(string[] args)

I am still looking into whether this is good practice. They tell me that this attribute ensures the communication mechanism between the current thread and other threads that may want to talk to it via COM. [Is this ever needed in an Ogre app?]

NOTE: The app exits fine in windowed mode either way (with [STAThread] in or out)

I’m glad you’ve started a thread on this. I’ll keep posting my findings here.

Sincerely

EB

Oh, one thing I’ve been wondering… and this is probably a stupid question, but I’m relatively new at this stuff…

What are the benefits of using a debug version of the dlls vs a release version?

As far as I can tell, you can’t step around in the dll code with Express edition (and I’m not sure even if you can do it with pro ed. either. Please someone tell me that you can… I’d love to be able to step into the wrapped code.)

But look, if Ogre doesn't add more debug features (like a verbose log or something), with a debug version of the dlls, then why even bother with trying to get them to compile and just move straight on to the release version… (Seems they’d be faster anyhow).

EB

Hi EB,

Well, I guess that's good news and bad. It means I'm not alone, but it means a community stumbling block. This path is getting darker by the minute.

Ok...I copied Plugin_BSPSceneManager.dll from the \release folder of the 1.2 SDK to my project \bin folder, renamed it Plugin_BSPSceneManagerR.dll (added R for 'Release') and edited the Plugins.Cfg file so it would try to load that sucker instead.

I get exactly the same log error when trying to load the release version.

I don't even want to think about what's going to happen after we solve this little SOB.

Cheers,

GregH.

PS/ Does anyone know how to use an iterator on AnimationStateSets?

Only changing one dll to release won't do it... all the dlls must be release to get around that error... so... does that clue anyone in??

Stumped,

EB

GregH

No, that wouldn't help.. You need to build ogredotnet in release config. So all dll's are release-versions, then you need to get all ogre dll's from release directory too. don't use ANY debug-versions or use ONLY debug-version.

Hi Folks,

Just another thought on this mongrel of a topic: if Plugin_BSPSceneManager.dll is part of the formal 1.2 SDK, then the main ORGE Forum should be reporting the same issues...that is, this fickle little dll is not DotNet specific...

I've scoured the Main Forum and can't find any probs related to this..how come?

Cheers,

GregH PS/ Does anyone know how to use an iterator on AnimationStateSets?

Hi Vintersorg,

Thank you for the non-mixed debug/release advice. Let me guess - that's another commonly known fact that few know

OK...supposing I spend yet another night rebuilding the whole ODN enchilada...what are we going to do when when we hit E'blisses exception fiasco that ensues? Plus, I imagine the purpose of having debug versions is that they provide a higher level of crash detail than that of release?

Methinks we need to get to the bottom of BSP's attention deficit syndrome before forging another 30cm/foot/small pizza width.

Cheers,

GregH.

Ogre 1.2 is RC1, that’s Release Candidate 1. Seems this is a bug in VS2005 version the BSP plug-in is messed up. 2003 version the open GL renderer does not work, for me at least. RC2 will be out soon maybe they will be fixed. Try searching the Main forums to see if others have had this problem.

If you don’t plan to use BSP remove it from Plugins.cfg.

Hi Folks,

Ok..so the next question is:

"How does Plugin_BSPSceneManager.Dll differ in the way it is structured/compiled to the other Plugin_*.Dll files that work for us?"

We ODN folk (well at least this little black duck) may not be savvy with the internal workings, but surely someone *is* that can answer the question. Why is *this* Plugin different to the others? And along the same line, it used to work, now it doesn't - so what has changed?

Cheers,

GregH.

Ahhh here is another thread (in the main forum) that talks about it... but alas, no solution mentioned.

It looks like jacmoe was trying to help but...

Here is the thread: http://www.ogre3d.org/phpBB2/viewtopic.php?t=19034&highlight=debug++release


I will try to answer the questions he posted:


Can you build a regular win32 application and run it without errors?
Yes. I have the MS Platform SDK installed per these instructions: http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/default.aspx


Does the compiler tell you anything at all about failing to link in a manifest?
No. To the contrary, as the build on OgreBindings reads:
1>Linking...
1> Creating library Release/OgreBindings.lib and object Release/OgreBindings.exp
1>Embedding manifest... <<------------------------------<<<<<<
1>Performing Post-Build Event...
1> 1 file(s) copied.
1>Build log was saved at "file://c:\_projects\ogredotnet\OgreNet\Release\BuildLog.htm"
1>OgreBindings - 0 error(s), 7 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========


Are you absolutely sure that you've built everything from scratch using the default vc8 solution?
About as "from scratch" as I know how. I'm not rebuilding ogrenew from scratch if that's what you mean.


Care to share your buildlog with us?
Well.. its big and UGLY... if we don't get this resolved soon.. then I'll post it.

EB

Greg:
Plus, I imagine the purpose of having debug versions is that they provide a higher level of crash detail than that of release?
If you are correct about that.... and that's still an *if* right? I mean, are we certain that there is a high lvl of detail? [I'm sure you're correct about this but I honestly don't know.]

What version has everyone else here been using?

If, in the previous version, you were able to use the debug versions (and they provide *at least* a little benefit) then I'm with ya on this: Methinks we need to get to the bottom of BSP's attention deficit syndrome before forging another 30cm/foot/small pizza width

This is a good question:
"How does Plugin_BSPSceneManager.Dll differ in the way it is structured/compiled to the other Plugin_*.Dll files that work for us?"

I not sure its having trouble *finding* the dll. I think it's having trouble loading it. But we can't debug the thing, as we're on the outside of wrapper. (at least I haven't found a way yet but I'm just a noob)

I'm half-tempted to log the snot out of DynLib::load... hmmm actually the loging should probably be done in the errant dll... there's just *got* to be a better way of debuging this...

EB

At this point, I'm almost completely convinced that the problem lies in the VS 2005 debug version of Ogre.

I'm not having this problem at all. When troubleshooting the problem with EB, I asked him what his file size was and he said 616k or so, whereas my debug version of that DLL is ~400... At first I thought this was really odd, but then I realized that the Ogre SDK has a VS7.1 version, and a VS8 version... I got the VS8 version and all of the files had different sizes. Different environments, different file sizes I guess... but that also means we're using completely different FILES. Honestly this is the ONLY point of departure between the two of us. We are both using the very same OgreDotNet code. We are both using the very same config files... it's the Ogre SDK that's the problem.

Witness also that it's only in Debug mode, indicating a single buggy DLL is the problem. It may NOT be the specific BSPSceneManager DLL that's the problem (it may be a DLL calling it), but still, he's using a whole different SET of OgreSDK DLLs.

Also look at the similarities. Rastaman and I: VS2003 for both of us, or Mono (which uses the VS2003 versions of things)... and we have no problems.

EB, GregH, and now this guy on the main forums... all of them using VS2005 in debug mode.

Friends, it's a bug in the SDK... nothing we're doing wrong.

Friends, it's a bug in the SDK... nothing we're doing wrong.
Hmm… it seems as though this could be the case and makes me want to move forward with the release dlls for a while to give the SDK some time to update.

Please excuse my ignorance here, but could it be that the debug dlls don’t work when the release dlls do? It seems to me that if the debug dlls don’t work then the release dlls wouldn’t either… but what the heck do I know.

Well… I think I’m going to put the quest-for-a-workable-set-of-DEBUG-dlls on the back burner for a bit… let ‘em simmer… (eventhough I *have* made some progress… check my post below…)

EB

It's entirely possible that the debug DLLs don't work when the release ones do. The build instructions could be messed up for the debug version or something...

Okay... here’s a progress report.

The good news is, I finally got the debug version of the dlls working!

I went ahead with the advice given to me by both EagleEye and Rastaman and removed Plugin=Plugin_BSPSceneManager from the mix.

I can create a skybox but I can’t get CE’s GUI working.

protected override void CreateScene()
{
mLog = LogManager.Singleton.createLog("DemoCEGUI.log", false, true);
mLog.LogMessage("My new Log. Hells yeah!");

base.mSceneManager.AmbientLight = Color.FromArgb(125, 125, 125, 125);
base.mSceneManager.SetSkyDome(true, "Examples/CloudySky", 5, 8);
}

The above code works fine… but if I add this line after the SetSkyDome call it bombs out:

mGuiRenderer = new OgreCEGUIRenderer(base.mRenderWindow, (byte)RenderQueueGroupID.RENDER_QUEUE_OVERLAY, false, 3000, mSceneManager);

Here is the inner exception:

InnerException = {"Unable to load DLL 'OgreBindings_Cegui': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"}

Now… I *know* that the 'OgreBindings_Cegui.dll file is in there! [Strange, and interesting, that we have such a similar error.] Could it be that both BSPSceneManager *and* Cegui aren’t updated in the SDK yet?


Okay so I can get this app to run with the debug dlls:

using System;
using System.Drawing;

using OgreDotNet;

namespace DemoCEGUI
{
class CEGUIApplication : ExampleApplication
{
protected override void CreateScene()
{
base.mSceneManager.AmbientLight = Color.FromArgb(125, 125, 125, 125);
base.mSceneManager.SetSkyDome(true, "Examples/CloudySky", 5, 8);
}

public override void Dispose()
{
base.Dispose();
}

[STAThread]
static void Main(string[] args)
{
CEGUIApplication app = new CEGUIApplication();
try
{
app.Start();
}
catch (Exception ex)
{
Console.WriteLine("### Exception {0}\n{1}\n{2}", ex.Message, ex.Source, ex.StackTrace);
}
finally
{
try
{
app.Dispose();
}
catch (Exception ex)
{
Console.WriteLine("### Exception {0}\n{1}\n{2}", ex.Message, ex.Source, ex.StackTrace);
}
}
}
}
}

But a strange thing happens when calling base.Dispose() in full screen mode.

I get the dreaded:

AccessViolationException was unhandled error

It goes on to say:

Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

But when I run *the exact same code* in windowed mode the app exits gracefully.

If I take the base.Dispose() call out, the fullscreen mode will exit gracefully too.

What the heck is going on here?


Dumbfounded,

EB

The protected memory error likely has something to do with not disposing something that was created. The debug version will throw an exception (because in debug development you're supposed to be looking for memory leaks and such, which this is likely to be).

In my own code, I have to call the CEGUI method "destroy all windows" then I have to destroy my CEGUI object... let me get the actual code...

WindowManager.Instance.destroyAllWindows()
GUISys.Dispose()
GUI.Dispose()
Root.Dispose()
Me.Dispose()

So dispose Root first, then your application...

Oh, one other thing...

This is going to be obvious but… I’m going to post it anyway.

The FPS while using the debug dlls is around 120fps… but with the release dlls the FPS goes up to a whopping 1000fps!

EB out…

So dispose Root first, then your application...

I took Crazy Eddie completely out of the picture so calls to dispose it are (obviously) failing.

When I try to Dispose mRoot I get a stack overflow error on it.

public override void Dispose()
{
mRoot.Dispose();
this.Dispose();
}

Bahhh!!! LOL

EB

I guess the next thing that we vs2005 users need to do is build the dlls from the source and see if we can reproduce this problem with libraries that were compiled natively.

I have a feeling that we are going to have some build issues with the ogrenew code as well.

I'll get started and report back here.

Oh... this is excellent... DC...

If there are errors in the native code (that are similar)... that just might prove that it's the sdk and then we can rest a little easier.

One major gap in my understanding of ODN is the SWIG stuff... I guess I need to take some time out and learn some swig. I just can't help but wonder if swig needs updating for the new platform too.

Any swig experts out there think these issues we are having with "can't find dlls" (or better still, "can't load dlls") could be related to swig?

I can't wait to see what you find out DC... In the mean time... I'll start working on a step-by-step to get a good working set of "Release dlls". [I'm tired of getting kicked around by the debug dlls and want some joy!]

EB

Ok here's what I found.
Since CVS was still down, I used a copy from ~week ago.
I downloaded the dependencies from


http://www.ogre3d.org/index.php?option= ... fileinfo&f
ilecatid=46&parent=category

and extracted them into ogrenew as the wiki

(http://www.ogre3d.org/wiki/index.php/Bu ... rom_Source) suggests.


(build notes, DEBUG configuration)
OgreMain -
Aside from a fair amount of conversion warnings during the compile process:
and a few signed/unsigned mismatch warnings

I get various link warnings like this:
zziplibd.lib(err.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with

'..\..\Dependencies\lib\Debug\zziplibd.lib' or at

'c:\Ogre\ogrenew\OgreMain\lib\Debug\vc80.pdb'; linking object as if no debug

info

Which I disregard assuming that all is well.

Plugin_BSPSceneManager -
Plugin_BSPSceneManager - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Plugin_CgProgramManager
Plugin_CgProgramManager - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Whoa.. I'm feeling pretty good. no warnings on the last 2 steps.

Plugin_OctreeSceneManager
lots of warnings of the same varieties (conversion,signed/unsigned mismatch)
as OgreMain.
Plugin_OctreeSceneManager - 0 error(s), 96 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

But I maintain faith that all is still well

Plugin_ParticleFX
1 single type conversion warning.
Plugin_ParticleFX - 0 error(s), 1 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

1 warning.. ok. still feeling pretty good about this.

ReferenceAppLayer
1 link warning which looks like it might bite me the arse later:
LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs;

use /NODEFAULTLIB:library
ReferenceAppLayer - 0 error(s), 1 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

But, I forage on. (still in a good mood.)

OgreGUIRenderer
OgreGUIRenderer - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

RenderSystem_Direct3D9
many of the same type conversion warnings.
RenderSystem_Direct3D9 - 0 error(s), 78 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

RenderSystem_GL
OOPS I forgot to update this log.
lots of warnings.

PlatformManager_Win32
PlatformManager_Win32 - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Ok. now we're cooking.
Time to try a Demo

Demo_Shadows
Demo_Shadows - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 8 up-to-date, 0 skipped ==========


So I launch it
got the Orge Startup GUI .. so far so good.
choose DirectX click go.
OK! joy. slow framerate ~30-40 fps. but a good sign.


Now, since I've had success, Im going to be brave and "build solution"

well, I'm ecstatic.
========== Build: 34 succeeded, 0 failed, 11 up-to-date, 0 skipped ==========


Now,
because Im lazy I just copied all the debug dlls that are buried within the
ogrenew\*\bin\debug\ to my project's bin\debug folder

then I build a simple app which should reproduce EB's bug.

run it

voila.

no more PLugin_BSPSceneManager.dll not found error..

yay!!!

but wait.. 1 more small thing to test..
so, I put the OgreSDK\bin\debug\* into my project's bin\debug\*

I close vcs 2005 express

I open it and my project again.

make clean

rebuild

rerun

BINGO. same error:

//-------- from Ogre.txt in bin\debug ------
-----------------------------------
Details:
-----------------------------------
Error #: 9
Function: DynLib::load
Description: Could not load dynamic library .\Plugin_BSPSceneManager. System

Error: The specified module could not be found..
File:

e:\projects\ogrecvs\branches\dagon_vc8_clean\ogrenew\ogremain\src\ogredynlib.cp

p
Line: 82
Stack unwinding: <<beginning of stack>>
22:14:56: Termination handler: uncaught exception!
22:14:56: *-*-* OGRE Shutdown
----------------------------------------


I think we conclude the error is in the SDK build of the debug dlls

Bug reported...

http://www.ogre3d.org/phpBB2/viewtopic. ... 842#139842

one quick note.

I tried using the OgreSDK\bin\debug dlls and Plugin_BSPSceneManager.dll from ogrenew.

the error also goes away..

I put OgreSDK\bin\debug\Plugin_BSPSceneManager.dll back and voila Orge barfs again.

Cheers ladies & gentlemen.

good work DigitalCyborg

Hi Folks,

Well collectively we nailed the problem as a grumpy debug version of the Plugin_BSPSceneManager.Dll (even though the release version appears to work Ok) - and EagleEye has reported the bug.

For the Community's benefit, what usually happens next? I guess what I'm really asking is should we all use/recompile release versions of all 25 dll's until further notice, or wait X long for an update to appear.

I don't mind what the answer is - just an indication of typical process time.

Cheers,

GregH.

My suggestion would be to download the CVS and compile a debug version of the BSP Scene Manager DLL there. That seems to be the best solution.

Hi EE,

But if the problem hasn't yet been fixed in CVS, won't that still produce a flaky dll Or are you suggesting that a local compile of the offending dll may fix the problem

Cheers,

GregH.

Read the description of the problem again... the SDK DLL for that plugin is faulty...

The CVS version isn't.

That's how we tracked down and isolated the problem... swapping out SDK DLL for CVS DLL fixed it... putting SDK DLL back in caused it to reappear.

I think we conclude the error is in the SDK build of the debug dlls

DigitalCyborg… excellent work mon! This is GREAT news!!!

So EagleEye's premonition was correct when he said:

Friends, it's a bug in the SDK... nothing we're doing wrong.

Now… I *hope* we can get a few small-pizza-lengths further... before the next... But with this kind of brains and brawn on the matter... they don't stand a chance...

Thanks again for your excellence DC! YES!!!

Elated,

EB

Just wanted to give kudos to the *excellent* bug report too!

Great work gentlemen...

EB

Hi Folks,

Sorry to sound stupid earlier ... but I had never heard of "ogrenew" which I gather is a CVS version of some or all of the source of OGRE. I trust the Forum understands that we don't all know this stuff by default, osmosis or genetic inheritance. Nor do we have time to read/follow a zillion links to educate ourselves

Currently I'm CVSing the dependencies and the Windows source in an effort to follow DC' steps in recompiling the faulty debug version of the Plugin_BSPSceneManager.Dll

I hope I succeed, because then I can write a program using OgreDotNet, which will continue to be my major focus. All of this other stuff continues to be an impediment to our collective goal.

Here's to moving a truckload of small pizza-widths forward.

Cheers,

GregH.

I trust the Forum understands that we don't all know this stuff by default, osmosis or genetic inheritance.
LOL… I’m glad I’m not the only one feeling like an underachiever.

You have been instrumental in furthering the solution to this challenge and you started the thread in perfect timing.

As far as I’m concerned… we’re in this together.

Here's to moving a truckload of small pizza-widths forward.
Hear, Hear!

Cheers *to you* Aussie Brother!

EB

!! WARNING: This is info if incorrect... see my post below:

Be sure the get the v1-2 revision branch as per Sinbad.

For those of you noobs (like me) you'll find the Revisions tab in Tortoise... that's where to set the branch.

Nice... the cvs dnld just completed... off to find some joy... [fingers x-ed]

EB

Be sure the get the v1-2 revision branch as per Sinbad.

If you dont want to get rev1.2 you can also get "HEAD" which will give you top of tree, which is the newest shxt.. I think there are some fixes in HEAD that Rasta checked in a day or 2 ago.

Actually, I think the fixes that Rasta mentions here:
http://www.ogre3d.org/phpBB2addons/viewtopic.php?t=906

are in the HEAD of ogredotnet not orgenew.

Sorry for the confusion.

Okay, CVS is a repository as well as a way for keeping all developers up to date.

There are different "branches" of a CVS tree.

The main one for ogre is "ogrenew". This is also called the "CVS Head", as it contains all of the most recent updated files.

Every time a new major release comes out, the CVS Head is copied in to a "revision" folder, so future updates don't ruin the old working copies.

You can download revisions, or you can just download the CVS Head...

Search the wiki for how to get the CVS head.

Strike what I said above... the revision v1-2 has the bad Plugin_BSPSceneManager.dll file!

The current HEAD works fine.

EB

Hi Folks,
I’m attempting to build OGRE SDK 1.2 from scratch (and this relevant to ODN because one of the DLL's in the SDK is NBG) and I require assistance with the step involving WIKI instructions:



“Extract the Ogre source, then extract the dependencies inside the ogrenew folder”



Due to the ambiguous nature of the English language, I take it that the Ogre Source zip files in is ogre-win32-v1-2-0RC1.Zip need to ‘merged’ with the freshly CVS’d “OgreNew” folder content?

If this is the case, I am at a loss as to why I’d be overwriting very recent files (in “ogrenew”) with many radically out-dated Ogre Source files from the zip.

The WIKI definitely says to obtain ogrenew as the first step, then extract the source, then the dependencies.

Sorry, call me thick, but I just don’t see how retro-dated files are going to help. Moreover, I’m a little concerned that this is the first step in a long chain – just so I can get ODN working on my box.

Cheers,

GregH.

GregH
Why are you building from source? Are you trying to use the BSP plugin? I'v read that OctTree is better than BSP now. Ogre RC2 will be out soon most likely this weekend. the only reason it wasn't released last weekend was because developer cvs was down. Sinbad is aware of the problem with the plugin dll and has a way to verivy if its ok http://www.ogre3d.org/phpBB2/viewtopic.php?t=19209

anyway if you download cvs you need the Dependencies (Precompiled versions of 3rd-party libraries, like DevIL zzip...)
http://www.ogre3d.org/index.php?option=com_remository&Itemid=74&func=selectcat&cat=4
Get the one for you compiler (OgreDependencies_VC8_1.2.0.zip).
Put it in ogrenew dir.
Then extract it there.
Open the solution file
Do a batch build (this will take forever
In OgreDotNet projects you will have to tweek the include and lib paths in the Bindings projects. Because the souce dir layout is a bit different than in the SDK.

Hi Folks,
I’m attempting to build OGRE SDK 1.2 from scratch, and I require assistance with the step involving WIKI instructions:

“Extract the Ogre source, then extract the dependencies inside the ogrenew folder”

Due to the ambiguous nature of the English language, I take it that the Ogre Source zip files in is ogre-win32-v1-2-0RC1.Zip need to ‘merged’ with the freshly CVS’d “OgreNew” folder content?


Not exactly..
EB proved that you need to download the orge source code from the CVS repository since the code in the ReleaseCandidate zip file is broken.

After you do that, you'll have to download the windows dependencies from
http://www.ogre3d.org/index.php?option= ... tcat&cat=4

Then, once you have that file downloaded, you'll have to extract its contents into the ogrenew folder. The ogrenew folder is where the CVS files that are downloaded live.


If this is the case, I am at a loss as to why I’d be overwriting very recent files (in “ogrenew”) with many radically out-dated Ogre Source files from the zip.

nope... ogrenew from CVS, dependencies from the link I posted.


The WIKI definitely says to obtain ogrenew as the first step, then extract the source, then the dependencies.

Once you get ogrenew from CVS, you only need the dependencies.

Hi DC,

Thanks for the advice: so in effect, CVS "ogrenew", skip the "Extract the Ogre source" and go straight to the "dependencies" step. Well that makes more sense !!!

So the WIKI is incorrect. Ok. I'll remember to use WIKI docs as a 'rough guide' rather than actual instructions in future. This is not a criticism, as I'm aware that they are provided by good people with good intentions.

Cheers,

GregH.

Okay… GOT IT!

Well… it’s been a long and arduous road… but it looks like I’ve finally arrived.

First, BIG THANKS to everyone who’s helped. Especially EagleEye and DigitalCyborg… much appreciated gents.

After DC rebuilt the Plugin_BSPSceneManager.dll we found that it finally loaded. I proceeded to download the v1-2 branch of the OgreCVS only to find the same problem! So I downloaded the HEAD (as DC did) and it worked fine.

This was great… but… alas…. A new error. It was some kind of unhandled type error when constructing a new OgreCEGUIRenderer. I forget the exactly error and I’m not going back to find out!

To make a very long story short, if you are using VSC# Express 2005 then, just download the OgreCVS HEAD and build the whole thing in VSC++ Express 2005.

Then, I made this batch file to pull the needed dlls (and their pdb files if you wish) from the OgreCVS. The batch file can be found in this thread: http://www.ogre3d.org/phpBB2addons/viewtopic.php?p=5822#5822

Use these dlls… not the ones in the SDK… The only stuff you need from the SDK is the cfg files from bin/Debug and the media directory. I (for now) have been putting the media dir on the same level as the bin dir of my project. (You can put the media dir anywhere just edit the media.cfg file.))

Then build the ODN CPP bindings projects. Then build the ODN C# projects.

Then take all the dlls that were created and put them in their respective dirs of your project (i.e. all Debug dlls into MyProject\bin\Debug and all Release dlls into MyProject\bin\Release)

I’m able to run just fine with both debug and release dlls now!

There is just one very small issue now. (Isn’t there always?) I am going to create a new thread for it here. http://www.ogre3d.org/phpBB2addons/viewtopic.php?p=5824#5824

Okay… looks like this issue has been solved. Once Greg finds joy that’ll confirm it.

Things are lookin’ UP!

EB

Hi Folks,

Boy, what a long road !

Hey EB...looks like we arrived on the VS 2005 welcoming mat at the same time...check out my thread on "Eihort now executing under VS 2005".

Dude, I nearly wet myself when my ocean appeared !!!

Thanks once again to all that helped with this prob. Way to go !!

Cheers,

GregH.

Dude, I nearly wet myself when my ocean appeared !!!


Got screen shots?