• Advertisement

Archived

This topic is now archived and is closed to further replies.

D3D temperature-mapped primitives?

This topic is 6524 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

In the game I''m working on, each vertex of my polygons has an extra arbitrary value (16-bit, 0 to 65535) that I''d like to be linearly interpolated to some surface. Let me clarify this with an example: Let''s say I want to draw a triangle, and I''ve already got 3 vertices that have screen-space x,y coordinates. In addition, each vertex of this triangle happens to have a certain temperature associated with it - suppose it''s a single 16-bit value ranging from 0 (cold) to 65535 (hot). Now, I could of course display my triangle to my primary surface''s back buffer (or where-ever) using some texture and light data. But what I really want to do is display the triangle''s temperature to another surface. The temperature from the 3 vertices would be interpolated across the triange face, much like how monochromatic light values are interpolated for monochromatic lighting. So, how can I do this? Here''s the best idea I''ve come up with: If I use the D3DTLVERTEX vertex format, I''ve got a z value which I don''t need. I could assign my temperature to the z value, and then my "temperature-mapped" triangle would get rendered to the z-buffer surface during normal rendering. The problem here is that z-values are usually in the range 0 to 1 (float), which means I''d have to convert to 0-65535 (what I need) at some point. Also, the exact implementation of z-buffers (bit-depth, for example) varies from card to card. Another possibility might be using the alpha channel... I''d appreciate any other suggestions for this.

Share this post


Link to post
Share on other sites
Advertisement
What?
What is the "temperature" render supposed to look like, and how does it relate to a "normal" 3d or 2d render? Is the color per vertex changing? Is the mesh deforming somehow? Is it supposed to look like a 3d bar chart? I don''t get it, and unless someone else replies, no one else does either.

Share this post


Link to post
Share on other sites
RotoMuffin, yes, I think I need to clarify a little more.

For those of you reading this, I think you need to understand what I mean by interpolating a value across a polygon. D3D allows you to specify lots of types of data for vertices, besides their location: RGB values for lighting, Z values, (U,V) coordinates for texture mapping, etc. When the renderer knows these values for the vertices of a polygon, it can determine these values at *any* point withing the polygon by interpolating these values across the polygon. (For example, if you specify the Z values of your vertices, the renderer determines the Z value for every pixel within your polygon.)

So the renderer already interpolates RGB values, (U,V) coords, Z values, etc.; what I''m trying to do is get the renderer to interpolate my arbitrary value in addition to all these. I called my arbitary value "temperature" earlier because it was a nice random type of data that could be assigned to the vertices of a triangle.

RotoMuffin, you asked what the temperature render is supposed to "look" like. The triangle would get rendered to a DD surface, but the surface would **never be displayed** -- the values in the surface would be these 16-bit "temperature" values from 0 - 65535. Presumably the program would have some internal use for the temperature data, because, like a z-buffer, it''s not graphical data.

Share this post


Link to post
Share on other sites
Okay, if you are never going to display polys, then why just not render tris without texture and use the color/alpha value AS temperature ? youre wont get any 3D card to interpolate anything more for you, than 2 sets of texture coordinates, and color+alpha intensity.
i might be wrong ... as usual

-kertropp

C:\Projects\rg_clue\ph_opt.c(185) : error C3142: 'PushAll' :bad idea
C:\Projects\rg_clue\ph_opt.c(207) : error C324: 'TryCnt': missing point

Share this post


Link to post
Share on other sites
Kertropp, yes, the cards will only interpolate the values they think they need (color, texture coords, z vals, etc.).
Using the color/alpha values is probably along the lines of what I'll have to do, but here's the problem with using the color/alpha values specifically: Suppose I use a 16-bit pixel format (I need 16 bits), something like this:

AAAA RRRR GGGG BBBB

That's four bits for alpha and four for each hue. Now if I had a poly that was 4 pixels long and fades from dark red at one end to black at the other, here is basically how it would interpolate (I set alpha to zero for simplicity):

0x0100 <-- dark red
0x0100
0x0000
0x0000 <-- black

Notice that the fade from red to black is not smooth at all, because there are no intermediate shades of darker red available. Now, recall that the "dark red" and "black" end values are really just supposed to be 16-bit temperature values, which means the fade *should* have been done like this:

0x0100 <-- 256
0x00AA <-- 170
0x0055 <-- 85
0x0000 <-- 0

Because the alpha, R, G, and B values get interpolated separately, the 16-bit value as a whole does not "ramp down" correctly. I considered using z values earlier because that *is* a single value (and hopefully at least 16-bit), but then that had its own problems.


Edited by - Eric on 4/12/00 3:24:30 PM

Share this post


Link to post
Share on other sites
Monochrome ? blah there is no monochrome supported pixel format in DX.
only thing i can think of, is use some 32 bit surface, then you get 8 bits for one colour value and just use one colour value for "temperature". I guess i didnt give it a proper thought b4 .... hmm, sounds complicated now. Actually using in 32bit you can have 16bit colour and 16bit Zbuffer.. use Zbuffer bits .. ? what little problems did you find with it?

-kertropp

C:\Projects\rg_clue\ph_opt.c(185) : error C3142: 'PushAll' :bad idea
C:\Projects\rg_clue\ph_opt.c(207) : error C324: 'TryCnt': missing point

Share this post


Link to post
Share on other sites
Regarding using the z values: The D3DTLVERTEX vertex format allows you to specify the screen-space z coordinate with the dvSZ field; I could specify my "temperature" value here. dvSZ is a 32-bit fractional value (float) that is required to be in the range 0-1, so my 16-bit integer would have to be converted. That''s not a big deal.

Here''s the tricky part. Even though you specify z as a float, the renderer doesn''t write floats to your z-buffer surface. The renderer *interprets" your z value and fills the z-buffer with the interpretted value ("The actual interpretation of a depth value is specific to the 3-D renderer" - SDK). I guess the reason that the renderer can interpret however it likes is that the z-buffer is not generally used for anything other than rendering.

Anyway, I think this interpretted value is often a 16-bit value (It is in the HEL), so there''s actually an outside chance that the float z values I provide (in the range 0-1) would automatically get converted back to the 16-bit integer I started with! (If I weren''t so lazy, I would have tried this before making this post). Realistically, though, this interpretted z value could be just about any bit-depth and any format (integer, or fractional like a float), and I would have to be able to convert from this mysterious type when I''m accessing the values from the z buffer later. I''m not sure how I could do that.

Share this post


Link to post
Share on other sites
Yes well Z buffer usage is pretty much up to particular 3dcard. They can do it exactly like they darn well please. It doesnt even have to be zbuffer, it just has to expose itself as zbuffer from developers side. Prolly some tile-based renderer wouldnt even put anything reasonable in there. So i think you are better of using 8bit colour value,
sad. But single colour value at least is guaranteed to be interpolated properly on any hware. Otherwise it would produce poor quality image.

-kertropp

C:\Projects\rg_clue\ph_opt.c(185) : error C3142: 'PushAll' :bad idea
C:\Projects\rg_clue\ph_opt.c(207) : error C324: 'TryCnt': missing point

Share this post


Link to post
Share on other sites

  • Advertisement