Problem running IRender after loading Twilight.

Al Hart · 20 Oct 2009, 02:24

I'm definitely not the right person to ask when it comes to ruby-codes and how to avoid this...
Hopefully those involved knows what needs to be done...

I have our man trying to trace down the problem. It appears that we are loading different versions of the .NET DLLs into SketchUp. We will try to come up with a fix.

xrok1 · 20 Oct 2009, 02:26

i'm sorry, my post should have read "why would you want IRender if you have Twilight anyway?" but i was just clowning around, i didn't mean to offend anyone or any software.

Please accept my apologies.

Al Hart · 20 Oct 2009, 05:18

@xrok1 said:

the question is... why would you want IDX if you have Twilight anyway?

Are there any moderators following this thread? If so, how do we report abuse.

I think people who want to turn legitimate threads into personal attacks should be banned - if not permanently, a least for a meaningful period.

I don't think that the SCF should turn into a place for people to add inappropriate comments.

I wonder if this author has ever tried IDX? I know I haven't. But, still, I wouldn't go around taking pot shots at it.

notareal · 20 Oct 2009, 07:46

@al hart said:

@frederik said:

I'm definitely not the right person to ask when it comes to ruby-codes and how to avoid this...
Hopefully those involved knows what needs to be done...

I have our man trying to trace down the problem. It appears that we are loading different versions of the .NET DLLs into SketchUp. We will try to come up with a fix.

Some older version?

bravoddb · 20 Oct 2009, 09:29

@xrok1 said:

i'm sorry, my post should have read "why would you want IRender if you have Twilight anyway?" but i was just clowning around, i didn't mean to offend anyone or any software.

Please accept my apologies.

Hi, I have both Irender and Twilight, and for me I use and I "need" both, why? Irender is very very fast, and I use when I have to make a presentation with too many renderings for the next day or so, Irender has very good quality, very useful features, I use Irender for animations too,is easy to make animations with I render, and Twilight, I have some clients that know a little of renderings (some friends that are architects too) and they want unbiased renderings, and I use Twilight for thatis very easy to use, but unbiased renderings takes more time.

So I completely understand when some one has both rendering engines.

Chris_at_Twilight · 20 Oct 2009, 14:14

When I installed the demo for IDX, it installed the Visual C++ 2005 runtime dll's. Twilight uses the 2008 dll's. I've never encountered (I think) an application with plugins using separate VC++ dlls so I don't know that this is the cause...actually I kind of expect it should work but Microsoft made such big changes with SxS etc... who knows.

We'll try to help solve this too. We have no intention of conflicting with any other software.

notareal · 20 Oct 2009, 14:20

Is this related to http://nxt.accurender.com/forums/t/2645.aspx
" Hi,

I just purchased the licence and then followed up to update my previous version with the latest one and since then I seem to be getting this crazy visualc++ bug every time I either try to edit materials or render. I've found for some strange reason that if I use nxt stable edition I can modify the textures but not render and if I use the Beta version I can render but not modify the textures. As I might not be making myself clear I've put a ling to a screencap ... was wondering if it has happened to anyone and if anyone knows how to fix this problem.

thanks.

http://www.creationscoquerel.com/irender_bug.jpg
Filed under: visual runtime error"

So would the problem be in Visual C++ Runtime, not in .net?

notareal · 20 Oct 2009, 14:23

Beated me, Chris. Good old dll hell.

Al Hart · 20 Oct 2009, 14:36

@notareal said:

Is this related to http://nxt.accurender.com/forums/t/2645.aspx
" Hi,

I just purchased the license and then followed up to update my previous version with the latest one and since then I seem to be getting this crazy visual c++ bug every time

Is the problem you are having related to twilight, or is it a completely different problem.

If you have twilight installed, rename the .rb file to a different extension, and see if that fixes your problem. If you do not have it installed, then this is a different problem, and we will have to find a different fix for it.

Al Hart · 20 Oct 2009, 14:39

@chris_at_twilight said:

When I installed the demo for IDX, it installed the Visual C++ 2005 runtime dll's. Twilight uses the 2008 dll's. I've never encountered (I think) an application with plugins using separate VC++ dlls so I don't know that this is the cause...actually I kind of expect it should work but Microsoft made such big changes with SxS etc... who knows.

We'll try to help solve this too. We have no intention of conflicting with any other software.

I'm sure you meant IRender, and not IDX.

This may be a MSVC 2005 vs MSVC 2008 problem. If so, that will be unfortunate, but hopefully we can work out a fix. We thought it was related to .NET, but it may be the 2005 DLLs instead.

Thanks for taking a look at it for us.

[Edit] Also, our other applications, using a similar 2005 DLL work OK with Twilight loaded. So it is something about the rendering application which is interfering.

notareal · 20 Oct 2009, 14:49

@al hart said:

@notareal said:

Is this related to http://nxt.accurender.com/forums/t/2645.aspx
" Hi,

I just purchased the license and then followed up to update my previous version with the latest one and since then I seem to be getting this crazy visual c++ bug every time

Is the problem you are having related to twilight, or is it a completely different problem.

If you have twilight installed, rename the .rb file to a different extension, and see if that fixes your problem. If you do not have it installed, then this is a different problem, and we will have to find a different fix for it.

But I though that was MSVC 2005 vs MSVC 2008 problem, so basically the same that with Twilight? So you never did go to MSVC 2008... or is there some other dll that might conflict, like freeimage? Anyhow perhaps you should continue solving this private.

