0

I have rendered a 3D scene in OpenGL viewed from the gluOrtho perspective. In my application I am looking at the front face of a cube of volume 100x70x60mm (which I have as 1000x700x600 pixels). Inside this cube I have rendered a simple blue sphere which sits exactly in the middle and 'fills' the cube (radius 300 pixels).

I now want to read the color value of pixels (in 3D) at specific points within the cube; i.e. I wish to know if say point (100,100,-200) is blue or blank (black).

glReadPixels only allows 2D extraction of color and I have tried it with the DEPTH_COMPONENT but am unsure what this should return in byte form? Is there a way to combine the two? Am I missing something?

I am using Eclipse with Java and JOGL.

genpfault
  • 51,148
  • 11
  • 85
  • 139
Tim Wood
  • 67
  • 1
  • 7
  • there's nothing called 'pixel' in opengl 3D space, it's seemless. only the screen has rectangular pixels. – jondinham Aug 30 '11 at 18:23

2 Answers2

4

This can't be done in the context of OpenGL--you'll need some sort of scene graph or other space partitioning scheme working in concert with your application's data structures.

The reason is simple: the frame buffer only stores the color and depth of the fragment nearest to the eye at each pixel location (assuming a normal GL_LESS depth function). The depth value stored in the Z-buffer is used to determine if each subsequent fragment is closer or farther from the eye than the existing fragment, and thus whether the new fragment should replace the old or not. The frame buffer only stores color and depth values from the most recent winner of the depth test, not the entire set of fragments that would have mapped to that pixel location. Indeed, there would be no way to bound the amount of graphics memory required if that were the case.

Drew Hall
  • 28,429
  • 12
  • 61
  • 81
  • Thanks, that is what I feared. Might try Java3D as that uses scence graphing. More learning to be done! – Tim Wood Jan 27 '11 at 13:12
  • Just having a scene graph would help you, to as the scene graph is a purely abstract representation where "colour" is just some numeric value. Java3D is even less usefull than OpenGL for this. What you need to do, is peeling the scene into it's depth layers. Essentially you've to cast a ray into the scene, look with which objects it intersects and determine the surface properties of each object's intersection point. Inside/Outside determination is even harder on triangulated meshes, you'll have to do some spatial subdivision for that. Like building a BSP-tree. – datenwolf Jan 27 '11 at 16:49
  • Apologies for my ignorance but how do I go about building a scene graph? Does OpenGL support this at some level or will I need a more different approach? – Tim Wood Jan 28 '11 at 12:33
  • OpenGL only covers gettings things on the screen. A scene graph is a/the data structure used to manage the objects to be drawn and controlling the rendering process. There are some ready-to-use scene graph libraries, also having some other components for a 3D engine (OGRE, Irrlicht, Crystal Space). But I think for what you want to do, you need something custom. – datenwolf Jan 28 '11 at 12:55
  • Thanks for the advice, I will have a look through the already available libraries but envisage I will have to create my own. I am not really interested in the 'viewing' the 3D rendering, merely extracting data from it and using that. – Tim Wood Jan 28 '11 at 13:09
1

You're not the first to fall for this misconception, so I say it the most blunt way possible: OpenGL doesn't work that way. OpenGL never(!) deals with objects or any complex scenes. The only thing OpenGL knows about are framebuffers, shaders and single triangles. Whenever you draw an object, usually composed of triangles, OpenGL will only see each triangle at a time. And once something has been drawn to the framebuffer, whatever has been there before is lost.

There are algorithms based on the concepts of rasterizers (like OpenGL is) that decompose a rendered scene into it's parts, depth peeling would be one of them.

datenwolf
  • 159,371
  • 13
  • 185
  • 298