I'm not sure what my problem is...

As some of you might now I am writing my own file format so I can read it in and render it using C++ and OpenGL. I have it figured out how to do it. So I started writing Python code (I am completely new to python) to export it.

At first I was having endianness problems but I managed to fix that… I think… I’m almost 100% sure it’s a problem with my python script and not how I am reading it in with my C++ code.

The reason I am so sure is that I actually opened up the file I created with my python script using a hex editor, looked at the values and double checked them with IEEE-754 Analysis and they all match perfectly with what my C++ program is outputting.

I am not exporting the data correctly. I know this because of two things:

  1. I exported the data using the obj format and just compared vertex values with what I was exporting. They don’t match at all.

  2. If I use the values from my file that my C++ program is outputting, I should be able to use blender to place the cursor on that vertex of the model by copy and pasting the values in. Instead it doesn’t. It points to some other place that isn’t a vertex.


I think I figured out my problem. See, the values that I am printing out as a y coordinate the obj file has as a z coordinate. Also when my y value is positive obj z value is negative… besides that they completely match…

There was also something stupid on my part that confused me. When I saw -3.25963e-009 etc I didn’t think “oh that’s basically 0” which is what the obj file wrote.

I’m pretty sure the problem is that my x,y and z values are messed up in blender somehow… is there an easy way to fix this?


std::fixed fixed my 3.23422e-009 type of results also:

I decided to export a default cube using the obj exporter and then with my exporter and compare results… The same thing happened again. Then I realized that opengl xyz axis are different than blenders axis. So I figure it isn’t just the one model I messed up in blender but just that obj exporter took the difference in coordinate systems in consideration and flipped them where I never did.

I don’t know but as of now it seems to work.