rd-rend2 (old thread)

[Raz0r]

Yes you must create the assets manually, but they are applied to Ghoul2 models the same way they're applied to anything else. There's nothing specific for Ghoul2 models.

[Tempust85]

So normal maps are working for animated Ghoul2 creature/player models? @@DT85 -- can you provide a quick rundown on what the bugs/issues are?

 

The normal maps aren't looking as they should. They appear fine on MD3 models & BSP, but not Ghoul2 so there may be a problem with the Ghoul2 USE_VERT_TANGENT_SPACE code. I had a look and it's not done the same way as MD3 & IQM. Then there's the issue of UV seams where the surface of the model breaks along the UV seams but MD3 (and probably IQM) also has this issue.

[Archangel35757]

The normal maps aren't looking as they should. They appear fine on MD3 models & BSP, but not Ghoul2 so there may be a problem with the Ghoul2 USE_VERT_TANGENT_SPACE code. I had a look and it's not done the same way as MD3 & IQM. Then there's the issue of UV seams where the surface of the model breaks along the UV seams but MD3 (and probably IQM) also has this issue.

So does anyone have this on their ToDo list? Regarding seams -- @@Psyk0Sith, I thought UV seams were always visible on game characters... and that's why all the UVW training States to try and hide the seams at material transitions on the character-- e.g. belts, pants waistline, etc., no?

 

is there a blend function that could be used in the Shader to diminish these seam issues?

[Psyk0Sith]

@@Archangel35757
When creating game content, you should be mindful of where you hide your seams especially when using normal maps. From a perfromance point of view you could plan how your object's material are going to be broken down into UV chunks and plan as you model, by creating clean seam/material edgeloops. Doing this means you can have "free smoothing groups" because if you have split your materials matching the UV islands, these operations can be done in one drawcall instead of let's say 3 for a poorly planned model. This does not influence how your model looks in an engine that can handle tangent space correctly.

So...
 

The problem could be an issue with how tangent space (see definition below) is handled on non planar objects. If you apply a character's normals on a flat plane you shouldn't see weird artifacts because the flat plane has uniform direction in tangent space, as soon as you switch to a more complex mesh with non uniform directions, there will be shading seams.

 

Form polycount WIKI:

Tangent-space normal maps use a special kind of vertex data called the tangent basis. This is similar to UV coordinates except it provides directionality across the surface, it forms a surface-relative coordinate system for the per-pixel normals stored in the normal map.

Light rays are in world space, but the normals stored in the normal map are in tangent space. When a normal-mapped model is being rendered, the light rays must be converted from world space into tangent space, using the tangent basis to get there. At that point the incoming light rays are compared against the directions of the normals in the normal map, and this determines how much each pixel of the mesh is going to be lit. Alternatively, instead of converting the light rays some shaders will convert the normals in the normal map from tangent space into world space. Then those world-space normals are compared against the light rays, and the model is lit appropriately. The method depends on who wrote the shader, but the end result is the same.

Why artifacts can occur:

When you look at a tangent-space normal map for a character, you typically see different colors along the UV seams. This is because the UV shells are often oriented at different angles on the mesh, a necessary evil when translating the 3D mesh into 2D textures. The body might be mapped with a vertical shell, and the arm mapped with a horizontal one. This requires the normals in the normal map to be twisted for the different orientations of those UV shells. The UVs are twisted, so the normals must be twisted in order to compensate. The tangent basis helps reorient (twist) the lighting as it comes into the surface's local space, so the lighting will then look uniform across the normal mapped mesh.

When an artist tiles a tangent-space normal map across an arbitrary mesh, like a landscape, this tends to shade correctly because the mesh has a uniform direction in tangent space. If the mesh has discontinuous UV coordinates (UV seams), or the normal map has large directional gradients across it, the tangent space won't be uniform anymore so the surface will probably have shading seams.

 

[Archangel35757]

@@DT85-- So is it that there are artifacts created inside of 3dsMax when you do a render-to-texture for the normal map, and you have to clean up those artifacts in Max? Or are you saying you have a clean normal map that is messed up in the game engine?

 

Would you post a screenshot of your normal map?

[Tempust85]

Doesn't matter whether I use crazybump, zbrush or Max to generate normal maps, they are still not appearing properly on ghoul2 models. If used on an MD3 model, they appear as they should.

[Archangel35757]

Doesn't matter whether I use crazybump, zbrush or Max to generate normal maps, they are still not appearing properly on ghoul2 models. If used on an MD3 model, they appear as they should.

But is the normal map for your Ghoul2 character "clean" ?  Or does it contain artifacts from its creation using whatever modeling app?

[Tempust85]

It's clean. Like I said, it looks as it should when applied to an MD3 version of my model just with the UV seams which is present in both formats.

[Xycaleth]

I had a look at the MD3 code for calculating the tangent vectors and it looks like there's a bug. I'll need to check with SmileTheory to see why it's doing what it's doing. That's not to say there aren't problems with the GLM tangent vector calculations though.

[Archangel35757]

I had a look at the MD3 code for calculating the tangent vectors and it looks like there's a bug. I'll need to check with SmileTheory to see why it's doing what it's doing. That's not to say there aren't problems with the GLM tangent vector calculations though.

I had a look at the MD3 code for calculating the tangent vectors and it looks like there's a bug. I'll need to check with SmileTheory to see why it's doing what it's doing. That's not to say there aren't problems with the GLM tangent vector calculations though.

@@Xycaleth -- Yes! Please fix the Ghoul2 tangent space calculations for normal mapping.

 

@@Psyk0Sith, @@DT85 -- In regards to UV seams, couldn't you create a second UV texture map in Map Channel #2, and then select only the polygons bordering the offending seams and create another texture to be used in a Shader blending function? I've seen this done before in a UVW tutorial.

