Graphics Problems
Graphics problems
Problems with X_Windows addresses over a network
The X_Windows protocol makes a distinction between the process running the computer programme, the "client", and that displaying the graphics, the "server". This is to enable a software package to operate in the same way whether it is running on the local machine, or on a remote machine over a network.
Where client and server are the same machine then no confusion arises since there is no ambiguity about where graphics should be displayed. However when you are displaying results over a network from a remote client you may get the message:
Unable to open display :0
This means that the host machine must be told where to display graphics. On UNIX machines you do this by setting the DISPLAY environment variable as follows:
| C shell: | setenv DISPLAY <server>:0 |
| Bourne shell: | DISPLAY=<server>:0 export DISPLAY |
Where <server> is the network address of the machine on which you are displaying the graphics. A raw address (eg 69.60.10.1 ) may always be used or, if the host machine knows about your server, you can use the machine's name.
Multiple screens : The " :0 " is the screen id on that machine, and this will almost always be screen zero as here. The exception is when you have multiple screens attached to a device, in which case the syntax will become " :0.0 " for the first screen, " :0.1 " for the second screen, and so on.
Therefore typical destination commands might be:
| setenv DISPLAY snoopy:0 |
(Machine "snoopy", screen 0) |
| setenv DISPLAY 69.23.15.2:0 | (Address 69.23.15.2, screen 0) |
| setenv DISPLAY :0.1 | (This machine, screen 1) |
( nb: On UNIX machines see the file /etc/hosts for host names and internet addresses. You will only be able to refer by name to machines in this file. However you can display on any machine by referring directly to its numeric address: the names in this file are just convenient aliases for this.)
Problems when the server refuses a connection
A further complication may arise due to permission not being granted for that host to connect to your server. This will generate the message:
Host is not permitted to connect to server
In this case you must also tell your server to accept graphics from the host with the command:
xhost + <hostname>
If you omit <hostname> then access will be permitted to all hosts. Your system manager can configure your system such that access is permanently permitted to a selected list of hosts, or indeed all hosts. The latter (all hosts) is potential security hole since the inter-client communication permitted by X window managers is a possible back door for hackers. Network users: you have been warned!
Screen-picking selects invisible entities
Because hidden surface removal is performed in the hardware Z-buffer it is difficult for the client D3PLOT process to know what is and is not visible in a hidden or shaded plot. The picking algorithms attempt to work this out, but occasionally they make mistakes.
There is no absolute cure for this, but suggestions are: reject the pick, rotate the image a touch, and try again as this may make the selection of the visible element less ambiguous. Or maybe just try again taking more care to pick the centre of the item you want.
The image disappears altogether
This can happen for a variety of reasons:
| Z-clipping | It is possible to rotate, translate or scale an image such that it passes totally outside the screen Z clipping region. Try resetting these planes: ( , ). Turn the projection box ( , switch) on to see the view frustrum and clipping plane locations. |
| Bad matrix | The hardware rotation matrix can sometimes get corrupted if a very large number of screen rotations give rise to progressive ill-conditioning: (ie direction cosines no longer have unit length). In this case reset the matrix with the command (reset to default viewing state). |
There can also be less obscure reasons: see "The terminal won't draw anything" in General graphics problems .
Hidden-line quality is poor
This is a limitation of Z-buffered graphics. The problem arises because hidden-line plots are generated by drawing visible borders around black polygons, and sometimes the Z coordinates of the polygon win, and sometimes those of the line win, resulting in a broken line. The breaks will move as the image is rotated. D3PLOT attempts to get round this by raising the lines slightly above the polygon surface, but this doesn't work very well when polygons are near edge-on to the viewer.
You can adjust the amount by which the polygon borders are lifted above the surface by holding down the < left control > button and the < left mouse button >. Moving the mouse up the screen will lift lines off the surface towards you, moving it down will move them back down.
Animations become horrendously slow.
Storing animations can use large amounts of memory. This means that you run your machine out of memory much faster and the slowdown is due to it "paging" memory to and from disk.
Unless you are prepared to buy more memory the only thing you can do is to reduce the memory being used by one or more of:
|