3D Graphics Programming

[PhantasyStar]

Does anyone know what program I should use to develop 3D graphics? I don't need them to be too fancy, as I'll be running them off a GDEV. But, would you recommend Maya or something similar? Then, when I have my models built, does anyone have any guides to implementing that into my code? Thanks

[babu]

I would say maya if you got the $$$, otherwise there's allways things like blender, wings 3d and other cheaper/free tools

[webjeff]

phantasystar,

Are you a programmer? Getting 3d models on the screen is not a difficult task, if you've done work like that before?

You basically need to supply the graphics chip with your Verts & TexCoords (for simplistic models) and then setup the rendering states and draw.

But from your question, I'm not sure what you need to know. I use 3d Studio Max to build the models but then convert them into my own format and then import those into the game.

Jeff.

[PhantasyStar]

Okay, thanks guys. Yes, I'm a programmer(not a pro yet, I'm a sophomore in Computer Science at Purdue). I haven't done anything with 3D graphics... Basically I've done everything so far from basic programming to data structures, etc. babu, I can get Maya for pretty cheap here, or 3DS Max, so I might look into that. But when I make a model, I can just import it into a .h file and implement it as an object? I'm sure there is more to it...I'm just tired of making crappy text based games, and finally decided to work on a homebrew game for NGC.

[babu]

well this is (very simplified) how it's usually done:
- Artist makes a model
- Exports it to a game engine specific format (or export to something like COLLADA and then using the game engines toolset convert it to the game engines format)
- Game engine reads file and render.

Usually a mesh consist of at least Vertices, Indices and possible materials:

A vertex usually consist of things like:
- 3D position
- Normal
- UV coordinate (if using texture)
- Diffuse color
...

Indices are to describe how the vertices are connected to each other to form polygons.

Materials can contain textures, diffuse-, specular-, ambient colors, ...

[webjeff]

I would start simple, choose a format that max/maya exports to and write a loader for that and fill a structure with the data. For example, you could choose (.x or .ase from max) which are human readable formats and export a box with a texture. Then get a simple loader that takes that file format and fills a data structure with that info:

struct ModelData
{
int nVerts;
int nNormals;
int nTexCoords;
int nMaterials
Vector3f* m_VertList;
Vector3f* m_NormList;
Vector3f* m_TexCoordList;
Vector3f* m_MatList;
}

Or whatever and then it will be much easier to render that. But in all fairness its not as simple as you may want it to be to get 3d models on screen. Of course with a little help here, you may be able to get some stuff working. Let us know how far you get and what stumbling blocks you run into, I'm sure we can help.

Jeff.

[marshallh]

I'm not sure if you have access to the 3d hardware using homebrew NGC. Your best bet is to start messing with the framebuffer. Get some pixels drawn, stuff like that.

Then, write yourself a software 3D engine. Before you say "no! its way too complicated", bullshit. It's not. Let me break it down for you

- Write a program to fill a triangle with a solid color.
http://www.cs.virginia.edu/~gfx/cour...1-polyscan.pdf
http://www.cs.berkeley.edu/~ddgarcia/cs184/r3/

- Now, learn how to transform model coordinates into 3d space.
http://www.devmaster.net/articles/so...ring/part1.php

Using these two, you should be able to show a solid blob of a model. You'll have to devise some way to load model data. I'd start with http://www.anim8or.com and make your model, Export to ".vtx" type. This is a list of raw vertices and triangles. Very useful.

- Next keep reading up on scanline conversion. Get your program running gouraud shading to blend colors between the vertices of the triangle. (Interpolating across the triangle basically)

- The same way you interpolated color, now interpolate screen Z coordinates. Before writing the pixel to a frame buffer, check to see if it is nearer (less) then the stored value in a z-buffer. A z-buffer just stores z-values for each pixel on the screen (like long zbuf[480][640]; ) Now you have objects drawn correctly.

