Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Matrices and Multitexturing

Author
Message
Mighty Batsonator
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Atmosoft Ltd. World Headquarters
Posted: 7th Dec 2008 19:55
I'm developing a matrix-based terrain engine for my game. I've nearly finished a rudimentary editor (all it does is select and alter the height of matrix vertices, one at a time, and then saves the resulting heights to file). I was hoping to assign 3 texture files to the matrix - low (Grass), medium (Rocks), high (Ice), and have my code automatically fade from one to the next as the height of the matrix increased.

-- Coding your worst nightmare --
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2008 21:13
Matrix's don't support multiple textures. The obvious choices you have at this point are to generate the texture yourself from your 3 base textures, or to switch to objects which do allow you to multitexture.

Zuka
16
Years of Service
User Offline
Joined: 21st Apr 2008
Location: They locked me in the insane asylum.
Posted: 7th Dec 2008 21:15
Yeah. IanM is right. The object way would be easy enough. Just use memblock meshes.
Mighty Batsonator
18
Years of Service
User Offline
Joined: 24th Mar 2006
Location: Atmosoft Ltd. World Headquarters
Posted: 7th Dec 2008 21:16
I chose the matrix route because I was havind issues with the Terrain class (it would crash my program on any call to Build if I wasn't using the Viewport, even if i copied the example code).

-- Coding your worst nightmare --
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2008 21:23 Edited at: 7th Dec 2008 21:24
Quote: "Just use memblock meshes"

Ugh. With the GDK there is absolutely no need to use memblocks to update the vertices in an existing mesh. You have direct access to the vertex data - why not use it? It's no more complex than memblocks, and a darn sight faster.

Zuka
16
Years of Service
User Offline
Joined: 21st Apr 2008
Location: They locked me in the insane asylum.
Posted: 7th Dec 2008 21:25 Edited at: 7th Dec 2008 21:25
What? Where? I didn't see it in the documentation.

Oh. You mean the DirectX stuff?
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2008 21:47 Edited at: 7th Dec 2008 21:49
Nope. I've just spent 10 minutes converting a bit of plug-in code to GDK to show how you can generate an object from scratch:


It just generates a triangle, but it's writing the mesh data directly into the object.

Zuka
16
Years of Service
User Offline
Joined: 21st Apr 2008
Location: They locked me in the insane asylum.
Posted: 7th Dec 2008 21:52 Edited at: 7th Dec 2008 22:02
Oh yeah, that.

I just tried it.

I see nothing but a blank, blue screen.

IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2008 22:30
You haven't set up any indexes, and you are only updating vertex 0.

The way that I set up a plane in my plug-ins is to set the vertices to the intersection points of a grid, then arrange the indexes to point to those.

I've updated the DarkGDK function to show how to build a 4 vertex plane with indexes:


Zuka
16
Years of Service
User Offline
Joined: 21st Apr 2008
Location: They locked me in the insane asylum.
Posted: 7th Dec 2008 23:04
Oh. I'm trying to get it to do a n by n grid.
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 7th Dec 2008 23:36
Let's assume that you want a 9x9 grid of cells on a plane to keep the numbers relatively simple. That's actually a 10x10 set of vertices, or 100 vertices numbered from 0 to 99 - ( (rows+1) * (cols+1) )

You want to arrange them like this:
(00, 01, 02, 03, 04, 05, 06, 07, 08, 09)
(10, 11, 12, 13, 14, 15, 16, 17 ,18, 19)
(... etc ...)
(90, 91, 92, 93, 94, 95, 96, 97, 98 ,99)

Given an 'x' across and a 'y' down, the coordinate of each point at the corner of each cell will be (x + y * number_of_vertex_columns) where x and y are the vertex coordinates, not the cell coordinates.

Each cell will require 6 indexes - 3 for each of the 2 polys that make up each cell on the grid. In this case, that's 6x9x9 or 486.

Then you fill out the indexes to produce each and every cell on the grid - the calculations for each polygon pair will be something like (y * cols + x, y * cols + x + 1, (y + 1) * cols + x) and ( (y + 1) * cols + x, y * cols + x + 1, (y + 1) * cols + x + 1), where x and y are the cell coordinates (ie 0 to 8 in this example).

If you have problems understanding that, then I suggest you actually draw it out on gridded paper with maybe a 3x4 grid until you understand what's going on.

sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 8th Dec 2008 03:34 Edited at: 8th Dec 2008 08:28
@ IanM,

Thanks for all that. Will do a rewrite of some of my terrain creation code .

Quick question:
There are many possible configurations for setting up the indexes to point to the vertices.

// Set up the indexes to point to the vertices
// First poly
pMesh->pIndices[0] = 0;
pMesh->pIndices[1] = 1;
pMesh->pIndices[2] = 2;

// Second poly
pMesh->pIndices[3] = 0;
pMesh->pIndices[4] = 2;
pMesh->pIndices[5] = 3;


or for example:

// Set up the indexes to point to the vertices
// First poly
pMesh->pIndices[0] = 2;
pMesh->pIndices[1] = 3;
pMesh->pIndices[2] = 0;

// Second poly
pMesh->pIndices[3] = 1;
pMesh->pIndices[4] = 2;
pMesh->pIndices[5] = 0;


If we are creating an object mesh, is there some sequence that is optimised for speed of rendering ?

Also, could some other shape rather than triangles (pMesh->iPrimitiveType = D3DPT_TRIANGLELIST; ) be used as the primitive.
For example, a water mesh or cloud layer mesh would only have to be made from squares rather than triangles. If this is possible within DGDK, would it provide any significant speed improvement?

EDIT: Santa Claus helps those that help themselves , just had to give it a try.
It looks like lines are possible:


Quads are not working.
D3DPT_QUADLIST is an "undeclared identifier"

If one were to activate this mode, would it break some of the default DGDK functions ?
IanM
Retired Moderator
22
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 8th Dec 2008 14:14
Quote: "is there some sequence that is optimised for speed of rendering ?"

The sequence of vertices specified within the index array has no effect on speed that I'm aware of. However, the fact that you have fewer vertices to transform simply because you are using an index will generally mean that rendering will go faster because of that (less vertices to transform = faster, faster through your vertex shaders too).

Quote: "Also, could some other shape rather than triangles ... be used as the primitive"

As you've discovered, yes.

Quote: "Quads are not working."

I wasn't aware that quads were supported by DirectX 9 - is that a DirectX 10 addition, or were you just hopeful?
No matter - quads are harder for you to support as you have to ensure that all corners of the quad are on the same plane, otherwise you get unpredictable results during rendering.

sydbod
16
Years of Service
User Offline
Joined: 14th Jun 2008
Location: Just look at the picture
Posted: 8th Dec 2008 14:33 Edited at: 8th Dec 2008 14:34
Quote: "I wasn't aware that quads were supported by DirectX 9 - is that a DirectX 10 addition, or were you just hopeful?"


I guess I must have been hopeful.

Last Christmas I had a play with some source code of an old flight sim, about 10 years old.... directX 5 or 6 era.

All the aircraft were rendered via BSP tree, and it supported primitives of up to 8 nodes. I guess I just assumed that there was support all the way up to "D3DPT_OCTLIST"

At that time I did not know what I was doing .... and now I still don't know what I am doing.
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA

Login to post a reply

Server time is: 2024-09-30 13:34:09
Your offset time is: 2024-09-30 13:34:09