PHIGS TOOLKIT INFORMATION ** REGISTER NOW **
----------------------------------------------
We would like to encourage all people interested in the PHIGS Toolkit to
register as PHIGS Toolkit users. This will ensure that all PHIGS Toolkit
users will receive notice of new versions, course dates, bug reports and
any other useful information. Please send the following information to
phigstoolkit@cs.man.ac.uk.
Name:
Organisation:
email:
Telephone/FAX:
PHIGS implementations used:
Even if the PHIGS Toolkit is not currently available for your particular
PHIGS implementation, please register. We are currently working on ports to
several other PHIGS implementations and it would be very useful to know
what the demand is for different versions.
HOW TO OBTAIN THE PHIGS TOOLKIT
-------------------------------
The PHIGS Toolkit is available from two sites in the UK:
PTK from Kent
-------------
The PHIGS Toolkit is available from HENSA (Higher Education National
Software Archive) at the University of Kent.
The HENSA Service at the University of Kent can be accessed in a number
of ways:
Interactive
-----------
There is a friendly interactive interface which has a useful find
utility for locating software. Connect to unix.hensa.ac.uk and log
in as "archive" for an interactive interface to the HENSA archive.
Connections can be made using telnet (unix.hensa.ac.uk) and X.29
across JANET (uk.ac.hensa.unix, DTE 000049200900).
anonymous ftp
-------------
Using DARPA FTP connect to the machine unix.hensa.ac.uk and
login as "anonymous", giving your email address as the password.
guest NI-FTP]
Using Blue Book NI-FTP with the following:
address: uk.ac.hensa.unix
login: guest
path: /filename
eg. % fcp -b "/uunet/ls-lR.Z"@uk.ac.hensa.unix ls-lR.Z
User name on uk.ac.hensa.unix? guest
Password on uk.ac.hensa.unix? jn@ukc.ac.uk
email server
------------
Send a message to "archive@unix.hensa.ac.uk" containing the
string "help" for details on how to use it.
Any general queries regarding the HENSA service at The University of
Kent should be directed to hensa@unix.hensa.ac.uk, queries specific to
the Netlib service should be sent to netlib-admin@unix.hensa.ac.uk and
stuff concerning the source archive to archive-admin@unix.hensa.ac.uk.
The relevant files for the PHIGS Toolkit on HENSA are:
PTK 3.2 /misc/unix/phigstk/PhigsToolkit3.2.tar.Z
for SunPHIGS 2.0 on SunOS,
HP PHIGS 2.2 on HP-UX,
graPHIGS 1.02 on AIX,
PEX-SI on SunOS.
PTK 2.0 /misc/unix/phigstk/PhigsToolkit.tar.Z
for SunPHIGS 1.x on SunOS.
/misc/vms/phigstk/ptk.hex for DEC PHIGS 2.3A on VAX/VMS.
PTK from Manchester
-------------------
By anonymous ftp from uk.ac.mcc.hpb. (130.88.200.7)
Username "anonymous", and your network address as password.
The files are:
PTK 3.2 pub/cgu/ptk/ptk3.2.tar.Z for SunPHIGS 2.0 on SunOS,
HP PHIGS 2.2 on HP-UX,
graPHIGS 1.02 on AIX,
PEX-SI on SunOS.
PTK 2.0 pub/cgu/ptk/ptk.tar.Z for SunPHIGS 1.x on SunOS.
pub/cgu/ptk/ptk.shar* for DEC PHIGS 2.3A on VMS.
(
For VMS the Toolkit is stored as a collection of SHAR files.
There are 288 files in total, each 15K in size.
They are called ptk.shar_X where X is 1 ... 288.
To rebuild the Toolkit directory structure the
files must be concatenated together and run as a command file.
$ copy ptk.shar_%, ptk.shar_%%, ptk.shar_%%% ptk.shar
$ @ptk.shar
)
PTK by Magnetic Tape
--------------------
Send a 1/4 inch cartridge for SunOS, and a 1/2 inch open reel magnetic tape
for VMS to:
Tim Hopkins
Computing Laboratory
University of Kent
email: trh@uk.ac.ukc
or
Toby Howard
Department of Computer Science
University of Manchester
Oxford Road
Manchester M13 9PL
United Kingom
Tel: +44 61 275 6274
Fax: +44 61 275 6236
email: toby@uk.ac.man.cs
PHIGS TOOLKIT TRAINING COURSE
-----------------------------
A training course for users of the PHIGS Toolkit was held at the
University of Manchester on September 23rd 1992. Course materials
including four programming exercises and three step-through
tutorials are provided in this release of the Toolkit.
FUTURE WORK
-----------
The first phase of the PHIGS Toolkit does not include support for PHIGS
PLUS. Work is now underway to expand the Toolkit to include extensive
support for PHIGS PLUS functions, and the expanded PHIGS Toolkit will be
released in April 1993.
A toolkit providing support for NURBS curves and surfaces has also
been developed at Manchester, and is designed to be complementary to
the PHIGS Toolkit. It is available from the same sites as PTK.
BETA TEST
---------
We are currently looking for beta testers for the PHIGS PLUS extensions
and the test will start in the new year and finish at the end of February
1993. A short report will be required from testers. Please get in touch
if you are interested in being a tester.
Toby Howard, Terry Hewitt, Gareth Williams, Steve Larkin, David Yip
University of Manchester
Oxford Road, Manchester, M13 9PL, United Kingdom
-----
Subject: 15) Why doesn't HLHSR mode (Z buffering) work with the PEX-SI?
From: Rich Thomson
Date: Mon Mar 28 14:14:49 MST 1994
Sorry, the PEX-SI doesn't have any support for hidden line and hidden
surface removal (HLHSR), commonly implemented through Z buffering.
The PEX-SI team decided that since Z buffering is very device specific
they would leave it up to each vendor to implement Z buffering support
for the first release.
[The PEX-SI (server code) decomposes PEX primitives down to X-level
primitives and draws them via the DDX interface. This allows the
PEX-SI code to work with virtually any X server implementation.
The downside is that certain non-X features like Z buffer operations
and color interpolation of spans is not available. KS]
It is planned to provide software Z buffer HLHSR support in the
PEX-SI, probably in the R6 release.
[There is a patch on contrib that does this. KS]
The PHIGS standard allows an implementation to provide only HLHSR mode
NONE and still be a conformant implementation of the standard. This
is probably a leftover from the days of calligraphic and storage-scope
type displays which don't have Z buffers or other HLHSR removal methods
in hardware (except hardware-based sorting for hidden-line removal).
-- Rich
-----
Subject: 16) printing from PEX
From: kws@fc.hp.com (Karl Schultz)
Date: 4 Aug 1995 14:44:28 GMT
In article <3vl5ev$gn0@euler.space.net>, gero@PROBLEM_WITH_INEWS_DOMAIN_FILE (Gero Dargel) writes:
> Hi,
> can anybody tell me how to print (in better quality than
> screen-dump) from PEX-PHIGS (PEX-SI).
> I'm looking for a mechanism like the CGM-workstation in
> S?N-PHIGS.
In a word, no.
There may be a chance that some vendor has added this as a feature to
their product.
Additional info:
The PHIGS SI doesn't support any sort of hardcopy workstation type.
As noted above, some vendors may have PHIGS-related products that do
this. The PHIGS SI does have some support of "workstation types" in
the area of whether or not PHIGS will create the window for you, or
will accept an existing window to draw into as is convenient with
toolkit applications. This particular control is all implemented in
the PHIGS client-side library, so no real PEX protocol support is
required.
However, for additional workstation type requirements like hardcopy
support where you want the work done in the server someplace, PEX
would need some sort of extension or augmentation to allow the client
to specify what workstation type to use when creating a workstation.
In the PEX Workstation Subset, this might be some sort of list of
supported workstation types to select from, and in the Renderer Subset
of PEX, this concept might be introduced via "renderer classes" that
can be specified when creating a renderer. This might, for example,
allow selection of a ray-tracer to draw a scene, instead of the
usual polygonal renderer. In any case, the PEX protocol today probably
cannot support hardcopy workstation/renderer types and the SI certainly
does not implement anything like it.
Karl Schultz
-----
Subject: 17) Porting from PEX-SI PHIGS to PEXlib
From: Karl Schultz
Here is an account (provided by David Friend) of the experience
of porting a PEX-SI PHIGS application to PEXlib. As always,
your mileage may vary, but you can get some ideas of what is
involved from these notes.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I started by doing the following:
- Stuff involved in making the decision.
- Bought a copy of "PEXlib Programming Manual" by Tom Gaskins.
- Printed out a copy of "PEXlib Specification and C Language
Binding" by Jeff Stevenson. (This is a postscript file that
comes with X11R6. It is for PEX version 5.1. It was written
November 5, 1992. I did not buy the PEXlib reference manual
because every store in town that normally stocked it was out.)
At this point I went through the source code in my program and,
using my PHIGS and PEXlib manuals, replaced each structure type and
function call with the equivalent in PEXlib. (I commented out the
three routines that handle picking, exposures, and the X-Windows to
world coordinates conversion. I did not need these routines immed-
iately.) After fixing errors and warnings generated by the compiler,
and one bug (to be mentioned shortly), I had a working program, barring
the missing sections. In all, it took 30 hours to port the 550 Kbytes
of source code. The picking and exposures took another 7.5 hours.
The XC to WC conversion routine took 7.5 hours; this is the one
point in the entire port that I had to write new code, rather than
do a straight forward conversion.
The one serious bug I had was this. Many of the routines require
that you pass a pointer to the display. You must pass the one
returned by XOpenDisplay(). If you pass one returned by XtDisplay()
you will get an unexplained core dump. Furthermore, some X and Xt
routines that worked fine before with the value returned by XtDisplay()
will now behave incorrectly. Use the value from XOpenDisplay() instead.
(KWS: This is probably some sort of bug; I've written many PEXlib
programs that obtain the Display variable from XtDisplay().)
Completing the port, updating documentation, porting a second
program of similar size, creating installation disks, installing the
code in client sites, etc. will probably result in the port taking a
total of 150 hours.
(KWS: Port was done on Sun equipment - here are some notes:)
- You may use shared library /usr/openwin/lib/libPEX5.so.2 that
comes with Solaris. However, you must provide your own include
files. They may be found in /usr/X11R6/include/X11/PEX5/PEX*.h,
or in xc/lib/PEX5/PEX*.h in the uncompiled source distribution
for X11R6. Almost identical include files are provided with
X11R5 after you have applied the 22 patches.
- If you also use Motif, you may use the shared libraries and
include files found under /usr/dt. Do not use the ones that
come with the Software Development Kit. Programs that are
compiled and linked with the SDK versions will not run unless
the target computer also has the Motif shared libraries that
come with the SDK.
- Always use the Display pointer returned by XOpenDisplay() for
all PEX, Xt and X routines. Don't use the one returned by
XtDisplay(). (Actually, I had two non-PEXlib routines that
insisted on the one returned by XtDisplay(), and would not
work with the one returned by XOpenDisplay().)
- Your LD_LIBRARY_PATH environment variable must point to the
correct shared library directories. Unlike Solaris v1.1.x,
the programs do not appear to know where to look for their
shared libraries. Use command "ldd" to see what shared
libraries your program is looking for.
- My program exercised PHIGS pretty thoroughly. However, it did
not use most of the new features available in PHIGS PLUS. It
did complicated viewport, etc. transformations. It did picking,
handled exposures, grabbed the images from the server after they
were drawn, etc. It used a fake RGB standard colormap, in which
it wrote what every colours it wanted. This kludge ported without
special effort. All of this translated easily into PEXlib,
barring the X-Windows to World coordinates transformation.
- Find below the notes I made while porting that relate directly
to the PEX-SI to PHIGS conversion. They are edited to remove
some of the notes specific to my program.
PEX-SI to PEXlib Porting Notes
Done (in general):
- In Imakefile replace "-lphigs" with "-lPEX5".
- In Imakefile, for Solaris, add -I../R6_PEX5.
- Replace "" with "".
- Replace ppost_struct() and pupd_ws() with PEXRenderNetwork().
- Replace pescape() request to wait for PHIGS update with XSync().
- PEX cannot handle the value returned by XtDisplay(). It must use
the one returned by XOpenDisplay(). Some X and Xt routines have
the same problem. Modify code accordingly.
- Redid main.c:xc_to_wc().
- Redid main.c:RedrawPHIGS().
Done (to initialize system and renderers, etc):
- In main() replace initializing PHIGS with initialzing PEXlib.
- In main() don't tell PHIGS to ignore DC limits.
- Put "PEXRenderer renderer" in TargetType. Initialize to None in main().
- In create_workstation():
- Remove test to see if workstation is open.
Use "Target->renderer != None" in place of "workstation_open".
- Remove closing of PHIGS workstation.
- Replace section opening PHIGS workstation with the equivalent
for opening a PEX renderer.
- Add global values RendererDefaults and RendererDefaultMask.
- Replace pclose_ws() with PEXFreeRenderer().
- Deleted pclose_phigs().
Done (to update colour tables):
- Replace "Pcolr_rep" with "PEXColorSpecifier".
- Use the new member values in Target->ColourMap for read_file()
and scale_image(); ColourMap in read_tiff_image(), write_tiff_image()
and colour_to_bw(); rgb in create_workstation(); and colr in
set_palette().
- In create_workstation() call PEXSetTableEntries() in place of
pset_colr_rep().
- In main() create colour table and colour approximation table.
Initialize the colour approximation table.
- Move initializing colour table from create_workstation() to main().
Done (to update generating structures);
- In main(), when calling PEXInitialize, make sure that the server
supports structures.
- Replace pempty_struct() with PEXDeleteElements().
- Remove all calls to popen_struct() and pclose_struct().
- In main() create the PEX structures.
- In main(), at end, don't call punpost_all_structs(), do delete all
PEX structures.
- Replace pexec_struct() with PEXExecuteStructure().
- Replace pset_line_colr_ind() with PEXSetLineColorIndex().
- Replace "Ppoint3" with "PEXCoord". (The members are the same.)
- Got rid of "Ppoint_list3".
- Replace ppolyline3() with PEXPolyline().
- Replace pset_int_colr_ind() with PEXSetSurfaceColor().
- Replace pfill_area_set3() with PEXFillArea().
- Delete calls to pinq_edit_mode(), pset_edit_mode(), pset_edge_flag()
and pset_linetype(). They were all setting values to the defaults.
- Replace pset_int_style() with PEXSetInteriorStyle().
- Replace pset_linewidth() with PEXSetLineWidth().
- Replace pset_text_colr_ind() with PEXSetTextColor().
- Replace pset_char_ht() with PEXSetCharHeight().
- Replace ptext3() with PEXText().
- Replace pset_text_align() with PEXSetTextAlignment().
Done (to update picking):
- Replace padd_names_set() with PEXAddToNameSet().
- Replace premove_names_set() with PEXRemoveFromNameSet().
- In main() add and initialize a pick filter for the renderer defaults.
- In main(), at end, free the pick filter name set resources.
- Change "Ppick_path_elem" to "PEXPickElementRef". Change members
struct_id, pick_id and elem_pcs to sid, pick_id and offset.
- Change "Ppick_path" to "PEXPickPath". Change members depth and
path_list to count and elements.
- Replace pescape() request to do picking with PEXPickOne().
- Replace pinq_elem_type_size() and pinq_elem_content() with
PEXFetchElements() and PEXDecodeOCs().
Done (to update views):
- Create a separate view table for each PEX renderer.
- Replace pset_view_ind() with PEXSetViewIndex().
- Replace pset_view_rep3() with PEXSetTableEntries().
- Replace pset_ws_vp3() and pset_ws_win3() with PEXChangeRenderer()
with mask = PEXRAViewport | PEXRANPCSubVolume.
- Replacae peval_view_ori_matrix3() with PEXViewOrientationMatrix().
- Replace Pview_rep3 with PEXViewEntry. (The members have changed.)
- Replace peval_view_map_matrix3() with PEXViewMappingMatrix().
Done (to update modelling transformations):
- Replace "Pmatrix3" with "PEXMatrix".
- Replace "Pvec3" with "PEXVector". Change members from delta_x,
delta_y and delta_z to x, y and z.
- Replace ptranslate3() with PEXTranslate().
- Replace pscale3() with PEXScale().
- Replace protate_x() and protate_y() with PEXRotate().
- Repalce pcompose_matrix3() with PEXMatrixMult().
- Replace pset_local_tran3() with PEXSetLocalTransform().
- Replace ptran_point3() with PEXTransformPoints().
-----
Subject: 18) Using PHIGS with PEX servers w/o the Workstation Subset
From: Karl Schultz
Some PEX vendors (HP, and now Sun) do not support the PHIGS
Workstation Subset in their PEX servers. Is it still possible
to use the PEX-SI PHIGS API with these servers?
The answer is YES, if you set the right environment variable.
The environment variable is PEX_SI_API_CLIENT_SS.
If you set it to a non-zero value, the PHIGS API will not use the
PHIGS workstation subset in the PEX server and send the data in
immediate mode to the server.
Note that this has obvious performance implications if you are
running your application over a network, but if running locally,
the difference may not be noticable.
-----
Subject: 19) OReilly's Program! (BadMatch error in first.c)
From: kws@fc.hp.com (Karl Schultz)
Date: 1 Dec 1995 01:42:57 GMT
Organization: Hewlett-Packard Fort Collins Site
Lines: 59
Message-ID: <49lmj1$lfa@fcnews.fc.hp.com>
References: <49l2jv$37d@ef2007.efhd.ford.com>
NNTP-Posting-Host: manfred.fc.hp.com
In article <49l2jv$37d@ef2007.efhd.ford.com>, nramabad@pt0308.pto.ford.com (Narayanan Ramabadran (R)) writes:
>
> Hi Everyone!
> I know i have been bugging some of you these past few days as to try and
> figure out why my "first.c" was not working on the sun solaris.
> I have figured out what the problem is.......
Maybe I'll add this to the FAQ.
> Here goes:
> the rest of the programs use the functions given is "book_utils.c" where
> there is no bug... On the other hand, in the "first.c" the function call
> to XCreateWindow misses one of the parameters (in the calling function!).
> To be specific, the "CWBorderPixel" is missing... I added this and BINGO!
> it works fine..... i am feeling sick that i have been scratching my heaD
> over this for the last week or so!!!
If anyone wants to understand WHY, please read:
In the failing environment, Sun, in this case, the example program was
apparently trying to create a window that was of different (deeper) depth
than the parent. This is fairly common on servers that support both
8 and say, 24 bit deep visuals. The root window is usually 8 bit
and X clients can create 24-bit deep windows if they want.
When a client creates a window, the window usually inherits all its attributes
from the parent, unless they are overridden by parameters and supplied
window attrubutes. In this case, the 24-bit window tried to inherit
the 8-bit parent's BorderPixel attribute. A pixel for an 8-bit drawable
cannot be logically converted for use in a 24-bit drawable, so this
attribute MUST be supplied/overriden when creating a window of different
depth than its parent.
This is a very common error that traps a lot of people.
> But with the same error, it works from the IBM RS/6000...
Probably because the IBM machine didn't support visuals of more than
one depth.
> Karl: thanks for the mail you sent me.. i was trying to figure out what
> the border and background pixel values were (as per your advice) and that's
> when i noticed this!!!!!
I sent that to you because that is what I thought was causing the problem! :-)
> the book (pexlib prog. manual) also has the error... (i think its an error,
> but if it's not, please correct me)..
Yeah, technically it probably is an error.
The book_utils are probably more robust than the same type of code in
first.c. The first.c program was trying to get folks started without
a lot of other distractions. It is also possible that the bug was
discovered and fixed by somebody who didn't realize that first.c did not
include book_utils, so they assumed that fixing book_utils would fix the
entire set, which was *almost* a correct assumption.
Note that the problem is not strictly related to PEX. You can get in the
same hole with an Xlib application.
