mckie@sky.arc.nasa.gov (Bill McKie) (05/26/91)
We have recently installed SunPHIGS 1.3. Apparently, there is still no support for hidden line / hidden surface removal in the cgm output workstation type (phigswstcgmout). E.g., as in SunPHIGS 1.1, we get the following message when trying to do a SET HLHSR MODE on the cgm output workstation. SunPHIGS error 111 in SET HLHSR MODE Ignoring function, the specified HLHSR mode is not available on the specified workstation. HLHSR mode continues to work ok on the phigswsttool workstation type in SunPHIGS 1.3 (although somewhat slowly on our cg6 hardware). We use cgm files as our basic image exchange media, including moving images to other machines, making video tape movies out of frame sequences, and for making hardcopy of the images. It seems strange that we can't generate cgm images which are HLHSR-compatible with those that we can generate on console screens with SunPHIGS. Am I missing something and is there a way to generate cgm files from SunPHIGS with the expected hidden lines/surfaces properly handled? [We don't want to do screen dumps because the resolution is not as good as that for cgm, expecially for generating hardcopy.] Also, does anyone know if Sun will be supporting direct color PostScript output from SunPHIGS soon? We have color PostScript printers, and are currently forced to first create a cgm file from SunPHIGS, then translate cgm to PostScript, then print the PostScript. It would be useful to directly generate color PostScript from SunPHIGS. Thanks, -Bill McKie NASA Ames Research Center mckie@sky.arc.nasa.gov
rthomson@mesa.dsd.es.com (Rich Thomson) (05/28/91)
In article <1991May25.230056.26508@news.arc.nasa.gov> mckie@sky.arc.nasa.gov (Bill McKie) writes: >Apparently, there is still >no support for hidden line / hidden surface removal in the cgm output >workstation type (phigswstcgmout). I don't use SunPHIGS, but from what I read in Appendix H of the PHIGS standard, CGM is 2D and not 3D. I would suspect that this makes it impossible for the workstation to support HLHSR, which is a 3D concept. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
jdonsbac@reverie.Prime.COM (Jeff Donsbach) (05/28/91)
From article <1991May27.185153.29565@dsd.es.com>, by rthomson@mesa.dsd.es.com (Rich Thomson): > In article <1991May25.230056.26508@news.arc.nasa.gov> > mckie@sky.arc.nasa.gov (Bill McKie) writes: >>Apparently, there is still >>no support for hidden line / hidden surface removal in the cgm output >>workstation type (phigswstcgmout). > > I don't use SunPHIGS, but from what I read in Appendix H of the PHIGS > standard, CGM is 2D and not 3D. I would suspect that this makes it > impossible for the workstation to support HLHSR, which is a 3D > concept. Not at all. One of the final transformation in the graphics pipeline is from 3D space to 2D space (ie the screen). The CGM output workstation is just another 2D workstation. It should be possible, although using a Z buffering technique probably wouldn't be. Bill: we asked SUN for the same thing and their answer was "no". This holds true for the latest SunPHIGS 1.4 FCS release and will also be true on the X based SunPHIGS 2.0 as far as we've been told. The people we've talked to at SUN didn't seem to know that much about the CGM workstation. Apparently, this workstation type was written by Precision Visuals for SUN. You could always do your own analytical HLHSR on your trees and construct new trees with your lines and surfaces removed. That's probably not the answer you wanted, but it would probably be faster than waiting for SUN to give you what you want. -Jeff ========================== Jeff Donsbach, Computervision, A Prime Computer Company, Bedford, MA UUCP: {decvax|linus|sun}!cvbnet!jdonsbac | Internet: jdonsbac@cvbnet.prime.com "Hermits have no peer pressure" - Steven Wright
rthomson@mesa.dsd.es.com (Rich Thomson) (05/29/91)
In article <1991May27.185153.29565@dsd.es.com>, rthomson@mesa.dsd.es.com (Rich Thomson) wrote: >> I don't use SunPHIGS, but from what I read in Appendix H of the PHIGS >> standard, CGM is 2D and not 3D. I would suspect that this makes it >> impossible for the workstation to support HLHSR, which is a 3D >> concept. In article <1529@cvbnetPrime.COM> jdonsbac@reverie.Prime.COM (Jeff Donsbach) writes: >Not at all. One of the final transformation in the graphics pipeline >is from 3D space to 2D space (ie the screen). The CGM output workstation >is just another 2D workstation. It should be possible, although using >a Z buffering technique probably wouldn't be. I went back and read the PHIGS standard, and I don't think this is correct. Workstations of type MO (metafile output) are not just another workstation. Section 4.6.1, page 68 of ISO/IEC 9592-1:1988(E) says (my comments in []'s): The categories MO [metafile output] and MI [metafile input] are special facilities for filing graphical information for external storage and exchange. They are treated as workstations for the purposes of control, but otherwise have quite different characteristics (see section 4.9). The mentioned section 4.9 says: [...] For the capture of structure definitions, PHIGS provides an archive file format which enables the contents of the centralized structure store to be captured. Pictures in PHIGS are created by traversal of the centralized structure store. PHIGS provides the MO workstation category to capture pictures generated by the traversal process. The precise way in which this is realized is implementation dependent. Annex H of this part of ISO/IEC 9592 describes a mechanism which enables pictures to be captured in a sensible manner as a CGM metafile. In this case the MO workstation uses display update mode WAIT-NIVE and a picture description is recorded in the metafile when the UPDATE WORKSTATION or REDRAW ALL STRUCTURES functions are invoked by the application program. [...] It is implementation dependent whether some workstation control and inquiry functions are applicable or meaningful for MO and MI workstations. [...] This tells me that although the MO workstation is not just another workstation, it does follow the mechanism of traversal and records 2D pictures. This is why HLHSR has no meaning here -- after traversal, all hidden lines and surfaces are already removed. If you want to maintain HLHSR information in some archived format of the structure, use archive files. -- Rich -- ``Read my MIPS -- no new VAXes!!'' -- George Bush after sniffing freon Disclaimer: I speak for myself, except as noted. UUCP: ...!uunet!dsd.es.com!rthomson Rich Thomson ARPA: rthomson@dsd.es.com PEXt Programmer
tgross@dopey.prime.com (Tom Gross) (05/29/91)
In article <1991May28.194621.13640@dsd.es.com> rthomson@dsd.es.com (Rich Thomson) writes: > >This tells me that although the MO workstation is not just another >workstation, it does follow the mechanism of traversal and records 2D >pictures. This is why HLHSR has no meaning here -- after traversal, >all hidden lines and surfaces are already removed. > So you're saying that CGM files discharged from PHIGS Metafile-Out Workstations should already have hidden lines and surfaces removed? Can we get a ruling on this from the judges? /tom
jdonsbac@reverie.Prime.COM (Jeff Donsbach) (05/30/91)
From article <1991May28.194621.13640@dsd.es.com>, by rthomson@mesa.dsd.es.com (Rich Thomson): > > This tells me that although the MO workstation is not just another > workstation, it does follow the mechanism of traversal and records 2D > pictures. This is why HLHSR has no meaning here -- after traversal, > all hidden lines and surfaces are already removed. > > If you want to maintain HLHSR information in some archived format of > the structure, use archive files. > Rich, If you go back and re-read Bill's original question, he was asking if the SunPHIGS CGM workstation did what you expect it to do - remove hidden lines and surfaces from the 2D picture for plotting purposes. He is not trying to maintain that info. The problem is that the SunPHIGS CGM workstation type does not do hidden line and surface removal. We have asked SUN for this capability but they have not committed to implementing it. -Jeff ========================== Jeff Donsbach, Computervision, A Prime Computer Company, Bedford, MA UUCP: {decvax|linus|sun}!cvbnet!jdonsbac | Internet: jdonsbac@cvbnet.prime.com "Hermits have no peer pressure" - Steven Wright
jch@Stardent.COM (Jan Hardenbergh) (05/31/91)
> So you're saying that CGM files discharged from PHIGS > Metafile-Out Workstations should already have hidden lines > and surfaces removed? > > Can we get a ruling on this from the judges? Thomas, my dear boy, you should know that to get an official clarification on a PHIGS issue one must submit the appropriate forms in triplicate... (It's so much more fun to make fun of them than to help them :-) One of the responsibilities on the PHIGS committee is to clarify things like this. I'm not sure how one submits things to the official ruling queue... While I usually agree with Rich, on this my urge to generalize and simplify would tend to ignore the differences in metafile output workstations. So, yes, if the Metafile-Out Workstation does support HLHSR, which you can inquire with pinq_hlhsr_mode_facs(). That can return error 62, "this information is not available for this MO workstation type". It specifically does not say category, so some MO workstation types will and some will not. But, Thomas, if you don't know how do expect anyone else, too? -- -Jan "YON" Hardenbergh jch@stardent.com (508)-371-9810x261 Stardent Computer, 6 N.E. Tech Center, 521 Virginia Rd,Concord, MA 01742
mckie@sky.arc.nasa.gov (Bill McKie) (06/03/91)
Thanks to all who have contributed to the discussion of hidden line &
hidden surface removal in CGM output using SunPHIGS, which I mentioned
in article 14261 of this newsgroup.
As there has been some variation in what people thought I was talking
about in 14261, and because it still appears to me that something is
lacking in the SunPHIGS handling of CGM output, I'll try to make the
statement of the problem (& why someone might be concerned about it)
clearer here.
As at least one other person has confirmed, there is currently no way
to generate SunPHIGS CGM output files whose images have the hidden
lines and surfaces removed, and there is apparently no clear reason
why this cannot be done.
The desired thing is to get SunPHIGS CGM output that contains images
which look like those we get on the console screen, when we print or
otherwise look at the CGM images. Without this capability, CGM is not
a useful output type when dealing with 3-D images in which it is
intended to have hidden lines and surfaces removed by SunPHIGS, mainly
because the images one sees when printing or otherwise looking at the
CGM files are not similar (with respect to HLHSR) to those one sees on
the console output.
In short, the expected and useful behavior of a SunPHIGS program is
to get a final display which looks very similar whether image output
is directed to the console, or to a CGM which is subsequently displayed
by some means.
Although CGM is a 2-D standard, a CGM should be logically very similar
to a console canvas, which is also 2-D and which displays images from
SunPHIGS with hidden lines and hidden surfaces removed, even when there
is no z-buffer hardware on the console.
E.g. with our Sun GX h/w (which has no z-buffer), I believe the
SunPHIGS HLHSR phase of the graphics pipeline for console output occurs
entirely within the SunPHIGS software. It would seem that this same
kind of thing could be done in the software which handles CGM output,
because HLHSR is in some sense, a part of the final transformations to
the 2-D image. [Ultimately, even 3-D images with hidden lines &
surfaces removed end up as sets of 2-D polyline and 2-D polygon
primitives, both of which CGMs handle.]
CGMs are a nice standard way to store & transmit images for future
viewing & printing, and using CGMs is apparently the only way to
generate high resolution hard copy from SunPHIGS. To get hard copy,
we first run a SunPHIGS program which outputs images onto a CGM, optionally
viewing the images simultaneously on the console workstation. We then
use the gplot program to convert the image(s) in the CGM to color or
B&W PostScript (and sometimes to a variety of other devices and
formats). The PostScript is then printed.
Screen dumps are an alternative route to moving images to a printer,
but they don't carry the same high resolution as do the CGMs, and are
inadequate for many complex images.
One reason we purchased SunPHIGS (it's not cheap) is that it handles
for us the complicated pipeline of graphics transformations that
ultimately end up in a 2-D projection, including HLHSR. It is a
disappointment that the HLHSR part of this pipeline is apparently
available for some SunPHIGS output and not available for others,
especially since the other features of SunPHIGS work so well. (We're
currently using version 1.3)
Can anyone from Sun comment on this problem and how soon we could
expect relief? We've lived with the problem for over a year using
SunPHIGS 1.1. When we upgraded to 1.3, I found that the problem had
not gone away.
Thanks,
-Bill McKie
NASA Ames Research Center
mckie@sky.arc.nasa.govtgross@dopey.prime.com (Tom Gross) (06/04/91)
>> So you're saying that CGM files discharged from PHIGS >> Metafile-Out Workstations should already have hidden lines >> and surfaces removed? >> >> Can we get a ruling on this from the judges? > >Thomas, my dear boy, you should know that to get an official >clarification on a PHIGS issue one must submit the appropriate forms in >triplicate... (It's so much more fun to make fun of them than to help >them :-) > Careful Jan, don't say anything that might offend the members of the Phigs committee; one certainly can't make a career out of adjudicating Phigs issues in email without staying on their good side. Personally, I would prefer to see these questions debated in comp.graphics, but... >One of the responsibilities on the PHIGS committee is to clarify things >like this. I'm not sure how one submits things to the official ruling >queue... > Well for God's sake hurry up and FIND OUT! And while your at it, where can I get copies of the Ansi Phigs spec? And what does Pex stand for anyway? (Is it "PHIGS extension to X" or "Phigs Extension to X-windows"?) Come to think of it, shouldn't it be spelled P.H.I.G.S.? Like, you know, the "Man from U.N.C.L.E."? >While I usually agree with Rich, on this my urge to generalize and >simplify would tend to ignore the differences in metafile output >workstations. So, yes, if the Metafile-Out Workstation does support >HLHSR, which you can inquire with pinq_hlhsr_mode_facs(). > >That can return error 62, "this information is not available for this >MO workstation type". It specifically does not say category, so some >MO workstation types will and some will not. That's what I love about P.H.I.G.S.: an implementation can do anything it wants and still be compliant with the S.T.A.N.D.A.R.D. It certainly paves the way for wide acceptance by hardware vendors. It's a good thing for them that usability was not one of the criteria used in the design of P.H.I.G.S. >But, Thomas, if you don't know how do expect anyone else, too? Of course I have an "informed opinion", but these matters I prefer to leave to the "experts". /tom
del@hpfcdq.HP.COM (David Larson) (06/05/91)
>>> >>> Can we get a ruling on this from the judges? >> >>Thomas, my dear boy, you should know that to get an official >>clarification on a PHIGS issue one must submit the appropriate forms in >>triplicate... (It's so much more fun to make fun of them than to help >>them :-) Triplicate is not really required. However, if it would make you happy to do it that way, go ahead! > > Careful Jan, don't say anything that might offend the members of > the Phigs committee; one certainly can't make a career out of > adjudicating Phigs issues in email without staying on their good > side. Personally, I would prefer to see these questions debated in > comp.graphics, but... Please feel free to debate those questions here. Input from several sources will generally help, not harm, the process. However, remember that the PHIGS committee may not agree with you. If you provide well thought out arguments you have a better chance of getting things "your way". > >>One of the responsibilities on the PHIGS committee is to clarify things >>like this. I'm not sure how one submits things to the official ruling >>queue... That's true, the PHIGS committee does do this -- within ISO since PHIGS is an ISO document. > > Well for God's sake hurry up and FIND OUT! And while your at it, ^^^^ -3 spelling I am the editor for the ISO PHIGS defect processing committee. You can submit defect reports to me either through e-mail (using phigs_defects@hpdel.hp.com) or paper mail Dave Larson Hewlett-Packard Co. 3404 E. Harmony Rd. Ft. Collins, CO 80525 USA I prefer getting reports through e-mail. I will not directly generate an answer or interpretation, but will submit the problem to the editing committee. If your question is a duplicate I'll let you know; if it has been resolved I'll let you know that also. For each defect, please include the following information: 1. References in the document (page and clause numbers) 2. What you believe the problem is 3. What you believe the resolution should be > where can I get copies of the Ansi Phigs spec? And what does Pex Have you tried calling ANSI (212-354-3300)? They sell all of the various ANSI standards... Ask for: ANSI X3.144 or ISO 9592 parts 1,2 and 3 for PHIGS ANSI X3.144.1 or ISO 9593-1 for PHIGS Fortran ANSI X3.144.3 or ISO 9593-3 for PHIGS Ada PHIGS C (ISO 9593-4) should be published this summer. Dave Larson