code FEATURE: OpenGL 3 Renderer

[minilogoguy18]

Ah ok, I just thought that there was like some sort of standard.

[Xycaleth]

You can flip the normal channels in the shaders.

 

I'll try it with GLM, see how I go.

 

I don't think @@SmileTheory added support for AO or transparency.

What do you mean transparency? That's just controlled by the alpha channel like it always has been. Or do you mean something different?

[Psyk0Sith]

Could be an issue for other models, but Ashura's clone normal maps require the model to be completely smooth.

 

That's usually because the model was baked with 1 smoothing group. You cannot break that 1:1 relationship after the normals are baked or it will bork the way normals are displayed.

[AshuraDX]

That's usually because the model was baked with 1 smoothing group. You cannot break that 1:1 relationship after the normals are baked or it will bork the way normals are displayed.

Yes. The Mesh Was baked with 1 smoothing group. And that's how it was exported for the game.

The mesh is also triangulated the same way as it was when it was baked and it appears to have the same vertex normals, judging by a comparison between modviews normal display and 3ds max.

 

And the normal map issues are not visible on the Screenshots of the static md3 version @@DT85 created from my GLM, so it really shouldn't be a mesh problem.

 

EDIT: Reimported the GLM into 3ds max, exported as .obj and loaded that in Marmoset.

here's a comparison with the previous mesh I used for previewing, the imported GLM is the larger model on the left - added untextured versions of both meshes for further comparison

 

as you can see, there are no differences in the shading of both models.

[SomaZ]

@@AshuraDX Thats so crazy, I will Look at it, when I have some time. Must be something with the renderer then.

[Tempust85]

While the result is almost the same as the MD3, it looks like GLM normals are still screwy. I'm using $whiteimage as the diffuse to show the normal differences better.

 

GLM:

 

 

 

 

 

 

MD3:

 

 

 

 

 

 

As you can see on the left of each image, both model normals are matching.

 

 

@@Xycaleth

 

I'm guessing they're screwy because mdxm doesn't have actual tangent or bitangents in the format like MD3 appears to? Or am I reading it wrong?

[Archangel35757]

...but those tangents are all computed by the renderer-- so how does the renderer's computations differ between MD3 and MDX (aka GLM)?

[Xycaleth]

I'm not sure why the normals would be different. The bitangent and tangent are calculated at load time (when the models are loaded). Neither have them stored in the file itself.

 

Here's the bitangent/tangent code for MD3s:

https://github.com/DT85/OpenDF2/blob/rend2-sp/code/rd-gl2/tr_model.cpp#L714

 

GLM here:

https://github.com/DT85/OpenDF2/blob/rend2-sp/code/rd-gl2/tr_ghoul2.cpp#L3607

 

They look pretty much the same to me at a quick glance. The code is split up a bit more than the GLM version.

 

Maybe there's something I'm missing.

 

EDIT: It's more likely the tangent/bitangent calculations are a bit wacky.

[Archangel35757]

@@Xycaleth - perhaps it is a coordinate system thing between MD3 and GLM? The MD3 specs state:

The encoded normal vector uses a spherical coordinate system. Since the normal vector is, by definition, a length of one, only the angles need to be recorded. Each angle is constrained within [0, 255], so as to fit in one octet. A normal vector encodes into 16 bits.

Also, aren't MD3 vertices/normals defined in a left-handed 3-space coordinate system and GLM is right-handed?

[Tempust85]

The only difference I can see is that MD3 has tangent, normal and bitangent in a struct. GLM has normals in a struct, but not tangent or bitangent.

 

Also my VS likes to point to MDR code when finding the definition of normal, even though it is coded to point to the GLM one.

[Archangel35757]

@@DT85 ...you may need to specify the class and "::" scope operator to make it find the correct one for GLM.

[Xycaleth]

@@Xycaleth - perhaps it is a coordinate system thing between MD3 and GLM? The MD3 specs state:

 

Also, aren't MD3 vertices/normals defined in a left-handed 3-space coordinate system and GLM is right-handed?

 

The result of converting the spherical coordinates to a 3-vector will be in the Q3 coordinate space, and will be the same space as the normals stored in the GLM files. That shouldn't be the issue.

 

 

The only difference I can see is that MD3 has tangent, normal and bitangent in a struct. GLM has normals in a struct, but not tangent or bitangent.

 

Also my VS likes to point to MDR code when finding the definition of normal, even though it is coded to point to the GLM one.

 

The bitangent and tangent vectors aren't stored in memory for GLM models because the CPU never needs to do calculations on them. They're stored entirely on the GPU. I think the same thing can happen for the MD3 models too but it just hasn't been done.

 

Do the normals look correct if you turn off normal mapping? That would rule out the normals being the problem since the bitangents and tangents are only used when normal mapping is enabled. If the problem is still there, it could be an issue with the exporter?

[Archangel35757]

@@Xycaleth - @@DT85 already posted comparisons of the MD3 and GLM normals-- and they are equivalent. It's in the renderer.

 

While the result is almost the same as the MD3, it looks like GLM normals are still screwy. I'm using $whiteimage as the diffuse to show the normal differences better. As you can see on the left of each image, both model normals are matching...

GLM:

MD3:

[Tempust85]

I made sure to check. Left side of each image are the model normals without normal mapping.

[Tempust85]

Unless there's someone else, we really need you to fix this please @@Xycaleth. I know you can't debug, but I'm more than willing to test any potential fixes you make.

[Archangel35757]

@@DT85 - Something about the GLM's normal map on the right side seems like it needs inverting...

[SomaZ]

My guess is, that the bitangent is scaled wrongly for the glm. As I already said, I will look at it, when I have some time. Thank you all, for tracking down the issue.

[Xycaleth]

Try outputting the normals as the colour from the fragment shader. It'll be something like

color.rgb = normal * 0.5 + vec3(0.5);

That will give you a better look at the normals on a per pixel basis.

[SomaZ]

Try outputting the normals as the colour from the fragment shader. It'll be something like

 

color.rgb = normal * 0.5 + vec3(0.5);

That will give you a better look at the normals on a per pixel basis.

Yea, already did that two days ago. I also played around with the bitangent scaling. Or better, changed it a bit. The md3 normals looked the same after changing the bitangent Code, so I think the problem lies there. I just had no time to investigate further. I have some time tomorrow, so maybe I'll figure it out whats wrong with it.

[Tempust85]

Really should make showing normals a cvar for debugging such as this.

[Ramikad]

Really should make showing normals a cvar for debugging such as this.

 

Doesn't r_shownormals 1 work? Or you meant something else?

Every time I check this thread I feel like I'm visiting the Kennedy Space Center: you like everything you see, but you have no clue on what's going on or what people are talking about.

[Tempust85]

r_shownormals isn't implemented fully in GL2.

[Archangel35757]

@@SomaZ - I thought the problem was with GLM normal maps, not MD3, yeah?

[SomaZ]

@@SomaZ - I thought the problem was with GLM normal maps, not MD3, yeah?

Yea, instead of fixing the problem, I kind of recreated it. Which is kind of a good clue...

[Archangel35757]

@@SomaZ - curious to see how it looks when you output normals as rgb color... could you post a pic of those results?