!. What’s with “integers” ? I am getting used to “everything” is “float” and now this.
“bytes” to my knowledge was / is not C basic type anyway.
Is using “integers” to save memory ? Why ? Does it really applies today ?
2. The “window” is 2x2 square -1 to +1 ( I know there is a correct term for these coordinates, just forgot for a spell) - so where does anything but 1 and 0 come from ? What do you call these coordinates > 1 and why are they used anyway?
3. If using int is to save memory, why use glVertex3i with z = 0 instead of glVertex2i? To "save " few keystrokes …( Just kidding)
The color is often marked by it’s read-green-blue components (all 0->256 … a byte/char). You read your glColor3ub (3 component unsigned byte) as ‘high’ in read.
I dunno. You probably have all options as to what you put in … what comes out is most likely spelled in ‘pixels’. Your coordinates comes out of context.
Have a look at what the viewport() does. Together with an orthographic projection you could flip to use screen-coordinates in pixels. Anyway, as long as you have a gist of your coordinates, do what you find most comfort in.
You use bytes or chars if you want to spare memory. Have you tried to put anything else? Could work none-the-less.
… Be warned, I’ve never used deprecated opengl, and presciously little of the modern.
When OpenGL builds window it’s dimensions are in "normalized device coordinates " AKA -1 0 +1 and vertex functions are limited to such range.
Thus anything >1 MAY be referring to viewport , I guess I have to try that.
Of course knowing this really does not get me any closer to build WORKING stencil application.
Interestingly, taking about “legacy” code - the 4.5 version introduces more stencil stuff , but the official sample code is still same as my 1.1 version!
Which I cannot make work…and running out of resources where to ask for help.
Technically, normalised device coordinates are mapped to the viewport rather than the window. When a context is first bound, the viewport is set to the cover the window (i.e. the viewport origin is set to (0,0) and its dimensions to the size of the window), but can be changed thereafter with glViewport. The viewport isn’t automatically changed if the window is resized; the application needs to do that.
Vertex positions aren’t constrained to the viewport; primitives are clipped to the view frustum after primitive assembly. Note that this doesn’t necessarily mean that rendering is constrained to the viewport; rasterisation of wide lines and points may generate fragments which lie outside of the viewport.
Have you looked at opengl-profiling? The compabillity-profile makes ‘old-style opengl’ possible. That’s what you’r using. I don’t think that it’s developed anymore.
Anyway … finding a book that has what you can use, and nothing more than that is hard to come by. The Red-Book 7. marks down what’s compatible to be discerned from what’s core. The 9.th does not.
Well, I am not trying something"off the wall" - more I get into this stencil stuff, more I am convinced it is just plain boolean algebra “if A is true and B is true then C is true”. It really does not matter what A an B are as long as they are “true”.
With all the “stencil samples” - old (1.1) and “new” I am seeing same - if you first render something one pixel wide then next “something” on top of it - you get “outline”
That is NOT stenciling by any means !
Sorry,little off topic as far as coordinates goes.
It is just plain boolean algebra; it always was. You’re applying a boolean test between a fragment’s reference value and the value in the current stencil buffer for that fragment. That’s all it ever was.
Except it is. “Stenciling” represents creating a pattern that cuts out another thing to fit that pattern. The pattern is the stencil. An OpenGL stencil buffer works exactly the same way.
The “pattern” is the per-pixel values in the stencil buffer, which can be set by rendering with reference stencil values that don’t do a stencil test. That allows you to draw any shape. When you want to draw something against this pattern, you apply a boolean test to the rendering, testing the current fragment’s stencil value against a reference value. That can cull out all fragments not within the area of the stencil.
Alfonse,
I am not disputing WHAT stencil is or does, I was commenting on that majority of “samples” do 2D OUTLINE . That can be done, in crude approach, by rendering “objects” on top of each other - in sequence.
My next “challenge” is 3D stencil, assuming I can use “depth” buffer to do that.
The intended purpose of stencil operations is for insideness testing. Given a boundary (closed curve in 2D, or closed surface in 3D), any line segment between a point inside the boundary and a point outside of it will cross the boundary an odd number of times. This is why glStencilOp supports the operations which it does.
In 2D, if you draw the vertices of a polygon (which can be non-convex, self-intersecting, and/or contain holes) as a triangle fan (the choice of central vertex is irrelevant) into the stencil buffer, incrementing for front faces and decrementing for back faces, at the end of the operation the stencil buffer will contain the winding number for each pixel. Filling a region which encloses the polygon with stencil tests enabled will fill the polygon. The choice of stencil test allows selection of different winding rules (non-zero, even-odd, positive, negative). For even-odd winding, you can use GL_INVERT as the stencil operation, which eliminates the need to distinguish between front and back faces and only requires a 1-bit stencil buffer (it also avoids issues with the finite range of stencil values which could theoretically be an issue for particularly complex polygons).
In 3D, rendering a convex volume with glStencilOp(GL_KEEP, GL_KEEP, GL_INVERT) will result in the stencil buffer containing a non-zero value only for pixels where an odd number of faces pass the depth test. This can be used to implement light/shadow volumes (the stencil buffer indicates where the geometry represented by the depth buffer intersects the volume). It can also be used to implement more general constructive solid geometry, although that typically requires decomposing at least one of the volumes into a union of convex regions.