home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / graphics / 9455 < prev    next >
Encoding:
Internet Message Format  |  1992-09-02  |  2.8 KB
  1. Xref: sparky comp.graphics:9455 comp.windows.x.pex:530 comp.unix.aix:9396
  2. Newsgroups: comp.graphics,comp.windows.x.pex,comp.unix.aix
  3. Path: sparky!uunet!stanford.edu!ames!pacbell.com!well!levine
  4. From: levine@well.sf.ca.us (Ron Levine)
  5. Subject: Re: IBM's graPHIGS package, problem with GPNBS, any hint?
  6. Message-ID: <Bu2BFs.Lzw@well.sf.ca.us>
  7. Summary: graPHIGS uses non-standard NURBS data. 
  8. Keywords: PHIGS, graPHIGS, NURBS 
  9. Sender: news@well.sf.ca.us
  10. Organization: Whole Earth 'Lectronic Link
  11. References: <1484@igd.fhg.de>
  12. Date: Fri, 4 Sep 1992 16:35:51 GMT
  13. Lines: 41
  14.  
  15. In article <1484@igd.fhg.de> pfuetz@igd.fhg.de (Matthias Pfuetzner) writes:
  16. >Hi Everybody!
  17. >
  18. >I have a problem with IBM RS/6000 graPHIGS library and the GPNBS call.
  19. >
  20. >Simply said: The above call inserts the corresponding element into the
  21. >structure store, but I don't see nothing on the screen!
  22. >
  23. >I checked whether the currently open workstation supports non-uniform B-spline
  24. >surfaces (it does), what the maximum order is (6, I only use 2x3 and sometimes
  25. >3x3), so that I'm sure, this primitive is available.
  26. >
  27. >Before inserting the GPNBS I inserted "pfill_area_set3" using the ISO C
  28. >Binding provided under /usr/lpp/graPHIGS/samples/cbinding, so that I can use
  29. >mixed calls for those routines that are currently not supported in ISO C
  30. >Binding form.  This fill_area_set3 is properly drawn, so that I'm sure the
  31. >workstation is opened correctly. The data I supply for the B-spline surface is
  32. >OK, as I am also using libphigs.a (producing PEX calls) on the IBM and on Sun
  33. >workstations with X11R5 by MIT. With these libraries I see my surface!
  34. >
  35. .... stuff deleted...
  36.  
  37. I'm not sure this is your problem, but it's worth checking:
  38.  
  39. I haven't worked directly with graPHIGS, but a couple of years ago, when 
  40. porting a graPHIGS demo application to DEC PHIGS, I discovered that for the 
  41. RATIONAL B-spline case, graPHIGS expects DIFFERENT data from DEC PHIGS, 
  42. SunPHIGS, and most of the other implementations.  Namely, for the coordinate 
  43. 4-tuple for the weighted control points, graPHIGS expects the application to 
  44. pass (x,y,z,w), while the other implementations expect (xw,yw,zw,w). 
  45.  
  46. The PHIGS PLUS DIS Specification document of February 14, 1991 is not 
  47. absolutely clear on the point.  It says simply that "When RATIONAL is 
  48. specified the control points are specified as homogeneous modelling 
  49. coordinates with the restriction that the fourth coordinate be greater than 
  50. zero".  Technically, the graPHIGS implementation does not violate the 
  51. specification, because (x,y,z,w) are indeed homogeneous coordinates for the 3D 
  52. point (x/w,y/w,z/w).  I guess most people would say that the IBM 
  53. interpretation is wrong, but I think it is preferable from the point of view 
  54. of the application, because in most situations it would save the application 
  55. the work of multiplying the 3D coordinates by the weights.
  56.