Anim8or Community

General Category => Ongoing Anim8or Development => Topic started by: Steve on January 26, 2016, 08:16:33 pm

Title: Normal Maps
Post by: Steve on January 26, 2016, 08:16:33 pm

Build 1213 (http://www.anim8or.com/download/preview/files/animcl1213.zip) of Anim8or now supports Normal Maps.

Attached is a sample project.

Title: Re: Normal Maps
Post by: neirao on January 27, 2016, 01:20:24 am

thanks for this new version Steve! :)

Title: Re: Normal Maps
Post by: cooldude234 on January 27, 2016, 03:29:27 am

NICE

Title: Re: Normal Maps
Post by: captaindrewi on January 27, 2016, 06:49:02 am

Had a try or two with normal map but anim8or crashes.
update...that was with a subdivided sphere with spherical uv mapping.
it worked ok with a basic mesh,i then subdivided the sphere afterwards and anim8or didn't crash.
update 2 seems ok now...but it did crash the first two times...will play some more.
update 3 perplexing :o just crashed again using a simple rectangular object.
anyone else getting this?

Title: Re: Normal Maps
Post by: Raxx on January 27, 2016, 07:16:59 am

Hey Steve, glad it's finally in there! Normal maps load fine for me. I do have a suggestion, and that is to allow more options to specify for the normal maps. It'd be nice if there could be a button next to the normal map load button, that points to a dialog like this:

