.OBJ files are saved using a left hand coord system I believe. Im not sure what blitz uses... but I do believe that terabit's obj loaded loads then backwards and inside out etc due to the flip mesh command. I need to have access to the actual normals that are saved with the object though. Calculating them based on whatever method besides using the normal data is not sufficient.
I am curious as to what the ordeal is anyways. I can change that stupid indexing offset about -2 and it still works and messed up just the same without any vertex index out of range errors or anything. So I think I might seriously have something screwed up in those counters. Also this looks like it creates multiple surfaces and joins them etc... if that is the case am I simply losing the vertex normal info when everything is slammed into one object? Ie. Does blitz re-order the vertices when you muck with the surfaces?
There were two more testing methods I was going to try but I didnt want it to have to go that far in order to figure this out. The first was to apply the vertex normal data at the time the vertex is created, and before it is used in the addtriangle command. The second method involved loading the mesh as is, then creating a type for each of the vertices x,y,z locations, then to do a distance check across all of the verticies on the surface and if they were close then apply the vertex normal data saved in the OBJ_VN type to the vertex at that location... I figured the first would eliminate the surface issue, and the second would eliminate whether or not the vertices are being re-indexed.
Any suggestions?
I am curious as to what the ordeal is anyways. I can change that stupid indexing offset about -2 and it still works and messed up just the same without any vertex index out of range errors or anything. So I think I might seriously have something screwed up in those counters. Also this looks like it creates multiple surfaces and joins them etc... if that is the case am I simply losing the vertex normal info when everything is slammed into one object? Ie. Does blitz re-order the vertices when you muck with the surfaces?
There were two more testing methods I was going to try but I didnt want it to have to go that far in order to figure this out. The first was to apply the vertex normal data at the time the vertex is created, and before it is used in the addtriangle command. The second method involved loading the mesh as is, then creating a type for each of the vertices x,y,z locations, then to do a distance check across all of the verticies on the surface and if they were close then apply the vertex normal data saved in the OBJ_VN type to the vertex at that location... I figured the first would eliminate the surface issue, and the second would eliminate whether or not the vertices are being re-indexed.
Any suggestions?