Chris_at_Twilight · 20 Oct 2009, 15:10

I ran SketchUp through ProcMon to watch what libraries are getting loaded when NXT works and when it doesn't. It appears that when it doesn't work, Windows is unable to locate the arobjects.dll. Why having Twilight running makes any difference for that, I can't imagine. Certainly Twilight is not actively impacting it. It doesn't appear to be a VC++ problem either (thought I'm not certain), as you can see the 2005 (VC8) dlls are loaded in the images.

Sorry, yes, I meant IRender.

Al Hart · 20 Oct 2009, 15:34

@chris_at_twilight said:

I ran SketchUp through ProcMon to watch what libraries are getting loaded when NXT works and when it doesn't. It appears that when it doesn't work, Windows is unable to locate the arobjects.dll. Why having Twilight running makes any difference for that, I can't imagine. Certainly Twilight is not actively impacting it. It doesn't appear to be a VC++ problem either (thought I'm not certain), as you can see the 2005 (VC8) dlls are loaded in the images.

Sorry, yes, I meant IRender.

Thanks Chris,

This could be a big help. It may be something simple, like that the problem is that the Twilight DLL is changing the default folder in Windows, and we just need to change it back before loading our DLL.

Chris_at_Twilight · 20 Oct 2009, 15:44

I think I've got it. Twilight adds it's own directory to the DLL search path. According to Microsoft documentation, simply adding a directory to the search path (not changing, just adding), switches the DLL search mode from "Default". Probably IRender is not setting it's own search paths, but relying on the "default". You can see more about it here: http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx

I've modified Twilight to restore the "default" search mode and IRender works after that. However, if there are any plugins loaded before Twilight who are using a modified dll search path, switching to "default" mode can impact them in the same way. So either way, there is no really "safe" method. One way or the other has a potential to impact other plugins. As notareal said, dll hell.

I guess the best "safe" practice is to set your own dll search path, load your dll, then restore to the default. If everyone did that it would probably avoid all these issues.

Al Hart · 20 Oct 2009, 15:49

@chris_at_twilight said:

Certainly Twilight is not actively impacting it.

With Twilight not loaded, it looks for arobjects.dll in:

c:\Program Files\Google\SketchUp 7, --- then in
c:\Windows\system32
c:\Windows\system
c:\Windows, --- and then in the current folder,
c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt
(where it finds it)

With Twilight loaded, it looks in

c:\Program Files\Google\SketchUp 7, --- then in
c:\Program Files\Google\SketchUp 7\Twilight, --- then
c:\Windows\system32
c:\Windows\system
c:\Windows,

but never in c:\Program Files\Render Plus System

Does Twilight make a ruby call, or a Windows call, to change the DLL search path?
(I am wondering because it looks in the twilight folder before the windows folder)

If so, then we could make a similar call to add "c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt" to the DLL search path.

Thanks,

Chris_at_Twilight · 20 Oct 2009, 15:57

@al hart said:

@chris_at_twilight said:

Certainly Twilight is not actively impacting it.

Does Twilight make a ruby call, or a Windows call, to change the DLL search path?
(I am wondering because it looks in the twilight folder before the windows folder)

If so, then we could make a similar call to add "c:\Program Files\Render Plus Systems\IRender_nXt\bin_nxt" to the DLL search path.
Thanks,

Yes, exactly. If you set your search path immediately before loading the dll, that should resolve the problem. This is probably a good idea no matter what because, according to Microsoft, the DLL search that is finding the arobjects.dll is looking in the "current path". Since many things can influence the current path, it's probably not safe to rely too much on it.

I've added code to Twilight to restore the "default" search path immediately after loading the dll, and that seems to work well, so I suggest doing that also.

Al Hart · 20 Oct 2009, 16:19

@chris_at_twilight said:

I've added code to Twilight to restore the "default" search path immediately after loading the dll, and that seems to work well, so I suggest doing that also.

I presume you are doing this in Ruby.

I suspect you are not restoring the search path, because Twilight still seems to be in it when IRender nXt is trying to load its DLL.

Can you send the two lines of Ruby code? (set path and restore path).
I want to see why the restore path is (apparently) not working.

Al Hart · 20 Oct 2009, 19:05

@chris_at_twilight said:

If you set your search path immediately before loading the dll, that should resolve the problem.

Thanks for your help on this, we are setting ENV["PATH"] before loading the DLL and it seems to work better now.

Chris_at_Twilight · 20 Oct 2009, 21:07

Sorry for the confusion. I meant, with the next release, this will be added. The current publicly available release does not 'reset' the dll search path.

The code I'm using is Windows API. SetDllDirectory (more on it here: http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx )

Al Hart · 21 Oct 2009, 08:17

@chris_at_twilight said:

Sorry for the confusion. I meant, with the next release, this will be added. The current publicly available release does not 'reset' the dll search path.

The code I'm using is Windows API. SetDllDirectory (more on it here: http://msdn.microsoft.com/en-us/library/ms686203%28VS.85%29.aspx )

AHA.

I turns out that we were using SetCurrentDirectory() to define the DLL path, and depending on the LoadLibrary defaults which include the current directory.

When you call SetDllDirectory(), with a path name, the current directory is no longer used, so our logic no longer worked.

If you had called SetDllDirectory() again with a blank name to reset it, then the current directory logic is restored. So that is what was causing the original problem.

We are going to switch to using SetDllDirectory() ourselves, which will eliminate this problem, but we both need to be carefull to reset it so we don't mess up anyone else who is depending on the current directory method of loading DLLs