Hey, I'd like to display text in a 2D szenario using JOGL. But I can't figure out, how to rotate text using com.sun.opengl.util.j2d.TextRenderer. It does not have any methods concerning the rotation. So I was expecting the modelview matrix to have an effect on the rotation.
val renderer = new TextRenderer(new Font("SansSerif", Font.BOLD, 36))
[...]
renderer.beginRendering(drawable.getWidth(), drawable.getHeight())
gl.glRotatef(90,0,0,1)
renderer.draw(content, 0, 0)
renderer.endRendering()
Do you know any help?
For me, the following order -- and only the following order -- works:
renderer.beginRendering(...)
glMatrixMode(GL_MODELVIEW)
glPushMatrix()
glRotatef(...)
renderer.draw(...)
renderer.endRendering()
glPopMatrix()
If I so much as switch the order of the last two lines, it stops working. Don't know why.
Call glRotatef before you beginRendering() the text.
Make sure to glMatrixMode(GL_MODELVIEW) just before calling glRotatef. You don't know what matrix mode the beginRendering method leaves OpenGL in.
Related
When I create a figure with MATLAB with a title, then use the File|Print option to print the figure, the title is clipped. Please try this code for an example
t = linspace(0,2*pi,1000);
s = sin(t);
figure
plot(t,s)
titleString = sprintf('Multi\nLine\nTitle');
title(titleString)
disp('Now press File|Print Preview on the figure and observe that the title is clipped.')
disp('This happens with all titles, the multi line title makes it more obvious.')
disp('I know I can fix it with Fill Page or Center, but I should not have too.')
You can also see the problem in print preview. As I say in the example code, I know I can get round the problem using Print Preview then Fill Page or Center, but I don't want people using my code to have to use a work around.
I have observed this problem with r2014a and r2015b. I assume other releasse are also affected.
Is there setting I can make before creating the figure that centres the plot or fills the page and makes the problem go away? Is there some other setting I should make to avoid the problem?
Here is a little more debug information. If I press File|Print Preview, MATLAB reports Left 0.64, Top -0.59, Width 20.32, Height 15.24. I guess the problem is related to the negative Top value. These are defaults from MATLAB; I have not made any attempt to change these values.
One extra thing. I am in the UK, so my default paper/printer setting will be for A4 paper, if that makes a difference.
Edit:
It looks like my problems are caused by two lines further up in my program:
set(0,'DefaultFigurePaperOrientation','landscape')
set(0,'DefaultFigurePaperType','A4')
I think that becuase plots expect to be on paper with a portrait orientation, I am seeing these problems.
Perhaps I should revise my question to: what to I need to change in MATLAB figures so they print correctly on landscape A4 paper (ideally in the center, scaled to fill the page, but with correct orientation). All this without using Print Preview.
But I am going to do this instead to code around my problem.
set(0,'DefaultFigurePaperOrientation','portrait')
set(0,'DefaultFigurePaperType','A4')
I can't seem to reproduce your problem on the computer I'm currently on (see the values I'm getting by default - Top is 8.11):
However, if your problem is what I think it is (I'm getting something that fits this description on another computer I'm working on), try adding _{ } at the end of your string. This is a TeX string meaning "subscripted space" which pushes the rest of the text slightly upward. You can also use ^{ } on the first line if the clipping is happening from the top. I found this workaround to work on axis titles and labels as well.
Exaggerated, the workaround looks like this:
titleString = sprintf('^{^{^{^{^{^{ }}}}}}Multi\nLine\nTitle');
Which shows the word "Multi" even for Top = -0.59.
If the above is not what you're looking for, you might want to look at the robust export_fig.
I can confirm that my clipping problems are caused by this line:
set(0,'DefaultFigurePaperOrientation','landscape')
I have revised my program to start with this instead.
set(0,'DefaultFigurePaperOrientation','portrait')
set(0,'DefaultFigurePaperType','A4')
And the problem has gone away.
Users can still print in landscape if they use the print preview feature.
I have problems with intersection() in OpenSCAD. Here is the code
intersection(){
rotate_extrude($fn=200)
translate([30, 0, 0])
circle(r=5);
translate([0,0,-50])
cube([100,100,100]);
};
It looks good
until you chance the point of view
It is not what I expected. How can I fix it?
if you only compile your code, the view might be damaged. Compile and render and you see your correct 3D-object. To verify export as stl, then import the stl-file in a new document and examine it
You probably should set the convexity parameter in the extrusion, otherwise the renderer might assuming the object is convex, leading to the rendering errors in your screen shot.
For a torus, convexity should be set to at least 4, because a straight line can intersect it as many as four times. I believe the torus example in the docs sets the convexity to 10, which is overkill, but there doesn't seem to be a problem with erring in that direction.
I am currently using the fill command in MATLAB to create a graph of boxes that were created using the 'fill' command (the actual code is based off this StackOverflow Question.
My issue is that the boxes that I create do not have "corners." I am attaching a PNG that illustrates the issue. Note that you have to look a little carefully since the image was heavily rendered, though in this example my arrows also look weird since they don't have edges either)
I am wondering if anyone has an idea of what might be going wrong? The boxes appear this way immediately after I use the fill command, which has the following structure:
fill(X,Y,MyFaceColor,'FaceAlpha',0.5,'EdgeColor', MyEdgeColor,'LineStyle','','LineWidth',box_line_width,'EdgeAlpha',1)
The function fill appears to leave space for corner markers if they are not explicitly defined. Hence, calling fill with the marker property will solve your problem. However, since markers and linewidths seem to work on different scales, you will have to play around with the marker size to get smooth edges.
Example:
fill(X,Y,'r','FaceAlpha',0.5,'EdgeColor', 'k',...
'LineWidth', 5,'EdgeAlpha',1 , 'marker', '.', 'markersize', 15)
To try and solve this problem, I started looking into writing a plugin for flot to do what I needed. It looked surprisingly straight-forward, but I have run into a minor snag. I First used the draw hook to draw my axis (note: I'm aware this code needs some error checking to make sure the origin isn't off the chart)
function draw(plot, ctx) {
var offset = plot.getPlotOffset();
var origin = plot.pointOffset({ x: 0, y: 0 });
ctx.moveTo(offset.left, origin.top);
ctx.lineTo(plot.width() + offset.left, origin.top);
ctx.stroke();
ctx.moveTo(origin.left, offset.top);
ctx.lineTo(origin.left, plot.height() + offset.top);
ctx.stroke();
}
And this works, with 2 small snags. The first and most important is that for some reason it makes the very last point of my data series change color! See here:
The point in the upper right-hand corner has turned black. By stepping through the code I can observe that this only happens when the axes are drawn. Before my draw code is called, the point is the correct color. So I think it has something to do with the drawing on the first "stroke". For some reason it seems to then apply the black color to the last point. Any idea on how to fix this?
The second problem is that this code is called only after flot has draw everything else (including the data points) which means that my lines appear on top of points instead of underneath them. This is only a problem for those two points that are very close to the vertical axis. Looking at the flot documentation, it mentions a drawBackground hook, but this doesn't seem to actually exist. I tried using it and it complained the drawBackground was null. So what happened? And is there a better place to hook into and draw my axes? I want to draw after flot has worked out the size of the plot area and before it draws the first series of data points.
What's currently on the website API documentation does not match the newest released version (0.7). In order to use the backgroundDraw hook, you'll need a newer version of flot, directly from their github repository. The newest version is fine, but anything after this commit would be workable.
I have a question about the values returned by getPosition. Below is my code. It lets the user set 10 points on a given image:
figure ,imshow(im);
colorArray=['y','m','c','r','g','b','w','k','y','m','c'];
pointArray = cell(1,10);
% Construct boundary constraint function
fcn = makeConstrainToRectFcn('impoint',get(gca,'XLim'),get(gca,'YLim'));
for i = 1:10
p = impoint(gca);
% Enforce boundary constraint function using setPositionConstraintFcn
setPositionConstraintFcn(p,fcn);
setColor(p,colorArray(1,i));
pointArray{i}=p;
getPosition(p)
end
When I start to set points on the image I get results like [675.000 538.000], which means that the x part of the coordinate is 675 and the y part is 538, right? This is what the MATLAB documentation says, but since the image is 576*120 (as displayed in the window) this is not logical.
It seemed to me like, somehow, getPosition returns the y coordinate first. I need some clarification on this.
Thanks for help
I just tried running your code in MATLAB 7.8.0 (R2009a) and had no problems with image sizes of either 576-by-120 or 120-by-576 (I was unsure which orientation you were using). If I left click inside the image, it places a new movable point. It did not allow me to place any points outside the image.
One small bug I found was that if you left-click in the image, then drag the mouse pointer outside the image while still holding the left button down, it will place the movable point outside the image and won't display it, displaying a set of coordinates that are not clipped to the axes rectangle.
I'm not sure of what could be your problem. Perhaps it's a bug with whatever MATLAB version you are using. I would suggest either restarting MATLAB, or clearing all variables from the workspace (except for the image data im).
Might be worth checking to see which renderer you are using (Painter or OpenGL), a colleague showed me some wierd behaviour with point picking when using the OpenGL renderer which went away when using the Painter renderer.
Your code uses the Image Processing Toolbox, which I don't have, so this is speculation. The coordinate system is probably set to the figure window (or maybe even the screen), not the image.
To test this, try clicking points outside the image to see if you can find the origin.