Hi,

I have made a small app that will read in several objects and move the
camera or select and move objects. I have enabled Z buffering and
everything appears to be working correctly until now as I am trying to
use glReadPixels to read the depth buffer.

GLint viewport[4];
glGetIntegerv(GL_VIEWPORT, viewport);
GLint width = viewport[2];
GLint height = viewport[3];
GLfloat *pixels = new GLfloat[width * height];
glPixelStorei(GL_UNPACK_ROW_LENGTH, viewport[2]);
int rowSkip = 0;
int pixelSkip = 0;
glPixelStorei(GL_UNPACK_SKIP_PIXELS, pixelSkip);
glPixelStorei(GL_UNPACK_SKIP_ROWS, rowSkip);
glReadPixels(0, 0, width, height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);

At this stage, I am just writing out my pixels to an .csv file (comma
delimited) just so I can see the values:

std::ofstream pixelFile;
pixelFile.open("c:\\pixels.csv");

int testH = 0;
for(int i = 0; i < numPixels; i++)
{
    if((i % (width)) == 0)
    {
        pixelFile << "\n";
        testH++;
    }
    pixelFile << pixels[i] << ", " ;
}
pixelFile.close();

When I look at the ougput file, there appears to be a border on the
right as well as a border on the bottom of large negative numbers.

