Some Graphics Issues

[grumpy_coder]

(06-04-2013 12:06 AM)[Unknown] Wrote:  hasNormals means whether or not the vertex coordinates contained a normal (a lighting coordinate.)

For example, the coordinates can also contain colors (hasColor) and positions, as well as some other things like I think weights and stuff.

Before, we assumed that if the coordinates didn't specify lighting at all, this meant lighting should not be applied. However, we found a game that did expect lighting to be applied even when it did not provide a normal (it seemed to use a default one pretty clearly.)

I took a quick look at JPCSP for this question now:
https://code.google.com/p/jpcsp/source/b...hader.vert

It seems to apply lighting even when there is no normal specified, although I may be reading it wrong. That said, it seems to use the default coordinate vec3(1.0, 0.0, 0.0) (I assume that's x, y, z?) They seem to normalize it, which I'll be honest - I'm not sure what that means for a coordinate (I'm not great with 3D, I don't know the terminology and suck at trig.) But, it does not seem like applying lighting without normals is wrong.

We just have to figure out what is right.

-[Unknown]

As long as the PSP has an internal vertex attribute state (which, having different formats input formats, it's likely, as it has to decompress/un-quantize them somewhere before using it), it's safe to assume it has some default normal. I don't really have the time to check it out, neither to skim documentation, just throwing ideas here

If PSPs GPU has internal state, then ,even when not providing that attribute in the vertex arrays, you would get lighting when enabling one of the lights.

About the vec3(1,0,0), in case you're interested, it's (x,y,z), and it's normalized because it has some nice properties, for example, the dot product of two normalized vectors is the cosine between those vectors, thus lighting is trivial to compute.

Good luck fixing that, emulating proprietary fixed GPUs is a PITA :/