- Next interpolate U/V coordinates (texture coordinates) across the triangle. Grab each pixel from a buffer and use that color for the triangle pixel.


That's it. Now you have a software-based renderer that is [almost] platform-independent. You will be doing a LOT of reading. You will not understand most of it. That's fine.

For me I had no knowledge of rasterizers, but in 3 weeks I had a set-up going in C (which I recommend for speed).

If you target SDL you will be almost 100% platform-independent. Here's my end result:



If you want I can show some of the code to you. It's a lot to take in, but believe me, the knowledge you gain will be well worth it.

[PhantasyStar]

Great, thanks guys.

Looks like I'll be busy for a while ;p

[Barc0de]

I'm not sure if you have access to the 3d hardware using homebrew NGC. Your best bet is to start messing with the framebuffer. Get some pixels drawn, stuff like that.

Then, write yourself a software 3D engine. Before you say "no! its way too complicated", bullshit. It's not. Let me break it down for you

- Write a program to fill a triangle with a solid color.
http://www.cs.virginia.edu/~gfx/courses/2004/Intro.Fall.04/handouts/11-polyscan.pdf
http://www.cs.berkeley.edu/~ddgarcia/cs184/r3/

- Now, learn how to transform model coordinates into 3d space.
http://www.devmaster.net/articles/so...ring/part1.php

Using these two, you should be able to show a solid blob of a model. You'll have to devise some way to load model data. I'd start with http://www.anim8or.com and make your model, Export to ".vtx" type. This is a list of raw vertices and triangles. Very useful.

- Next keep reading up on scanline conversion. Get your program running gouraud shading to blend colors between the vertices of the triangle. (Interpolating across the triangle basically)

- The same way you interpolated color, now interpolate screen Z coordinates. Before writing the pixel to a frame buffer, check to see if it is nearer (less) then the stored value in a z-buffer. A z-buffer just stores z-values for each pixel on the screen (like long zbuf[480][640]; ) Now you have objects drawn correctly.

- Next interpolate U/V coordinates (texture coordinates) across the triangle. Grab each pixel from a buffer and use that color for the triangle pixel.


That's it. Now you have a software-based renderer that is [almost] platform-independent. You will be doing a LOT of reading. You will not understand most of it. That's fine.

For me I had no knowledge of rasterizers, but in 3 weeks I had a set-up going in C (which I recommend for speed).

If you target SDL you will be almost 100% platform-independent. Here's my end result:



If you want I can show some of the code to you. It's a lot to take in, but believe me, the knowledge you gain will be well worth it.

He's got full control of the hardware using a GDEV

[Dreamcast]

Barcode, would you mind removing the quote and using "Marshallh, he's got full control of the hardware using a GDEV" instead? There's been good information posted here and I want to follow up on this thread, but don't want to have to scroll past long unnecessary quotes. Aside from convenience, it also keeps the thread clean. Thanks. :)

[webjeff]

don't want to have to scroll past long unnecessary quotes

LOL! how lazy can someone be :)

Good stuff, but although as helpful as it might be, depending on what your goals are, making a software rasterizer may or may not be what PhantasyStar is looking to do. Using a software renderer on the GC would be as slow as peanut butter running down your drain with no water.

We'll have to see how far he gets and if he needs anymore help.

PhantasyStar, you might want to try GameDev.net... for non specific gamecube stuff, you could search through the forums and get general help on game development stuff.... more specifically, all aspects of game development.

Jeff.

[marshallh]

If you have the libs to access the 3d hardware, that's only half the battle. You'll need some examples to study off of. I assume since you have a GDEV you will also have some software to go along with it.

Honestly if this is your first foray into 3d programming, start with C++ and DirectX on the PC. Instant results and good debugging (with Visual C++ 6)

There are plenty of tutorials out there for PC programming, I'm sure you've found how many examples of GC coding there are on the 'net :)