(http://wub-wub.com/junk/normal_map_options.png)

The current issue is that Anim8or only supports Object Space normal maps. Tangent Space is best suited for models with repeated or changed UVs (such as most game models). If the object was, say, mirrored, the normals would look flipped in Object Space, such as in the video below (rendered in Anim8or). In fact, I'd say that Tangent Space should be the default mode in Anim8or (more reading here (http://wiki.polycount.com/wiki/Normal_Map_Technical_Details#Tangent-space_normal_map)).

If Tangent Space was supported, it'd look correct (like in the image below)

(http://wub-wub.com/junk/tangent_space.png)

Also, since not all models and normal maps will be created from the same source, their handedness might be different than Anim8or's default. Red might be flipped (X-) or actually represent Y+, not X+. I'm guessing Anim8or is X+, Y+, Z+. Some programs like 3ds Max is X+, Y-, Z+ or a different variation. Hence why the Swizzle option in the dialog box would be spectacular, since the user can adjust it based on their incoming files.

Couldn't get attachments to work, so click here (http://wub-wub.com/junk/Sample.zip) to download the .an8 file used in the examples above.

Title: Re: Normal Maps
Post by: neirao on January 27, 2016, 12:17:42 pm

Steve,
Normal Maps, work very well
but, only for test i create a new texture, a Bump Map texture
based in your normal map "EC_Stone_Wall_Normal.jpg"(see attachments)
but when i try render(raytrace mode and "antialias" ) the blocks with (normal map+another block with bump map)

"sometimes" the render stop, and not ends... is a bug?
(demo in attachments)

thanks

Title: Re: Normal Maps
Post by: Raxx on January 27, 2016, 01:09:19 pm

Something that seems to be a bug: Ambient intensity changes to the scene's global lighting setup doesn't affect normal map objects.

Also, Anim8or seems to crash *a lot* when in the scene editor at seemingly random times.

Title: Re: Normal Maps
Post by: neirao on January 27, 2016, 01:21:25 pm

yes, PS: i try the render only in "object mode" not in scenes.

Title: Re: Normal Maps
Post by: Steve on January 27, 2016, 01:22:21 pm

Raxx: I thought Anim8or is using tangent space maps.  They are transformed by the normal/bi-normal/tangent matrix before they are used.  Object space normal maps are used as-is.  I'll check my math and see if I'm doing something else wrong.

neirao and Raxx: I'll look into the crashes.  If you have an example that reproduces a crash fairly reliably please post it.

Title: Re: Normal Maps
Post by: Steve on January 27, 2016, 01:59:34 pm

Here's another Anim8or project that uses a Z-brush normal map that I got here: Tanget space tutorial (http://www.surlybird.com/tutorials/TangentSpace/)  Anim8or shows the proper bumping "in" and "out" that the map indicates.  What am I missing?

Play the scene to see things rotate.

Title: Re: Normal Maps
Post by: Raxx on January 27, 2016, 02:34:50 pm

Hey Steve, it could be correct afterall, except for the case shown in the sample I uploaded earlier. I assumed it was object-space because of that and some tests I made using other models found online gave weird results when they had textures with repeated UVs. I guess it's just the repeated UVs that's wrong?

Whatever it is, would still be useful to have those extra options.

Title: Re: Normal Maps
Post by: Steve on January 27, 2016, 02:47:34 pm

Yes, I agree that options to support multiple types of normal maps is good.

Note: I've found a major issue when the normal map texture weight is less that 100% in the scanline renderer, and a very minor one in the GLSL code (but it's small so that you'd probably not notice it).

Title: Re: Normal Maps
Post by: Raxx on January 27, 2016, 03:58:02 pm

I found a good example to compare what's shown in Anim8or vs what it should look like. The reference is located here: https://sketchfab.com/models/fd449cfec6a04659a840f5ffe3da9e63

Sketchfab:


Marmoset Toolbag:


Anim8or:


There are apparently a few visual disparities. One is that in some areas (like in the shoulder), it's washed out. It's certainly not as crisp in any areas as in the top two images. The other thing is that it seems that face normals are blending/influencing the normal map. There are polygonal creases and shading. Aren't they supposed to be completely overridden by the normal maps?

Dog an8 file and textures (http://wub-wub.com/junk/Dogling.zip)

Title: Re: Normal Maps
Post by: Steve on January 27, 2016, 07:31:09 pm

The normal map is rotated by a 3x3 matrix consisting of the normal, bi-normal and tangent vectors to align it to the orientation of the face. Theoretically these three vectors form an ortho-normal matrix.

Anim8or computes a binormal for each vertex based on it's normal and du/dv directions of the texture coordinates.  Then the normals and binormals are interpreted across the triangle.  Each pixel then computes the tangent = normal X bi-normal. These should be interpreted smoothly across the surface.

If these three vectors aren't more or less orthogonal, or if they aren't smoothly interpreted across the edges between adjacent faces, then the whole thing falls apart.  My guess is that Anim8or isn't computing a good set of binormals.

So I'm looking into it.  I downloaded the model in the link to work with.

On another note: does anyone have a good example of something that crashes or loops?

Title: Re: Normal Maps
Post by: captaindrewi on January 27, 2016, 09:06:46 pm

i can recreate a crash pretty consistently load a sphere ....load a diffuse and a normal map ....every thing ok here if i render.....pause there a moment........Now go back and reload the same maps again.....anim8or goes white screen and crashes for me at this stage even before i hit the render button, sometimes after i hit render[scanline]
slightly different results depending on what maps i use.
but it happens with just a basic sphere mesh,the EC normal map you supplied and any diffuse texture.

Title: Re: Normal Maps
Post by: Steve on January 27, 2016, 10:37:16 pm

Raxx: there are two problems that I've found in the bulldog model's normals:

1. The model imports into Anim8or with some creases because the solid angle between some adjacent faces is greater that 45 degrees. Changing the Smooth Angle in the mesh properties dialog to a higher number fixes this.

2. Anim8or computes binormals with rather different directions on adjacent faces. Then it smooths them across between adjacent faces for a consistent transform space.  The results can interpolate poorly.  I'm looking into a fix for this.

Title: Re: Normal Maps
Post by: Raxx on January 28, 2016, 02:15:37 am

Hey Steve, in the render of it I posted earlier, I had already set it to 180. I've tested it in Blender and Unity3D and it works great in both of them. Oddly, in 3ds Max the UV seams stood out badly and I couldn't figure out how to fix it. I attribute it to my lack of expertise in that software :P

Hopefully fixing #2 will do the trick!

Title: Re: Normal Maps
Post by: $imon on January 28, 2016, 03:52:09 am

Wow, nice new feature, Steve! It's a great step for Anim8or. My viewport was messing up because of the GLSL shader issues with my (Nvidia) graphics card, but it's looking promising!

Raxx, I tried out your model in 3d Studio Max and I think you have answered your own question already earlier. Try checking 'flip green' in the normal map.

Title: Re: Normal Maps
Post by: Raxx on January 28, 2016, 05:01:01 am

$imon, already tried it and just about every option, no dice. I know 3ds Max is -Y on green, but changing it didn't affect the seams. It's probably something else I missed. I'm not too concerned since I don't have any intention of learning the program right now.

Title: Re: Normal Maps
Post by: Hypure on January 28, 2016, 06:56:48 pm

New toys, thanks Steve.

Title: Re: Normal Maps
Post by: Steve on January 28, 2016, 09:16:15 pm

Raxx: I'm making progress.  There was a bug in the way that I computed binormals but when I averaged and normalized them for rendering it worked mostly OK. Here's some images of the normals, and the binormals before and after.

But there's still a problem: The texture map coordinates aren't continuous - there are huge differences in the ST values for the same point in adjacent triangles. You can see the transition from reddish to greenish in the new binormals. This causes the remaining hard edges. I think I can fix it by comparing adjacent faces' binormals and if they are going in opposite directions flip one of them, sort of like I do for normals in the "Fix Normals" command.

Title: Re: Normal Maps
Post by: Raxx on January 29, 2016, 02:14:39 am

No wonder it was a mess! From the little I researched about it, it seems one way people resolve this is by splitting/detaching the vertices where the UV seams are located. This way both sides will have their own correct set of values to read from.

Title: Re: Normal Maps
Post by: Steve on January 29, 2016, 08:49:41 pm

Further investigation shows that the normal map texture, after mapping to the model, has discontinuities where these seams appear.  See the first two images below.  I've also posted an image with the specular weight exaggerated to highlight Anim8or'x curent results.

I'm at a loss to know how it eliminates the edges.

Title: Re: Normal Maps
Post by: Raxx on January 30, 2016, 05:36:28 am

Looks like you've nearly fixed it! Are you making sure to load it in linear space and not srgb/gamma space?

The texture itself does have discontinuities, as you've said. You can see the seams in the other programs if you look close enough. I can't say if it's the same level as what you've currently got though, just looking at the image. Having matcap turned on in Sketchfab shows not as much seam issue as in your bottom picture. Perhaps it's related to the texture filtering or UV handling? Are mipmaps getting in the way?

Title: Re: Normal Maps
Post by: Raxx on February 01, 2016, 08:34:49 pm

It is a bit weird. I created a plane, split it into various divisions and unwrapped it so that there would be UV seams all over it, then baked random details onto it. It's a fairly perfect texture with no visible seams on the texture itself. However, with the normal map applied, the seams are there blended and so it iterates flipping the normals around. In the attachments, you can see what I'm talking about. Is there no way to internally split the vertices at the seams so that the binormals are calculated correctly per-vertex rather than blended?

Also, a bug I keep forgetting to report: When adding a normal map to an existing material, the entire material gets shades darker until it's saved and reloaded. Also, if you click in Anim8or while it's loading a texture or the file itself in the beginning, it crashes (win 10). Would be nice if this was prevented.

Title: Re: Normal Maps
Post by: Steve on February 01, 2016, 11:41:41 pm

I see the issue.  It looks like I need to add diacontiguous binormals where UV's are discontinuous.  I'll look into it. That might also help with the original creases in your previous example with that shiny, nasty-looking dog :).

Here's the texCoord0 view. As you can see, it's discontinuous on the boundaries.  The binormals should be the same.

Title: Re: Normal Maps
Post by: cooldude234 on February 02, 2016, 03:32:53 am

Quote from: Steve on February 01, 2016, 11:41:41 pm

That might also help with the original creases in your previous example with that shiny, nasty-looking dog :).

Don't judge it! It's been through a lot. It got stuck in an oil spill and we had to wash it with brand name soap!
:P


(jk I think its good that dawn helps when those horrible things happen)

Title: Re: Normal Maps
Post by: Smirkyguy on February 10, 2016, 10:53:04 pm

Is the workspace going to render normals or will this just be a final renders thing

Title: Re: Normal Maps
Post by: cooldude234 on February 10, 2016, 11:03:26 pm

I don't see why it wouldn't or shouldn't, I mean if you are already running opengl 2.0 (with glsl) then why not... right?

Title: Re: Normal Maps
Post by: Steve on February 11, 2016, 09:33:34 am

All normal map functionality will be in final renders, including the crease change (if it works as I think it will :) )

Title: Re: Normal Maps
Post by: cooldude234 on February 11, 2016, 07:06:32 pm

Quote from: Steve on February 11, 2016, 09:33:34 am

All normal map functionality will be in final renders, including the crease change (if it works as I think it will :) )

the question was if it was going to be in the work-space rendering (opengl), but I think what you said means that the pictures  you are showing are rendering through opengl then?

Title: Re: Normal Maps
Post by: Smirkyguy on February 11, 2016, 09:30:07 pm

Quote from: cooldude234 on February 11, 2016, 07:06:32 pm

Quote from: Steve on February 11, 2016, 09:33:34 am

All normal map functionality will be in final renders, including the crease change (if it works as I think it will :) )

the question was if it was going to be in the work-space rendering (opengl), but I think what you said means that the pictures  you are showing are rendering through opengl then?

Yeah that's what I meant