[Tempust85]

Now that I think of it, Xycaleth said a while ago he might be able to fix the GLM output to have no breaks along UV seams with his FBX 2 GLM converter. I wonder if there's a way to fix it via the renderer?

[Psyk0Sith]

@@Psyk0Sith, @@DT85 -- In regards to UV seams, couldn't you create a second UV texture map in Map Channel #2, and then select only the polygons bordering the offending seams and create another texture to be used in a Shader blending function? I've seen this done before in a UVW tutorial.

 

Hmm possibly, but i don't know how tangent basis would react to something like that (rotating and moving chunks around could mean mismatch between UV channel 1 and 2 = more errors)

[Archangel35757]

Hmm possibly, but i don't know how tangent basis would react to something like that (rotating and moving chunks around could mean mismatch between UV channel 1 and 2 = more errors)

Hmm possibly, but i don't know how tangent basis would react to something like that (rotating and moving chunks around could mean mismatch between UV channel 1 and 2 = more errors)

IIRC, Basically it's another texture with an alpha channel that you could blend with your main texture using a shader blending function.

[Psyk0Sith]

Yes i know, it sounds good in theory but normal maps are quite easy to break.

 

[Tempust85]

It would be better to just fix the conversion to GLM or somehow try to fix it in the renderer.

[Archangel35757]

It would be better to just fix the conversion to GLM or somehow try to fix it in the renderer.

What makes you think the tangent space in the Carcass GLM file is bad? Is the GLM file different from Blender or FBX Converter? I agree the renderer would be best solution.

[Xycaleth]

Carcass doesn't handle any of the tangent space calculations.

 

These are all done in the renderer, but are calculated using the normal and UV information, which obviously come from your exporter of choice. So to me, the best solution would be to 'fix' this in the exporter if possible. If it was done in the renderer, then loading times would increase (if only by a little).

[Archangel35757]

Carcass doesn't handle any of the tangent space calculations.

 

These are all done in the renderer, but are calculated using the normal and UV information, which obviously come from your exporter of choice. So to me, the best solution would be to 'fix' this in the exporter if possible. If it was done in the renderer, then loading times would increase (if only by a little).

 

I'm not too sure if the dotXSI format directly supports normal mapping... as far as the dotXSI 3.0 Exporter that I've been re-developing based on the original Softimage Co. open source code... their original FAQ states the exporter code supports the following features:

 

 

• Polygon Meshes
  • Geometry
    • Triangulated
    • Polygons (via MNMesh)
  • Envelopes
    • Native Skin Modifier
    • Physique Modifier
  • UV Co-ordinates
  • Normals
    • Face
    • Vertex
  • Shape Animation
    • Auto-detect
    • Force
    • Morph-Targets Only
• Nulls
  • Dummy Helper objects converted to Nulls
• NURBS Surfaces
  • Geometry
  • Envelope
• Inverse Kinematics / Character Studio Biped
  • Exported as Forward Kinematics with Nulls or Geometric representation of bones.
• Material
  • Types
    • Ambient
    • Diffuse
    • Specular
    • Transparency
    • Emissive ("Self-Illumination")
• 2D Textures
  • UV Mapping
• Animation
  • Baked fCurves (Standard or Compound)
  • Convert to XSI Action Clips (Nameable actions)
• Unsupported
  • Cameras
  • Lights
  • NURBS Curves
  • Constraints

 

 

 

...and in my code changes I have added exporting of procedural animations (i.e., constraints).  Perhaps @@minilogoguy18 or @@Corto would be kind enough to try and export out a simple Softimage model containing normal mapping and export out as dotXSI 3.0 and send me the file (or post it) to look at. 

[Xycaleth]

It doesn't need to support normal mapping. The information needed for normal mapping can be calculated using the per-vertex normals and UV coordinates.

[Archangel35757]

It doesn't need to support normal mapping. The information needed for normal mapping can be calculated using the per-vertex normals and UV coordinates.

The per-vertex normals option ignores smoothing groups... does that matter?

[Xycaleth]

How can you tell it ignores smoothing groups? If it did, then you wouldn't get any hard edges on your GLM models.

[Archangel35757]

How can you tell it ignores smoothing groups? If it did, then you wouldn't get any hard edges on your GLM models.

Because that is what the exporter option says when you select Vertex as the Normals type.

 

 

@@DT85 -- Did you ever try the "Remap UVs" option?

[minilogoguy18]

Not sure if it matters but Softimage doesn't use smoothing groups, hard edges are used instead (way better solution IMO). The most guaranteed way to have hard edges is to just break them but that increases the vertex count.

[Archangel35757]

Not sure if it matters but Softimage doesn't use smoothing groups, hard edges are used instead (way better solution IMO). The most guaranteed way to have hard edges is to just break them but that increases the vertex count.

Smoothing Groups is 3dsMax nomenclature (perhaps other 3D software too)-- the dotXSI exporter dialog says it ignores smoothing groups when exporting vertex normals. I thought Carcass ignored smoothing group info anyway... or made it's own smoothing groups when converting to Ghoul2, no?

[AshuraDX]

@@Xycaleth I'd like to offer my skiff model for testing purposes as it has fitting normal and spec maps I could also offer a version that doesn't utilise any smoothing groups if that'd be desired for testing purposes

if you need to take a look at the mesh's vertex normals : modview can display them - just press ctrl+v

here are the 2 normal maps if you're interested :

https://jkhub.org/images/Q1dbG1M.jpg

https://jkhub.org/images/DTyymIk.jpg

 

edit :

https://jkhub.org/files/file/1910-bantha-ii-cargo-skiff/