home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 8 / CDASC08.ISO / NEWS / RADIANCE / DOC / RADIANCE.V21 < prev    next >
Text File  |  1993-10-07  |  58KB  |  1,529 lines
  1. ~s Radiance Digest, v2n1
  2. Dear Radiance Users,
  3.  
  4. Here once again we have a culling of e-mail exchanges to share.
  5. I hope by now that most of you have picked up version 2.0 of the
  6. program, which seems mostly stable except for one or two minor
  7. glitches.  Please check also the previous digest, v2n0, if you
  8. have not seen it already.  As always, back issues of the digest
  9. are available via anonymous ftp from hobbes.lbl.gov (128.3.12.38)
  10. in the pub/digest directory.
  11.  
  12. Here is a table of contents that you can use for finding the
  13. sections you are interested in.  Use the search string /^==*$/
  14. to skip to the next section.
  15.  
  16.     BUG        - A memory bug in rpict
  17.     DAYLIGHT    - Daylight Scripts and TIM's
  18.     ALIASING    - Anti-aliasing in Radiance (again?)
  19.     LANGUAGE    - Radiance input language definitions
  20.     NEXT        - Radiance compilation on the NeXT
  21.  
  22. By the way, if anyone has need of some first rate consulting or training
  23. on Radiance, I have someone I can recommend (besides myself!).
  24.  
  25. -Greg
  26.  
  27. ===========================================================
  28. BUG        - A memory bug in rpict
  29.  
  30. Date: Wed, 11 Dec 91 00:59:10 MED
  31. From: bojsen@moria (Per Bojsen)
  32. To: greg@hobbes.lbl.gov
  33. Subject: Bug in rpict (rpict.c)?
  34.  
  35. Hi Greg,
  36.  
  37. [I'm the guy working on the Amiga port of Radiance if you don't remember me.]
  38.  
  39. A couple of weeks ago I picked up Radiance 2.0, and now have a working port.
  40. I think I may have discovered a bug in rpict, specifically the rpict.c
  41. module, though.  Rpict crashes when run with anything other than `-sp 1'.
  42. Rpict overwrites (or rather underwrites ;-) memory just before a malloc()'d
  43. buffer.  The amount of bytes overwritten is proportinal to the `-sp'
  44. setting.  On the Amiga such overwriting is nasty because the free memory
  45. list will be mangled.
  46.  
  47. I snooped around in the source a bit to find something that depends on
  48. `-sp', i.e., the psample variable.  I found something in the
  49. fillscanline() routine that may be the cause of the bug.  Take a look
  50. on fillscanline():
  51.  
  52. fillscanline(scanline, zline, sd, xres, y, xstep)       /* fill scan at y */
  53. register COLOR  *scanline;
  54. register float  *zline;
  55. register char  *sd;
  56. int  xres, y, xstep;
  57. {
  58.         static int  nc = 0;             /* number of calls */
  59.         int  bl = xstep, b = xstep;
  60.         double  z;
  61.         register int  i;
  62.  
  63.         z = pixvalue(scanline[0], 0, y);
  64.         if (zline) zline[0] = z;
  65.                                 /* zig-zag start for quincunx pattern */
  66.         for (i = ++nc & 1 ? xstep : xstep/2; i < xres-1+xstep; i += xstep) {
  67.                                    ^^^^^^^^^
  68.                 if (i >= xres) {
  69.                         xstep += xres-1-i;
  70.                         i = xres-1;
  71.                 }
  72.                 z = pixvalue(scanline[i], i, y);
  73.                 if (zline) zline[i] = z;
  74.                 if (sd) b = sd[0] > sd[1] ? sd[0] : sd[1];
  75.                 b = fillsample(scanline+i-xstep, zline ? zline+i-xstep : NULL,
  76.                                ^^^^^^^^^^^^^^^^
  77.                                 i-xstep, y, xstep, 0, b/2);
  78.                 if (sd) *sd++ = nc & 1 ? bl : b;
  79.                 bl = b;
  80.         }
  81.         if (sd && nc & 1) *sd = bl;
  82. }
  83.  
  84. Now, every other call of fillscanline() will have `i' start with xstep/2
  85. in the for loop.  In the call to fillsample() the first parameter is
  86. `scanline + i - xstep', i.e., `scanline - xstep/2' (xstep is even, if xstep
  87. is odd it will be `scanline - xstep/2 - 1', I think).  If xstep is greater
  88. than 2 (it is 6 for -sp 4), the pointer represented by `scanline + i - xstep'
  89. will point to some memory (on reasonable systems, anyway) before the scanline
  90. array.  If the fillsample() routine writes to colline[0], for example,
  91. we have found a bug.
  92.  
  93. Could you try to look into this and confirm if its indeed a bug?  I'll
  94. try to change some things to see if my problem goes away.
  95.  
  96. Thanks for making your work available!
  97.  
  98. --
  99. "There had been something loose about the          // Greetings from Per Bojsen
  100.  station dock all morning, skulking in            //
  101.  amongst the gantries and the lines and the    \\//   cbmehq!lenler!bojsen
  102.  canisters which were waiting to be moved ..."  \/    pb@id.dth.dk
  103.  
  104. Date: Wed, 11 Dec 91 01:15:06 MED
  105. From: bojsen@moria (Per Bojsen)
  106. To: greg@hobbes.lbl.gov
  107. Subject: Bug in rpict.c fillscanline()
  108.  
  109. I just tried a simple thing:  I malloc()'d a somewhat larger buffers for
  110. the scanlines and pointed the scanbar[] pointers into these larger buffers
  111. to allow for the overwrite of the memory before the buffer.  This made
  112. the symptom of the bug go away (no crash).  So I'm pretty certain that
  113. what I described in my previous mail must be a bug.  The question is:
  114. how do I fix it?
  115.  
  116. --
  117. "There had been something loose about the          // Greetings from Per Bojsen
  118.  station dock all morning, skulking in            //
  119.  amongst the gantries and the lines and the    \\//   cbmehq!lenler!bojsen
  120.  canisters which were waiting to be moved ..."  \/    pb@id.dth.dk
  121.  
  122. From greg Tue Dec 10 17:48:15 1991
  123. Return-Path: <greg>
  124. Date: Tue, 10 Dec 91 17:48:12 PST
  125. From: greg (Gregory J. Ward)
  126. To: bojsen@moria
  127. Subject: Re:  Bug in rpict (rpict.c)?
  128. Status: RO
  129.  
  130. Hi Per,
  131.  
  132. Of course I remember you.  There aren't many people with your kind of nerve,
  133. going where no programmer has gone before and all that.
  134.  
  135. You have indeed found a bug.  A bit of stupidity on my part after the last
  136. so-called "enhancement" to my sampling code.  I guess it doesn't show up on
  137. most machines (including mine) because the memory doesn't get freed until
  138. after the program is done.  Anyway, here is the routine returned to its
  139. original intent, and thanks for your thorough analysis of the problem!!
  140.  
  141. -Greg
  142. -----------------
  143.  
  144. ------- rpict.c -------
  145. 4c4
  146. < static char SCCSid[] = "%Z%%M% %I% %G% LBL";
  147. ---
  148. > static char SCCSid[] = "@(#)rpict.c 2.3 12/10/91 LBL";
  149. 280,281c280,285
  150. <         b = fillsample(scanline+i-xstep, zline ? zline+i-xstep : NULL,
  151. <                 i-xstep, y, xstep, 0, b/2);
  152. ---
  153. >         if (i <= xstep)
  154. >             b = fillsample(scanline, zline, 0, y, i, 0, b/2);
  155. >         else
  156. >             b = fillsample(scanline+i-xstep,
  157. >                     zline ? zline+i-xstep : NULL,
  158. >                     i-xstep, y, xstep, 0, b/2);
  159.  
  160. From bojsen@dc.dth.dk Thu Dec 12 06:13:23 1991
  161. Return-Path: <bojsen@dc.dth.dk>
  162. Date: Thu, 12 Dec 91 15:12:01 +0100
  163. From: bojsen@dc.dth.dk (Per Bojsen)
  164. To: greg@hobbes.lbl.gov
  165. Subject: bug and fix
  166. Status: RO
  167.  
  168. Hi Greg.
  169.  
  170. I've incorporated the bug fix now and it works like a charm!  Thanks
  171. for acting so promptly.
  172.  
  173. A question regarding your special malloc() implementation.  Do you
  174. depend on the memory added by subsequent sbrk() calls to be contiguous
  175. with the already allocated memory?  The problem is that the sbrk()
  176. that comes with the SAS/C compiler is *not* compatible with UNIX in
  177. that regard (an can never be due to the way memory allocation works on
  178. the Amiga);  every time sbrk() is called you get a new memory block
  179. that is uncontiguous with the rest.
  180.  
  181. Your malloc() does seem to work, though.  I just want to be sure
  182. there's no hidden danger.
  183.  
  184. --------------------------------------------------------------------------------
  185. Per Bojsen                The VLSI Research Group        EMail: bojsen@dc.dth.dk
  186. MoDAG                 Technical University of Denmark
  187. --------------------------------------------------------------------------------
  188.  
  189. From greg Thu Dec 12 09:46:09 1991
  190. Return-Path: <greg>
  191. Date: Thu, 12 Dec 91 09:45:59 PST
  192. From: greg (Gregory J. Ward)
  193. To: bojsen@dc.dth.dk
  194. Subject: Re:  bug and fix
  195. Status: RO
  196.  
  197. Hi Per,
  198.  
  199. My malloc does indeed work better if sbrk() returns contiguous blocks of
  200. memory, but it does not depend on it.
  201.  
  202. -Greg
  203.  
  204. ==============================================================
  205. DAYLIGHT    - Daylight Scripts and TIM's
  206.  
  207. [TIM stands for Transparent Insulation Materials -- if you don't know
  208. what it is than you probably wouldn't care. -G]
  209.  
  210. Date: Wed, 11 Dec 91 13:59:32 PST
  211. From: greg (Gregory J. Ward)
  212. To: apian@ise.fhg.de
  213. Subject: RE: Questions
  214.  
  215. Hi Peter,
  216.  
  217. > Modelling rooms with TIM windows looks very promising and take most
  218. > of my time beside end-of-year paperwork etc.
  219.  
  220. Raphael Compagnon recently started looking at these, and I tried to
  221. help him out with the BRDF description of a certain kind of TIM,
  222. the kind made up of many closely packed plastic cells aligned
  223. perpendicular to the window surface.  Here is the .cal file I made:
  224.  
  225. --------------------------------
  226. {
  227.     Calculate BRTDF of Transparent Insulation Materials
  228.     made up of many small tubes packed tightly together.
  229.  
  230.     29 Nov 1991    Greg Ward and Raphael Compagnon
  231.  
  232.     Apply with following BRTDfunc:
  233.  
  234.     mod BRTDfunc tim1
  235.     10    0    0    0
  236.         stran    stran    stran
  237.         brtdf    brtdf    brtdf
  238.         tim1.cal
  239.     0
  240.     7 0 0 0 R T 1 K
  241.  
  242.     where:
  243.         R = diffuse reflectance when Ktan_t is zero
  244.         T = total transmittance divided by (1-R)
  245.         K = ratio of tube length to diameter
  246. }
  247.  
  248. Ktan_t = A7 * Sqrt(1-Rdot*Rdot)/Rdot;
  249.  
  250. stran = if(1-Ktan_t, 2/PI*Acos(Ktan_t) - Ktan_t/PI*Sqrt(1-Ktan_t*Ktan_t), 0);
  251.  
  252. brtdf(lx,ly,lz) = (1-stran)/PI;
  253.  
  254. -------------------------------------
  255.  
  256. You might like to ask Raphael how it's going.  His e-mail is
  257. compagnon@eldp.epfl.ch.
  258.  
  259. > If you like, an user-id at ISE would be no problem at all.
  260. > e.g., I found access to man pages of other machines is fine sometimes.
  261.  
  262. Sure, when you get time could you do this for me?  Also, give me some
  263. details and a model so I can reproduce the error you got from readfargs.
  264.  
  265. > I've got a question, I don't dare to ask, because it shines bright
  266. > light on my ignorance:
  267. > -ad N     is the number of random rays sent out into the hemisphere to
  268. >         look for light coming from other surfaces
  269. > -as N    if two of these rays differ, N other rays are sent in the
  270. >         directions between them
  271. > -ar and -aa specify what happens when one of these rays hit an area
  272. >         on a surface where there are to ambient values (yet).
  273. >        Either this initiates a new hemisphere sampling or the value
  274. >        is interpolated by using other ambient values on that the    
  275. >        surface. -aa spicifies the threshold when a new hemisphere
  276. >        sampling is started. 
  277. > As for the moment, am I totally lost or somehow on the right track ?
  278.  
  279. It seems that you understand it pretty well to me.  I would add the following:
  280.  
  281. -ad N     is the number of INITIAL rays sent out into the hemisphere to
  282.     look for light coming from other surfaces
  283. -as N    is the number of ADDITIONAL rays sent out to reduce variance
  284.     in the initial hemisphere sample, based on the assumption that the
  285.     initial sample captured all significant intensity gradients
  286. -ar and -aa specify what happens when one of these rays hit an area
  287.     on a surface where there are to ambient values (yet).
  288.     Either this initiates a new hemisphere sampling or the value
  289.     is interpolated by using other ambient values on that the    
  290.     surface. -aa specifies the threshold when a new hemisphere
  291.     sampling is started.  -ar specifies a maximum resolution, past
  292.     which the -aa value will start to be relaxed.  The resolution
  293.     is computed by the global cube size (as determined by oconv
  294.     and displayed by getinfo -d on the octree) divided by the
  295.     -ar parameter.
  296.  
  297. -Greg
  298.  
  299. From: Environmental Design Unit <edu@leicester-poly.ac.uk>
  300. Date: Tue, 10 Dec 91 15:18:30 GMT
  301. To: ray@hobbes.lbl.gov
  302.  
  303. Hi Greg,
  304.  
  305. I thought i'd get back to you about the daylight factor
  306. scripts.  For comparison purposes, contour lines are
  307. preferable to bands.  However, when I switch from one to the
  308. other, the lines appear to be mid-way between the bands.  I
  309. would have expected the line to overlap the band (or be it's
  310. leading edge) - also the legend arrangement is different.  It does
  311. look like one scheme is giving the mid-way values of the other.  It's
  312. a small point but I would like to clear it up before I start to compare
  313. results with other programs.  The modification to dayfact to allow
  314. user fixed contour levels works fine - but ... it's still not
  315. ideal.  Is their a way around having fixed increment scaling,
  316. i.e. 1,3,5,7,9, and so on?  Levels of 1,2,4,6,10,15,20 etc. would
  317. be better.
  318.  
  319. More generally, is v2.0 different in any way from the beta release
  320. I obtained from you?  Also, could you briefly explain the changes
  321. to the source function for windows?
  322.  
  323. Did you get the OpenWindows file-manager mods for RADIANCE, I hadn't
  324. actually e-mailed a tar file before (or since) so I just sent it off
  325. as normal mail, hoping that's how it is done.
  326.  
  327. Hope all is well,
  328.  
  329. -John
  330.  
  331. Date: Thu, 12 Dec 91 10:05:17 PST
  332. From: greg (Gregory J. Ward)
  333. To: edu@leicester-poly.ac.uk
  334. Subject: Re:  RADIANCE
  335.  
  336. Hi John,
  337.  
  338. Yes, the contour lines do appear midway between values rather than at
  339. those values like the bands.  Currently, there is no way to specify
  340. exact contour levels an irregular intervals using this script.  I would
  341. have to rewrite it significantly, which I may do when I find some time.
  342. In the meantime, I would like you at least to have the latest version
  343. of the dayfact script.  I made some changes following release 2.0 to
  344. correct an error in the illuminance contour calculation and add a new
  345. ability to calculate daylight savings.
  346.  
  347. Unfortunately, I do not remember exactly when I gave you the beta copy
  348. so I don't know how much I changed since then.
  349.  
  350. I did get the OpenWindows modifications you sent me, and thank you.  Did
  351. you not receive the latest Radiance Digest?  In it I included your mods
  352. for other OpenWindows users.
  353.  
  354. -Greg
  355.  
  356. From: Environmental Design Unit <edu@leicester-poly.ac.uk>
  357. Date: Mon, 16 Dec 91 11:25:24 GMT
  358. To: greg@hobbes.lbl.gov
  359. Subject: Radiance
  360.  
  361. Greg,
  362.  
  363. Thanks for the reply.  I sort of guessed that mods to
  364. dayfact would not be trivial.  Yes I did get the digest
  365. with my OpenWindows stuff, but it did look garbled.  Changing
  366. the subject altogether, is RayShade a shading analysis program?
  367. We have on occasion used a heliodon to give shading info for
  368. our thermal analysis work - despite the complexity of current
  369. 'state of the art' programs, the treatment given to sun-patching
  370. is still rather simplistic and best results are obtained if the
  371. user tweaks the input a bit.  What has this to do with Radiance?
  372. Well, must confess, I used your program in a rather trivial mode
  373. to look at the shading effectiveness of bridge structures in
  374. a proposed atrium design.  What surprised me was how quickly I
  375. could generate an adequate description with a load of genbox
  376. and xform commands and a bit of vi'ing.  A couple of simple
  377. shell-scripts to generate the oct and pic files and Bingo!
  378. I admit, it's a bit like using a CRAY to work out the grocery
  379. bill, but it's quick and simple.  In fact, i'd be amazed to
  380. find a program which does it more efficiently - a PC based
  381. commercial package we have provides no contest.  I know this
  382. is very much a side issue but I thought i'd let you know anyway.
  383.  
  384. Regards,
  385.  
  386. -John
  387.  
  388. P.S.  As you've no doubt guessed my daylighting project has been
  389. put back yet another month by other work commitments.
  390.  
  391. Date: Tue, 17 Dec 91 09:46:41 PST
  392. From: greg (Gregory J. Ward)
  393. To: edu@leicester-poly.ac.uk
  394.  
  395. Hi John,
  396.  
  397. Yes, I think the OpenWindows stuff you sent may have been garbled.  I
  398. couldn't tell myself because I didn't know what it was supposed to look
  399. like!  I suggest creating a compressed tar file and uploading it to
  400. the pub/libraries directory on hobbes.lbl.gov (128.3.12.38) by anonymous
  401. ftp.  The libraries directory is exactly right, but I don't have one that
  402. is so it will have to do.
  403.  
  404. I am glad that you had some success using Radiance for your shadowing
  405. calculation.  I agree that most of the work is getting the geometry
  406. right.  I have used vi, xform and genbox (and gensurf, genprism, etc.)
  407. to create my models for many years now.  I still don't use a CAD system,
  408. for better or worse.
  409.  
  410. RayShade was not made specifically for shadow calculation, although it
  411. probably does it just as well as Radiance.  I don't think you get a
  412. solar position program like gensky or anything like genbox, but RayShade
  413. does provide a few more surface primitive types.  I should stop talking
  414. about it, though, since I really don't know that much about the software.
  415.  
  416. -Greg
  417.  
  418. =======================================================
  419. ALIASING    - Anti-aliasing in Radiance (again?)
  420.  
  421. From: Paul Douglas <douglas@ctr.columbia.edu>
  422. Date: Thu, 9 Jan 92 13:30:47 EST
  423. To: greg@hobbes.lbl.gov
  424. Subject: Aliasing 
  425.  
  426. Hi Greg,
  427. You probably don't remember, but we communicated early last year.  I was
  428. hoping to use radiance to produce a vidoe sequence and you kindly sent me
  429. ready-made letters and numbers.  Well, the project was shelved, but now it
  430. looks like its on again, so I have a question.  
  431.  
  432. When I use rpict to generate the radiance image and then convert to a 
  433. sunraster image diagonal edges are jagged.  Pfilt seems not able to reduce
  434. this type of aliasing, but I'm guessing that it can be reduced by changing
  435. the pixel size, although I'm not sure how.  Can you offer any quick suggestions
  436. that will reduce the roughness of the object edges??
  437.  
  438. Thanks much
  439. Paul
  440.  
  441. Date: Thu, 9 Jan 92 11:02:19 PST
  442. From: greg (Gregory J. Ward)
  443. To: douglas@ctr.columbia.edu
  444. Subject: Re:  Aliasing
  445.  
  446. Hi Paul,
  447.  
  448. The anti-aliasing approach taken in Radiance is a little different from
  449. other raytracers inasmuch that you must combine rpict with pfilt in order
  450. to arrive at the desired result.  This is done by specifying an initial
  451. picture resolution for rpict a few times greater than what you want in
  452. the final image, then using pfilt to reduce it down.  This implements
  453. anti-aliasing by oversampling, which is the most effective approach
  454. for ray tracing.
  455.  
  456. For example, you might use the following commands to get a 512x512 
  457. anti-aliased image:
  458.  
  459.     % rpict -x 1024 -y 1024 -vf scene.vp scene.oct > scene.u.pic
  460.     % pfilt -x /2 -y /2 scene.u.pic > scene.f.pic
  461.  
  462. This would produce a reasonably anti-aliased image in a minimum of time.
  463. To get a really fine image, you can increase your sampling rate and use
  464. the Gaussian filter option of pfilt, like so:
  465.  
  466.     % rpict -x 1536 -y 1536 -vf scene.vp scene.oct > scene.u.pic
  467.     % pfilt -x /3 -y /3 -r .67 scene.u.pic > scene.f.pic
  468.  
  469. I hope this helps.
  470. -Greg
  471.  
  472. ======================================================
  473. LANGUAGE    - Radiance input language definitions
  474.  
  475. Date: Mon, 9 Dec 91 15:13:28 -0800
  476. From: mcancill@denali.csc.calpoly.edu (Mike Cancilla)
  477. To: GJWard@Csa2.lbl.gov
  478. Subject: Radiance Language BNF...
  479.  
  480. Hi,
  481.     I've been using Radiance for about 1.5 months now, and
  482. I think it's really nice.  I've still got to ftp 2.0 though.
  483.  
  484. I'm a graduate student here at Cal Poly, and I'm currently in
  485. a graduate languages class.  My final paper consists of a
  486. comparison of 3 ray tracing languages, namely the Radiance
  487. language, the language for DKB trace, and an in-house raytracing
  488. language.
  489.  
  490.     I was wondering if I could get the BNF specs for the
  491. Radiance language?  Any other info you might deem as helpful would
  492. also be helpful.  I'll send you a plain text copy of the report
  493. if you want it.
  494.  
  495.     The report will probably use three different languages to
  496. do the same scene, and make a comparison based on ease and features.
  497. A technical description of each language, such as sytax and semantics
  498. will also be given.  I will also focus on any looping structures, 
  499. math functions, texture availability, and animation features the
  500. language may have.
  501.  
  502. Any help would be greatly appreciated.
  503.  
  504. Thanks,
  505.  
  506. Mike
  507.  
  508. Date: Mon, 9 Dec 91 20:08:26 PST
  509. From: greg (Gregory J. Ward)
  510. To: mcancill@denali.csc.calpoly.edu
  511. Subject: Re:  Radiance Language BNF...
  512.  
  513. Hi Mike,
  514.  
  515. Excuse my ignorance, but what's a BNF?  Personally, I would hesitate even
  516. to call the input format of Radiance a language!  The only reference I
  517. can offer is in ray/doc/ray.1 of the standard distribution.  I can send
  518. you a PostScript version if you haven't got it already.  Version 2.0 
  519. does contain a few new BRDF material types, but other than that, the
  520. input language looks pretty much the same as 1.4.
  521.  
  522. I would say that most of the sophistication of the Radiance scene description
  523. is external, contained in the various object generators and auxiliary files
  524. available.  The function files in particular use a Turing-equivalent
  525. expression language that provides recursive functions as its prime mode
  526. of programming as well as access to an extensive math library.
  527.  
  528. If you give me some more details of what you want, or suggestions on how
  529. to go about describing a particular scene, I'd be happy to help.
  530.  
  531. -Greg
  532.  
  533. Date: Thu, 12 Dec 91 01:55:21 -0800
  534. From: mcancill@denali.csc.calpoly.edu (Mike Cancilla)
  535. To: greg@hobbes.lbl.gov
  536. Subject: Re:  Radiance Language BNF...
  537.  
  538. Hi Greg,
  539.  
  540.     I mailed you a few days ago regarding a BNF for the Radiance scene
  541. description language.  BNF stands for Backus-Naur (sp) Form.  Its a
  542. way of describing the syntax of programming languages.  The YACC utility,
  543. or BISON if you're of the GNU flavor, takes a BNF description of a language
  544. and anonyzes the syntax of an input file written the target language.
  545.  
  546. Here's a BNF description for a Raytracing mini-language I wrote for
  547. a class project, it's taken from an actual YACC input file:
  548.  
  549. %%
  550.  
  551. program:    open_stmt decls stmt close_stmt
  552.         ;
  553.  
  554. decls:        /* nothing */
  555.         | decls YOBJ_TYPE YOBJ_VAR ';'
  556.         | decls YFLOAT YNUM_VAR ';'
  557.         ;
  558.  
  559. open_stmt:    YOPEN_SCENE ';'
  560.         ;
  561.  
  562. close_stmt:    YCLOSE_SCENE ';'
  563.         ;
  564.  
  565. stmt:        /* nothing */
  566.         | stmt render_stmt
  567.         | stmt do_loop
  568.         | stmt assign
  569.         | stmt foreach
  570.         | stmt move
  571.         | stmt specularity
  572.         | stmt reflectivity
  573.         | stmt ambient
  574.         | stmt color
  575.         ;
  576.  
  577. render_stmt:    YRENDER_SCENE ';'
  578.         ;
  579.  
  580. do_loop:    YDO expr YTIMES '{' stmt '}'
  581.         ;
  582.  
  583. assign:        YNUM_VAR '=' expr ';'
  584.         ;
  585.  
  586. foreach:    YFOREACH YOBJ_TYPE '{' stmt '}'
  587.         ;
  588.  
  589. move:        YMOVE YOBJ_VAR YTO expr ',' expr ',' expr ';'
  590.         | YMOVE YIT YTO expr ',' expr ',' expr ';'
  591.         ;
  592.  
  593. specularity:    YSPEC YOF YOBJ_VAR YIS expr ';'
  594.         | YSPEC YOF YIT YIS expr ';'
  595.         ;
  596.  
  597. reflectivity:    YREFL YOF YOBJ_VAR YIS expr ';' 
  598.         | YREFL YOF YIT YIS expr ';'
  599.         ;
  600.  
  601. ambient:    YAMBI YOF YSCENE YIS expr ';'
  602.         ;
  603.  
  604. color:        YCOLOR YOF YOBJ_VAR YIS expr ',' expr ',' expr ';'
  605.         | YCOLOR YOF YIT YIS expr ',' expr ',' expr ';'
  606.         ;
  607.  
  608. expr:        assign
  609.         | expr '+' expr
  610.         | expr '-' expr
  611.         | expr '*' expr
  612.         | expr '/' expr
  613.         | '(' expr ')'
  614.         | YNUM_VAR
  615.         | YNUMBER
  616.         ;
  617. %%
  618.  
  619.     So there's a BNF.  I can probably try and derive some form of one
  620. by looking at some example Radiance scene descriptions.  I've printed out the
  621. Postcript version of the documentation draft for 2.0.
  622.  
  623.     Here's a list of topics I'm going to cover in my paper, the three
  624. languages I'm going to compare are the language for Rayshade, Radiance, and
  625. the Cal Poly raytracing project language, Goober.
  626.  
  627. Topics:
  628.  
  629. Specification of scene parameters
  630.     - Right or left hand coordinate system
  631.     - Eyepoint
  632.     - View direction, etc.
  633.  
  634. Supported primitives
  635.  
  636. Lighting Models
  637.     - Whats available, and how to specify a certain model via the lang.
  638.  
  639. Textures
  640.     - How are they handled by the lang.
  641.     - Can users specify their own?
  642.  
  643. Bit Mapping
  644.     - How do you apply a bitmap, such as the infamous Mandrill,
  645.         to an object.
  646.  
  647. Constructive Solid Geometry (CSG)
  648.     - Is it supported, how does one build objects
  649.  
  650. Looping Constructs and/or Recursive Calls
  651.     - Are they available, how to use
  652.  
  653. Functions or Procedures
  654.     - Supported by lang.?
  655.  
  656. User Extensibility
  657.     - How does the user specify his/her own objects, textures, etc.
  658.  
  659. I decided to throw out the "Let's see how three different languages specify
  660. the same scene" idea.  They all pretty much looked the same!  Plus, with
  661. this type of topic scheme, I get to  turn in a heavier paper, :-).
  662.  
  663. ANY input on how the Radiance Language fits in to these topics would be
  664. appreciated.  I'm sure I can look most of it up in the documentation.
  665.  
  666. Thanks a bunch,
  667.  
  668. Mike
  669.  
  670. Date: Thu, 12 Dec 91 12:50:42 PST
  671. From: greg (Gregory J. Ward)
  672. To: mcancill@denali.csc.calpoly.edu
  673. Subject: Re:  Radiance Language BNF...
  674.  
  675. Hi Mike,
  676.  
  677. Thanks for explaining a BNR.  I figured it was something like that.  Since
  678. I did not use yacc or similar for the parser, I will try to come up with
  679. a BNR independently.  The first thing to understand is that altogether
  680. there are at least 4 "languages" involved with Radiance scene descriptions:
  681. the basic scene input language, the function file language, the data file
  682. language and the font language.  All except the function file language are
  683. exceedingly simple.
  684.  
  685. Scene Input
  686. =========== 
  687.  
  688. statement:    primitive
  689.         | alias
  690.         | command
  691.         | comment
  692.  
  693. primitive:    STRING type STRING
  694.         INTEGER string_args
  695.         INTEGER integer_args
  696.         INTEGER real_args
  697.  
  698. alias:        STRING alias STRING STRING
  699.  
  700. command:    '!' STRING string_args
  701.  
  702. comment:    '#' string_args
  703.  
  704. string_args:    /* nothing */
  705.         | STRING string_args
  706.  
  707. integer_args:    /* nothing */
  708.         | INTEGER integer_args
  709.  
  710. real_args:    /* nothing */
  711.         | REAL real_args
  712.  
  713. type:        "polygon"
  714.         | "cone"
  715.         | "sphere"
  716.         | "texfunc"
  717.         | "ring"
  718.         | "cylinder"
  719.         | "instance"
  720.         | "cup"
  721.         | "bubble"
  722.         | "tube"
  723.         | "plastic"
  724.         | "metal"
  725.         | "glass"
  726.         | "trans"
  727.         | "dielectric"
  728.         | "interface"
  729.         | "plasfunc"
  730.         | "metfunc"
  731.         | "brightfunc"
  732.         | "brightdata"
  733.         | "brighttext"
  734.         | "colorpict"
  735.         | "glow"
  736.         | "source"
  737.         | "light"
  738.         | "illum"
  739.         | "spotlight"
  740.         | "mirror"
  741.         | "transfunc"
  742.         | "BRTDfunc"
  743.         | "plasdata"
  744.         | "metdata"
  745.         | "transdata"
  746.         | "colorfunc"
  747.         | "antimatter"
  748.         | "colordata"
  749.         | "colortext"
  750.         | "texdata"
  751.         | "mixfunc"
  752.         | "mixdata"
  753.         | "mixtext"
  754.         | "prism1"
  755.         | "prism2"
  756.  
  757. Function File
  758. ============= 
  759.  
  760. decl:        ';'
  761.         | function_decl ';'
  762.         | variable_decl ';'
  763.  
  764. function_decl:    ID '(' id_list ')' assign_op e1
  765.  
  766. variable_decl:    ID assign_op e1
  767.  
  768. id_list:    ID
  769.         | ID ',' id_list
  770.  
  771. assign_op:    '='
  772.         | ':'
  773.  
  774. e1:        e1 '+' e2
  775.         | e1 '-' e2
  776.         | e2
  777.  
  778. e2:        e2 '*' e3
  779.         | e2 '/' e3
  780.         | e3
  781.  
  782. e3:        e4 '^' e3
  783.         | e4
  784.  
  785. e4:        '+' e5
  786.         | '-' e5
  787.         | e5
  788.  
  789. e5:        '(' e1 ')'
  790.         | ID
  791.         | ID '(' id_list ')'
  792.         | REAL
  793.         | '$' INTEGER
  794.  
  795. Comments may appear between any two tokens set off by curly braces {},
  796. and may be nested to any level.
  797.  
  798. Data File
  799. ========= 
  800.  
  801. data:        dimensions value_list
  802.  
  803. dimensions:    INTEGER dim_list
  804.  
  805. dim_list:    dim
  806.         | dim dim_list
  807.  
  808. dim:        REAL REAL INTEGER
  809.         | '0' '0' INTEGER indep_list
  810.  
  811. indep_list:    REAL
  812.         | REAL indep_list
  813.  
  814. value_list:    /* nothing */
  815.         | REAL value_list
  816.  
  817. Font File
  818. ========= 
  819.  
  820. glyph_list:    /* nothing */
  821.         | glyph glyph_list
  822.  
  823. glyph:        INTEGER INTEGER coord_list
  824.  
  825. coord_list:    /* nothing */
  826.         | INTEGER INTEGER coord_list
  827.  
  828. --------------------------------------------------------------
  829.  
  830. With regards to your topics, I have the following comments.
  831.  
  832. Specification of scene parameters:
  833.     - Radiance uses a right-hand coordinate system
  834.     - The eyepoint and view direction are given as options
  835.         to the renderers, and can be stored in a separate file
  836.  
  837. Supported primitives:
  838.     - N-sided polygons
  839.     - spheres
  840.     - cones, cylinders, rings
  841.     - hierarchical instancing for very complex geometries
  842.  
  843. Lighting models:
  844.     - Completely general
  845.     - Converter provided for IES luminaire specification
  846.  
  847. Textures:
  848.     - I break "textures" into two kinds, patterns and textures
  849.     - Patterns are variation in color, and can be specified as
  850.         pictures, data or functions in any combination
  851.     - Textures are perturbations in surface normal, and can
  852.         be specified in the same ways as patterns
  853.     - A light source distribution is a pattern
  854.  
  855. Bit Mapping:
  856.     - Usually given as a picture-type pattern (ie. "colorpict" type)
  857.     - True bit-maps (ie. 1-bit depth images) may also be produced
  858.         using a special bit font
  859.  
  860. CSG:
  861.     - Radiance has an "antimatter" type which supports some rudimentary
  862.         CSG subtraction, but otherwise we are strictly B-rep
  863.  
  864. Looping constructs or Recursion:
  865.     - The function file language supports recursion
  866.     - The "xform" program provides iteration for repeated objects
  867.  
  868. Functions or Procedures:
  869.     - The function file language supports functions without side effects
  870.  
  871. User extensibility:
  872.     - The user may create function files, data files and font files,
  873.         or provide his/her own images for patterns
  874.     - General bidirectional reflection distribution functions may
  875.         also be specified in the same way as patterns and textures
  876.  
  877. One additional topic I would like to see evaluated are the degree to which
  878. a language encourages the user to produce physically valid models.  I
  879. realize that this is not the goal of many ray tracers, but I think it
  880. should be and it is certainly a foremost consideration in Radiance.
  881. If a simulation produces bogus results, what value is it really?
  882. Along these lines, you made no mention of the reflectance model chosen
  883. or its specification.  I think this is at least as important as the
  884. geometry.
  885.  
  886. Good luck with your paper.  I'd love to see it when it's finished!
  887.  
  888. -Greg
  889.  
  890. ========================================================
  891. NEXT        - Radiance compilation on the NeXT
  892.  
  893. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  894. Subject: Help?
  895. To: GJWard@Csa2.lbl.gov
  896. Date: Sun, 15 Dec 91 16:27:23 EST
  897.  
  898. Greg:
  899.  
  900. I'm trying to compile Radiance version 2.0 on my NeXTstation (but don't
  901. let that scare you).  I got the older version to compile; but only by
  902. nuking all X references and changing malloc() references to something
  903. like foo_malloc() due to conflicts with the standard library.
  904.  
  905. Note that I really appreciate your "noX11.help" file in 2.0, but
  906. here I am again for 2.0, changing malloc() references.
  907.  
  908. Am I doing something stupid?  Every time I try to compile Radiance,
  909. I get myriads of:
  910.  
  911. /bin/ld: multiple definitions of symbol _strcmp
  912. /bin/ld: multiple definitions of symbol _realloc
  913. /bin/ld: multiple definitions of symbol _malloc
  914. /bin/ld: multiple definitions of symbol _free
  915.  
  916. messages and cannot continue without prefixing foo_ to everything.
  917.  
  918. Help.
  919.  
  920. --
  921. |         John B. Lockhart         |.:Did you know that all the water:. .:. .:|
  922. |      Junior/EE, Georgia Tech     |:.between California and Japan would:. .:.|
  923. | john%3jane.uucp@mathcs.emory.edu |. fill the Pacific Ocean? .:. .:. .:. .:. |
  924. |   (Above address NeXTmailable.)  | .:. .:. .:--John's Stupid Quotes #64721 .|
  925.  
  926. Date: Mon, 16 Dec 91 08:37:48 PST
  927. From: greg (Gregory J. Ward)
  928. To: john%3jane.UUCP@mathcs.emory.edu
  929. Subject: Re:  Help?
  930.  
  931. Hi John,
  932.  
  933. Sorry you are having trouble with my C declarations.  This seems to be one
  934. of the least well standardized parts of C.  Different C compilers seem to
  935. insist on totally different declarations.  You may find in your cc man page
  936. some options to affect the type of declarations the compiler will accept.
  937. The default mode seems to be incompatible with old C standards (the ones
  938. I use for coding).  See if there is a k+r option to the compiler, or
  939. something to turn ANSII-type declarations off.  It should not be necessary
  940. to change the names of the functions!
  941.  
  942. I cannot code to newer standards, because people with the older standards
  943. wouldn't be able to cope, whereas the reverse is usually possible.
  944.  
  945. I am assuming that the errors you get are fatal ones.  If they are only
  946. warnings, you can feel safe to disregard them and the programs should
  947. compile anyway.
  948.  
  949. Hope this helps.
  950. -Greg
  951.  
  952. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  953. Subject: Re:  Help?
  954. To: greg@hobbes.lbl.gov (Gregory J. Ward)
  955. Date: Mon, 16 Dec 91 16:30:49 EST
  956.  
  957. I've tried setting my C compiler to handle non-ANSI, etc, etc, which
  958. only causes more problems.
  959.  
  960. :I cannot code to newer standards, because people with the older standards
  961. :wouldn't be able to cope, whereas the reverse is usually possible.
  962. I can't see how changing references "malloc" to "my_malloc" constitutes
  963. coding to a new standard; it wouldn't hurt anyone else and it would
  964. sure help people with the newer compilers.
  965.  
  966. :I am assuming that the errors you get are fatal ones.  If they are only
  967. :warnings, you can feel safe to disregard them and the programs should
  968. :compile anyway.
  969. They're fatal, of course.  I've been relegated to renaming all of your
  970. functions to something non-conflicting and then just compiling Radiance
  971. using the standard library equivalents.  (The brute force method of
  972. porting. :)
  973.  
  974.  
  975. I've been wondering for some time what rview does; I've glanced over the
  976. man pages but have been unable to run it (of course) due to the fact that
  977. I don't have any of the drivers.  I know you don't want to write a NeXT
  978. driver for it (seeing as I wouldn't either if I didn't have a NeXT!), but
  979. perhaps you could give me a shove in the right direction to write my own,
  980. which you might perhaps incorporate into a future Radiance release...
  981.  
  982. --
  983. |         John B. Lockhart         |..As bad as it is, the U.S. Constitution..|
  984. |      Junior/EE, Georgia Tech     |..is a lot better than what we have now...|
  985. | john%3jane.uucp@mathcs.emory.edu |..........................................|
  986. |   (Above address NeXTmailable.)  |...............................--Unknown..|
  987.  
  988. Date: Mon, 16 Dec 91 14:01:12 PST
  989. From: greg (Gregory J. Ward)
  990. To: john%3jane.UUCP@mathcs.emory.edu
  991. Subject: Re:  Help?
  992.  
  993. Hi John,
  994.  
  995. I still say that you should not rename the functions.  The declarations
  996. I have are either for functions in the system library (such as calloc)
  997. or for my own replacement for these functions (such as malloc).  Renaming
  998. functions to foo_malloc and so forth is counter-productive.  If the
  999. advance declarations I give cause conflict, then remove them rather
  1000. than renaming them.
  1001.  
  1002. I hope I am not misunderstanding your problem.  Which declarations are
  1003. in conflict?  I do not believe that there is any real conflict involved,
  1004. only changes in the syntax of advance declarations.
  1005.  
  1006. Regarding device drivers for rview, I would be delighted if you would
  1007. write one.  You should first read the file driver.h in ray/src/rt, then
  1008. look at the routines in x11.c for ideas.  You may find that the existing
  1009. driver for NeWS is the closest to the Display PostScript used by the NeXT.
  1010.  
  1011. -Greg
  1012.  
  1013. P.S.  If you are on the network and willing to make me an account, I will
  1014. be happy to look at the compile problems myself and see if I can figure
  1015. a way around them.
  1016.  
  1017. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  1018. Subject: Re: Help?
  1019. To: greg@hobbes.lbl.gov (Gregory J. Ward)
  1020. Date: Mon, 16 Dec 91 18:38:55 EST
  1021.  
  1022. Greg:
  1023.  
  1024. :I still say that you should not rename the functions.  The declarations
  1025. :I have are either for functions in the system library (such as calloc)
  1026. :or for my own replacement for these functions (such as malloc).  Renaming
  1027. :functions to foo_malloc and so forth is counter-productive.  If the
  1028. :advance declarations I give cause conflict, then remove them rather
  1029. :than renaming them.
  1030. :
  1031. :I hope I am not misunderstanding your problem.  Which declarations are
  1032. :in conflict?  I do not believe that there is any real conflict involved,
  1033. :only changes in the syntax of advance declarations.
  1034.  
  1035. Ok, lemme explain again:  Any function that you declare to replace a
  1036. standard library function with the same name is causing my *linker*
  1037. to have screaming fits about "duplicate symbols."  It is *not* over-
  1038. riding the standard library functions with yours, like it should be,
  1039. and I have no idea how to get it to do so (I've tried just about every
  1040. command-line option on the man page).  In order to alleviate this,
  1041. I have renamed *your* function-declarations that are in conflict; thus
  1042. Radiance compiles using the standard library versions rather than its own.
  1043. This essentially just creates dead code; I could just comment them
  1044. out and have it work.  I was suggesting that you rename your functions
  1045. to something else to prevent conflicts with the standard library, but
  1046. as most compiler/linkers override library symbols with your own, it
  1047. isn't necessary for many machines.  The only way for me to get Radiance
  1048. to use it's own memory allocation routines is to rename them to something
  1049. that doesn't conflict with the standard library, throughout *all* of
  1050. Radiance.
  1051.  
  1052.  
  1053. In other words, it is impossible for me on my NeXT to compile:
  1054.  
  1055. char *malloc()
  1056. {
  1057.   return NULL;
  1058. }
  1059.  
  1060. main()
  1061. {
  1062.   malloc();
  1063. }
  1064.  
  1065. because *my* malloc() conflicts with the standard library malloc().
  1066.  
  1067. :Regarding device drivers for rview, I would be delighted if you would
  1068. :write one.  You should first read the file driver.h in ray/src/rt, then
  1069. :look at the routines in x11.c for ideas.  You may find that the existing
  1070. :driver for NeWS is the closest to the Display PostScript used by the NeXT.
  1071. I'll give it a shot.  First I need to get Radiance working!  :)
  1072.  
  1073. :P.S.  If you are on the network and willing to make me an account, I will
  1074. :be happy to look at the compile problems myself and see if I can figure
  1075. :a way around them.
  1076. Unfortunately my only InterNet account is a Sequent student account.
  1077. My 'station is at home connected via a UUCP link.  So it goes.  I've
  1078. been standing on soap boxes shouting for student SLIP or PPP (yeah, right),
  1079. to no avail.  If I get some sort of campus computer employment, then one
  1080. day Georgia Tech might suddenly have a clandestine PPP link (hehehe)...
  1081.  
  1082. --
  1083. |         John B. Lockhart         |..What kind of dream was this,............|
  1084. |      Junior/EE, Georgia Tech     |..so easy to destroy?.....................|
  1085. | john%3jane.uucp@mathcs.emory.edu |..........................................|
  1086. |   (Above address NeXTmailable.)  |.........................--Pet Shop Boys..|
  1087.  
  1088. Date: Tue, 17 Dec 91 09:36:23 PST
  1089. From: greg (Gregory J. Ward)
  1090. To: john%3jane.UUCP@mathcs.emory.edu
  1091. Subject: Re: Help?
  1092.  
  1093. Hi John,
  1094.  
  1095. I guess I had no idea of the magnitude of the problem.  I've NEVER heard
  1096. of a linker that refused to override library definitions.  That goes
  1097. against a very fundamental law of libraries.
  1098.  
  1099. The reason for having library replacements is efficiency.  Sometimes the
  1100. library functions do not perform well, sometimes they are unreliable on
  1101. different architectures (or missing entirely), and sometimes there is
  1102. something particular about the program that makes the library implementations
  1103. less efficient than they could be.  A simple example of where a library
  1104. function is overridden is in my definition of strcmp() (in common/savestr.c).
  1105. Most library's strcmp's do not compare the pointer values they are handed
  1106. for equality because this case never happens.  But when using savestr(),
  1107. many strings will end up pointing to the same address so comparing pointers
  1108. avoids having to test for equal bytes through the length of the string.
  1109. The new implementation of savestr does the same job as the library version,
  1110. but in the special case of equal pointers it does it much faster.
  1111. Similarly, I wrote my own malloc() routines to work in consort with a
  1112. variation called bmalloc() that allocates untagged blocks of memory.
  1113. Most libraries do a decent job nowadays with malloc (although there are
  1114. some notable exceptions), but if I use the library malloc, then bmalloc
  1115. does not work as efficiently.  (And bmalloc is what I do most of my
  1116. big allocations with.)
  1117.  
  1118. Sure, removing my implementations of the library functions will work,
  1119. but with some loss in efficiency.  I do not want to rename all references
  1120. myself, because some of these routines I use other places without my
  1121. particular implementations and I don't want to have to carry all my
  1122. routines with them.  It's very inconvenient to call mystrcmp() everywhere
  1123. I would normally use strcmp() when I may or may not be linking to my own
  1124. library containing mystrcmp.  I also cannot call both my library function
  1125. and the standard one because in some cases they are incompatible.  I know
  1126. there are implementations of malloc that fail catastrophically if you make
  1127. a call to sbrk() (as mymalloc would) inbetween calls to it.
  1128.  
  1129. In conclusion, I think you are taking the only possible course of action
  1130. by renaming or removing my implementations of the library routines.  Do
  1131. not rename the calls, though.  Just discard my replacements.
  1132.  
  1133. I recommend contacting the folks at NeXT to find out what is going on
  1134. with their linker.  Those guys are really out on a limb or out to lunch
  1135. or something.
  1136.  
  1137. -Greg
  1138.  
  1139. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  1140. Subject: Re: Help?
  1141. To: greg@hobbes.lbl.gov (Gregory J. Ward)
  1142. Date: Tue, 17 Dec 91 14:51:38 EST
  1143.  
  1144. Greg:
  1145.  
  1146. :I guess I had no idea of the magnitude of the problem.  I've NEVER heard
  1147. :of a linker that refused to override library definitions.  That goes
  1148. :against a very fundamental law of libraries.
  1149.  
  1150. I agree.  I could be missing something; in any case I'm certainly very
  1151. frustrated.  I think I'll post that little program I gave you onto
  1152. comp.sys.next.programmer and hope someone there says "-$, stupid!" or
  1153. something...
  1154.  
  1155. I completely understand your replacement of the standard library functions;
  1156. I was never in disagreement with that.  Also, using the same names allows
  1157. you to use either your version or the standard version by merely including
  1158. a library or not as an arg to the compiler.  My only problem was that this
  1159. wreaks havoc with my system, which is not as it should be.
  1160.  
  1161. :In conclusion, I think you are taking the only possible course of action
  1162. :by renaming or removing my implementations of the library routines.  Do
  1163. :not rename the calls, though.  Just discard my replacements.
  1164.  
  1165. That's what I've done.  Seems to be working well enough now.
  1166.  
  1167. :I recommend contacting the folks at NeXT to find out what is going on
  1168. :with their linker.  Those guys are really out on a limb or out to lunch
  1169. :or something.
  1170.  
  1171. To tell you the truth, I don't think it's NeXT--my suspicion is that it's
  1172. GNU.  I had a friend compile my little program on a SPARC with and without
  1173. the GNU CC compiler and he got the same message when he used GNU; it worked
  1174. fine using Sun's CC.
  1175.  
  1176. I will take your suggestion though and try to find out what (if anything)
  1177. I'm doing wrong...
  1178.  
  1179. Thanks.
  1180.  
  1181. --John
  1182.  
  1183. PS:  I'll proabaly be in touch sooner or later about NeXT driver woes
  1184.      or (perhaps) the solution to the multiple-symbol-definitions problem
  1185.      so that you may add a NeXT line to your makeall script.
  1186.  
  1187. --
  1188. |         John B. Lockhart         |..Bow down before the one you serve.......|
  1189. |      Junior/EE, Georgia Tech     |..You're going to get what you deserve....|
  1190. | john%3jane.uucp@mathcs.emory.edu |..........................................|
  1191. |   (Above address NeXTmailable.)  |.......................--Nine Inch Nails..|
  1192.  
  1193. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  1194. Subject: Multiple Symbol Madness
  1195. To: GJWard@Csa2.lbl.gov
  1196. Date: Thu, 19 Dec 91 1:15:45 EST
  1197.  
  1198. Greg:
  1199.  
  1200. You're going to *love* this.  I posted the message about the linker
  1201. having real fits about multiple symbols onto comp.sys.next.programmer,
  1202. and pretty much got flamed for not noticing this until now.  Seems
  1203. I've revived an old thread.  (Woe be unto me, for I have sinned!)
  1204.  
  1205. Someone did, however, mail me the following solution which, though
  1206. kludgy, hackish, and ugly besides, works:
  1207.  
  1208. cc -O -Dmalloc=my_malloc -o prog prog.c
  1209.  
  1210. Yes, that's right.  Just tell it to redefine matters and let the
  1211. preprocessor do the search/replace work for you.  This can be added
  1212. as args in your makeall script at least until something better comes
  1213. along.  "-Dmalloc=my_malloc -Dstrcmp=my_strcmp ..."
  1214.  
  1215. I don't like it any more than you do.
  1216.  
  1217. --John
  1218.  
  1219. --
  1220. |         John B. Lockhart         |..I don't think we're in..................|
  1221. |      Junior/EE, Georgia Tech     |..Kansas anymore, Toto!...................|
  1222. | john%3jane.uucp@mathcs.emory.edu |..........................................|
  1223. |   (Above address NeXTmailable.)  |...............................--Dorothy..|
  1224.  
  1225. Date: Thu, 19 Dec 91 08:51:54 PST
  1226. From: greg (Gregory J. Ward)
  1227. To: john%3jane.UUCP@mathcs.emory.edu
  1228. Subject: Re:  Multiple Symbol Madness
  1229.  
  1230. Hi John,
  1231.  
  1232. It's not a pretty solution, but at least it's a solution!  I suppose that
  1233. one of us should have thought of that...
  1234.  
  1235. Anyway, I am prepared to add it to the makeall script.  Rather than trying
  1236. to remember what standard library functions I have redefined, do you have
  1237. a list that you could share with me?  The only ones I can think of offhand
  1238. are malloc and strcmp.
  1239.  
  1240. Thanks a million!
  1241. -Greg
  1242.  
  1243. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  1244. Subject: Re:  Multiple Symbol Madness
  1245. To: greg@hobbes.lbl.gov (Gregory J. Ward)
  1246. Date: Thu, 19 Dec 91 15:21:30 EST
  1247.  
  1248. Greg:
  1249.  
  1250. :It's not a pretty solution, but at least it's a solution!  I suppose that
  1251. :one of us should have thought of that...
  1252. No it isn't.  Yes we should've.  Perhaps we were thinking along the lines
  1253. of horror at the fact that the linker wasn't doing things right and "there
  1254. must be a command line switch" rather than just looking for kludgy solutions.
  1255.  
  1256. :Anyway, I am prepared to add it to the makeall script.  Rather than trying
  1257. :to remember what standard library functions I have redefined, do you have
  1258. :a list that you could share with me?  The only ones I can think of offhand
  1259. :are malloc and strcmp.
  1260.  
  1261. Ok, the ones I've got a "Z" in front of are malloc(), realloc(), free(),
  1262. and strcmp().  To assist you with adding a NeXT option:  It is of course
  1263. BSD-derived, not RISC, and has never heard of X11.  I think your noX11help
  1264. isn't entirely complete--some other Makefiles needed patching to remove
  1265. X stuff, and I can't quite remember which ones.  I had only two more fatal
  1266. errors in Radiance-in-general that I can think of:  You prototype atof()
  1267. somewhere and I think that's a macro; this caused the compiler to have
  1268. screaming fits--all that needs be done is remove the prototype.  Also,
  1269. in one file you define a macro:
  1270.  
  1271. #define CTRL(c)  ('c'-'@')
  1272.  
  1273. this *always* compiles to ('c'-'@') on ANSI preprocessors, regardless of
  1274. the argument.  Thus in your switch statement later in the same file, the
  1275. compiler barfs at duplicated case values.  I merely replaced it with
  1276. things like ('R'-'@'), etc, and everything was o.k.
  1277.  
  1278. Finally, I have not been able to get the AutoCad-->Radiance converter
  1279. and the TIFF library to compile.  The AutoCad-->Radiance bit has to do
  1280. with malloc() again for some reason, and the TIFF library is just a pain.
  1281.  
  1282. This is somewhat disturbing as TIFF is the rasterfile of choice on NeXT;
  1283. there are library calls to write pixmaps as TIFFs builtin to NeXT.  But
  1284. a machine-independent lib won't compile.  Arrrrg.
  1285.  
  1286. But with the patches I've listed I've been able to trace things in rpict.
  1287. Rview of course is useless.
  1288.  
  1289. I realize you can't make all of these patches and still have Radiance
  1290. compile well on other machines--perhaps a machine-dependent note file?
  1291. Who knows.
  1292.  
  1293. --
  1294. |         John B. Lockhart         |..I want to hear you scream...............|
  1295. |      Junior/EE, Georgia Tech     |..--Play some rap music...................|
  1296. | john%3jane.uucp@mathcs.emory.edu |..........................................|
  1297. |   (Above address NeXTmailable.)  |....................--The Last Boy Scout..|
  1298.  
  1299. Date: Thu, 19 Dec 91 14:16:10 PST
  1300. From: greg (Gregory J. Ward)
  1301. To: john%3jane.UUCP@mathcs.emory.edu
  1302. Subject: Re:  Multiple Symbol Madness
  1303.  
  1304. Thanks, John, for all your help.  I will incorporate as many changes as I
  1305. can figure out how to do in a machine-independent way.  Thanks especially
  1306. for spotting the macro failures -- I knew nothing about those before!
  1307.  
  1308. I am sorry you weren't able to figure out the TIFF library or dxfcvt.
  1309. Unfortunately, both were written by others and so I have limited ability
  1310. to fix them.
  1311.  
  1312. -Greg
  1313.  
  1314. Date: Thu, 19 Dec 91 14:21:35 PST
  1315. From: greg (Gregory J. Ward)
  1316. To: john%3jane.UUCP@mathcs.emory.edu
  1317. Subject: another thing...
  1318.  
  1319. Did you test this -Dmalloc=Zmalloc thing already?  As I said before, some
  1320. malloc's are incompatible with outside calls to sbrk.  If the NeXT has
  1321. such a malloc, then this redefinition will cause troubles for sure.
  1322.  
  1323. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  1324. Subject: Oops!
  1325. To: greg@hobbes.lbl.gov (Gregory J. Ward)
  1326. Date: Thu, 19 Dec 91 19:19:48 EST
  1327.  
  1328. :Thanks, John, for all your help.  I will incorporate as many changes as I
  1329. :can figure out how to do in a machine-independent way.  Thanks especially
  1330. :for spotting the macro failures -- I knew nothing about those before!
  1331.  
  1332. Don't mention it.  Anyone putting out free software of Radiance's quality
  1333. deserves all the help he can get.  Note that you can add some special-cased
  1334. code if necessary with
  1335.  
  1336. #ifdef NeXT
  1337. ...
  1338. #endif
  1339.  
  1340. 'cause NeXT is defined in the compiler.  That may not be necessary, however.
  1341.  
  1342. :I am sorry you weren't able to figure out the TIFF library or dxfcvt.
  1343. :Unfortunately, both were written by others and so I have limited ability
  1344. :to fix them.
  1345.  
  1346. No big deal.  I don't use AutoCAD, and I can convert from Sun Raster to
  1347. TIFF anyway.
  1348.  
  1349. :Did you test this -Dmalloc=Zmalloc thing already?  As I said before, some
  1350. :malloc's are incompatible with outside calls to sbrk.  If the NeXT has
  1351. :such a malloc, then this redefinition will cause troubles for sure.
  1352.  
  1353. Oops.  What was I thinkin'!??  I tested it on that sample program but didn't
  1354. test it on Radiance due to some subconcious fear of compiling for an hour.
  1355. I looked at your malloc() stuffs, though, and noted your use of sbrk()
  1356. like you said (I've never used it before but assume it to be crucial
  1357. in bypassing malloc())... then checked the NeXT man page on a hunch:
  1358.  
  1359.  
  1360. % man sbrk
  1361.  
  1362. BRK(2)              UNIX Programmer's Manual               BRK(2)
  1363.  
  1364. NAME
  1365.      brk, sbrk - change data segment size
  1366.  
  1367.      The UNIX system calls brk and sbrk are not supported on the
  1368.      NeXT computer.
  1369.  
  1370.  
  1371. Ain't that just dandy?  At this point I assumed it wasn't worth the bother
  1372. of recompiling Radiance.  Since it's working fine with the standard library
  1373. malloc(), and that's what I used in v1.4, why don't we call it even and just
  1374. special-case your malloc() defs out of the Makefile or something, then just
  1375. add the -Dstrcmp=my_strcmp for strsave?
  1376.  
  1377.  
  1378. (Such a mess.  If you think this is bad, though, try porting an IBM Pascal
  1379. program to a Mac C program that uses the GUI.)
  1380.  
  1381. --
  1382. |         John B. Lockhart         |: Then again: : : : : : : : : : : : : : : |
  1383. |      Junior/EE, Georgia Tech     | :We could all be WRONG: : : : : : : : : :|
  1384. | john%3jane.uucp@mathcs.emory.edu |: (Wouldn't be the first time.) : : : : : |
  1385. |   (Above address NeXTmailable.)  | : : : : : : : : : : : --Laurie Anderson :|
  1386.  
  1387. Date: Thu, 19 Dec 91 16:49:54 PST
  1388. From: greg (Gregory J. Ward)
  1389. To: john%3jane.UUCP@mathcs.emory.edu
  1390. Subject: Re:  Oops!
  1391.  
  1392. OK, thanks for checking.  I guess NeXT users will just have to make some
  1393. additional Makefile changes -- namely, deleting malloc.o from the Makefile's
  1394. in src/ot and src/rt.
  1395.  
  1396. Date: Thu, 19 Dec 91 17:02:36 PST
  1397. From: greg (Gregory J. Ward)
  1398. To: john%3jane.UUCP@mathcs.emory.edu
  1399. Subject: Re:  Oops!
  1400.  
  1401. Actually, it wasn't so hard to make the deletions automatically.  NeXT users
  1402. will still have to deal with the X11 shortcomings, at least until we write
  1403. a driver for Display PostScript...
  1404.  
  1405. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  1406. Subject: Re:  Oops!
  1407. To: greg@hobbes.lbl.gov (Gregory J. Ward)
  1408. Date: Fri, 20 Dec 91 1:05:52 EST
  1409.  
  1410. :Actually, it wasn't so hard to make the deletions automatically.
  1411. That's good!
  1412.  
  1413. :NeXT users
  1414. :will still have to deal with the X11 shortcomings [...]
  1415. Did you make the non-X11 compilation automatic, too?  Isn't that just the
  1416. same sorta thing as removing malloc.o compilation except for several files?
  1417.  
  1418. :at least until we write
  1419. :a driver for Display PostScript...
  1420. Well, I'll get to work on that.  I've scanned over (not parsed :) the
  1421. code for existing drivers and am curious--do you get the entire bitmap
  1422. on the screen via rectangle painting (e.g.: bunches of small rectangles)?
  1423. Or did I miss something in my once-over--I only saw things like
  1424. open/close/clear/paint-rect etc.
  1425.  
  1426. 'cause if that's all there is then it should be a five-minute hack
  1427. once I figure out how the hell one gets a normal bonafide window without
  1428. having a normal bonafide Objective-C app running.
  1429.  
  1430. Oh, one last question:  Can you route "command-line" i/o to the terminal
  1431. you started rview from and just have a floating window?  (Note that this
  1432. should be moot if I can figure out what I need to figure out.)
  1433.  
  1434. --
  1435. |         John B. Lockhart         |......The Georgia......|   ___      |.....|
  1436. |      Junior/EE, Georgia Tech     |.....Institute  of.....|  |  _____  |.....|
  1437. | john%3jane.uucp@mathcs.emory.edu |......Technology:......|  |___||    |.....|
  1438. |   (Above address NeXTmailable.)  |.....We don't mold!....|       |    |.....|
  1439.  
  1440. Date: Fri, 20 Dec 91 08:34:01 PST
  1441. From: greg (Gregory J. Ward)
  1442. To: john%3jane.UUCP@mathcs.emory.edu
  1443.  
  1444. Hi John,
  1445.  
  1446. I didn't want to take out the X11 stuff automatically for the NeXT, just in
  1447. case NeXT should support X11 in the future.  I should probably have a
  1448. special question about X11 support, though, and make the changes based
  1449. on the presence or absence of certain files.  It all gets so complicated...
  1450.  
  1451. Yes, the picture is drawn by rview soley with paintrect calls.  I tried to
  1452. keep the driver interface as bone-headed simple as possible.  The tricky
  1453. part is usually getting input while drawing.  Rview has to be notified
  1454. (using the inpready member) as soon as input is available or response
  1455. time suffers.  It should be possible to get this from the standard input,
  1456. although I have never done it this way.  Keep in mind that rview should
  1457. run continuously until "interrupted" by user input.  This mode of interaction
  1458. is not supported easily by all window systems, but there is usually a way.
  1459.  
  1460. A specific problem we have had with our NeWS driver is that the rectangles
  1461. it paints don't really mesh nicely.  Because PostScript uses its own
  1462. device-independent coordinate system, there is some inaccuracy in exactly
  1463. which pixels are drawn by a paintrect call, and the result is a lot of
  1464. ugly seams everywhere.  If you have this problem and find a solution,
  1465. I would be most curious to hear about it.
  1466.  
  1467. Good luck, and let me know how I can help!
  1468. -Greg
  1469.  
  1470. From: john%3jane.UUCP@mathcs.emory.edu (John B. Lockhart)
  1471. Subject: Re:  Oops!
  1472. To: greg@hobbes.lbl.gov (Gregory J. Ward)
  1473. Date: Fri, 20 Dec 91 13:24:27 EST
  1474.  
  1475. Yo, Greg.
  1476.  
  1477. :I didn't want to take out the X11 stuff automatically for the NeXT, just in
  1478. :case NeXT should support X11 in the future.  I should probably have a
  1479. :special question about X11 support, though, and make the changes based
  1480. :on the presence or absence of certain files.  It all gets so complicated...
  1481.  
  1482. That's what I wanted.  Heaven forbid you make it just a NeXT switch--
  1483. I mean ask if you have X then it compiles or doesn't compile things based
  1484. on that.  I realize it is somewhat complicated--Make isn't quite built
  1485. for all the extremes of compatibility you're pushing it to.
  1486.  
  1487. :Yes, the picture is drawn by rview soley with paintrect calls.  I tried to
  1488. Makes sense.
  1489.  
  1490. :Keep in mind that rview should
  1491. :run continuously until "interrupted" by user input.  This mode of interaction
  1492. :is not supported easily by all window systems, but there is usually a way.
  1493. I guess I'm still foggy on what you're doing because I've never seen rview
  1494. run (hell of a disadvantage, writing a driver for something you have to
  1495. write the driver for to make it work).  I'll just study the NeWS code real
  1496. well then patch a NeXT hack to get a feel for it then refine things.
  1497.  
  1498. :A specific problem we have had with our NeWS driver is that the rectangles
  1499. :it paints don't really mesh nicely.  Because PostScript uses its own
  1500. :device-independent coordinate system, there is some inaccuracy in exactly
  1501. :which pixels are drawn by a paintrect call, and the result is a lot of
  1502. :ugly seams everywhere.  If you have this problem and find a solution,
  1503. :I would be most curious to hear about it.
  1504.  
  1505. I had a feeling you'd say that.  I've run into this problem before with
  1506. PostScript resolution nastiness while trying to make a radar screen for
  1507. a game I'm working on--seems that 1/72" screen rectangles are sometimes one
  1508. pixel and sometimes two pixels wide, depending on where you draw them!
  1509. Can you say "averaging?"  I knew you could.  That looks really good in
  1510. terms of printed output and smooth transitions but it's real hell for
  1511. the sort of thing we're trying to do.
  1512.  
  1513. I have an idea for a kludge:  Since I imagine your rview makes the rect
  1514. call only if it has to draw a "pixel," why not make the driver allocate
  1515. a bitmap, attach it to a window, then set pixels in it on the fly while
  1516. occasionally flushing it to the window?  Though sortof aesthetically
  1517. displeasing, it should work with a reasonable amount of speed and give
  1518. normal picture quality, since PostScript knows about bitmaps...  And
  1519. as an added bonus I think that'd make it really easy to put the picture in
  1520. a resizable, scrolling window (instead of just lobbing a 1024 x 768 over
  1521. everything).  I'll look into that.
  1522.  
  1523. --
  1524. |         John B. Lockhart         |: : : : : : : : Alien III : : : : : : : : |
  1525. |      Junior/EE, Georgia Tech     | : : : : : : : : : : : : : : : : : : : : :|
  1526. | john%3jane.uucp@mathcs.emory.edu |: : : : : : The bitch is back!: : : : : : |
  1527. |   (Above address NeXTmailable.)  | : : : : Coming Memorial Day 1992: : : : :|
  1528.  
  1529.