About the "missing" file, in fact, those functions are "syscalls", wich means you use plateform and OS specifics functionnalites. With the Casio SDK, you need to use assembly to be able to use them (there's a way to do it in plain C, but that's not clean at all), so you need a source file wich will be a .src with the sdk, and here you've got utils.src wich contains the told functions.

Yes, looks like it's utils.src for casio. but generally, any discrepancies between the casio makefiles and windows, use the file list from the windows build, which is more recent.

Models were originally in obj format, but exported to binary for space reasons. The teapot is the famous Utah teapot. which, at one time, was used as a standard render test. Also, the "crinkles" where the handle meets the body and where the spout meet the body are errors in the teapot model. Basically, in these cases the polygons pass through each other. This violates the idea of a manifold and doesnt work when you are sorting polygons - because any order goes wrong.

A lot of systems z-buffer, so such teapots look ok. Of couse, the model could be pre-processed to break up such polyons to restore the manifold. There's free software to do such things nowadays.

thanks Nemhardy for your input!

I noticed in the file "files.cpp", line 82, in the function "load_object()" it opens up the teapot model and then using "getc()", "getShort()" to access the values stored in the binary file.

how did you know how to interpret the binary file? from doing a little research binary files must follow a standard so that the values can be interpreted. e.g. how did you know that the first value represents the model version and that the second value is the number of vertices in the object, etc?

just checked into git a couple of minor files.cpp tidy ups, mostly removal of dead or bogus code.

the models were originally in wavefront obj format. there must have a been a loader for this format into memory. the files here have been created by the `save_object' code. `load_object' *knows* because it's been created by `save_object'.

ah I see.

I really like the code in matrix.cpp, line 697. Hope this is ok, I'll paste it here to show u what I am referring to exactly:

void normalise8(Vector3 *vect)
{
int mod;
long x,y,z;
int nx, ny, nz;

x = vect->x;
y = vect->y;
z = vect->z;
if (nx = (x < 0)) x = -x;
if (ny = (y < 0)) y = -y;
if (nz = (z < 0)) z = -z;

// reduce to 8 bits each
while ((x | y | z) & ~((1<<8)-1))
{
x >>= 1;
y >>= 1;
z >>= 1;
}

if (nx) x = -x;
if (ny) y = -y;
if (nz) z = -z;

mod = isqrt(x*x + y*y + z*z) + 1;
vect->x = (x << 7) / mod;
vect->y = (y << 7) / mod;
vect->z = (z << 7) / mod;
}

Very impressive, good use of bitwise operations and assignment operator in the condition. I would never have thought of doing that.

assignments in conditionals like that do not usually make any improvement. this code is quite old and that sort of trick was ok when compilers were a bit lame (some embedded ones still are).

a modern compiler would generate the same if the conditional and assignment were written longhand, and the code would be easier to understand.

this routine reduces a directional vector to 8 bit, which is enough for lighting calculation. it's done to save space.

Great project CrazySquid1
Do you already have screenshots ?
Hope to see a 1.0 version soon

Hi Jpto

unfortunately I do not have anything screenshots to show. I hate maintaining code so before I dedicate a bunch of my free time to writing the program I have decided to read a book that will show me how to make my programs easy to maintain (and teach me more about c++). This might seem like an overkill to read a 600 page book before beginning but I am sure it will pay off in the long term. For those interested the book is called "Using C++" by Bruce Eekel. brilliant book, I highly recommend it (especially if u r going from C to C++, like myself).

You can expect a release of my 3D grapher in about 2 to 3 month. I think that's a very reasonable time frame. however with uni starting up again, I might not be able to keep my word.

I noticed that each model is made up of vertices, planes and subgroups. could you please explain what you used subgroups for. I can see that a subgroup is made up of a "point" and a number of planes. what does the "point" do?

Also each Point3 object has a variable called "refs". what does that do? I noticed it is used in the function "calcVertexRefs()" (line 426 of model.cpp). maybe if you explain what that function does it, it will answer my question.

By the way if you start to get tired of answering my questions hughs, just say so. From the group projects I have done in the past I learnt to asking lots of questions until it makes sense.

For those reading this thread there is a good tutorial on win32 API programing here:

http://www.winprog.org/tutorial/message_loop.html

it explains how the message loop works in hugh's program.

After about 2 months working on this project I am finally proud to show my first screenshot of my progress.

http://gyazo.com/897617472db27cfec45199609859fc56

my program can take in an equation and generate a graph. currently it only can graph 1 function at a time.

some of the things I still need to do include:
-add a menu/settings
-use shaders instead of wire frame
-add some overlay GUI for the graph e.g. buttons for tracing and calculating x,y,z intercepts plus more.
-handle complex numbers and multiple graphs

as u can probably imagine all of this is going to take time. thx again hugh for your help.

here is my GitHub repository:

https://github.com/BlueSquid1/3DGrapher