Blender and True-Normals  1-20  21-23

Next
 From:  anthony
3583.1 
Lately, I have been reading through Blender's source code. I have modified (i.e., hacked) Blender's internal renderer (both 2.49b and 2.5x) to make use of MOI's true nornals! This may not sound like a big deal to you, but it is for me because I learned to code in C, and I can finally render the true normals that my python script imports.

Here's my old post of the script:
http://moi3d.com/forum/index.php?webtag=MOI&msg=979.1

Binaries, test renders, and more info:
http://home.comcast.net/~chronosphere/true-normals.htm

Warning: This has been tested with Moi 1.1 only. I do not plan on upgrading to 2.0, so if you have problems with that version, I can't be of much help.
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
3583.2 In reply to 3583.1 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Phil (PHILBO)
3583.3 In reply to 3583.2 
As a Blender head...awesome indeed. Thanks.
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Mip (VINC)
3583.4 
Hi Anthony,

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

Michel
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  anthony
3583.5 In reply to 3583.4 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Marc (TELLIER)
3583.6 In reply to 3583.5 
Looks good, thanks!

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

Marc
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  anthony
3583.7 In reply to 3583.6 
Yes, but my modification takes care of that. You can switch to edit mode, and the true normals will not be lost.
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Marc (TELLIER)
3583.8 In reply to 3583.7 
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

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
3583.9 In reply to 3583.8 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Mark Brown (MABROWN)
3583.10 In reply to 3583.9 
Fantastic job Anthony & many thanks for your work.

---
Mark
http://www.homepages.ihug.com.au/~mabrown/index.html

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Marc (TELLIER)
3583.11 In reply to 3583.9 
-> 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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  anthony
3583.12 In reply to 3583.11 
I built it on XP with Visual C++ 2008 Express Edition. Has anyone else had any problems with my exe?
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
3583.13 In reply to 3583.12 
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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  anthony
3583.14 In reply to 3583.13 
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.
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
3583.15 In reply to 3583.14 
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

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  anthony
3583.16 In reply to 3583.15 
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.
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
3583.17 In reply to 3583.16 
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

  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  anthony
3583.18 In reply to 3583.17 
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?
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Michael Gibson
3583.19 In reply to 3583.18 
> 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
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged

Previous
Next
 From:  Marc (TELLIER)
3583.20 In reply to 3583.19 
Works here also, thanks!

Will check this out...

Marc
  Reply Reply More Options
Post Options
Reply as PM Reply as PM
Print Print
Mark as unread Mark as unread
Relationship Relationship
IP Logged
 

Reply to All Reply to All

 

 
Show messages:  1-20  21-23