I would argue that writing a software rasterizer is not for practicality, but to give yourself a very good grounding on 3d theory so that when you have all that nice hardware to do the work, it will be cake to convert things over.

And remember webjeff the rasterizer is only as complex as you want it to be - don't expect to run Quake 3 on GC using a software rasterizer. You can easily however rotate some simple textured meshes no problem.

[smf]

And remember webjeff the rasterizer is only as complex as you want it to be - don't expect to run Quake 3 on GC using a software rasterizer. You can easily however rotate some simple textured meshes no problem.

And developing any piece of software from scratch isn't always as easy as writing parts a, b & c. Sometimes you can't start c until you have part of a working but you can't do parts of a until c is doing it's stuff.

It's always much much easier to take existing software and change it. I try to never have to write something from scratch.

[Dreamcast]

No, not lazy, Webjeff. :D I just can't see why there's the need to waste database space when you can get the same effect by using a comma and the name of the username you're making reference to. The only time quotes should be used are if you're responding to a particular point.

Back on topic, does anyone have a link to an explanation of the vertex file format? I have a basic engine going, but for prelimiary tests I've been creating my models by assigning the points manually, but for load testing, want to create more complex models.

I exported an object file from within Anim8tor and I was able to understand that since it only has points, normals, uv coordinates, and face constructs. However, when I exported a model in VTX format, the same cube that had eight vertices in the OBJ file now has 24. Marshallh said the the VTX file is using triangles, which makes sense since my face count is 12 (6 sides * 2 triangles per square face.). What I don't understand is where the 24 vertices come from. It would have to be four vertices per side of the cube, but how would you build two triangles out of that? Do they share vertices?

My object consists of a cube that is 50 px wide, high, and deep. It's positioned at 0, 0, 0.

[webjeff]

Dreamcast,

I just don't see it big enough of a deal to say anything. Just my 2 cents, I'd rather not talk about this anymore as its pointless to this thread.

To your second question, your 24 verts come from, just as you said, 6 sides * 4 verts a piece. You should have a list of faces though, each face contains 3 indices face0 { int v0, v1, v2; };.... so you just need to index into your verts from each face:

xyz = Pos[face.v0];
uv = UV[face.v0];
normals = Normal[face.v0];

The faces are the key to drawing those 24 verts in a tri-list.

Jeff

[marshallh]

Here's my loader code that might help you with the format:

[CODE]FILE *ifp;

ifp = fopen("model.vtx", "r");
if (ifp == NULL) {
printf("Can't open model file\n");
exit(1);
}

while (!feof(ifp)) {
fgets(temp, 256, ifp);

if(strncmp(temp, ".Faceset", 8) == 0)
{
// object vertices & faces

fgets(temp, 256, ifp);
fgets(temp, 256, ifp);
sscanf(temp, "%s %d %s", &temp2, &numVertices, &temp2);
fgets(temp, 256, ifp);

for(i = 0; i < numVertices; i++)
{
fgets(temp, 256, ifp);
sscanf(temp, "%f %f %f %f %f %f %f %f", &vertices[i].x,
&vertices[i].y,
&vertices[i].z,
&vertices[i].nx,
&vertices[i].ny,
&vertices[i].nz,
&vertices[i].u,
&vertices[i].v);

vertices[i].x *= 1.1;
vertices[i].y *= 1.1;
vertices[i].z *= 1.1;

vertices[i].v *= -1; // invert texture to compensate for BMP format

lightVertex(&vertices[i]);
}

fgets(temp, 256, ifp);
fgets(temp, 256, ifp);
fgets(temp, 256, ifp);
sscanf(temp, "%s %d %s", &temp2, &numFaces, &temp2);
fgets(temp, 256, ifp);
for(i = 0; i < numFaces; i++)
{
fgets(temp, 256, ifp);
sscanf(temp, "%d %d %d", &faces[i].f1,
&faces[i].f2,
&faces[i].f3);

}
}
}

fclose(ifp);[/CODE]