I am checking that my width and height are correct. The border to the
right appears to be about 3% and the border on the bottom looks to be
30% when the width is 69 and the height is 115. (I made the window as
small as I could by sizing it before I initialized the OpenGL context
and viewport.

The numbers are supposed to be clamped between 0.0 and 1.0. Most
values are around 0.999982 for a simple shallow cube that I have
zoomed to fill the view. The bad values look like: -431602000.

Please advise.

Judie

On Dec 17, 9:50 pm, Judie <judie.m.stan...@gmail.com> wrote:
>
> Please advise.
>

Is the window fully visible? Any part of the window which
is not visible (under another window or whatever) will
give bad values.


--
<\___/>
/ O O \
\_____/  FTB.     Remove my socks for email address.

"Judie" <judie.m.stanley@gmail.com> wrote in message 
news:3e8b5f26-5e6b-40cc-aa2b-00230208cc9e@b40g2000prf.googlegroups.com...
> On Dec 18, 1:11 pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
> wrote:
>> Judie wrote:
>> > No you don't understand. I only want a subregion of the depth
>> > buffer!
>>
>> Yes I understood. But you have have a misconception about how
>> OpenGL works with image data. A subregion to be fetched is
>> selected solely with the parameters to glReadPixels. There's no
>> need to fiddle around with GL_PACK_SKIP... if the buffer in
>> which you want to store the depth buffer has the same size as
>> the dimensions you supply to glReadPixels.
>>
>> In your code you write:
>>
>> GLsizei bufferSize = width * height;
>> GLfloat *pixels = new GLfloat[bufferSize];
>> //...
>> glReadPixels(pixelSkip, rowSkip, width,
>> height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);
>>
>> i.e. you request glReadPixels to store a width*height sized
>> picture into buffer 'pixels'.
>>
>> However the values you specified to GL_PACK_SKIP... let's OpenGL
>> think, that 'pixels' is a a buffer of larger size than
>> width*height, and the values you specified place the data to be
>> read with some offset within pixels.
>>
>> As I told: You don't have to fiddle around with GL_PACK_SKIP...
>> to select the subregion to be read of the framebuffer.
>>
> Oh I see! Jeeze.
>
> I read to much into it.
>
> Maybe I should tell you what I am trying to do and see what you think
> OpenGL has to offer that would work best.
>
> The goal: In a scene of complex geometry that is stationary (I will
> call this geometry B), there is one object that is moving (I will call
> this object A). I only want to render B once only when the camera
> moves. I want to render A as it moves and it is possible that some of
> the geometry could be overlapped by parts of B.
>
> Step 1
> Render B
>
> Step 2
> Disable writing to the color buffer, Enable stippling so that if a
> value to the Z buffer is 1, then the stipple buffer is written to for
> that pixel and draw A. Somehow I need to save the stencil buffer. and
> the background behind the stencil for Step 4.
>
> Step 3
> Enable writing to the color buffer. Draw A using the stipple pattern
> as a mask so that only the visible pixels will be drawn
>
> Step 4
> Before drawing the next frame (I only update if there is movement),
> put back the area of the B that I had previously drawn using the
> stencil in Step 2, in essence, erase A while preseving B.
> Step 5
> rinse and repeat starting at step 2.
>
> So I think I only need to save the stencil and the color buffer areas.
> So what you have taught me about the glReadPixels will definitely
> help.
>
> Thank you.
>
> Judie
>

it's not very likely that this plan will actually work amy better than 
redrawing evertyhing unless the static background is very (very!) complex. 
Don't confuse a stipple pattern with a stencil buffer.

Don't forget that you have 2 color buffers. You can always copy the static 
background back color buffer to the front after "damage" if you draw the 
overlay stuff in the front buffer only. Probably a lot faster than readback 
stuff.

jbw

Judie wrote:

> Hi,
> 
> I have made a small app that will read in several objects and
> move the camera or select and move objects. I have enabled Z
> buffering and everything appears to be working correctly until
> now as I am trying to use glReadPixels to read the depth
> buffer.
> 
> GLint viewport[4];
> glGetIntegerv(GL_VIEWPORT, viewport);
> GLint width = viewport[2];
> GLint height = viewport[3];
> GLfloat *pixels = new GLfloat[width * height];
> glPixelStorei(GL_UNPACK_ROW_LENGTH, viewport[2]);
> int rowSkip = 0;
> int pixelSkip = 0;
> glPixelStorei(GL_UNPACK_SKIP_PIXELS, pixelSkip);
> glPixelStorei(GL_UNPACK_SKIP_ROWS, rowSkip);
> glReadPixels(0, 0, width, height,GL_DEPTH_COMPONENT,GL_FLOAT,
> pixels);

GL_UNPACK... applies to data you upload to OpenGL, i.e. data that
is _unpacked by OpenGL_.

What you want in this case is GL_PACK..., as to tell OpenGL how
to pack the values for you.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

On Dec 18, 1:53 am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
> Judie wrote:
> > Hi,
>
> > I have made a small app that will read in several objects and
> > move the camera or select and move objects. I have enabled Z
> > buffering and everything appears to be working correctly until
> > now as I am trying to use glReadPixels to read the depth
> > buffer.
>
> > GLint viewport[4];
> > glGetIntegerv(GL_VIEWPORT, viewport);
> > GLint width = viewport[2];
> > GLint height = viewport[3];
> > GLfloat *pixels = new GLfloat[width * height];
> > glPixelStorei(GL_UNPACK_ROW_LENGTH, viewport[2]);
> > int rowSkip = 0;
> > int pixelSkip = 0;
> > glPixelStorei(GL_UNPACK_SKIP_PIXELS, pixelSkip);
> > glPixelStorei(GL_UNPACK_SKIP_ROWS, rowSkip);
> > glReadPixels(0, 0, width, height,GL_DEPTH_COMPONENT,GL_FLOAT,
> > pixels);
>
> GL_UNPACK... applies to data you upload to OpenGL, i.e. data that
> is _unpacked by OpenGL_.
>
> What you want in this case is GL_PACK..., as to tell OpenGL how
> to pack the values for you.
>

Thanks, that did the trick and it works great when I grab the size of
the viewport. However, now I have a new issue. When I am grabbing the
rectangle around an object I am getting an access violation.

here is my code:
                               GLsizei bufferSize = width * height;//
(32 bit Z buffer) * sizeof(GLfloat); // machine storage size
		int numPixels = width * height;
		int test2 = bufferSize/4;
		test2++;
		bufferSize = test2*4;

		GLfloat *pixels = new GLfloat[bufferSize];

		//The window coordinates of the first pixel that is read from the
frame buffer.
		//This location is the lower-left corner of a rectangular block of
pixels.
		SIZE OGLBottomLeft;
		OGLBottomLeft.cx = LeftTop.cx;
		OGLBottomLeft.cy = BottomRight.cy;


		glPixelStorei(GL_PACK_ROW_LENGTH, viewport[2]);
		int rowSkip = OGLBottomLeft.cy;
		int pixelSkip = OGLBottomLeft.cx;
		glPixelStorei(GL_PACK_SKIP_PIXELS, pixelSkip);
		glPixelStorei(GL_PACK_SKIP_ROWS, rowSkip);
		glReadPixels(pixelSkip, rowSkip, width,
height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);

this very code works fine when the area is the entire window.

If i look at teh values for a rectangle area they are something like
this:
height = 81, width = 80, pixelSkip = 157, rowSkip = 117, viewport[2] =
237, viewport[3] = 198

This should be correct shouldn't it?
80+157 = 237
81+117 = 198

I even made my pixel array 4 byte aligned. The fact that it works for
the entire window but not an area has me stumped!

Judie

Judie wrote:

> glPixelStorei(GL_PACK_ROW_LENGTH, viewport[2]);
> int rowSkip = OGLBottomLeft.cy;
> int pixelSkip = OGLBottomLeft.cx;
> glPixelStorei(GL_PACK_SKIP_PIXELS, pixelSkip);
> glPixelStorei(GL_PACK_SKIP_ROWS, rowSkip);
> glReadPixels(pixelSkip, rowSkip, width,
> height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);

You're confusing pixel skip with x offset. If you just want to
fetch a rectangular area of width*height pixels from a
win_width*win_height window into a width*height sized buffer,
just leave the GL_PACK_SKIP_... values 0 (zero). GL_PACK_...
values tell OpenGL, how to fill a buffer you supply with values.

Your code makes me presume, that you think, you want to tell
OpenGL how to handle its own buffers.

In the everyday application you don't have to fiddle around with
that. You need them only, if you want to overwrite a subimage in
a larger sized buffer. But in your case the buffer is just
width*height pixels large, however your GL_PACK_SKIP... values
makes OpenGL draw calls, that require a win_width*win_height
large buffer.

Or in other words: You complicated a problem, that is not
complicated, for you made wrong assumptions.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

On Dec 18, 11:03 am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
> Judie wrote:
> > glPixelStorei(GL_PACK_ROW_LENGTH, viewport[2]);
> > int rowSkip = OGLBottomLeft.cy;
> > int pixelSkip = OGLBottomLeft.cx;
> > glPixelStorei(GL_PACK_SKIP_PIXELS, pixelSkip);
> > glPixelStorei(GL_PACK_SKIP_ROWS, rowSkip);
> > glReadPixels(pixelSkip, rowSkip, width,
> > height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);
>
> You're confusing pixel skip with x offset. If you just want to
> fetch a rectangular area of width*height pixels from a
> win_width*win_height window into a width*height sized buffer,
> just leave the GL_PACK_SKIP_... values 0 (zero). GL_PACK_...
> values tell OpenGL, how to fill a buffer you supply with values.
>
> Your code makes me presume, that you think, you want to tell
> OpenGL how to handle its own buffers.
>
> In the everyday application you don't have to fiddle around with
> that. You need them only, if you want to overwrite a subimage in
> a larger sized buffer. But in your case the buffer is just
> width*height pixels large, however your GL_PACK_SKIP... values
> makes OpenGL draw calls, that require a win_width*win_height
> large buffer.
>
> Or in other words: You complicated a problem, that is not
> complicated, for you made wrong assumptions.
>
> Wolfgang Draxinger
> --
> E-Mail address works, Jabber: hexar...@jabber.org, ICQ: 134682867

No you don't understand. I only want a subregion of the depth buffer!
Not the entire window's worth. But my region could be anywhere in the
window. I want the region where a particular object is. I have the
bounding box coordinates of the object and I have these coordinates
translated into window space and I have the max and min of the x and y
corresponding to this little rectangle that I want to grab. Is this
too much to ask?

Judie

On Dec 18, 11:35 am, Judie <judie.m.stan...@gmail.com> wrote:
> On Dec 18, 11:03 am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
> wrote:
>
>
>
>
>
> > Judie wrote:
> > > glPixelStorei(GL_PACK_ROW_LENGTH, viewport[2]);
> > > int rowSkip = OGLBottomLeft.cy;
> > > int pixelSkip = OGLBottomLeft.cx;
> > > glPixelStorei(GL_PACK_SKIP_PIXELS, pixelSkip);
> > > glPixelStorei(GL_PACK_SKIP_ROWS, rowSkip);
> > > glReadPixels(pixelSkip, rowSkip, width,
> > > height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);
>
> > You're confusing pixel skip with x offset. If you just want to
> > fetch a rectangular area of width*height pixels from a
> > win_width*win_height window into a width*height sized buffer,
> > just leave the GL_PACK_SKIP_... values 0 (zero). GL_PACK_...
> > values tell OpenGL, how to fill a buffer you supply with values.
>
> > Your code makes me presume, that you think, you want to tell
> > OpenGL how to handle its own buffers.
>
> > In the everyday application you don't have to fiddle around with
> > that. You need them only, if you want to overwrite a subimage in
> > a larger sized buffer. But in your case the buffer is just
> > width*height pixels large, however your GL_PACK_SKIP... values
> > makes OpenGL draw calls, that require a win_width*win_height
> > large buffer.
>
> > Or in other words: You complicated a problem, that is not
> > complicated, for you made wrong assumptions.
>
> > Wolfgang Draxinger
> > --
> > E-Mail address works, Jabber: hexar...@jabber.org, ICQ: 134682867
>
> No you don't understand. I only want a subregion of the depth buffer!
> Not the entire window's worth. But my region could be anywhere in the
> window. I want the region where a particular object is. I have the
> bounding box coordinates of the object and I have these coordinates
> translated into window space and I have the max and min of the x and y
> corresponding to this little rectangle that I want to grab. Is this
> too much to ask?
>
> Judie- Hide quoted text -
>
> - Show quoted text -

Nevermind... I think that what I want to do is use glCopyPixels to
copy from the Depth buffer to the stencil buffer.

Judie wrote:

> No you don't understand. I only want a subregion of the depth 
> buffer!

Yes I understood. But you have have a misconception about how
OpenGL works with image data. A subregion to be fetched is
selected solely with the parameters to glReadPixels. There's no
need to fiddle around with GL_PACK_SKIP... if the buffer in
which you want to store the depth buffer has the same size as
the dimensions you supply to glReadPixels.

In your code you write:

GLsizei bufferSize = width * height;
GLfloat *pixels = new GLfloat[bufferSize];
//...
glReadPixels(pixelSkip, rowSkip, width,
height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);

i.e. you request glReadPixels to store a width*height sized
picture into buffer 'pixels'.

However the values you specified to GL_PACK_SKIP... let's OpenGL
think, that 'pixels' is a a buffer of larger size than
width*height, and the values you specified place the data to be
read with some offset within pixels.

As I told: You don't have to fiddle around with GL_PACK_SKIP...
to select the subregion to be read of the framebuffer.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

On Dec 18, 1:11 pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
> Judie wrote:
> > No you don't understand. I only want a subregion of the depth
> > buffer!
>
> Yes I understood. But you have have a misconception about how
> OpenGL works with image data. A subregion to be fetched is
> selected solely with the parameters to glReadPixels. There's no
> need to fiddle around with GL_PACK_SKIP... if the buffer in
> which you want to store the depth buffer has the same size as
> the dimensions you supply to glReadPixels.
>
> In your code you write:
>
> GLsizei bufferSize = width * height;
> GLfloat *pixels = new GLfloat[bufferSize];
> //...
> glReadPixels(pixelSkip, rowSkip, width,
> height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);
>
> i.e. you request glReadPixels to store a width*height sized
> picture into buffer 'pixels'.
>
> However the values you specified to GL_PACK_SKIP... let's OpenGL
> think, that 'pixels' is a a buffer of larger size than
> width*height, and the values you specified place the data to be
> read with some offset within pixels.
>
> As I told: You don't have to fiddle around with GL_PACK_SKIP...
> to select the subregion to be read of the framebuffer.
>
Oh I see! Jeeze.

I read to much into it.

Maybe I should tell you what I am trying to do and see what you think
OpenGL has to offer that would work best.

The goal: In a scene of complex geometry that is stationary (I will
call this geometry B), there is one object that is moving (I will call
this object A). I only want to render B once only when the camera
moves. I want to render A as it moves and it is possible that some of
the geometry could be overlapped by parts of B.

Step 1
Render B

Step 2
Disable writing to the color buffer, Enable stippling so that if a
value to the Z buffer is 1, then the stipple buffer is written to for
that pixel and draw A. Somehow I need to save the stencil buffer. and
the background behind the stencil for Step 4.

Step 3
Enable writing to the color buffer. Draw A using the stipple pattern
as a mask so that only the visible pixels will be drawn

Step 4
Before drawing the next frame (I only update if there is movement),
put back the area of the B that I had previously drawn using the
stencil in Step 2, in essence, erase A while preseving B.
Step 5
rinse and repeat starting at step 2.

So I think I only need to save the stencil and the color buffer areas.
So what you have taught me about the glReadPixels will definitely
help.

Thank you.

Judie

On Dec 18, 6:02 am, "jbwest" <jbw...@comcast.net> wrote:
>
> it's not very likely that this plan will actually work amy better than
> redrawing evertyhing unless the static background is very (very!) complex.
>

I agree....



--
<\___/>
/ O O \
\_____/  FTB.     Remove my socks for email address.

Judie wrote:

> The goal: In a scene of complex geometry that is stationary (I
> will call this geometry B), there is one object that is moving
> (I will call this object A). I only want to render B once only
> when the camera moves. I want to render A as it moves and it is
> possible that some of the geometry could be overlapped by parts
> of B.

You see a bottleneck where none is, and OTOH create another one.
You should know, that glDrawPixels is slow, if you don't supply
it the data in the very format it is stored on the GPU's memory.
The same goes for glReadPixels. Then in what you want to do it's
usually better to do it with the whole framebuffer having the
static objects, not just a subregion. And lat but not least: If
the geometry you're drawing is not too complex it's probably
faster just to redraw the whole stuff.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

On Dec 17, 9:02 pm, "jbwest" <jbw...@comcast.net> wrote:
> "Judie" <judie.m.stan...@gmail.com> wrote in message
>
> news:3e8b5f26-5e6b-40cc-aa2b-00230208cc9e@b40g2000prf.googlegroups.com...
>
>
>
>
>
> > On Dec 18, 1:11 pm, Wolfgang Draxinger <wdraxin...@darkstargames.de>
> > wrote:
> >> Judie wrote:
> >> > No you don't understand. I only want a subregion of the depth
> >> > buffer!
>
> >> Yes I understood. But you have have a misconception about how
> >> OpenGL works with image data. A subregion to be fetched is
> >> selected solely with the parameters to glReadPixels. There's no
> >> need to fiddle around with GL_PACK_SKIP... if the buffer in
> >> which you want to store the depth buffer has the same size as
> >> the dimensions you supply to glReadPixels.
>
> >> In your code you write:
>
> >> GLsizei bufferSize = width * height;
> >> GLfloat *pixels = new GLfloat[bufferSize];
> >> //...
> >> glReadPixels(pixelSkip, rowSkip, width,
> >> height,GL_DEPTH_COMPONENT,GL_FLOAT, pixels);
>
> >> i.e. you request glReadPixels to store a width*height sized
> >> picture into buffer 'pixels'.
>
> >> However the values you specified to GL_PACK_SKIP... let's OpenGL
> >> think, that 'pixels' is a a buffer of larger size than
> >> width*height, and the values you specified place the data to be
> >> read with some offset within pixels.
>
> >> As I told: You don't have to fiddle around with GL_PACK_SKIP...
> >> to select the subregion to be read of the framebuffer.
>
> > Oh I see! Jeeze.
>
> > I read to much into it.
>
> > Maybe I should tell you what I am trying to do and see what you think
> > OpenGL has to offer that would work best.
>
> > The goal: In a scene of complex geometry that is stationary (I will
> > call this geometry B), there is one object that is moving (I will call
> > this object A). I only want to render B once only when the camera
> > moves. I want to render A as it moves and it is possible that some of
> > the geometry could be overlapped by parts of B.
>
> > Step 1
> > Render B
>
> > Step 2
> > Disable writing to the color buffer, Enable stippling so that if a
> > value to the Z buffer is 1, then the stipple buffer is written to for
> > that pixel and draw A. Somehow I need to save the stencil buffer. and
> > the background behind the stencil for Step 4.
>
> > Step 3
> > Enable writing to the color buffer. Draw A using the stipple pattern
> > as a mask so that only the visible pixels will be drawn
>
> > Step 4
> > Before drawing the next frame (I only update if there is movement),
> > put back the area of the B that I had previously drawn using the
> > stencil in Step 2, in essence, erase A while preseving B.
> > Step 5
> > rinse and repeat starting at step 2.
>
> > So I think I only need to save the stencil and the color buffer areas.
> > So what you have taught me about the glReadPixels will definitely
> > help.
>
> > Thank you.
>
> > Judie
>
> it's not very likely that this plan will actually work amy better than
> redrawing evertyhing unless the static background is very (very!) complex.
> Don't confuse a stipple pattern with a stencil buffer.
>
> Don't forget that you have 2 color buffers. You can always copy the static
> background back color buffer to the front after "damage" if you draw the
> overlay stuff in the front buffer only. Probably a lot faster than readback
> stuff.
>


I probably should not say too much about what I am doing but trust me
that this is embedded graphics on an older system and yes, the
geometry is complex, not in the amount of polys but in the operations
that will be applied to it. The minimizing of that will be my next
step after I understand this object A and B stuff.  But thanks about
the hint on the color buffers! Sometimes my brain gets a bit scrambled
and I don't see the obvious.

Judie

On Dec 19, 12:23 am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
> Judie wrote:
> > The goal: In a scene of complex geometry that is stationary (I
> > will call this geometry B), there is one object that is moving
> > (I will call this object A). I only want to render B once only
> > when the camera moves. I want to render A as it moves and it is
> > possible that some of the geometry could be overlapped by parts
> > of B.
>
> You see a bottleneck where none is, and OTOH create another one.
> You should know, that glDrawPixels is slow, if you don't supply
> it the data in the very format it is stored on the GPU's memory.
> The same goes for glReadPixels. Then in what you want to do it's
> usually better to do it with the whole framebuffer having the
> static objects, not just a subregion. And lat but not least: If
> the geometry you're drawing is not too complex it's probably
> faster just to redraw the whole stuff.
>
The problem is that the geometry is stored in breps. And the breps are
going through all these calculations when only one little area really
needs to be modified. So actually the drawing of the geometry is not
the bottleneck. I need to isolate the geometry of the parts that are
changing, create little breps on them and then do the boolean
operations and then just update those little areas. I was thinking
that I could use glScissors to make the window area that I am updating
smaller maybe.

Judie

Judie wrote:

> I probably should not say too much about what I am doing but
> trust me that this is embedded graphics on an older system and
> yes, the geometry is complex, not in the amount of polys but in
> the operations that will be applied to it. The minimizing of
> that will be my next
> step after I understand this object A and B stuff.  But thanks
> about the hint on the color buffers! Sometimes my brain gets a
> bit scrambled and I don't see the obvious.

"Premature optimization is the root of all evil." -- Donald E.
Knuth.

First get your app doing what you want. THEN use a profiler to
find the bottlenecks.

Wolfgang Draxinger
-- 
E-Mail address works, Jabber: hexarith@jabber.org, ICQ: 134682867

On Dec 19, 3:52 pm, Judie <judie.m.stan...@gmail.com> wrote:
>
> I probably should not say too much about what I am doing but trust me
> that this is embedded graphics on an older system

If it's only going to run on a single machine then you
can (and should!) time glReadPixels/glDrawPixels
and make your decision based on the results.

If the program was for release to the general public
then it's different - decisions like this are a lot more
complex.


--
<\___/>
/ O O \
\_____/  FTB.     Remove my socks for email address.

On Dec 19, 11:20 am, Wolfgang Draxinger <wdraxin...@darkstargames.de>
wrote:
> Judie wrote:
> > I probably should not say too much about what I am doing but
> > trust me that this is embedded graphics on an older system and
> > yes, the geometry is complex, not in the amount of polys but in
> > the operations that will be applied to it. The minimizing of
> > that will be my next
> > step after I understand this object A and B stuff.  But thanks
> > about the hint on the color buffers! Sometimes my brain gets a
> > bit scrambled and I don't see the obvious.
>
> "Premature optimization is the root of all evil." -- Donald E.
> Knuth.
>
> First get your app doing what you want. THEN use a profiler to
> find the bottlenecks.
>
> Wolfgang Draxinger
> --
> E-Mail address works, Jabber: hexar...@jabber.org, ICQ: 13468286

This is an older application and it uses a library to do the brep
booleans which are very correct but are very computationally
intensive. We have profiled and know that is the root of the problem.
I am not working in the brep code yet, someone else is. I am given the
assignment to figure out how to draw a subset of the geometry while it
is animating.

I am now using the STENCIL (not stipple) buffer and it works some of
the time :-) So I am still debugging. The problem is that as I move
the object and it goes through the drawing routine, sometimes
fragments are not drawn even if they were able to draw before. Here is
my code:

                                    int i = 0;
		//get the rectangle of the prim and scissor the window
		Primitive *prim = m_SelectedPrimitives[0];

		//Draw the other prims but they will only be done in the scissor
