add rgb color to an array

A

ahso

Hi
////// Terrain Data
float terrainMap[800][800][3]; // heightfield terrain data (0-255);
256x256

How could I add 3 float rgb colors to that? something alike r=0.42
g=0.22 b=0.9 for each terrain point.
Many thanks
Michael
 
G

Gert-Jan de Vos

Hi
////// Terrain Data
float terrainMap[800][800][3];  // heightfield terrain data (0-255);
256x256

How could I add 3 float rgb colors to that? something alike r=0.42
g=0.22 b=0.9 for each terrain point.
Many thanks
Michael

struct RgbColor
{
float r, g, b;
};

RgbColor terrainMap[800][800]; // heightfield terrain data (0-255);
for (int y = 0; y < 800; ++y)
for (int x = 0; x < 800; ++x)
terrainMap[y][x] = RgbColor{0.42, 0.22, 0.9};

Gert-Jan
 
F

Fred Zwarts \(KVI\)

"ahso" wrote in message
Hi
////// Terrain Data
float terrainMap[800][800][3]; // heightfield terrain data (0-255);

Why using a float for data (0-255)?

What does that mean?
How could I add 3 float rgb colors to that?

Again, I have some problems interpreting your question. What do you mean
with "that"?
I assume that you want to convert the single float to four floats.
So create a struct:

struct terrainMapWithColors_t {
float Height;
float Red;
float Green;
float Blue;
}
terrainMapWithColors_t terrainMapWithColors[800][800][3]; // heightfield
terrain data (0-255) and colors.
something alike r=0.42
g=0.22 b=0.9 for each terrain point.

terrainMapWithColors[17][29][2].Red = 0.42f;
terrainMapWithColors[17][29][2].Green = 0.22f;
terrainMapWithColors[17][29][2].Blue = 0.9f;
 
J

Juha Nieminen

ahso said:
float terrainMap[800][800][3]; // heightfield terrain data (0-255);
256x256

How could I add 3 float rgb colors to that? something alike r=0.42
g=0.22 b=0.9 for each terrain point.

Seems like an odd question. Are you asking how to iterate an array
and assign values to its elements in C++?

for(unsigned y = 0; y < 800; ++y)
for(unsigned x = 0; x < 800; ++x)
{
terrainMap[y][x][0] = 0.42;
terrainMap[y][x][1] = 0.22;
terrainMap[y][x][2] = 0.9;
}

If you are using C++11, this might work (untested):

for(auto row: terrainMap)
for(auto pixel: row)
pixel = { 0.42, 0.22, 0.9 };
 
C

Christopher

Hi
////// Terrain Data
float terrainMap[800][800][3];  // heightfield terrain data (0-255);
256x256

How could I add 3 float rgb colors to that? something alike r=0.42
g=0.22 b=0.9 for each terrain point.
Many thanks
Michael

If you are using DirectX or OpenGL then you use the structures they
supply you to represent color, rather than coming up with your own
representation. If not, then you create a struct or class that
represents color.

If you are wanting to contain both in the same structure, than contain
both:

struct MyHeightMapVertexData
{
D3DXVECTOR3 vertex_;
D3DXCOLOR3 color_;
};

You could make a class that allows for variable size heightmaps,
loading from file, parsing, etc. but assuming you always do some
defined size and want to do all that call by call:

MyHeightMapVertexData * myHeightMap = new
MyHeightMapVertexData[NUM_X_ELEMENTS][NUM_Y_ELEMENTS];
..
..
delete myHeightMap;
 
B

BGB

Hi
////// Terrain Data
float terrainMap[800][800][3]; // heightfield terrain data (0-255);
256x256

How could I add 3 float rgb colors to that? something alike r=0.42
g=0.22 b=0.9 for each terrain point.
Many thanks
Michael

If you are using DirectX or OpenGL then you use the structures they
supply you to represent color, rather than coming up with your own
representation. If not, then you create a struct or class that
represents color.

errm: only DirectX directly supplies structures for colors.

the usual OpenGL way is to pass a color as 3 or 4 floats (or as a
pointer to an array of 3 or 4 floats).

not that it actually matters all that much.


I will comment though that, unless there is a good reason, it is
probably wasteful to store RGB values as floats. bytes are much smaller
and cheaper, and can be easily enough converted into floats as-needed
(by dividing by 255.0 or similar, which is not normally particularly
expensive, and could potentially even work out faster in the case of
improved cache density).

If you are wanting to contain both in the same structure, than contain
both:

struct MyHeightMapVertexData
{
D3DXVECTOR3 vertex_;
D3DXCOLOR3 color_;
};

You could make a class that allows for variable size heightmaps,
loading from file, parsing, etc. but assuming you always do some
defined size and want to do all that call by call:

MyHeightMapVertexData * myHeightMap = new
MyHeightMapVertexData[NUM_X_ELEMENTS][NUM_Y_ELEMENTS];
.
.
delete myHeightMap;


this seems reasonable.


I will add though (maybe relevant, technically a bit more advanced,
ignore if not relevant):

for 3D models (in general), it often makes sense to break things like
this down into multiple arrays, so for example one will have a "vertex"
object which may in turn index into arrays for XYZ, ST, RGBA, Normals, ...

this isn't really necessary for height-mapped terrain though, since both
the density and redundancy of points are both fairly low.


the major reason is mostly to save memory and improve performance (one
doesn't have to store endless duplicate copies of the same values, and
if done correctly it can also facilitate faster rendering code as well).

for example, a layout I have often used:
XYZ array (shared between faces);
ST array (shared between faces);
Vertex array (indices for XYZ and ST arrays);
Normal array (identity with Vertex Array);
RGBA array (identity with Vertex Array);
Face Array (index and count in Vertex array, maybe other things).
Edge Array (optional, associates a pair of vertices with a pair of faces
sharing the edge, very relevant for certain calculations).

note: one doesn't need to store most of this in files or similar
(depending on use, all one really needs is the XYZ and ST coordinates
and some way to define the faces).

actually, in my case (for skeletal models) I didn't even bother storing
the bone/vertex associations, as I was instead mostly relying on simple
primitives (cylinders, cubes, ...) attached to the skeleton to rebuild
the bone weights (this also allows me to use the same file-format for
both static meshes and skeletal models). a drawback though is that it is
a lot harder to model/animate things with independently moving parts
(and one may end up "micro-tuning" the skeleton a more bit so that it
binds to the model as-desired, or create the model as multiple parts and
bring them together as part of the animation).

the main difference then is mostly that one adds several more arrays:
Bone Transformations (say, 4x4 transformation matrices);
Bone Solids (keyed solids, mostly used during loading / mesh-binding);
Vertex Bone Weights (bone number, local XYZ, weight value);
Vertex Bone Indices (keyed to vertex array, stores index and count of
bone weights).

the local XYZ is calculated from the vertex XYZ (in the base model) at
load-time, and is used to calculate the vertex XYZ at run-time.
similarly, one may also want to recalculate the normals (probably in a
similar manner to XYZ).

one might also have arrays for things like animation frames and similar
(maybe stored more compactly, such as Origin+Quarernion or similar, as
these are both easier to interpolate and require less memory than
matrices, albeit they are potentially harder to understand).

none of this is quite as complicated as it may sound, mostly it is just
code to walk over and calculate things using arrays (like a numerical
assembly line...).

or such...
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top