Jump to content

FEATURE: OpenGL 3 Renderer


Recommended Posts

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.

DT85 likes this
Link to comment

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

wFoQ1gbl.png

wHnIw4fl.png

 

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

minilogoguy18 likes this
Link to comment

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:

 

 

 

52mb7r.png

 

 

 

MD3:

 

 

 

pc3fd.png

 

 

 

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?

Link to comment

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.

Link to comment

@@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?

Link to comment

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.

Link to comment

@@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?

DT85 likes this
Link to comment

@@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:

52mb7r.png

MD3:

pc3fd.png

Link to comment

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.
DT85 likes this
Link to comment

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.

minilogoguy18 likes this
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...