I'm using bindings of OpenGL and glfw for Go on OS X 10.7, OpenGL version 3.x.
I enable GL_SCISSOR_TEST and set scissor rectangle to (0, 0, 1, 1). But it has absolutely no effect on the rendering -- the whole viewport is being updated.
Here's the code:
gl.Enable(gl.SCISSOR_TEST)
gl.Scissor(0, 0, 1, 1)
fmt.Printf("scissor enabled = %v\n", gl.IsEnabled(gl.SCISSOR_TEST))
box := make([]int32, 4)
gl.GetIntegerv(gl.SCISSOR_BOX, box)
fmt.Printf("scissor box = %v\n", box)
Console output:
scissor enabled = true
scissor box = [0 0 1 1]
I'm not sure what to make of this. The fact that glIsEnabled() and glGetIntegerv() both report correct values make me think that there is still some state missing that is necessary for activating the scissor test. I tried enabling GL_STENCIL_TEST and initializing glfw with 1 and 8 bits for stencil, still no effect, although glIsEnabled(GL_STENCIL_TEST) returns true.
Related
I am unable to set viewport to desired dimensions. Despite specifying (1980 x 1080), the resultant dimensions are (1366 x 855). The 3D examples in pyqtgraph too do not show full screen and are located at lower left corner only.
import pyqtgraph.opengl as gl
from PyQt5 import QtWidgets
from pyqtgraph.Qt import QtCore
app = QtWidgets.QApplication([])
view = gl.GLViewWidget()
view.opts['viewport'] = (0, 0, 1920, 1080)
view.showMaximized()
view.setMaximumSize(1920, 1080)
print ("%d %d" % (view.height() , view.width()))
view.setWindowTitle('3D Matrix Visualization')
## create three grids, add each to the view
xgrid = gl.GLGridItem()
ygrid = gl.GLGridItem()
zgrid = gl.GLGridItem()
view.addItem(xgrid)
view.addItem(ygrid)
view.addItem(zgrid)
## rotate x and y grids to face the correct direction
xgrid.rotate(90, 0, 1, 0)
ygrid.rotate(90, 1, 0, 0)
## scale each grid differently
xgrid.scale(0.2, 0.1, 0.1)
ygrid.scale(0.2, 0.1, 0.1)
zgrid.scale(0.1, 0.2, 0.1)
If I run the code without changing viewport settings, the parent window, by the virtue of showMaximized(), appears full screen. But the drawable area is confined to 1/4 of the screen in the lower left corner.
view.opts['viewport'] = (0, 0, 1920, 1080)
Using above code, does make drawable area larger but then it is not large enough to cover maximized screen. It is 1366x855. The grid/axis appears in upper right corner and not in the center of 1366x855. In the default mode, the grid/axis appears in the center of the 1/4 drawable area.
Any help is appreciated.
GLViewWidget is a subclass of QtOpenGL.QGLWidget, as shown in PyQtGraph's Doc.
So, maybe we can use the view.setFixedSize(WidthOfParent, HeightOfParent) to adjust the size of viewport while resizing the parent widget.
For Mac with Retina display: The problem is probably that Mac is trying to use virtual resolution when doing high DPI scaling whereas pyqtgraph uses physical resolution.
It should have been fixed in the latest pyqtgraph github branch(link), but the latest PYPI version hasn't been updated since 2016, so please try pip installing directly from github as per official recommendation:
pip install git+https://github.com/pyqtgraph/pyqtgraph
I'm learning from the example of osgpackeddepthstencil of OSG. This example first renders a mask square into a RTTI camera, affacting the stencil buffer while leaving the color buffer untouched. The stencil test is:
osg::Stencil *stencil = new osg::Stencil;
stencil->setFunction(osg::Stencil::ALWAYS, 1, ~0u);
stencil->setOperation(osg::Stencil::KEEP, osg::Stencil::KEEP, osg::Stencil::REPLACE);
osg::StateSet *ss = geode->getOrCreateStateSet();
ss->setAttributeAndModes(stencil, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
ss->setAttribute(new osg::ColorMask(false, false, false, false),osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
Then it renders a larger square into the same RTTI camera, setting the stencil test as not equal to 1. Then use the texture to render a square. The second stencil test codes are below:
osg::Stencil *stencil = new osg::Stencil;
stencil->setFunction(osg::Stencil::NOTEQUAL, 1, ~0u);
stencil->setOperation(osg::Stencil::KEEP, osg::Stencil::KEEP, osg::Stencil::KEEP);
osg::StateSet *ss = geode->getOrCreateStateSet();
ss->setAttributeAndModes(stencil, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
Everything goes fine, and the result is shown below. The clear color is green. The center of the square is green since the stencil buffer values are 1 in this small square due to the first round of rendering.
However, question comes when I change the second stencil test to be not equal to 0. According to my knowledge of stencil test, the result should be a reversed image of the previous one, which has a green boundary and a grey inner square. Quite confusing, the result is as follows which is a whole green:
What am I missing? How to interpret the second result? Any suggestions would be appreciated. Thanks! My OSG version is 3.4.0. My environment is : NVIDIA GTX 750 TI, Windows 10 64bit, Visual Studio 2013.
I am developing a Embree based ray tracer (currently very early in development). If you are not familiar with Embree you can read more at their webpage.
The issue:
Currently if you start the renderer to use 1 ray per pixel and per iteration (referred to 1 ray mode from now on), it renderers just fine. If you set it trace 4 rays in a packet (raypacket4) it renders the mesh fine, util you move some distace away from it, then some black lines appear.
Issue Screenshots
Screenshot camera parameters are (all in ray packet mode):
position 0, 1, 0, rotation 20, 0, 0
position 0, 38, 0 rotation 90, 0, 0
position 9.5, 5, 0 rotation 90, 0, 0
position 9.5, 38, 0 rotation 90, 0, 0
Investigation showed that the lines appear only in pakcet mode and when some distance away from mesh.
I am posting screens of the issue (rendered images) in several different camera positions.
Here is the source code of the project (on GitHub) Source Code
My bet is that the problem is in either the packet generation (found at camera.cpp/GetRayPacket4) or in the rendering (renderer.h/RenderBuffer4, Raytrace4).
Switching between the modes is done in main.cpp by just replacing RenderToBuffer4 with RenderToBuffer and RTC_INTERSECT4 to RTC_INTERSECT1.
Any help or ideas are much appreciated.
Edit:
I apologize for the lack of config files, or scene files, it is currently in very early dev stage( 2 days spent) and everything is hardcoded for testing at the moment.
Edit 2:
I have discovered that removid the + i in the ray direction calculation in GetRayPacket4, removes the issue, but then the 4 packed rays are identical. Why would that fix it ?
Solved.
The issue was that the __m128 keeps the data in reverse order, so some pixel swapping had to take place.
How do I make allegro 5 use anti-aliasing when drawing? I need diagonal lines to appear smooth. Currently, they are only lines of shaded pixels, and the edges look hard.
To enable anti aliasing for the primitives:
// before creating the display:
al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_SUGGEST);
al_set_new_display_option(ALLEGRO_SAMPLES, 8, ALLEGRO_SUGGEST);
display = al_create_display(640, 480);
Note that anti-aliasing will only work for primitives drawn directly to the back buffer. It will not work anywhere else.
On OpenGL, your card must support the ARB_multisample extension.
To check if it was enabled (when using ALLEGRO_SUGGEST):
if (al_get_display_option(display, ALLEGRO_SAMPLE_BUFFERS)) {
printf("With multisampling, level %i\n",
al_get_display_option(display, ALLEGRO_SAMPLES));
}
else {
printf("Without multisampling.\n");
}
You have two options: line smoothing or multisampling.
You can activate line smoothing by using glEnable(GL_LINE_SMOOTH). Note that Allegro 5 may reset this when you draw lines through Allegro.
The other alternative is to create a multisampled display. This must be done before calling al_create_display. The way to do it goes something like this:
al_set_new_display_option(ALLEGRO_SAMPLE_BUFFERS, 1, ALLEGRO_REQUIRE);
al_set_new_display_option(ALLEGRO_SAMPLES, #, ALLEGRO_SUGGEST);
The # above should be the number of samples to use. How many? That's implementation-dependent, and Allegro doesn't help. That's why I used ALLEGRO_SUGGEST rather than REQUIRE for the number of samples. The more samples you use, the better quality you get. 8 samples might be a good value that's supported on most hardware.
Update: This only seems to be a problem at some computers. The normal, intuitive code seems to work fine one my home computer, but the computer at work has trouble.
Home computer: (no problems)
Windows XP Professional SP3
AMD Athlon 64 X2 3800+ Dual Core 2.0 GHz
NVIDIA GeForce 7800 GT
2 GB RAM
Work computer: (this question applies to this computer)
Windows XP Professional SP3
Intel Pentium 4 2.8 Ghz (dual core, I think)
Intel 82945G Express Chipset Family
1 GB RAM
Original post:
I'm trying to apply a very simple texture to a part of the screen using Psychtoolbox in Matlab with the following code:
win = Screen('OpenWindow', 0, 127); % open window and obtain window pointer
tex = Screen('MakeTexture', win, [255 0;0 255]); % get texture pointer
% draw texture. Args: command, window pointer, texture pointer, source
% (i.e. the entire 2x2 matrix), destination (a 100x100 square), rotation
% (none) and filtering (nearest neighbour)
Screen('DrawTexture', win, tex, [0 0 2 2], [100 100 200 200], 0, 0);
Screen('Flip', win); % flip the buffer so the texture is drawn
KbWait; % wait for keystroke
Screen('Close', win); % close screen
Now I would expect to see this (four equally sized squares):
But instead I get this (right and bottom sides are cut off and top left square is too large):
Obviously the destination rectangle is a lot bigger than the source rectangle, so the texture needs to be magnified. I would expect this to happen symmetrically like in the first picture and this is also what I need. Why is this not happening and what can I do about it?
I have also tried using [128 0 1152 1024] as a destination rectangle (as it's the square in the center of my screen). In this case, all sides are 1024, which makes each involved rectangle a power of 2. This does not help.
Increasing the size of the checkerboard results in a similar situation where the right- and bottommost sides are not showed correctly.
Like I said, I use Psychtoolbox, but I know that it uses OpenGL under the hood. I don't know much about OpenGL either, but maybe someone who does can help without knowing Matlab. I don't know.
Thanks for your time!
While I don't know much (read: any) Matlab, I do know that textures are very picky in openGL. Last I checked, openGL requires texture files to be square and of a power of two (i.e. 128 x 128, 256 x 256, 512 x 512).
If they aren't, openGL is supposed to pad the file with appropriate white pixels where they're needed to meet this condition, although it could be a crapshoot depending on which system you are running it on.
I suggest making sure that your checkerboard texture fits these requirements.
Also, I can't quite make sure from your code posted, but openGL expects you to map the corners of your texture to the corners of the object you are intending to texture.
Another bit of advice, maybe try a linear filter instead of nearest neighbor. It's heavier computationally, but results in a better image. This probably won't matter in the end.
While this help is not Matlab specific, hope it is useful.
Without knowing a lot about the Psychtoolbox, but having dealt with graphics and user interfaces a lot in MATLAB, the first thing I would try would be to fiddle with the fourth input to Screen (the "source" input). Try shifting each corner by half-pixel and whole-pixel values. For example, the first thing I would try would be:
Screen('DrawTexture', win, tex, [0 0 2.5 2.5], [100 100 200 200], 0, 0);
And if that didn't seem to do anything, I would next try:
Screen('DrawTexture', win, tex, [0 0 3 3], [100 100 200 200], 0, 0);
My reasoning for this advice: I've noticed sometimes that images or GUI controls in my figures can appear to be off by a pixel, which I can only speculate is some kind of round-off error when scaling or positioning them.
That's the best advice I can give. Hope it helps!