• entries
743
1924
• views
583827

# 3D hee hee

230 views

We have a coloured 3D cube! Daft demo.

Basically, I've written a D3D program that loads a model from a text file where each vertex is specified in local space along with a colour value for each vertex. It doesn't use an index buffer, so each face can have a distinct colour.

Here is the text file, and boy was this a bugger to write [smile]:

36-1 -1 -1 255 0 0+1 +1 -1 255 0 0+1 -1 -1 255 0 0-1 -1 -1 255 0 0-1 +1 -1 255 0 0+1 +1 -1 255 0 0-1 -1 +1 0 0 255+1 -1 +1 0 0 255+1 +1 +1 0 0 255-1 -1 +1 0 0 255+1 +1 +1 0 0 255-1 +1 +1 0 0 255-1 -1 -1 0 255 0-1 -1 +1 0 255 0-1 +1 +1 0 255 0-1 -1 -1 0 255 0-1 +1 +1 0 255 0-1 +1 -1 0 255 0+1 -1 -1 255 255 0+1 +1 -1 255 255 0+1 +1 +1 255 255 0+1 -1 -1 255 255 0+1 +1 +1 255 255 0+1 -1 +1 255 255 0-1 -1 -1 0 255 255+1 -1 +1 0 255 255-1 -1 +1 0 255 255-1 -1 -1 0 255 255+1 -1 -1 0 255 255+1 -1 +1 0 255 255-1 +1 +1 0 255 255+1 +1 +1 0 255 255-1 +1 -1 0 255 255-1 +1 -1 0 255 255+1 +1 +1 0 255 255+1 +1 -1 0 255 255

I appreciate that this is not exactly cutting edge, but I'm pretty happy with this as the result of the first two or three hours exploring Direct3D. All the concepts seem to be making sense.

Next, I'm going to experiment with materials and lighting I think.

Oh, I'm also talking to Wijnand and some others he knows about getting involved in their new project. Thought it would be fun and a good way to stay motivated with all this 3D stuff. I was pretty impressed by the speed they got their last mini-engine together so thought I could probably learn more than contribute.

[EDIT] Updated the demo above so you can move the camera forward/backwards and strafe left and right with the cursor keys. For some reason, the projection that my book sets up looks a bit weird, so I changed:

	D3DXMatrixPerspectiveFovLH(&Proj,D3DX_PI*0.5f,800.0f/600.0f,1.0f,1000.0f);

to

	D3DXMatrixPerspectiveFovLH(&Proj,D3DX_PI*0.3f,800.0f/600.0f,1.0f,1000.0f);

and it seems to look a lot more normal. No idea what that is all about at this stage really.

Quote:
 For some reason, the projection that my book sets up looks a bit weird, so I changed: D3DXMatrixPerspectiveFovLH(&Proj,D3DX_PI*0.5f,800.0f/600.0f,1.0f,1000.0f); to D3DXMatrixPerspectiveFovLH(&Proj,D3DX_PI*0.3f,800.0f/600.0f,1.0f,1000.0f); and it seems to look a lot more normal. No idea what that is all about at this stage really.

That's the field of view (FoV), which is the angle representing the size of your viewing region. PI/2 is 90 degrees, the default, which I agree looks weird. PI/3, 60 degrees is arguably the general sweet spot. [smile]

##### Link to comment
Rock on! I found the sweet spot!

Cheers, HD. Appreciate the clarification.

##### Link to comment
Also, just to get some confusion out of the way (but you probably already knew this): index buffers don't prevent faces with distinct properties (such as colour). There are a few upsides to using IBs - they're probably best known for simplifying VBs - so you should use them right from the beginning to familiarize yourself with them. I agree that using an index buffer in this example is a bit overkill, since you need to duplicate each vertex for each face is shares anyway :-).

In any case: welcome to the wonderful world of 3D!

##### Link to comment
Quote:
 Original post by Todo Also, just to get some confusion out of the way (but you probably already knew this): index buffers don't prevent faces with distinct properties (such as colour). There are a few upsides to using IBs - they're probably best known for simplifying VBs - so you should use them right from the beginning to familiarize yourself with them. I agree that using an index buffer in this example is a bit overkill, since you need to duplicate each vertex for each face is shares anyway :-).

Cheers for the post.

So how would you assign a distinct diffuse colour value to each face if the vertices were shared via an index buffer? Surely even with the flat shading model, one vertex would be shared as the "first" vertex for more than one face, so the colour value of that vertex would be applied to both faces?

Or am I missing something? I did use IBs quite extensively in my 2D sprite library since this problem obviously did not apply to texturing 2D quads, but I don't understand how you could apply a per-face colour, texture or even a face normal for lighting unless each face had its own distict vertices.

##### Link to comment
Well, that's the point ;-). It works just the same with IBs. Each vertex has to be duplicated to coop with various different properties, but this doesn't mean that two indices can't point to two different vertices. The example here would be having 6 faces, each consisting of 4 distinct vertices. The total would then be 24 vertices and, likewise, 24 indices. The point is, working with IBs, while sometimes will yield no obvious gain, has certain advantages:

* simplicity/flexibility: writing different code to deal with meshes using just VBs and others using IBs and VBs is a pain and can lead to stealthy bugs (i.e. updating code in one class without updating the other);

* speed: it's easier to update indices than entire vertices.

There are most probably more advantages (and certainly disadvantages too, but that wouldn't really help me here :-)), but I can't think of any at the moment. There used to be a blog post about this, but I'm not using my own machine so I can't look it up (sorry :-)).

##### Link to comment
Quote:
 Original post by Todo Well, that's the point ;-). It works just the same with IBs. Each vertex has to be duplicated to coop with various different properties, but this doesn't mean that two indices can't point to two different vertices. The example here would be having 6 faces, each consisting of 4 distinct vertices. The total would then be 24 vertices and, likewise, 24 indices. The point is, working with IBs, while sometimes will yield no obvious gain, has certain advantages: * simplicity/flexibility: writing different code to deal with meshes using just VBs and others using IBs and VBs is a pain and can lead to stealthy bugs (i.e. updating code in one class without updating the other); * speed: it's easier to update indices than entire vertices. There are most probably more advantages (and certainly disadvantages too, but that wouldn't really help me here :-)), but I can't think of any at the moment. There used to be a blog post about this, but I'm not using my own machine so I can't look it up (sorry :-)).

Interesting. The two advantages you specify certainly make sense.

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account