window
		//TODO only do this once
		glDisable(GL_STENCIL_TEST);
		glClearStencil(0x0);
		glClear(GL_STENCIL_BUFFER_BIT);

		if(m_initStencil)
		{
		//	glEnable(GL_SCISSOR_TEST);
			m_initStencil = false;
			prim->CheckGLError();
			glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
			glEnable(GL_DEPTH_BUFFER_BIT);
			glDrawBuffer(GL_BACK);
			for(i = 0; i < (int)m_Primitives.size(); i++)
				m_Primitives[i]->Draw();

		}

		SwapBuffers(mhDC);
		glFinish();
	//	RECT rect = prim->GetPrimRect();
	//	int width = rect.right - rect.left;
	//	int height = rect.top - rect.bottom;
		//glScissor(rect.left, rect.bottom, width, height);
		//at this point both front and back buffers have the info...
		//that means I can reuse the back buffer as savings....
		glDrawBuffer(GL_FRONT);
		glReadBuffer(GL_BACK);

		//Set up stenciling to write the value 1 into the stencil buffer
when the depth test passes.
		//Also disable writes to the color buffer. Then draw the selected
prim's polygons.
		glClearStencil(0x0);
		glEnable(GL_STENCIL_TEST);
		glStencilFunc(GL_ALWAYS, 1, ~0);
		glStencilOp(GL_KEEP, GL_KEEP, GL_REPLACE);
		glColorMask(0,0,0,0);
		prim->Draw();
		glFinish();

		//With the color buffer writes still disabled, set the depth range
to write the farthest value
		//possible for all updated pixels and set the depth test to always
pass. Also, set the
		//stencil test to only update pixels tagged with the stencil value
1. Then draw the selected prim's
		//polygons.
		glColorMask(1,1,1,1);
		glDepthRange(0,1); // always
		glDepthFunc(GL_LEQUAL); // write the farthest depth value
		glStencilFunc(GL_EQUAL, 1, ~0); // match mirror's visible pixels
		glStencilOp(GL_KEEP, GL_KEEP, GL_KEEP); // do not change stencil
values

		prim->Draw();
		glFinish();


I am not trying the glScissor until I fix this part...

Judie

On Dec 19, 1:52 pm, fungus <openglMYSO...@artlum.com> wrote:
> On Dec 19, 3:52 pm, Judie <judie.m.stan...@gmail.com> wrote:
>
>
>
> > I probably should not say too much about what I am doing but trust me
> > that this is embedded graphics on an older system
>
> If it's only going to run on a single machine then you
> can (and should!) time glReadPixels/glDrawPixels
> and make your decision based on the results.
>
> If the program was for release to the general public
> then it's different - decisions like this are a lot more
> complex.

Yes, I know the machine(s) it will be released on.

Judie