That's great Anthony!

Hopefully that can get incorporated into the main Blender version at some point, it sure is frustrating that it decides to throw out the normals from the model and calculate different ones just for the render.

That should all work fine with MoI v2 as well - in v2 there is an option (under Options > Import/Export > LWO options) to change how normals are written to LWO files to support LightWave since it expects them to be in a different coordinate system than Modo does. But the default is the Modo style normals the same as MoI v1 exported.


Also something else that Blender people might be interested in is the updated OBJ import script that I posted here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=3164.11

That fixes the default Blender OBJ importer which was discarding the vertex normals at the very end after doing all the work of actually reading them in.

The OBJ importer also tries to import materials.


- Michael

As a Blender head...awesome indeed. Thanks.

Hi Anthony,

If you apply uv mapping to an object you imported from MoI, will its True-normals be lost ?

Michel

As far as I know, the only way to lose the true normals with my build is to:
1. apply a modifier
2. move/add/delete a vertex
3. Recalc the normals

Looks good, thanks!

Doesn't Blender recalculate the normals when switching to 'edit' mode?
You have to go in edit mode to unwrap.

Marc

Yes, but my modification takes care of that. You can switch to edit mode, and the true normals will not be lost.

Wow! this would be awesome!

Blender has a very good Uv unwrap system.


I can't get it to work on my system though, I get this message:



I'm running 7 64bits, the original 32 bit 2.49b is working.

Marc

Hi Marc, I think Anthony's blender.exe build is a 32-bit build, and you can't "mix-and-match" 32-bit and 64-bit .exe and .dll parts together.

So you will need to use Anthony's new .exe only with the 32-bit Blender version.

- Michael

Fantastic job Anthony & many thanks for your work.

-> Hi Marc, I think Anthony's blender.exe build is a 32-bit build, and you can't "mix-and-match" 32-bit and 64-bit .exe and .dll parts together.

Hi Michael, It's with the 32bit version of blender that I tried.
The original 2.49b 32bit version works on the 64bit os.

Maybe it will work with the 2.5 version, I will try later.

Marc

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.