gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

DS Misc > v10 normals are wrong!

#175533 - Rexhunter99 - Wed Dec 15, 2010 10:58 pm

I knew that when I converted my floating-point normals to v10 DS format that I'd lose a fair amount of precision, but when I loaded the model up in my viewer app before I put it into my nitro file system and found that the normals weren't lighting the vertices correctly in the lighting system so I flipped on normals and saw that they were all deformed terribly.

[Images not permitted - Click here to view it]

I am also packing these three v10s into a 32-bit variable. But this lack of precision practically kills any use of the lighting system for my purposes.

It isn't something I am doing that is wrong, I took the macros straight from t he libnds headers. This is a serious problem...
I guess I have to resort to manual, software lit vertices :/
_________________
[Images not permitted - Click here to view it] - Move over Mario... Cruise by Crash... Croc Rocks!

#175534 - elhobbs - Thu Dec 16, 2010 12:13 am

I can assure you that the macros in the libnds headers for normals function correctly and produce values that function correctly with the ds hardware lighting as I have used them myself on cquake. The normals that look messed up appear to be contained mostly to the region in your model that is apparently exceeding the ds vertex range limits - based on the error messages in your screenshots. Are you calculating the normals as floating point and converting them to v10 afterwards? Are verifying that the floating point normals are unit length before converting them to v10 format? Can you verify the values before they are converted to ds formats?

#175535 - Rexhunter99 - Thu Dec 16, 2010 6:48 am

elhobbs wrote:
I can assure you that the macros in the libnds headers for normals function correctly and produce values that function correctly with the ds hardware lighting as I have used them myself on cquake.

I know they function correctly, that's why I copied the macros exactly to make sure I was using the same macros as the library does.

elhobbs wrote:
The normals that look messed up appear to be contained mostly to the region in your model that is apparently exceeding the ds vertex range limits - based on the error messages in your screenshots.

No the normals are messed up all over the model, some of the ones on the thighs of Croc are so small that they just fit into a pixel. The co-ordinate system limit has no affect on the values, the limit is simply a 16x16x16 volume, my app checks to see if the floating point version of the v16 co-ordinate is outside the bounds and informs the user if they do so the problem can be fixed. The error messages just say that the x,y,z components of the variable are outside the box, the normals shouldn't be affected because they are unit length and are not affected by the location of the vertice they are assigned to.

elhobbs wrote:
Are you calculating the normals as floating point and converting them to v10 afterwards?

In 3dsMax I am converting my unit length normals (floats) into v10 signed short integers which I store into my exported mesh file.

elhobbs wrote:
Are verifying that the floating point normals are unit length before converting them to v10 format?

No need to verify. Unless I modify the normals manually or scale the node, 3dsMax ensures that the normals are all normalized to unit length. They never exceed -1.0f or 1.0f

elhobbs wrote:
Can you verify the values before they are converted to ds formats?
Already done so in the 3dsMax export. I printed the conversions to the Maxscript Listener to make sure they were correct.
If i convert a normal which consists of (1.0f, 0.0f, 0.0f) to v10 format I get: (511, 0, 0) just like the DS does. To further make sure that I am doing everything properly, I then pack all three v10 components into the 32-bit variable and unpack them before printing to make sure that I am unpacking the values correctly.

This is why I said it shouldn't be anything I've done wrong, I'm checking all my converted data and cross-reffing it with data I converted on the DS.
_________________
[Images not permitted - Click here to view it] - Move over Mario... Cruise by Crash... Croc Rocks!

#175536 - elhobbs - Thu Dec 16, 2010 3:30 pm

Quote:
No the normals are messed up all over the model
can you expand on what you mean by that? are they bad in the display list before it reaches the ds or after? before it is converted to display list?

#175538 - ritz - Thu Dec 16, 2010 3:56 pm

Rexhunter99 wrote:
...but when I loaded the model up in my viewer app before I put it into my nitro file system and found that the normals weren't lighting the vertices correctly in the lighting system so I flipped on normals and saw that they were all deformed terribly.

What does your lit model look like on the actual DS hardware? Perhaps your windows based viewer app is incorrect or is misleading you.
If it does look wrong on the DS, show us some of your drawing code... glLight/glNormal/etc calls so we can rule out some more stuff. From a previous post of yours, I'm assuming you do not use display/call lists.