I built it on XP with Visual C++ 2008 Express Edition. Has anyone else had any problems with my exe?

Hi Anthony, I actually get the same thing over here on Win XP 32-bit.

So it doesn't seem to be a 64-bit specific problem.

I tried running it under a debugger here, and if I ignore the exception that is thrown then I can actually run it.

But it looks like some kind of problem in DLL initialization.

The original blender.exe for 2.49b seems to have a dependency on VCOMP90.DLL (in the blender folder) which does not seem to be listed in your .exe, maybe that is the problem, one missing input in the linker settings?

Also maybe something is sensitive to the order of initialization of the DLLs, the ordering of their loading is different between the original blender.exe and yours - maybe if you use the same order it will avoid some initialization problem.

To see the ordering, use the "Dependency walker" utility (depends.exe), if it is not included with the VC Express edition, you can get it here:
http://www.dependencywalker.com/

- Michael

Thanks for the suggestions.

I compiled with scons, not with the IDE so I didn't see any way to select linker settings or anything about load order. In any case, on my PC, dependency walker shows the same order as the original, but without VCOMP90.DLL.

I also built a complete installer with nsis, and upon installing it on another system, it asks to download the Microsoft Visual C++ 2008 Redistributable Package. (http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&DisplayLang=en). That could also solve the problem.

Sorry guys. This is the first time I'm building blender. Just bear with me, I'll get it right. I guess the official distribution is built in a different way, I'll have to ask some blender devs for more details.

Hi anthony, I actually already tried the CRT redistributable installer, since I thought that could be the problem but it does not seem to make any difference over here.

I'm not familiar with scons, but somewhere it has to tell the linker which libs to link with, wherever that is possibly the order the libs are listed, and also the one for VCOMP90.DLL missing from that list may be significant.

For DLL initialization order, over here I get this order with your build, which seems to be in alphabetical order after kernel32 which has to come first.



The stock one seems to have this ordering:




- Michael

I had some more free time to compile new versions.

This exe has the same DLL load order as the original:
http://home.comcast.net/~chronosphere/moi/true-normals-blender.zip

If that doesn't work, here's a complete installer:
http://home.comcast.net/~chronosphere/moi/blender-2.49b-windows.exe

I tested both on 3 PCs with XP/Seven and they run perfectly.

Hi anthony, your new .exe works great over here now!

I tested just unzipping your new .exe and putting it in place of the original in the standard 2.49b installation.

I noticed that your original one was much smaller than this new one, (4MB vs 10MB), and your new one is about the same size as the stock blender.exe, so I guess there must have been a chunk missing and not getting linked in before.

It's a huge improvement to rendering in Blender, here is one quick test, original Blender render here:



And your patched version here:




All shading glitches are gone, that is fantastic!

I really don't understand why someone would want to have the normals recalculated just for the render anyway, it's really frustrating when the renderer modifies your model data rather than just rendering the data that is in the editor already.

If you want to have normals set up differently, that is something that I would expect to process in the modeling environment by some kind of normals modification tools, and then render the updated model data rather than having the renderer make modifications itself.

Any chance of getting your patch accepted into the main Blender build?

- Michael

I'm so glad to hear that it works. I didn't change anything in the compile process. The only difference this time is that the exe wasn't packed by upx.

I agree with you 100%. Blender shouldn't have to recalculate the normals before rendering. But it does, and I guess the devs have their reasons, or maybe it's just old leftover code.

I'll do more testing (and hope other MoI users will too) to find out if my code is bug free. Then I can submit a patch when 2.5 becomes stable. But since it changes they way Blender works, I doubt it will be accepted.

Have you tried my 2.5 build?

> But it does, and I guess the devs have their reasons, or
> maybe it's just old leftover code.

Check out this other post about it:

http://geheim.blender.org/forum/viewtopic.php?t=13141&view=next&sid=41ba63d8dcc1ad464905c435d109c552

There could be some situations like with displacement maps or something like render-time subdivision where you would expect for the renderer to make vertex normals because it is making geometry in those situations.

But when it is not making new geometry, that's when it should use the vertex normals that were included along with the existing geometry that is being rendered.

Probably what happened was to support something kinds of stuff like displacement maps, they added some code to generate all vertex normals but without skipping over things that did not need (and actually are degraded from) having new normals calculated.


> Have you tried my 2.5 build?

Just tried it now - it looks like it is working fine.


- Michael

Works here also, thanks!

Will check this out...

Marc

I suppose it's not a good idea to change blender's default rendering/editing behavior. So, in an effort to increase the chances of having my patch accepted by the blender devs, I made the change an option in user preferences, and it's off by default.

I did this both 2.49b:

and 2.5x:


I'm trying hard to follow good programming guidelines, and no one wants this in the official version more than me. I'm done with this project for now, but if there's anything else I can do to make this better, let me know.

Some links may have changed, please download from my page.

Hi Anthony

This looks like a really good (and necessary) improvement!

I'm just starting out using Blender (pretty bad interface for me to learn lol).

So I've just downloaded the 2.5 version of Blender from your website - is there anything else I need? (import script or something?)

Or can I just export the model from Moi, and (as long as i've enabled the preserve normals setting in blender) it will work?

Cheers!

Hi NightCabbage, you do also need an additional import script to go along with Anthony's build to get the best results.

There's some info and a link to Anthony's Blender import script here:
http://moi3d.com/wiki/Resources#Blender_importer


> Or can I just export the model from Moi, and (as long as
> i've enabled the preserve normals setting in blender) it
> will work?

As far as I understand, Anthony's new "preserve normals" setting will make Blender stop throwing away the normals in circumstances where it used to like going into edit mode, or also when rendering.

But that setting doesn't have anything to do with the file import itself, you still need to use an importer that will be able to bring the normals into Blender in the first place (which the default set of importers do not handle).

In addition to Anthony's import script there is also an OBJ import script which I modified to not throw away the normals at the last step of the import like the regular one happens to do. That's available here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=3164.11
I'm not quite sure if that OBJ one works with Blender 2.5 or only with Blender 2.49

- Michael