# rel4.4

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa12786; 2 Nov 91 4:23 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa13401; 2 Nov 91 3:26 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa13393; 2 Nov 91 3:20 EST Date: Sat, 2 Nov 91 3:12:23 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: errata4.0-sun-xgl Message-ID: <9111020312.aa12249@WOLF.BRL.MIL>

This is a minor change to make mged/dm-xgl.c compile on a Sun workstation with XGL. XGL is an add-on product for the Sun, desirable primarily if you have a Sun GX hardware graphics processor. Unless you have added dm-xgl to your MGED configuration, you do not need this fix.

Thanks to the folks at U.S. Army MICOM for contributing the dm-xgl.c module. This error is entirely my fault, it crept in when I converted their code to use the new "chunky" vlist structures. Since BRL does not have a copy of XGL, the modifications could not be tested. Thanks to David Turner of Sandia National Labs for pointing out the error, and debugging with me via "remote control" on the telephone one long afternoon.

Best, -Mike

923,925c923,925 < ptr->x = pt[0]; < ptr->y = pt[1]; < ptr->z = pt[2]; --- > ptr->x = pt[0][0]; > ptr->y = pt[0][1]; > ptr->z = pt[0][2]; 932,934c932,934 < ptr->x = pt[0]; < ptr->y = pt[1]; < ptr->z = pt[2]; --- > ptr->x = pt[0][0]; > ptr->y = pt[0][1]; > ptr->z = pt[0][2];

Date: Wed, 18 Dec 91 8:08:05 EST From: Mike Muuss <mike@brl> To: ACST@BRL.MIL Subject: mged pr_solid() eliminated Message-ID: <9112180808.aa16391@WOLF.BRL.MIL>

Inside MGED, I have eliminated the subroutine pr_solid(), and replaced it with a new one that uses import/export ft_describe() interface instead. This is an important step in the cleanup of solid editing. -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa13029; 13 Nov 91 19:57 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa11366; 13 Nov 91 19:54 EST Date: Wed, 13 Nov 91 19:35:21 EST From: "Lee A. Butler" <butler@BRL.MIL> To: Tng Tai Hou <taihou@iss.nus.sg> cc: cad@BRL.MIL Subject: Re: BRL for Sparc with X11R4, not OW Organization: Doubly-Linked_List Message-ID: <9111131935.aa11253@VMB.BRL.MIL>

>I am not much of a hacker, but I need to compile BRLCAD on >my Sparc 1+ running the MIT's X11R4, not OpenWindows.

In Cakefile.defs, change these two lines: # define sun_no_opts /* Production configuration */ # undef sun_x11

to these two lines: # undef sun_no_opts /* Production configuration */ # define sun_x11

If your X11 software is not in /usr/X11 (/usr/X11/include, /usr/X11/lib) then you will need to modify the following section to reflect where the include files and libraries are located:

# ifdef sun_x11 /* Sun with X11 configuration */ # define LIBFB_OBJS if_remote if_ab if_sun if_X # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB -DIF_SUN \ -I/usr/X11/include -DIF_X # define LIBFB_LIBES LIBPKG -lsuntool -lsunwindow -lpixrect \ -L/usr/X11/lib -lX11 # define MGED_OBJS dm-sun dm-X # define MGED_CONFIG -DDM_SUNPW -DDM_X -I/usr/X11/include # define MGED_LIBES -lsuntool -lsunwindow -lpixrect \ -L/usr/X11/lib -lX11 # endif

Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (301) 278-9200

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa13340; 13 Nov 91 21:13 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa11836; 13 Nov 91 21:02 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa11822; 13 Nov 91 20:55 EST Date: Wed, 13 Nov 91 20:45:26 EST From: "Lee A. Butler" <butler@BRL.MIL> To: cad@BRL.MIL Subject: 4.0 errata Organization: Doubly-Linked_List Message-ID: <9111132045.aa13281@WOLF.BRL.MIL>

There is a bug in the "pixscale" utility as distributed under 4.0 which causes it to dump core. The following patch should correct the problem.

155,156c155,156 < if (inx < outx) i = outx; < else i = inx; --- > if (inx < outx) i = outx * 3; > else i = inx * 3;

Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (301) 278-9200

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa21826; 15 Nov 91 12:40 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa01182; 15 Nov 91 12:35 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa00985; 15 Nov 91 12:11 EST Date: Fri, 15 Nov 91 12:06:16 EST From: "Lee A. Butler" <butler@BRL.MIL> To: cad@BRL.MIL Subject: Patch to fbserv.c Organization: Doubly-Linked_List Message-ID: <9111151206.aa21651@WOLF.BRL.MIL>

There is a bug in "fbserv" as distributed under 4.0 which causes a problem when used as a "lingering" window on some systems. Lingering windows which have been dismissed will disappear, but the process remains and consumes non-tirvial amounts of CPU time until the user logs out. The following patch to "fbserv.c" in the fbserv directory will fix this problem.

370a371,372 > else > break;

Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (301) 278-9200

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa02951; 20 Dec 91 21:10 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa11959; 20 Dec 91 20:33 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa11887; 20 Dec 91 20:25 EST Date: Fri, 20 Dec 91 20:18:30 EST From: Mike Muuss <mike@BRL.MIL> To: little@sei.cmu.edu cc: CAD@BRL.MIL Subject: Re: Re: sparc2 port Message-ID: <9112202018.aa02518@WOLF.BRL.MIL>

Considering the number of user sites that we have, and that we don't have any staff allocated for external user support, it can be a bit annoying when people don't experiment a bit with configuration before calling for help. We have tried to make configuration choices as clear and simple as possible.

Anyway, for some reason it was not clear to me that you wanted an X-only configuration. Simply change the lines to remove the if_sun, -DIF_SUN, dm-sun, -DDM_SUNPW entries, and remove the suntools library references.

I have expanded our copy of Cakefile.defs to make an X11-only version an easily configured option. I did it for Sun-4 machines, the same idea can be applied to other platforms:

#if defined(sparc) /* Sun-4 "SparcStation" hardware */ # undef sun # undef sun4 # define MTYPE sun4 # define BSD 43 # define HAS_TCP 1 # if 0 # define OPTIMIZER -O2 # else # define OPTIMIZER -g # endif /*# define CC_DEFS -DAUTOSPEC /* What does this do? */ # define LIBMALLOC /* use vendor library */ # define LIBRT_TIMER timer42 # if 1 /* Bare Sun configuration */ # define LIBFB_OBJS if_remote if_sun # define LIBFB_CONFIG -DIF_REMOTE -DIF_SUN # define LIBFB_LIBES LIBPKG -lsuntool -lsunwindow -lpixrect # define LIBRT_TIMER timer42 # define MGED_OBJS dm-sun # define MGED_CONFIG -DDM_SUNPW # define MGED_LIBES -lsuntool -lsunwindow -lpixrect # else # if 1 /* Sun with X11 (aka "openwin") & Suntools. Default for SunOS 4.1.1 */ # define LIBFB_OBJS if_remote if_ab if_sun if_X # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB -DIF_SUN \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG -lsuntool -lsunwindow -lpixrect \ -L/usr/openwin/lib -lX11 # if 1 /* Sun with X11 only */ # define MGED_OBJS dm-sun dm-X # define MGED_CONFIG -DDM_SUNPW -DDM_X -I/usr/openwin/include # define MGED_LIBES -lsuntool -lsunwindow -lpixrect \ -L/usr/openwin/lib -lX11 # else /* Sun with X11 and XGL (an unbundled product) */ /* Note that at MSIC, -lgks may also be needed */ # define MGED_OBJS dm-xgl dm-X # define MGED_CONFIG -DDM_XGL -DDM_X -I/usr/openwin/include # define MGED_LIBES -lxgl -L/usr/openwin/lib -lX11 # endif # else /* Sun with X11 ("openwin") ONLY. No Suntools support. */ # define LIBFB_OBJS if_remote if_ab if_X # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG \ -L/usr/openwin/lib -lX11 # define MGED_OBJS dm-X # define MGED_CONFIG -DDM_X -I/usr/openwin/include # define MGED_LIBES -L/usr/openwin/lib -lX11 # endif # endif # endif # if 0 /* "Unbundled" (i.e. "improved") compilers. Use if you have them */ # define CC /usr/lang/cc # define FC /usr/lang/f77 # endif #endif

I hope this helps. Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa28325; 3 Feb 92 16:32 EST Date: Mon, 3 Feb 92 16:25:45 EST From: dome@BRL.MIL Subject: What solid am i hitting? To: mike@BRL.MIL To: Message-ID: <9202031625.aa16268@VMB.BRL.MIL>

Mike, how have you been? I've gotten a survey and some info from the Surviac people and returned the questionaire. I talked to Keith Bowman about rt'ing a .g file and he wasn't able to answer my question. I am trying to find the exact solid that i hit when I rt a file, I'd also like to be able to find some of the data for the solid. thanks - John.

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa07598; 4 Feb 92 13:46 EST Date: Tue, 4 Feb 92 13:43:40 EST From: Carla Moyer <carla@BRL.MIL> To: Keith@BRL.MIL cc: cad-dist@BRL.MIL, mike@BRL.MIL Subject: Technical inquiry for BRL-CAD Message-ID: <9202041343.aa03137@VMB.BRL.MIL>

Dear Keith:

John Ecker <eckerjal@aplcomm.jhuapl.edu>, from the Johns Hopkins Applied Physics Laboratory, wanted to know how well supported the Apollo DN10000 is supported by BRL-CAD. He knows there is a configuration set up in the "cakefiles" but would like some more information. Keith (Bowman) is not familiar with the hardware, so he suggested to me that I forward this on to you. John's telephone number is (410) 792-6000 ext. 7902.

Thanks,

Carla

Date: Wed, 5 Feb 92 0:44:38 EST From: Mike Muuss <mike@brl> To: Carla Moyer <carla@brl.mil> cc: Keith@BRL.MIL, cad-dist@BRL.MIL, mike@BRL.MIL Subject: Re: Technical inquiry for BRL-CAD Message-ID: <9202050044.aa12824@WOLF.BRL.MIL>

The Apollo DN1000 is not on the "supported" list, but it works OK last I checked (which was 2 years ago). I expect that it will take minor polishing, but can probably be made to work. If the machine is on the net, and problems are encountered, I might be able to help for an hour sometime. But if Apollo has changed things drasticly, no telling.

Also worthy of note is that there is no "local" support for image output on the DN1000; only the X-windows interface is available. And that isn't the best way to use our software, but it does work. Best, -Mike

Date: Wed, 5 Feb 92 0:26:55 EST From: Mike Muuss <mike@brl> To: dome@BRL.MIL cc: Mike@BRL Subject: Re: What solid am i hitting? Message-ID: <9202050026.aa12756@WOLF.BRL.MIL>

Hi John -

When your a_hit() routine gets called, you have a doubly linked list of partition structures. Each partition represents a chunk of solid. From the partition structure, the element pt_regionp gives you a pointer to the region structure, which will give you your material properties info, and the partition name (pt_regionp->reg_namep). The elements pt_inseg and pt_outseg will give you pointers to the segment of the solid that the in and out points actually struck; from there, the primitive solid's name (as opposed to the region name) is found from pt_inseg->seg_stp->st_dp->d_namep, the entry solid type is in pt_inseg->seg_stp->st_id, and the particular surface number (specific to each st_id value) is in pt_inseg->seg_in->hit_surfno.

Does this give you enough to go on? If not, perhaps you can give me some kind of idea what info you need. Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa15429; 10 Feb 92 10:34 EST Date: Mon, 10 Feb 92 10:30:48 EST From: Mike Markowski <mmark@BRL.MIL> To: phd@BRL.MIL, jill@BRL.MIL, acst@BRL.MIL, davisson@BRL.MIL, wm@BRL.MIL Subject: brl-cad erim solids Message-ID: <9202101030.aa16973@VMB.BRL.MIL>

While Mike's duties temporarily took him away from our mged solid edit restructuring, I decided to add another solid, the elliptical torus, to brl-cad. Like the others, the only portion untested is surface curvature.

The full list of new solids is now:

RPC, Right Parabolic Cylinder RHC, Right Hyperbolic Cylinder EPA, Elliptical Paraboloid EHY, Elliptical Hyperboloid ETO, Elliptical Torus

Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa24590; 11 Feb 92 8:41 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa27387; 11 Feb 92 8:14 EST Date: Tue, 11 Feb 92 8:08:13 EST From: "Lee A. Butler" <butler@BRL.MIL> To: Susan Coates <scoates@BRL.MIL> cc: cad@BRL.MIL, scoates@BRL.MIL Subject: Re: concat command in mged 4.0 Message-ID: <9202110808.aa27144@VMB.BRL.MIL>

Sue,

Thank you for pointing out the problem with the MGED "concat" command under 4.0 of BRLCAD. I've fixed this locally. For everyone else, the context diff below should fix the problem. Apply to cad/mged/concat.c:

24a25 > #include <stdio.h> 27d27 < #include <stdio.h> 182c182 < (void)strncpy( local+ncharadd, name, NAMESIZE-ncharadd ); --- > (void)strncpy( local+ncharadd, name, NAMESIZE-1-ncharadd ); 186c186 < local[NAMESIZE] = '\0'; --- > local[NAMESIZE-1] = '\0'; 198c198 < local[NAMESIZE] = '\0'; /* ensure null termination */ --- > local[NAMESIZE-1] = '\0'; /* ensure null termination */ 230a231,234 > if ((ncharadd + strlen(name)) >= NAMESIZE) > printf("WARNING: solid name \"%s%s\" truncated to \"%s\"\n", > prestr,name, local); >

Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (410) 278-9200

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa20615; 24 Feb 92 22:18 EST Received: from vmb.brl.mil by VMB.BRL.MIL id ab15888; 24 Feb 92 17:35 EST Received: from vgr.brl.mil by VMB.BRL.MIL id aa15701; 24 Feb 92 17:17 EST Received: from [192.101.175.25] by VGR.BRL.MIL id aa01988; 24 Feb 92 14:52 EST Received: by max.mrj.com (911016.SGI/911001.SGI) for cad@brl.mil id AA03044; Mon, 24 Feb 92 14:54:40 -0800 Date: Mon, 24 Feb 92 14:54:40 -0800 From: John Ko <ko@max.mrj.com> Message-Id: <9202242254.AA03044@max.mrj.com> To: cad@BRL.MIL Subject: RPP on objects

I have noticed that in rtip->mdl_min and rtip->mdl_min is stored the bouding rectangular parallel piped for a model. But it seems that the values stored in the above points are not reflective of any combinatorial regions.

For example when a cube of 10x10x10 is cut in half by 5x10x10 object, rtip->mdl_min and rtip->mdl_max still give me 10x10x10.

Am I using them incorrectly or does anyone know of a (painless) simply way of getting at the bouding RPP for model made up of many combinations.

Thanks fo any help.

john ko mrj, inc ko@max.mrj.com

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa23909; 25 Feb 92 1:10 EST Received: from vmb.brl.mil by VMB.BRL.MIL id ab01234; 25 Feb 92 0:33 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa01228; 25 Feb 92 0:20 EST Date: Tue, 25 Feb 92 0:17:27 EST From: Mike Muuss <mike@BRL.MIL> To: John Ko <ko@max.mrj.com> cc: cad@BRL.MIL Subject: Re: RPP on objects Message-ID: <9202250017.aa23148@WOLF.BRL.MIL>

The values mdl_min and mdl_max are the corners of the bounding RPP for the model. The bound is computed at "prep" time, and is made as tight as it can be, without extensive effort.

In essence, the model RPP is the convex hull of all the solids in the model which are mentioned at least once in either a non subtracted or non intersected sense.

Thus, if you had a small object with a huge object subtracted out, the model RPP would be that of the small object.

In your example, of a larger object having a smaller object subtracted out, the model RPP remains that of the larger (non-subtracted) object. (The same thing holds true if you are using intersection to discard unwanted material).

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa05050; 25 Feb 92 11:06 EST Date: Tue, 25 Feb 92 10:59:32 EST From: "Edwin O. Davisson" (VLD/VMB) <davisson@BRL.MIL> To: Mike Muuss <mike@BRL.MIL> cc: cad@BRL.MIL Subject: Re: RPP on objects Message-ID: <9202251059.aa06215@VMB.BRL.MIL>

Mike,

Suppose I have n solids, { S1, S2, .., Sn } with bounding RPP's for each Si, RPP(Si), characterized by the two vectors,

[ minXSi, minYSi, minZSi ] & [ maxXSi, maxYSi, maxZSi ],

and I combine the Si's with boolean operations OPi, i.e.

region = OP1 S1 OP2 S2 .. OPn Sn ( where OPi is "+","u", or "-").

I want to define an RPP, RPP(k), characterized by

[ minXRk, minYRk, minZRk ] & [ maxXRk, maxYRk, maxZRk ],

for the object resulting from the first k combinations in the region list in terms of RPP(k-1), the bounding box of Sk, and the operation OPk.

Starting with the first solid and operation ( I assume it is not "-"), define

RPP(1) = RPP(S1) i.e. [ minXR1, minYR1, minZR1 ] = [ minXS1, minYS1, minZS1 ] and [ maxXR1, maxYR1, maxZR1 ] = [ maxXS1, maxYS1, maxZS1 ]

For RPP(k), k>1 the definition depends on the specific operation OPk:

if OPk = "u" then

minXRk = min ( minXRk-1, minXSk ) minYRk = min ( minYRk-1, minYSk ) minZRk = min ( minZRk-1, minZSk )

maxXRk = max ( maxXRk-1, maxXSk ) maxYRk = max ( maxYRk-1, maxYSk ) maxZRk = max ( maxZRk-1, maxZSk )

if OPk = "+" then

minXRk = max ( minXRk-1, minXSk ) minYRk = max ( minYRk-1, minYSk ) minZRk = max ( minZRk-1, minZSk )

maxXRk = min ( maxXRk-1, maxXSk ) maxYRk = min ( maxYRk-1, maxYSk ) maxZRk = min ( maxZRk-1, maxZSk )

if OPk = "-" then

minXRk = minXRk-1 minYRk = minYRk-1 minZRk = minZRk-1

maxXRk = maxXRk-1 maxYRk = maxYRk-1 maxZRk = maxZRk-1

Thus, for a union operation, the bounding RPP becomes the smallest (axis-aligned) RPP that contains the previously defined RPP and the RPP of the current solid. This is not the convex hull of these RPP's, but it is the smallest RPP that contains the convex hull of these RPP's. ( A convex hull of two sets is the smallest convex set that contains the two given sets.)

For the intersection operation it is possible for the RPP's to get smaller. In fact, if any of the min components are bigger than the max components for RPP(k), you have a null region.

For the subtraction operation, you have just ignored the the RPP of the subtracted solid.

Is this the way the RPP's for REGIONS are defined in terms of the RPPs of the SOLIDS and the corresponding operations in BRLCAD? Your last parenthetical comment leads me to believe that your intersection algorithm does not reduce the region RPP when it sometimes could.

Ed

Date: Tue, 25 Feb 92 15:20:49 EST From: Mike Muuss <mike@brl> To: Jill@BRL.MIL, PHD@BRL.MIL, ACST@BRL.MIL, Davisson@BRL.MIL cc: SCoates@BRL.MIL, Ennis@BRL.MIL, Wm@BRL.MIL Subject: Re: ICMG meeting in Tucson, trip report Message-ID: <9202251520.aa06485@WOLF.BRL.MIL>

> Bill Mermagen discussed the current status of the intermediate > rayhistory file generator for SRIM that uses RT for raytracing > functions. The generator uses a FORTRAN call to write the properly > formatted FITS header and ray information to a file that can be read by > SRIM 4.0. This then makes it possible for a user to use RT and still > run SRIM 4.0, a relatively painless transition from the current > approach. Users of SRIM have been given the option of tagging specific > solid faces with certain material properties; this can lead to ambiguous > material definition. Mermagen's approach has only allowed the user > access to the region identifiers--if a certain surface needs a > particular material type, the geometry must be explicitly modeled. > Mike Muuss indicated at some point that surface identifiers could be > provided with some small work, but that hasn't happened. ...

In BRL-CAD Release 4.0, I call your attention to

struct hit { : : int hit_surfno; /* solid-specific surface indicator */ };

which is provided at every point a ray enters and exits a region.

If you have some way of making sense of the different surfaces of the different solids that go into making up a region, you are welcome to use the information. It has always been present for purposes internal to the library; in Release 4.0 I gave the variable a more descriptive name, knowing that the ERIM folks had need of it. There isn't any documentation on how to use it, other than the source code of the geometry modules, but the legal values are all clearly #defined. A header file could be created if they are going to start getting used by applications.

I would be interested in learning more about what use these numbers would be put to.

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa06623; 25 Feb 92 15:29 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa10261; 25 Feb 92 15:08 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa10070; 25 Feb 92 14:52 EST Date: Tue, 25 Feb 92 14:51:37 EST From: Mike Muuss <mike@BRL.MIL> To: "John R. Anderson" <jra@BRL.MIL> cc: cad@BRL.MIL Subject: Re: [Mike Muuss: Re: RPP on objects] Message-ID: <9202251451.aa06309@WOLF.BRL.MIL>

John Anderson writes:

> Along the same lines, Mike, are the bounding boxes for each > individual object in the model available somewhere. We have occasion > to need this info and it would be convenient to have a little code to > spew them out.

The answer is yes, if you don't mind calling a subroutine.

If you have a ray partition (struct partition), pp->pt_regionp gives you a pointer to the (struct region) that you hit. So, declare a region pointer, and the min and max points of your RPP:

struct region *regp = pp->pt_regionp; point_t rpp_min, rpp_max;

rt_bound_tree( regp->reg_treetop, rpp_min, rpp_max );

Now you have the RPP of that region in rpp_min and rpp_max. Note that if

if( region_max[X] >= INFINITY )

then this region is infinite, e.g., it has a non-subtracted halfspace in it, and the RPP has no meaning -- it's infinite too. (For computation purposes, a specific number has been chosen to represent infinity, so that it can be tested against. The exact value is machine specific, but is always at least 1.0e+20 mm, which satisfies all but the astronomers in the crowd.

A similar procedure can be used to find the bounding RPP of an individual solid, but I'd be surprised if you really wanted that.

Hope this helps! Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa06723; 25 Feb 92 15:31 EST Received: from vmb.brl.mil by VMB.BRL.MIL id ab10515; 25 Feb 92 15:21 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa10418; 25 Feb 92 15:13 EST Date: Tue, 25 Feb 92 15:08:13 EST From: Mike Muuss <mike@BRL.MIL> To: "Edwin O. Davisson" <davisson@BRL.MIL> cc: CAD@BRL.MIL Subject: Re: RPP on objects Message-ID: <9202251508.aa06438@WOLF.BRL.MIL>

Thanks for the nice note, Ed. In fact, I mis-"spoke" when I said "convex hull"; the bound is tighter than that, and the algorithm used is precisely the one you spelled out. You described it to me some years ago, and the new tree walker implements it.

But this observation does not help the fellow I was responding to, because, as you noted:

> For the subtraction operation, you have just ignored the the RPP of the > subtracted solid.

whereas he was expecting the RPP to shrink after a subtraction. While I would enjoy having a tighter bound in that case, I don't know any cheap way it could be calculated. About the best I could suggest would be to tessellate, evaluate the boolean using the NMG code, and find the bounding RPP of that. Not exactly cheap. And I wouldn't suggest depending on the BRL-CAD 4.0 release to do any hard booleans.

I'm sure that folks will be happy to know that after a nearly year-long haiatus, NMGs are again getting active attention. Forward progress (as opposed to congress) is being made.

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa07946; 25 Feb 92 17:08 EST Date: Tue, 25 Feb 92 16:57:42 EST From: "Edwin O. Davisson" (VLD/VMB) <davisson@BRL.MIL> To: Mike Muuss <mike@BRL.MIL> Subject: Re: My previous note Message-ID: <9202251657.aa11171@VMB.BRL.MIL>

Mike,

Perhaps it is the downfall of a mathematician to be perpetually nitpicky but,

>Thanks for the nice note, Ed. In fact, I mis-"spoke" when I said >"convex hull"; the bound is tighter than that.. > ^^^^^^ > no.

Example:

u S1 u S2

with S1 and S2 as RPP's and so they are their own bounding RPP's:

|---------------| | | | | | | | | | | | |---------|-----| | | | | | | | | | | | | |-----|---------| | | | | | | | | | |---------------|

but the convex hull of the RPP's ( here both the solids and the bounding RPPs look like this:

|----------------\ | \ | \ | \ | \ | \ | | | | | | | | \ | \ | \ | \ | \ | \----------------|

whereas the resulting RPP would be this:

|---------------------| | | | | | | | | | | | | | | | | | | | | | | | | |---------------------|

which is less restrictive than the convex hull would be.

One other thing: you didn't address the question of whether the current method reduces the bounding RPP when intersections take place. Your first note implied in the last sentence that the intersection would simply ignore the second RPP upon intersection. The method I described reduces the RPP in such a case:

if in the case above we had S1+S2, then the bounding RPP would be the little box:

|---------------| | | | | | | | |

| |---------| ---| | | | | | | | | | | | | |-- |---------| |

| | | | |---------------|

Ed

Received: from vim.brl.mil by WOLF.BRL.MIL id aa27133; 28 Feb 92 11:23 EST Received: from VIM.BRL.MIL by VIM.BRL.MIL id aa15020; 28 Feb 92 11:15 EST Received: from vmb.brl.mil by VIM.BRL.MIL id aa14633; 28 Feb 92 11:07 EST Date: Fri, 28 Feb 92 10:41:56 EST From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> To: vld@BRL.MIL Subject: Lgt bug fixes available. Message-ID: <9202281041.aa00757@VMB.BRL.MIL>

Lgt users,

I have improved the hidden-line algorithm so that highly oblique surfaces no long get erroneously filled in. Thanks to Tyler Brown and Keith Applin for showing me a particularly pathological example of this problem; I was aware of it as a design flaw, but didn't have a solution for it. The severity of the example inspired me to revisit the problem. The fix involves testing for high obliquity against a built-in tolerance so if anyone still sees black areas I may need to tweak the tolerance a bit or make it user selectable. Note that low resolution will typically result in filled in areas (thick lines) where adjacent edges merge, but a 1024x1024 resolution can typically resolve the edges better, this is not a fault in the algorithm. Use of the anti-alias lgt option can further improve the apparent resolution with hidden-line drawings, it's not just for color shaded images. I am not aware of any remaining shortcomings in the hidden-line algorithm, let me know if you see any missing or spurious edges in your lgt images in the future.

There was also a minor bug where lgt would claim that a certain number of processors were in use when the user had in fact configured in a different number. This was due to printing the message after all UNIX shell command-line options were processed, but before all user commands were read from the standard input. This was easily fixed, thanks to Sue Coates for reporting this bug.

I have installed the fixed lgt yesterday on walrus in the BRL-CAD distribution, so all of the SGIs that get the rdist should receive it by today or tomorrow. The older version is still available as lgt.bak.

-Gary

Date: Tue, 1 Oct 91 2:59:57 EDT From: Mike Muuss <mike@brl> To: ACST@BRL.MIL Subject: SGI CAD performance boost Message-ID: <9110010259.aa21770@WOLF.BRL.MIL>

This evening, I made some modifications to librt, so that per-cpu statistics are now kept secretly in struct resource, and then merged into the rt_i struct after parallel processing ends.

This has resulted in the SGI results for 8 processors going from 4X one processor, up to 6X.

A pretty good fix, but I think some more performance can still be found.

My tentative conclusion is that multi-processor interlocks may have gotten somewhat more expensive in IRIX 4.0, but I don't have any firm indictment.

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa23114; 17 Mar 92 1:45 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa21455; 17 Mar 92 1:14 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa21404; 17 Mar 92 0:58 EST Date: Tue, 17 Mar 92 0:57:40 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: errata4.0-irix4 Message-ID: <9203170057.aa22896@WOLF.BRL.MIL>

Just now, I have placed the file "brl-cad/errata4.0-irix4" on ftp.brl.mil for anonymous FTP, containing a script which will upgrade your BRL-CAD Release 4.0 distribution for use on an SGI running IRIX 4.0.1.

-r--r--r-- 1 mike graphics 256381 Mar 17 00:54 errata4.0-irix4

Here is the head of that file:

++++++++++++++++++++ ++++++++++++++++++++

As promised, this file contains a comprehensive set changes to the BRL-CAD Release 4.0 which are necessary to compile the software on Silicon Graphics (SGI) workstation with the latest operating system releases, IRIX 4.0.0, and IRIX 4.0.1. In general, these changes should also be applied on other kinds of systems as well.

This file *includes* all the modifications from these four existing errata sheets:

-r--r--r-- 1 mike graphics 4245 Mar 16 20:58 errata4.0-cake -r--r--r-- 1 butler graphics 444 Nov 15 12:23 errata4.0-fbserv -r--r--r-- 1 butler graphics 349 Nov 15 12:23 errata4.0-pixscale -r--r--r-- 1 mike graphics 1054 Nov 2 03:13 errata4.0-sun-xgl

This means that you only have to run this one script before starting to compile everything.

Note that on IRIX 4.0.1, programs which link with LIBRT will produce the following two warning messages, which are due to a harmless (but annoying) SGI library bug. They can be safely ignored:

/usr/bin/ld: Warning: _oserror: multiply defined previous (used) definition from '/usr/lib/libmpc.a'; new (ignored) definition from '/usr/lib/libc_s.a' Warning: _setoserror: multiply defined previous (used) definition from '/usr/lib/libmpc.a'; new (ignored) definition from '/usr/lib/libc_s.a'

Cut off this top part of the file, and run the rest as a shell script. Note that it must be run from the top directory of your CAD source tree. "cd cad" before running it.

Best, -Mike Muuss

++++++++++++++++++++ ++++++++++++++++++++

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa29587; 17 Mar 92 17:33 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa29714; 17 Mar 92 17:23 EST Received: from vgr.brl.mil by VMB.BRL.MIL id aa29599; 17 Mar 92 17:15 EST Received: from uv4.Eglin.AF.MIL by VGR.BRL.MIL id aa15438; 17 Mar 92 16:34 EST Date: 17 Mar 92 15:20:00 CST From: BRUENNIN@uv4.eglin.af.mil Subject: errata4.0-irix4 install report To: CAD <CAD@BRL.MIL> Message-ID: <9203171635.aa15438@VGR.BRL.MIL>

E G L I N A F B

From: LEONARD E. BRUENNING Date: 17-Mar-1992 02:47pm CST BRUENNIN Tel No: 904 729 6226 Dept: ASD/YBES*SVERDRUP

TO: Internet Addressee ( _SMTP[CAD@BRL.MIL] )

CC: ROBERT L. STOVALL ( STOVALL ) CC: ELIZABETH T. THORN ( THORN ) CC: MILFORD A. REYNOLDS ( REYNOLDS ) CC: JOHN A. COLLINS ( COLLINS )

Subject: errata4.0-irix4 install report

Received and installed errata4.0-irix4 today on an SGI-4D/35. (Used to be a 4D20 but was upgraded) running IRIX 4.0.1. Everything went pretty smooth and "- most" stuff seems to be ok. However, a few difficulties were encountered:

1) 'edpix' utility was not compiled or installed. I think this is because of the code in gen.sh that skips the edpix code if the machine is NOT defined as a 4D. Strangely enough, this machine now responds to machinetype.sh as a 5D which apparently causes the edpix code to be skipped.

2) rpatch and patch-g executables not compiled or installed. This seems to be because the 'patch' directory is listed in the CDIRS list in gen.sh which, according to the comments, is for codes without cakefiles which really isn't the case for the rpatch and patch-g programs.

3) This machine has a 360MB internal hard drive holding the / and /usr file systems and an external 1.2GB drive holding the /usr2 file system. With the advent of IRIX4.0.1, there was not enough room on the /usr file system for the brlcad executables. Therefore, I elected the option indicated in the install.tr file and redefined by BINDIR, LIBDIR, and ETCDIR definitions in the appropriate files. This seemed to work fine EXCEPT for the man pages. The 'brlman' command was found - would respond with a usage prompt if no args were given - but would respond with nothing if any arg was provided. Turned out, definitions in the brlman and awf scripts in the ./bin directory ALSO had to be changed to reflect my non-standard installation.

4) I have executed most of the utilities I normally used and all seem OK EXCEPT rle-fb. This sits there apparently awaiting additional input. It seems that a file pointer (*infp at line 33 in rle-fb.c) had to be changed so it would compile but the change to 'stdin' seems to cause some problems here. I would appreciate some assistance in this area.

Hope this report is useful.

Bud Bruenning, Sverdrup/TEAS Group, (904) 729-6226

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa11852; 17 Mar 92 23:59 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa03996; 17 Mar 92 23:34 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa03994; 17 Mar 92 23:31 EST Date: Tue, 17 Mar 92 23:23:58 EST From: Mike Muuss <mike@BRL.MIL> To: BRUENNIN@uv4.eglin.af.mil cc: CAD <CAD@BRL.MIL> Subject: Re: errata4.0-irix4 install report Message-ID: <9203172323.aa11656@WOLF.BRL.MIL>

Bud -

Thanks for the detailed report, it was most helpful!

At BRL we are running both IRIX 3 and IRIX 4 systems. They are sufficiently different, that we needed "machinetype.sh" to distinguish between them. Since IRIX 3 systems are called "4d", IRIX 4 systems got named "5d".

1) re: edpix. You are correct, gen.sh has a special case for EDPIX that only works on "4d", but not "5d". Fixed, below.

2) re: patch directory. Correct again. Now that the patch tools have a Cakefile, they need to move from the CDIRS to BDIRS list. Fixed, below

3) re: /usr overflow. In a case such as yours, I would recommend using a symbolic link, rather than changing the definitions, although it *is* useful to know what got overlooked.... More specifically, what I'd do is something like this:

mkdir /usr2/brlcad ln -s /usr2/brlcad /usr/brlcad cd /usr/brlcad mkdir bin lib etc man .....

The symbolic link will not present a performance problem. However, I'll look into what got overlooked. (I note that newbindir.sh has the brlman/awf and brlman/brlman entries, even though install.tr does not. I have updated the development copy to reflect this change).

If you hadn't updated the setting of $MANPATH in your environment, that might have been the problem with the "brlman" command, especially if you also had not changed the MANPATH=/usr/brlcad/man line in brlman/brlman.

4) re: rle-fb. I blew it, the fix was wrong. Fixed, below.

> Hope this report is useful. > Bud Bruenning, Sverdrup/TEAS Group, (904) 729-6226

The report was very useful. In response to it, I have created a new version of the errata sheet which addresses items 1, 2, and 4, above. I have installed this updated version into FTP.BRL.MIL's brl-cad directory in place of yesterday's version. When this new version is applied, the CAD software will identify itself as BRL-CAD Release 4.1, to distinguish it from the unpatched software.

Here is the heading of the new, second edition, patch file:

++++++++++++++++++++ ++++++++++++++++++++

This document is at $Revision: 30344 $.

As promised, this file contains a comprehensive set changes to the BRL-CAD Release 4.0 which are necessary to compile the software on Silicon Graphics (SGI) workstation with the latest operating system releases, IRIX 4.0.0, and IRIX 4.0.1. In general, these changes should also be applied on other kinds of systems as well.

Applying this patch file will bring your software up to BRL-CAD Release 4.1.

This file *includes* all the modifications from these four existing errata sheets:

-r--r--r-- 1 mike graphics 4245 Mar 16 20:58 errata4.0-cake -r--r--r-- 1 butler graphics 444 Nov 15 12:23 errata4.0-fbserv -r--r--r-- 1 butler graphics 349 Nov 15 12:23 errata4.0-pixscale -r--r--r-- 1 mike graphics 1054 Nov 2 03:13 errata4.0-sun-xgl and -r--r--r-- 1 mike graphics 30388 Nov 9 04:58 cad4.0.tar-patch.Z

This means that you only have to run this one script before starting to compile everything.

Note that on IRIX 4.0.1, programs which link with LIBRT will produce the following two warning messages, which are due to a harmless (but annoying) SGI library bug. They can be safely ignored:

/usr/bin/ld: Warning: _oserror: multiply defined previous (used) definition from '/usr/lib/libmpc.a'; new (ignored) definition from '/usr/lib/libc_s.a' Warning: _setoserror: multiply defined previous (used) definition from '/usr/lib/libmpc.a'; new (ignored) definition from '/usr/lib/libc_s.a'

Cut off this top part of the file, and run the rest as a shell script. Note that it must be run from the top directory of your CAD source tree. "cd cad" before running it.

Best, -Mike Muuss

++++++++++++++++++++ ++++++++++++++++++++

Date: Fri, 20 Mar 92 12:05:00 EST From: Mike Muuss <mike@brl> To: Paul Tanenbaum <pjt@server.cs.jhu.edu> cc: ACST@BRL, Gwyn@BRL, fsbrn@BRL Subject: Re: free(2) Question Message-ID: <9203201205.aa08118@WOLF.BRL.MIL>

> To: fsbrn@BRL.MIL, gwyn@BRL.MIL, mike@BRL.MIL, stay@BRL.MIL > Subject: free(2) Question > From: Paul Tanenbaum <pjt@server.cs.jhu.edu> > > Sorry for the unsophisticated approach to the selection of addressees: > I just thought up a bunch of people, some set of whom would probably know the > answer to this question (I've RTFM already, and not found the answer)... > Is the following hunk of code kosher: > > foo () > { > widget *wp; /* data type defined elsewhere */ > > if ((wp = (widget *) malloc(10 * sizeof(widget))) == NULL) > { > fputs("foo(): Can't fit 10 widgets\n", stderr); > exit (1); > } > > do_something(wp); > > /* Hereafter need only the first 2 widgets */ > free(wp + 2); > } > > In other words, is it reasonable to pass free() an address in the middle of > an allocated block, instead of the address of the start of the block?

No. Quoting from the SGI man page, which is most handy:

The argument to free is a pointer to a block previously allocated by malloc.

If you didn't get it with malloc(), you shouldn't feed it to free(). The reason for this is that malloc/free use a small data structure just before the dynamic memory block is. The contents are system-specific, but often include things like:

*) Forward and backwards links of free/busy memory blocks *) The size of the memory block. *) The busy/free status of the memory block. *) Magic numbers to check for pointer corruption

> The > application was calling malloc() to get a starting chunk and then repeatedly > calling realloc() to double that amount as needed. Since in the worst case > this approach will use twice the required memory, I thought I'd give back > what I didn't need. I ended up dumping core, however, and inferred that > malloc()/free() might not be as sophisticated as I had assumed.

Or more sophisticated! In this case, what you should be doing is calling realloc() again to trim down the size of the block to exactly what is needed. Then the library will be able to shuffle the remainder off to it's internal free list, building new headers & other internal info as appropriate for that implementation.

Using realloc() to shrink the size of an allocation is not an expensive operation, and won't move the actual data (although it would be safest not to depend on that behavior).

Best, -Mike

Date: Fri, 20 Mar 92 11:37:01 EST From: Mike Muuss <mike@brl> To: joe edward meier <jem@bruker.com> cc: Mike Moss <mike@brl.mil> Subject: Re: BRL-CAD drafting features Message-ID: <9203201137.aa07010@WOLF.BRL.MIL>

> ... I have some questions regarding BRL-CAD's ability > to create production drawings. The documentation mentioned some work > being done with automatic dimension, is anything available for > incorporating into BRL-CAD? Even a primitive (Beta) version would be > useful. Also, is there a command to make BRL-CAD produce the drafting > drawings, or does one have to use seperate commands?

What we have, so far, is RTHIDE, RTSCALE, and RTREGIS.

> Also, the documentation mentions a numerical milling program, is > there a version of this avaliabe? I would be very interested in one.

Nope, sorry.

> I also was wondering what the vector font directory (vfont) was for, > is there some way to annotate the images, and what is libnurb for, > does BRL-CAD have a method for produceing nurb solids, or does one > have to create those outside of BRL-CAD?

vfont directory is used by CAT-FB, which puts troff output onto framebuffers and image files, and FBLABEL which is used for annotating images, usually from shell scripts.

libnurb is for the analysis of NURB solids. We don't allow interactive creation or editing of NURBS yet, but if you have a program that wants to create a NURB, it's easy! Look at proc-db/teapot.c for one example.

> These questions where some things I came up with while reading the > documintation and which I would like more information before I go to > the effort of porting the package to my MAC. Being in the NMR software > busness myself I can understand how easy it is to let the documentation > fall behind.

Actually, the documentation is in pretty fair shape. Problem is, our support contractor that was organizing all the camera-ready copy for the printshop is now 6 months late in delivering, so all you users don't actually HAVE the latest documentation. Sigh. It's a 5 volume set now.

Best, -Mike

Received: from vgr.brl.mil by WOLF.BRL.MIL id aa08552; 20 Mar 92 13:36 EST Date: Fri, 20 Mar 92 13:12:40 EST From: Doug Gwyn (VLD/VMB) <gwyn@BRL.MIL> To: Mike Muuss <mike@BRL.MIL> cc: Paul Tanenbaum <pjt@server.cs.jhu.edu>, ACST@BRL.MIL, Gwyn@BRL.MIL, fsbrn@BRL.MIL Subject: Re: free(2) Question Message-ID: <9203201312.aa00830@VGR.BRL.MIL>

realloc() might or might not move the data and it might fail, even for a request to shorten the allocation. Standard-conforming implementations of realloc() will not lose the original data when they report failure. (Older implementations sometimes did.) The programming idiom for this is: /* using p to refer to the start of the data block */ if ( (np = realloc( p, new_size )) != NULL ) /* and only if */ p = np; /* continue to use p to refer to the start of the data block */ (For clarity, I omitted details such as declarations, etc.)

An easy mistake to make is to store addresses within the previous data block into various pointer variables (e.g. sparse-array links), then fail to update them upon realloc()ation (probably because you didn't leave yourself any way to find them!). If you key off (base,offset) instead, then updating just the base pointer to the data block is all that is necessary to track a realloc()ation (the offsets don't change).

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa18631; 13 Apr 92 15:53 EDT Date: Mon, 13 Apr 92 15:53:20 EDT From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> To: acst@BRL.MIL cc: cmoore@BRL.MIL Subject: can't draw solid type 21? Message-ID: <9204131553.aa16761@VMB.BRL.MIL>

On vsb50.brl.dis, using a Silicon Graphics terminal, I ran MGED, which said BRL-CAD 4.0 (mike@walrus.brl.mil:/sunvld/mike/mged), and if I try to edit a certain region:

E regionname

I get:

proc_reg: Cannot draw solid type 21 (ARS) Error in converting solid regionname to ARBN E: 0 vectors in 0 sec

(but little "e" works OK; this region is not all that complicated, and big E should have worked pretty quickly) Let me know if you want a closer look at this case.

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa21751; 14 Apr 92 7:39 EDT Date: Tue, 14 Apr 92 7:38:29 EDT From: Keith Applin (VLD/VMB) <keith@BRL.MIL> To: cmoore@BRL.MIL cc: acst@BRL.MIL Subject: Re: can't draw solid type 21? Message-ID: <9204140738.aa02524@VMB.BRL.MIL>

Carl:

The "E" command doesn't do ARSs or TORs and never has.

-keith-

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa17420; 18 Apr 92 2:27 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00396; 18 Apr 92 2:24 EDT Received: from wolf16.brl.mil by VMB.BRL.MIL id aa00389; 18 Apr 92 2:18 EDT Date: Sat, 18 Apr 92 2:09:36 EDT From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: dm-4d performance Message-ID: <9204180209.aa17055@WOLF.BRL.MIL>

This evening, while working on part of our experimental Virtual Reality (VR) support in MGED, I was able to make an optimization to dm-4d.c, the display manager for the SGI Iris 4D workstations, which improved graphics drawing speed by 25% in the test case I tried.

The model was bldg391.g. I gave these commands: e all.g ae 35 25 size 4000 knob x 1

On the Release 4.1 version of the code, I obtained 12.5 frames/sec, while with the new version, I obtained 15.75 frames/sec. (I might note that the new MGED also continuously monitors it's drawing performance now, making it easy to read off frame rates).

Onwards! -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa17620; 18 Apr 92 3:09 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac00695; 18 Apr 92 3:08 EDT Received: from wolf16.brl.mil by VMB.BRL.MIL id aa00669; 18 Apr 92 2:59 EDT Date: Sat, 18 Apr 92 2:48:14 EDT From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: MGED perspective handling Message-ID: <9204180248.aa17492@WOLF.BRL.MIL>

As another part of the VR modifications, the handling of perspective viewing in MGED has been moved up from dm-4d.c into dozoom.c, so that all display managers (such as X, PostScript, Tektronix, Unix-Plot, etc) now have support for perspective drawing, rather than just the SGI. Best, -Mike

Received: from spark.brl.mil by WOLF.BRL.MIL id aa20192; 22 Apr 92 20:41 EDT Date: Wed, 22 Apr 92 20:48:09 EDT From: Phil Dykstra <phil@BRL.MIL> To: ACST@BRL.MIL cc: vis@BRL.MIL Subject: BRL-CAD updates Message-ID: <9204222048.aa12601@SPARK.BRL.MIL>

FYI, I installed some updates in the BRL-CAD tree today:

1) pix-ps Fixes problem with unusual file sizes that would cause stripes at the top, or failure to print. Quite a bit faster (uses builtin hex printer rather than printf) Page centering now default (with -l for lower left - which I doubt anyone used anyway).

2) loop John Grosh's latest floating point and leading zero version.

3) c-d argv dereference bug (would dump core on SGI's) protected atan2 against 0,0 calls.

- Phil

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa08488; 31 Jan 92 19:12 EST Received: from vmb.brl.mil by VMB.BRL.MIL id aa23391; 31 Jan 92 19:03 EST Date: Fri, 31 Jan 92 18:49:48 EST From: "Lee A. Butler" <butler@BRL.MIL> To: Paul Tanenbaum <pjt@BRL.MIL> cc: cad@BRL.MIL Subject: framebuffers under BRLCAD 4.0 Organization: Doubly-Linked_List Message-ID: <9201311849.aa23249@VMB.BRL.MIL>

Paul,

The lack of a shared memory framebuffer on the Indigo is not as burning an issue as you might at first think. The reason is that with release 4.0 BRLCAD has "fbserv". This is known as the "framebuffer server". The idea is that you create a process which opens a framebuffer and handles requests for that framebuffer. This allows you to create 1 framebuffer window for working with images, and removes the "popping window" syndrome. One of the great misfortunes of release 4.0 is that there is no man page for fbserv, and the useage message is of limited help. I will try to give a brief overview here.

fbserv opens a framebuffer window and lingers around waiting to service framebuffer requests. An application opens this framebuffer and reads/writes just like normal. The difference is that when the application closes the framebuffer the server does not close down the window and go away. Instead it goes back to waiting for new framebuffer requests. The next application to open framebuffer 0 gets the same fbserv, with the same framebuffer window and display memory as before. When the user finally wants to dismiss the framebuffer entirely (ie: at logout time) the command "fbfree" will caues fbserv to dismiss the actual framebuffer and then exit.

This method of operation has several advantages over previous methods of operation. The first is that the user gets a framebuffer window that doesn't "disappear" as soon as the application closes the framebuffer (as is the case with a framebuffer of "/dev/sgi"). Traditionally the workaround was to use a "lingering" framebuffer. The problem with this was that the window had to be dismissed by the user after each use or there would be a buildup of "duplicate" windows on the screen.

In addition to the "user interface" problem, there was the problem of using "shared memory" to hold the image. On many (if not all) systems, a shared memory segment was not pageable/swappable. This meant that a single paint of a 1024x1024 image would lock up 3MBytes of main memory until a user explicitly freed the shared memory segment. Few people remember to do this. On many workstations, the loss of 3MB poses a severe penalty on system performance.

Finally, it is possible with fbserv to maintain 2 independent framebuffers on the same system. This can be useful for comparing images, or allow rendering into one framebuffer while other images are viewed into a second.

Example:

% fbserv -S 512 0 /dev/sgip & # start server #1 % fbserv -S 512 1 /dev/sgip & # start server #2 % setenv FB_FILE 1 % pix-fb -F 0 image.pix % pix-fb picture.pix % rt -a 35 -e 25 moss.g all.g >& moss.log & [1] 10671 % setenv FB_FILE 0 % fb-rle image.rle % jobs [1] + Running rt -s 512 -a 35 -e 25 moss.g all.g >& moss.log % [1] Done rt -s512 -a 35 -e 25 moss.g all.g >& moss.log

It is important to note that "fbserv" can use any valid framebuffer name. Fbserv works equally well on a sun, sgi, cray....

Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (410) 278-9200

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa01219; 14 May 92 16:08 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ac22974; 14 May 92 16:00 EDT Received: from vgr.brl.mil by VMB.BRL.MIL id aa22830; 14 May 92 15:55 EDT Received: from dragon.dst.battelle.org by VGR.BRL.MIL id aa17394; 14 May 92 15:42 EDT Received: by dragon.dst.battelle.org (911016.SGI/911001.SGI) for cad@brl.mil id AA04365; Thu, 14 May 92 15:45:14 -0400 Date: Thu, 14 May 92 15:45:14 -0400 From: doug everhart <doug@dragon.dst.battelle.org> Message-Id: <9205141945.AA04365@dragon.dst.battelle.org> To: cad@BRL.MIL Subject: Frame Buffer (fb) Problems

I've got a problem running the fb routines on my SGI 4D/220. The window that the fb opens comes up and plots the image and then disappears as soon as the image is complete (along with the image). Any hints as to how I can fix this? Thanks.

---------------------------------------------------------------------------

R. Douglas Everhart (614)424-3214 Principal Research Scientist FAX:(614)424-3776 doug@dragon.dst.battelle.org Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201

---------------------------------------------------------------------------

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa02699; 14 May 92 22:08 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa00532; 14 May 92 22:04 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa00415; 14 May 92 21:53 EDT Date: Thu, 14 May 92 21:46:37 EDT From: Phil Dykstra <phil@BRL.MIL> To: doug everhart <doug@dragon.dst.battelle.org> cc: cad@BRL.MIL Subject: Re: Frame Buffer (fb) Problems Message-ID: <9205142146.aa08791@SPARK.BRL.MIL>

Try "setenv FB_FILE /dev/sgipl" and then pix-fb. The 'p' option means private memory (not shared) and the 'l' means to linger, i.e. stay around after the program that created the window has exited. See "fbhelp" for more information.

Another option is fbserv, which creates a reusable window. E.g.

% fbserv -w720 -n486 0 /dev/sgip & % setenv FB_FILE 0 % pix-fb -s512 file.pix % fbzoom

etc.

You can have several fbserv's known as '0', '1', etc. They work remotely as well:

remotehost% setenv FB_FILE yourfbservhost:0 remotehost% pix-fb

[Not to be confused with the X11 setenv DISPLAY hostname:0, but the syntax is very similar. If you are using the /dev/X frame buffer, you still need to set DISPLAY, xhost, etc.]

- Phil

Date: Fri, 15 May 92 6:52:03 EDT From: Jim Hunt <jehunt@brl> To: vld-lttb@BRL.MIL cc: mike@BRL.MIL, moss@BRL Subject: Region ID Instance Filter installed in RIP Message-ID: <9205150652.aa04620@WOLF.BRL.MIL>

Thanks to Mike Muuss, future releases of LIBRT now can renumber instanced region's item numbers. I have recompiled a version of RIP that uses the new LIBRT. You will need a file that contains regular expressions like those used in ED(1) that will be used to match region path names and remap their region ids. The file should have the same base name as your database file but with a ".regexp" suffix (e.g. target.regexp for the file target.g). Comments may be placed in the regular expression file on lines beginning with a '#'. The following is an example:

# # Each of the following lines follows the format: # # Regular_Expression TAB(s) command SEMICOLON # # Examples of valid "command"s for remapping region ids are: # # 99 replace old region id with 99 (or any number) # +99 increment old region id by 99 (or any number) # +uses increment the old region id by the # current instance (use) count # # Note that all regular expressions from ed(1), the line editor, are supported # Note that all commands MUST end with a semicolon ";" # Note that all backslashes have to be doubled. # Note that ., \, [, and * are special pattern matching characters # Blank lines are not significant. # Commands may extend over multiple lines -- they are terminated only by ";" # # Note that the regular expression may specify as much or as little # of the full path name as needed to get the desired effect. # # The order that commands are given is significant, if # several regular expressions select the same region. # # These lines demonstrate all currently supported features.

# discriminate between each instance of block.r /b./block\\.r +uses; # ditto for sph.r /s./sph\\.r +uses;

# For fourth instance of block.r only, go back and force the region ID to 321. /b4/block\\.r 321;

# For the third instance of sph.r only, go back and add 42 to prev. result /s3/sph\\.r +42;

# # Note that the above database had a tree that looked like: # #mged> tree all.g #all.g/ # u floor.r/R # u floor # u b1/ # u block.r/R # u block # u b2/ # u block.r/R # u block # u b3/ # u block.r/R # u block # u b4/ # u block.r/R # u block # u s1/ # u sph.r/R # u sph # u s2/ # u sph.r/R # u sph

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa07767; 15 May 92 13:15 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab21683; 15 May 92 13:04 EDT Date: Fri, 15 May 92 12:53:14 EDT From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> To: "John R. Anderson" <jra@BRL.MIL> cc: cad@BRL.MIL Subject: Re: [Paul Tanenbaum: Re: Frame Buffer (fb) Problems] Message-ID: <9205151253.aa21373@VMB.BRL.MIL>

# I think "+++paul" has brought up a good point, in fact, why not make # the lingering frame buffer the default.

I'll tell you why. The lingering frame buffer support is an ugly kludge that has serious consequences for interactive libfb clients like 'lgt' and 'fbed'. When the libfb/fbclose() function is called from an interactive program specifying a 'lingering' window, the client gets killed off. I have spent mega-hours answering calls from people whose 'lgt' run gets killed when they close a lingering window. Note that specifying a remote device (ie remote-host:/dev/sgipl) or using 'fbserv' is safe because the lingering window is a remote process, not a child of the client process.

# How often does one want a frame buffer that disappears as soon as its # displayed??

Not very often. Fbserv is definitely the way to go. Unfortunately, the man page didn't get distributed (an oversight apparently), and the inetd configuration is not part of the automatic BRL-CAD installation as far as I know. Getting fbserv properly installed and learning to use it is not a big deal and is definitely worth the trouble. There is the drawback that you can't get a remote fbserv window to resize itself from the client application, but this usually is not a big hardship for the user.

-Gary

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa08363; 15 May 92 14:32 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25097; 15 May 92 14:23 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa24827; 15 May 92 14:15 EDT Date: Fri, 15 May 92 14:14:07 EDT From: Phil Dykstra <phil@BRL.MIL> To: cad@BRL.MIL Subject: Re: Frame Buffer (fb) Problems Message-ID: <9205151414.aa24717@SPARK.BRL.MIL>

Gary mentioned a couple of reasons for not defaulting to lingering windows. I would add to that that if you are using shared memory windows for compositing or what have you, you may not want a stack of windows to pile up on the screen (easy to do). And while lingering may be more common for pix-fb, it often isn't correct for other programs that use frame buffers (take fbzoom for example). [I have however considered suggesting that private memory become the default (rather than shared). I almost *never* use shared any more. fbserv is usually better if you need to do the things shared memory buys you.]

I think a big problem is that answers to FAQ's like this are very hard to find in the documentation. How to use fbserv is almost non existant (my fault, since I wrote fbserv and didn't "finish" the job), and there are other charms in there like memory frame buffers with and without attached displays that let you do some neat things.

I have wanted to write a tutorial example on using these features for many months now. I think having such examples would help first time users (and even others) a lot.

- Phil

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa27441; 13 May 91 10:43 EDT Received: from vmb.brl.mil by VMB.BRL.MIL id ab08285; 13 May 91 10:32 EDT Received: from wolf.brl.mil by VMB.BRL.MIL id aa08135; 13 May 91 10:22 EDT Date: Mon, 13 May 91 10:15:48 EDT From: Susan Muuss (VLD/ASB) <sue@BRL.MIL> To: cad@BRL.MIL cc: sue@BRL.MIL Subject: CAD Addition Message-ID: <9105131015.aa26183@WOLF.BRL.MIL>

Today I added a new addition to the converter directory: it is a shell script that will "compact" mged databases. It takes two arguments: the database to be compacted and the new database. These two arguments must be different. The objective is to remove allocated space that remains when a component is killed. The program relies on g2asc and asc2g to do the actual compacting.

Beware: at this time there is no provision made to cover the following situation. When one of the converters skips a solid/solids, then the database is also "compacted", and the solids skipped by the converters are are omitted.

Cheers, Sue

Date: Fri, 5 Jun 92 22:33:59 EDT From: Mike Muuss <mike@brl> To: ACST@BRL.MIL cc: Jill@BRL Subject: progress Message-ID: <9206052233.aa10757@WOLF.BRL.MIL>

Lee just found and fixed a horrible and subtle memory leak in nmg_bool.c

I just added a "labelvert" command, which labels the vertices of the vlist of an object with it's model-space coordinates. Designed to help understand some of the NMG debugging plots, I suspect that it will prove valuable to modelers as well. -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa08168; 30 Sep 91 11:19 EDT Date: Mon, 30 Sep 91 11:18:08 EDT From: "Paul H Deitz: Chief, VLD" <phd@BRL.MIL> To: mike@BRL.MIL cc: jill@BRL.MIL Subject: [Ann Silirie: BRL TAP Report] Message-ID: <9109301118.aa04609@VMB.BRL.MIL>

FYI.

phd

----- Forwarded message # 1:

Received: from amigo.brl.mil by VMB.BRL.MIL id aa03767; 30 Sep 91 10:19 EDT Received: from AMIGO.BRL.MIL by AMIGO.BRL.MIL id ac07589; 30 Sep 91 10:11 EDT Date: Mon, 30 Sep 91 10:08:20 EDT From: Ann Silirie (OD) <silirie@BRL.MIL> To: senior-staff@BRL.MIL Subject: BRL TAP Report Message-ID: <9109301008.aa07517@AMIGO.BRL.MIL>

BRL TAP Report 30 September 91

VULNERABILITY/LETHALITY DIVISION

COMPARISON BETWEEN BLACK HAWK COMPONENTS HIT BY SMALL ARMS PROJECTILES IN GRENADA AND GEOMETRIC MODEL INTERROGATION PREDICTIONS

Interrogations of the three dimensional graphical model for The BLACK HAWK, UH-60A, were made along the same 7.62mm projectile hit shotlines encountered during "OPERATION URGENT FURY", the Grenada rescue mission. The combat damage data results were compared with the predictions from the Geometric Information For Targets (GIFT) code for the same shotlines encountered in combat. A total of 26 shotlines were examined from two helicopters involved in the conflict. The results of the GIFT code output correlated well with the actual combat damage. The results of this comparative study will be presented in a paper at the US Army Thirtieth Operation Research Symposium (AORS XXX) to be held this November at Fort Lee, VA. POC: Dr. Don Haskell, Ext. 2032.

INTERACTIVE SCREEN EDITOR STYLE COMMAND DEVELOPED FOR BRL-CAD'S MGED

The BRL-CAD, the Army's primary solid modeling system, is used by the BRL, other government agencies, and private industry. Its graphics-based user interface, MGED (Multidevice Graphics EDitor), now can be upgraded to employ screen editor-like capabilities in editing building blocks (called regions and groups) of models. Users can select from a variety of familiar screen editor environments such as "jove," "emacs," or "vi" to define or modify region and group definitions. Heretofore, users were forced to execute the "r" (region) or "g" (group) commands whose data inputs were completely free of syntax and model construction errors. The occurrence of an error in one of these commands often would require the user to completely retype the command and inputs. Now the new command "red" (Region EDitor) will invoke the user's choice of screen editor and allow the user to modify group and region definitions as easily as editing a simple file. POC: Donald Haskell, Ext. 2608.

Date: Fri, 19 Jun 92 0:51:14 EDT From: Mike Muuss <mike@brl> To: PHD@BRL, Jill@BRL cc: ACST@BRL Subject: spline editing Message-ID: <9206190051.aa15230@WOLF.BRL.MIL>

For the first evening this week, I actually got to do some programming, and I finished my first cut at interactive editing of NURB solids in MGED. It is now possible to interactively select a surface and control point, by pointing and clicking with the mouse, and then draging that control point around on the screen. The spline surface follows along beneath it.

My thanks to Mike Markowski for creating two support subroutines to assist with the point picking.

I'd be happy to show it folks. I've created a really deformed teapot with almost no effort... You can see for yourself in wolf:/m/cad/.mged.5d/ugly-teapot.pix (512).

The user interface needs some refinement before I'd turn anyone loose on it, but all the pieces are there now. (Finally). I've been waiting years to be able to do this!

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa18884; 5 Aug 92 13:12 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa21116; 4 Aug 92 20:50 EDT Received: from spark.brl.mil by VMB.BRL.MIL id aa20989; 4 Aug 92 20:38 EDT Date: Tue, 4 Aug 92 20:35:30 EDT From: Phil Dykstra <phil@BRL.MIL> To: "Robert D. LaFollette" <rlafolle@duchamp.nswc.navy.mil> cc: cad@BRL.MIL Subject: Re: Image Compression Message-ID: <9208042035.aa01939@SPARK.BRL.MIL>

I agree with Lee Butler. Factors are:

1) If there is a lot of constant color, run length encoding (RLE) really wins. See the Utah Raster Toolkit utilities (included in BRL-CAD). 2) For general images (e.g. with noise or lots of varying colors), general compression techniques (such as compress/uncompress) work every bit as well as "image" techniques for the lossless case. 3) Sometimes it helps to do color separations first, and then compress. 4) If you don't need lossless compression, there are some very good image oriented compression techniques available (e.g. JPEG).

Around here we use compress/uncompress a lot. It's lossless, and in general works as well or better than RLE (but slower).

- Phil

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa11157; 19 Aug 92 17:28 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07045; 19 Aug 92 17:22 EDT Date: Wed, 19 Aug 92 17:21:04 EDT From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> To: vld-superusers@BRL.MIL cc: x11@BRL.MIL, vmb@BRL.MIL Subject: VOTE X11 software update Message-ID: <9208191721.aa06541@VMB.BRL.MIL>

Just a warning that I updated VOTE with MIT's official patches 11-13. I I have been using this software for several weeks so it should be fine, but you may notice a large number of Sun4 files being updated via rdist; it's just a side-effect of rebuilding the core MIT X11R5 distribution.

Included in this update is the xrolo utility (mimics the functionality of a rolodex). I installed this because Jill asked for such a capability, but I haven't got the time to test it out properly, so use at your own risk (as usual ;-) and let me know if there are any problems. I noticed that it dumps core immediately on Sun3s, but so do many other xview clients. Apparently, the xview library has problems there, so I am not making it available at this point in time on Sun3s.

Finally, I installed xpa on VOTE; this is the X11 front end to my presented area, mass, moments and products of inertia, etc. program. The ray-tracing back end for xpa is called "paslave" and lives under /usr/vld/bin; it is typically run on a different host than the X11 part and is installed on some of the SGI servers. These programs (xpa/paslave) are experimental meaning that I have tested the results to the best of my ability, but it is the user's responsibility to convince himself that the answers are correct. I just do not have the resources to come up with a robust set of test cases with known answers for moments and products of inertia. It works for simple test cases (ie a cube), and there is no reason to suspect that the complexity of the MGED region should make any difference, but "caveat emptor" anyway.

-Gary

Date: Thu, 3 Sep 92 19:54:09 EDT From: Mike Muuss <mike@brl> To: ACST@BRL.MIL Subject: MGED anim previews Message-ID: <9209031954.aa07269@WOLF.BRL.MIL>

This evening I have made modifications to MGED to permit the "preview" command to process "anim", "tree", and "clean" commands from an RT animation script, and generate the correct display.

-M

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa13450; 10 Sep 92 17:38 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa02615; 10 Sep 92 17:35 EDT Received: from vim.brl.mil by VMB.BRL.MIL id aa02605; 10 Sep 92 17:32 EDT Date: Thu, 10 Sep 92 17:21:05 EDT From: Jodi Robertson <jlrob@BRL.MIL> To: cad@BRL.MIL Subject: mged and tvtwm Message-ID: <9209101721.aa01479@VIM.BRL.MIL>

CAD world,

When using mged and attaching sgi (either at the start of editing or attaching later) mged is (randomly) killed sending me back to my prompt

I am using the latest (?) version of mged BRL-CAD Release 4.1 Graphics Editor (MGED) Thu Sep 3 13:10:56 EDT 1992, Compilation 4 stay@wildcat:/n/wolf/m/dist4.1/mged

and running tvtwm with IRIX 4.0.5

Has anyone seen this problem and have a solution???????

thanks jodi

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa14387; 10 Sep 92 20:11 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa03733; 10 Sep 92 19:36 EDT Date: Thu, 10 Sep 92 19:26:21 EDT From: "Lee A. Butler" <butler@BRL.MIL> To: Jodi Robertson <jlrob@BRL.MIL> cc: cad@BRL.MIL Subject: Re: mged and tvtwm Message-ID: <9209101926.aa03711@VMB.BRL.MIL>

>When using mged and attaching sgi (either at the start of editing or >attaching later) mged is (randomly) killed sending me back to my prompt

Mike Markowski also noticed this. On the occasions it's been noticed, it seems to be related to an unusual state of the graphics engine. Applying the "Vulcan Death Grip" (simultaneous Lctrl,Lshift,F12,keypad-/) to reset the graphics hardware seems to correct the problem. If you can come up with a repeatable test case, please let us know.

Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (410) 278-9200

Date: Tue, 15 Sep 92 1:27:38 EDT From: Mike Muuss <mike@brl.mil> To: Edwin O. Davisson <davisson@brl.mil> cc: ACST@BRL.MIL Subject: Re: [Edwin O. Davisson: NMG's] Message-ID: <9209150127.aa02180@WOLF.BRL.MIL>

The short answer is that you didn't miss anything while you were sick. I hope you are feeling better now!

The files to read in preparation for doing something with NMGs are h/nmg.h, librt/nmg_*.c, librt/g_nmg.c, and mged/dodraw.c

For an example of some code that creates an NMG object, you might examine librt/g_arb.c: rt_arb_tess() and librt/g_ell.c: rt_ell_tess(). I don't promise that either are "clean" or the "best" way to accomplish that task, but they arn't bad, and work.

You are welcome to consider either the Release 4.0 versions, or the latest sources from wolf:/m/cad, although I note that the later may be in a state of disrepair on occasion, as Lee and I are working hard on the code, between briefings, TDY, and other excitement provided from on high.

After you've spent a little while looking around, it would probably be appropriate to get together and chat for an hour or two some afternoon, to answer whatever questions have come up.

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa04666; 9 Oct 92 1:14 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa24066; 9 Oct 92 1:09 EDT Received: from wolf16.brl.mil by VMB.BRL.MIL id aa24060; 9 Oct 92 1:05 EDT Date: Fri, 9 Oct 92 1:05:08 EDT From: Mike Muuss <mike@BRL.MIL> To: "Bruce A. Rickter" <bar@BRL.MIL> cc: cad@BRL.MIL Subject: Re: bw-imp Message-ID: <9210090105.aa04650@WOLF.BRL.MIL>

Bruce writes -

> What do the options -s squaresize, -w width, and > -h height do?

They specify the size of the input file. For a more full description of these options (which show up on almost every image processing command in BRL-CAD), run "man brlcad". That man page documents the overall conventions for command line options.

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa01084; 29 Jul 92 13:51 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id ai00267; 29 Jul 92 13:29 EDT Received: from vim.brl.mil by VMB.BRL.MIL id ab00224; 29 Jul 92 13:22 EDT Date: Wed, 29 Jul 92 13:17:29 EDT From: Jim Hunt <jehunt@BRL.MIL> To: Pat Gatewood <pat@helga.setd-ctl.nawcad.navy.mil> cc: cad@BRL.MIL Subject: Re: Trouble making edpix on sgi Message-ID: <9207291317.aa06485@VIM.BRL.MIL>

I can not reproduce this error on Irix 4.0.5, but do recall the exact same trouble when we were running 4.0.1. The fix is to put the Font Manager Library ( libfm_s.a ) before the other libraries:

./cad/edpix/Cakefile: 20c20 < CC LDFLAGS -o edpix OBJ LIB_PRE''LIBRLE -lgl_s -lfm_s LIBES --- > CC LDFLAGS -o edpix OBJ -lfm_s LIB_PRE''LIBRLE -lgl_s LIBES

I believe the C compiler is going through some groing pains? At leaset it has had other difficulties between 4.0.1 and 4.0.5 so for now I will blame it. Let me know if the problem persists.

-jim Hunt

Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa21046; 28 Oct 92 14:31 EST Date: Wed, 28 Oct 92 14:29:19 EST From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> To: acst@BRL.MIL, pjt@BRL.MIL cc: cmoore@BRL.MIL Subject: noise around the edges? Message-ID: <9210281429.aa18179@WUMPUS.BRL.MIL>

I had sent a previous message to PJT about this. Here, I am providing a sample run. Sending to "cad" reaches too many people at this time; besides, people outside the former BRL can't get at this sample.

On WUMPUS, look up the directory /vld/cmoore/CELLFBTEST , and run the executable (user-readable) file "runstream". For starters: Why do I get white space instead of red space (the latter indicating a value of 1) at (y = -40) x=+16,+12,-32,-40? x is the first field, y is the 2nd field, and I am plotting the 3rd field.

Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa00320; 29 Oct 92 15:43 EST Date: Thu, 29 Oct 92 15:39:38 EST From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> To: acst@BRL.MIL, pjt@BRL.MIL Subject: [Carl Moore: noise around the edges?] Message-ID: <9210291539.aa23543@WUMPUS.BRL.MIL>

Disregard this message (and I am deleting the copy to myself). Field number 3 is the third field AFTER the x and y columns. In other words, I was comparing field 3 to field 1.

----- Forwarded message # 1:

Date: Wed, 28 Oct 92 14:29:19 EST From: Carl Moore (VLD/VMB) <cmoore@BRL> To: acst@BRL.MIL, pjt@BRL.MIL cc: cmoore@BRL Subject: noise around the edges? Message-ID: <9210281429.aa18179@WUMPUS.BRL.MIL>

I had sent a previous message to PJT about this. Here, I am providing a sample run. Sending to "cad" reaches too many people at this time; besides, people outside the former BRL can't get at this sample.

On WUMPUS, look up the directory /vld/cmoore/CELLFBTEST , and run the executable (user-readable) file "runstream". For starters: Why do I get white space instead of red space (the latter indicating a value of 1) at (y = -40) x=+16,+12,-32,-40? x is the first field, y is the 2nd field, and I am plotting the 3rd field.

----- End of forwarded messages

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa04877; 2 Nov 92 17:58 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa22195; 2 Nov 92 16:31 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa22067; 2 Nov 92 16:16 EST Date: Mon, 2 Nov 92 16:12:33 EST From: Mike Muuss <mike@BRL.MIL> To: "Kenneth H. Fielding" <kfieldin@afit.af.mil> cc: cad@BRL.MIL Subject: Re: animation for brl-cad Message-ID: <9211021612.aa03696@WOLF.BRL.MIL>

It seems like external interest in animation using BRL-CAD is suddenly picking up:

> From: "Kenneth H. Fielding" <kfieldin@afit.af.mil> > > I would like to generate say a 10 frame sequence where I can define > scale, orientation, and position for the object in each frame. The > frames can then be ganged together to make a "movie". > > what is the easiest and most straight forward way to do this in > either "rt" or "lgt"?

> From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> > > I don't know the easiest way. Hopefully, if tools exist to do in-betweening > or other useful steps in generating smooth animation sequences, someone else > will speak up. I recall some buggy frame-interpolation software that used > to be available at BRL, but it was never made available for general use.

I'm not sure what software Gary is making reference to, but in Release 4.0 you will find the two primary tools that I have used for making animations: TABINTERP and TABSUB. They don't have manual pages at the moment.

TABINTERP is a table-based interpolator that can take an arbitrary collection of columns from an arbitrary number of input files, and resamples them using a selection of interpolators (including spline).

TABSUB is a macro processor especially suited for generating RT animation scripts from the output of TABINTERP.

Keyframes can be specified using MGED, by hand, or using an external program. I've done it all three ways.

Once an animation script has been prepared, it can be fed to either RT or REMRT on stdin by giving the -M flag on the commandline. All frames will be computed in sequence, with "checkpoint-restart" handled automaticly, so that the machine going down won't cost you more than a few pixels of the final result.

Note that the RT animation script facility can BOTH (a) move the eyepoint around stationary geometry, and (b) articulate the geometry at any number of arcs in the database DAG (tree). For example, the eye (camera) could by flying, while a rotation was being superimposed on the arc tank.g/turret.g.

Lee Butler has a draft of a paper on how to use this capability. It is not complete, but should serve as a useful baseline. Contact him at <butler@brl.mil>.

Also note that there is a tutorial session on using this capability being given by Chris Johnson at the BRL-CAD Users Conference this week. Contact the conferenct at 800-466-4862 for info. While I have not seen his presentation materials, he has produced quite a number of successful animation sequences using the RT animation capability, so his talk should be quite informative.

I'm sorry that there isn't more written about this stuff, but writing takes time. After you have looked over the intro materials, I'd be happy to send you an example of a simple animation.

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa15738; 11 Nov 92 15:15 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08475; 11 Nov 92 14:25 EST Received: from wharf.brl.mil by VMB.BRL.MIL id aa08473; 11 Nov 92 14:21 EST Received: from ti.com by WHARF.BRL.MIL id aa20376; 11 Nov 92 14:36 EST Received: from mk1501.dseg.ti.com ([128.247.206.175]) by ti.com with SMTP (5.59/LAI-3.2) id AA07893; Wed, 11 Nov 92 13:38:48 CST Received: from medusa.dseg.ti.com by mk1501.dseg.ti.com with SMTP (5.59/LAI-3.2) id AA10620; Wed, 11 Nov 92 13:37:46 CST Received: from ares.dseg.ti.com by medusa.dseg.ti.com (4.1/SMI-4.1) id AA14172; Wed, 11 Nov 92 13:37:26 CST Date: Wed, 11 Nov 92 13:37:26 CST From: harry campbell <harry@medusa.dseg.ti.com> Message-Id: <9211111937.AA14172@medusa.dseg.ti.com> To: cad@BRL.MIL Subject: perspective switch for MGED

At the BRLCAD conference it was demonstrated that their is a toggle switch for perspective viewing in MGED. On the SGI machines I beleive it was F2 or F3. One of the other keys could then be used to flip through the major perspective angles (90,60,30).

I have tried to put MGED into perspective viewing mode, and it doesn't seem to work. We have BRLCAD running on SPARC IPX. Is perspective viewing supported for the SUN running X? If so, what is the keystroke to turn it on?

Harry Campbell

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa16782; 11 Nov 92 20:11 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa09563; 11 Nov 92 19:26 EST Date: Wed, 11 Nov 92 19:18:33 EST From: "Lee A. Butler" <butler@BRL.MIL> To: harry campbell <harry@medusa.dseg.ti.com> cc: cad@BRL.MIL Subject: Re: perspective switch for MGED Message-ID: <9211111918.aa09557@VMB.BRL.MIL>

Alas, I believe the perspective function button is only available on the SGI at the moment.

Lee A. Butler U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa21107; 16 Nov 92 15:49 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa11754; 16 Nov 92 15:21 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa11664; 16 Nov 92 15:14 EST Date: Mon, 16 Nov 92 15:36:29 EST From: Mike Muuss <mike@BRL.MIL> To: Support@results.com cc: cad@BRL.MIL, harry campbell <harry@medusa.dseg.ti.com> Subject: Re: perspective switch for MGED Message-ID: <9211161536.aa21053@WOLF.BRL.MIL>

> The perspective viewing mode is not available under X. The reason is that > the perspective is generated in the view module of mged. Under the sgi > view module each vector is passed through a (hardware) matrix multiply. > There is no such manipulation in the X window support.

The details here are incorrect. In Release 4.0, the perspective is generated in the SGI-specific display manager module mged/dm-4d.c (*not* the view module). Both the SGI and the X display managers already transform each vector by a 4x4 transform matrix. But the conclusion is right -- in Release 4.0, there is no perspective viewing on the X interface.

However, in the development version of MGED, perspective support has been pushed up into the "top half" of the display interface, and thus automaticly operates properly on X displays, and all other displays.

No function key has been assigned on the X display yet, but keyboard commands can be used to assign the viewing angle, like:

set perspective=90 and set perspective=42.5

It can be turned off (orthoview) with

set perspective=0

Something to look forward to in the next release. Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa27709; 13 Nov 92 11:08 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25393; 13 Nov 92 10:11 EST Received: from worm.brl.mil by VMB.BRL.MIL id aa25316; 13 Nov 92 10:05 EST Date: Fri, 13 Nov 92 10:16:14 EST From: "Jill H. Smith, Ch., Vuln. Meth. Br." <jill@BRL.MIL> To: cad@BRL.MIL cc: jleonard@mbv.mbvlab.wpafb.af.mil Subject: [Jim Leonard: X term with BRLCAD] Message-ID: <9211131016.aa19779@WORM.BRL.MIL>

All,

Can anyone help Jim get is display diplaying?

Jill

----- Forwarded message # 1:

Received: from wharf.brl.mil by WORM.BRL.MIL id aa19456; 13 Nov 92 9:59 EST Received: from fivs01.flight.wpafb.af.mil by WHARF.BRL.MIL id aa08436; 13 Nov 92 9:40 EST Received: from fovea.mbvlab.wpafb.af.mil ([134.131.203.6]) by mbv (4.1/SMI-4.1) id AA13590; Fri, 13 Nov 92 09:39:04 EST Date: Fri, 13 Nov 92 09:39:04 EST From: Jim Leonard <jleonard@mbvlab.wpafb.af.mil> Message-Id: <9211131439.AA13590@mbv> To: jill@BRL.MIL Subject: X term with BRLCAD

Jill, I'm Jim Leonard and I talked with you at the conference last week. I am running the CAD on a Sun 4 using X11R4 on a Mac running AUX. Running mged everything is fine until I do a ray trace. The frame buffer opens and stays but the window stays black. I have: setenv DISPLAY to my Mac computer setenv FB_FILE /dev/Xl

Does anyone have any ideas what I need to do to get the frame buffer displayed? Thanks Jim Leonard jleonard@mbv.mbvlab.wpafb.af.mil phone DSN 785-1115 or commercial (513)255-1115

----- End of forwarded messages

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa28246; 13 Nov 92 12:30 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa26309; 13 Nov 92 11:23 EST Received: by VMB.BRL.MIL id aa26140; 13 Nov 92 11:13 EST Date: Fri, 13 Nov 92 11:11:28 EST From: "Lee A. Butler" <butler@BRL.MIL> To: "Jill H. Smith, Ch., Vuln. Meth. Br." <jill@BRL.MIL> cc: cad@BRL.MIL, jleonard@mbv.mbvlab.wpafb.af.mil Subject: Re: [Jim Leonard: X term with BRLCAD] Message-ID: <9211131111.aa26126@VMB.BRL.MIL>

>everything is fine until I do a ray trace. The frame buffer opens and stays >but the window stays black. I have: >setenv DISPLAY to my Mac computer >setenv FB_FILE /dev/Xl

I'm just guessing, but it could be that you need to make sure the mouse pointer moves into the framebuffer window. Since the X server will probably need to load a new color map for that window, you may not see anything until the mouse is in the window.

Taking another stab in the dark, can you display one of the pix files that came with BRL-CAD? Try: pix-fb -F /dev/Xl brlcad/pix/moss.pix

Since I don't have a Mac to try this on, I can't offer much else.

Lee

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa29993; 13 Nov 92 14:56 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa28268; 13 Nov 92 14:16 EST Received: from wharf.brl.mil by VMB.BRL.MIL id aa28178; 13 Nov 92 14:08 EST Received: from relay2.UU.NET by WHARF.BRL.MIL id aa10614; 13 Nov 92 14:16 EST Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA11419; Fri, 13 Nov 92 14:16:18 -0500 Received: from results.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 141114.2695; Fri, 13 Nov 1992 14:11:14 EST Received: from localhost by results.com (5.64/A/UX-AMR-1.0) id AA22820; Fri, 13 Nov 92 14:53:53 EST Message-Id: <9211131953.AA22820@results.com> Date: Fri, 13 Nov 1992 14:54:00 -0800 To: cad@BRL.MIL, "Jill H. Smith, Ch., Vuln. Meth. Br." <jill@BRL.MIL> From: Support@results.com Subject: Re: [Jim Leonard: X term with BRLCAD] Cc: jleonard@mbv.mbvlab.wpafb.af.mil

>To: jill@BRL.MIL >Subject: X term with BRLCAD > >Jill, >I'm Jim Leonard and I talked with you at the conference last week. I am >running the CAD on a Sun 4 using X11R4 on a Mac running AUX. Running mged >everything is fine until I do a ray trace. The frame buffer opens and stays >but the window stays black. I have: >setenv DISPLAY to my Mac computer >setenv FB_FILE /dev/Xl > >Does anyone have any ideas what I need to do to get the frame buffer displayed? >Thanks >Jim Leonard >jleonard@mbv.mbvlab.wpafb.af.mil

Jim,

The most likely problem you are having with your X display under A/UX (assuming that you are using MacX) is that you are using the wrong screen. The method that I use is: Make a version of libfb under A/UX that has X support compiled in. (There is a #if 0/1 in /m/cad/Cakefile.defs to do this) cd /m/cad/libfb cake clean; cake libfb.a cd ../fbserv cake (install fbserv) edit /m/cad/Cakefile.defs to change the frame buffer support to no X) cd /m/cad/libfb;cake clean; cake libfb.a

Once fbserv is installed, try the following: DISPLAY=localhost:0.2;export DISPLAY fbserv -F/dev/X 0& on your sun: FB_FILE=mac_name:0;export FB_FILE pix-fb /m/cad/pix/world.pix

This should work. Be aware that color support is not very good for X yet.

Chris Johnson -- Support@results.com 1-800-497-6165 BRL-CAD Support Group. Installations, technical support, animations, printing, plus more.

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa04279; 18 Nov 92 22:35 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa08369; 18 Nov 92 22:26 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa08365; 18 Nov 92 22:23 EST Date: Wed, 18 Nov 92 22:27:14 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: >9999 solids for VDECK Message-ID: <9211182227.aa03665@WOLF.BRL.MIL>

Responding to the suggestion of Tom Sullivan of SANDIA at the recent BRL-CAD Users Conference, I have modified the development copy of VDECK to support the creation of .cg files containing more than 9999 solids. This can be important for the calculation of radar signatures of certain large geometry files on Sandia's parallel machines.

Here is the RCS log entry:

date: 92/11/18 22:21:02; author: mike; state: Exp; lines added/del: 20/6 Added improvement suggeted by Tom Sullivan of Sandia to permit solids with numbers > 9999 to be referenced by a subtraction operation in the region table, by substituting operator "nn#" for " -#".

If you need this modification to support your work, please drop me a line and I'll E-mail it to you.

Best, -Mike

PS: Thanks to Harry Reed of GSI for the use of the Havoc 'chopper model, which I instanced 8 times to make a suitably large database to test the >9999 solids condition.

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa10101; 14 Dec 92 15:48 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa25706; 14 Dec 92 15:37 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa25651; 14 Dec 92 15:28 EST Date: Mon, 14 Dec 92 15:30:37 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: libfb autosize Message-ID: <9212141530.aa09776@WOLF.BRL.MIL>

Following up on a remark that Chris Johnson made at the BRL-CAD User's Conference, and motivated by having to process some SIGS images, I have expanded the autosize functionality of LIBFB (usually obtained with the "-a" flag on programs) so that if the image is exactly square (of any dimension), it will autosize.

This means that, e.g., 1800x1800 or 200x200 images or 52x52 images will all autosize, without having to add those sizes to the table.

Something to look forward to in the next release. Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa08776; 6 Jan 93 23:43 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa07211; 6 Jan 93 23:23 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id aa07199; 6 Jan 93 23:09 EST Date: Wed, 6 Jan 93 23:13:50 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: 'f' option to /dev/ab (LIBFB) Message-ID: <9301062313.aa08331@WOLF.BRL.MIL>

This evening, I added an 'f' option to the LIBFB routine if_ab.c, so that instead of writing .YUV data over the EtherNet to a network connected Abekas, the .YUV data is written into a disk file.

For example, the command:

pix-fb -F /dev/abovf@prefix#42 dragon.pix

will create the disk file:

prefix42.yuv

When the 'f' flag is given, what is usually the host name (following the '@') is now interpreted as a prefix string, which may include slashes to indicate a full path. The suffix of ".yuv" is always provided.

Similarly, the command

fb-pix -F /dev/abvf@/tmp/#42 newfile.pix

will read the (framebuffer) disk file "/tmp/42.yuv" and store it in "newfile.pix".

This new option should allow more efficient use of disk space when creating animations destined exclusively for an Abekas, because .YUV files are smaller than .PIX files. Also, if frames are stored in .YUV format, they can be bulk loaded to the Abekas without having to pay the 4-seconds per frame processing time for converting .PIX to .YUV. The transmission then becomes simply:

rcp *.yuv abekas:

This also makes it easy to write Abekas backup/restore formatted 8mm Exabyte tapes directly from the UNIX host. The Abekas loads images about twice as fast from the Exabyte as it does over the Ethernet. That, plus the advantage of getting a tape backup copy as a "free" by-product, makes this attractive for longer animations. More on this in some future note.

Best, -Mike

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa09594; 7 Jan 93 2:10 EST Received: from VMB.BRL.MIL by VMB.BRL.MIL id ab07211; 6 Jan 93 23:23 EST Received: from wolf16.brl.mil by VMB.BRL.MIL id ab07199; 6 Jan 93 23:09 EST Date: Wed, 6 Jan 93 23:20:53 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: /dev/ab addition Message-ID: <9301062320.aa08721@WOLF.BRL.MIL>

The line that read:

fb-pix -F /dev/abvf@/tmp/#42 newfile.pix

is likely to be more satisfying if it reads:

fb-pix -w720 -n486 -F /dev/abvf@/tmp/#42 newfile.pix

so that all the pixels are converted. (The default is -s512, which does not process all 720 pixels across).

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa11334; 20 Jan 93 13:59 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa20768; 20 Jan 93 13:30 EST Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa20644; 20 Jan 93 13:23 EST Date: Wed, 20 Jan 93 13:18:39 EST From: Mike Markowski <mm@BRL.MIL> To: cad@BRL.MIL Subject: NMG Polygon Extruder Organization: US Army Research Laboratory Message-ID: <9301201318.aa10569@WOLF.BRL.MIL>

Many brl-cad users have been interested in extruding into 3d an arbitrary polygon or in adding thickness to faceted objects.

Yesterday I finished a subroutine that given an NMG face and a vector, will extrude the face based on the direction and magnitude of the vector. The routine handles a single face of one or more loops. This is the 1st step towards a routine allowing general (multiple face) extrusion of faceted objects.

Stay tuned, Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa09877; 20 Jan 93 11:27 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa15940; 20 Jan 93 10:08 EST Received: from waffle.brl.mil by WALRUS.BRL.MIL id aa15805; 20 Jan 93 10:01 EST Date: Wed, 20 Jan 93 9:57:35 EST From: Paul Stay <stay@BRL.MIL> To: cad@BRL.MIL cc: phd@BRL.MIL, jill@BRL.MIL Subject: Hidden Line Drawings and Plot Files Message-ID: <9301200957.aa04781@WAFFLE.BRL.MIL>

At a recent meeting it was asked how to produce HPGL or Postscript files for line plots (hidden line drawings). Since it seems to of general interest in the community I thought that I would give a brief description on how to do this.

The first phase is to get a plot file made. I will use the m35 truck found in the database to illustrate on how this is done.

To get a top view of the m35 truck made into a plot file you can use the rthide command. rthide -o top.pl -s 1024 -a 90 -e 90 m35.g component

This creates an Extended Unix Plot file, the extended Plot format allows for 3D data, color, space bounding boxes, etc. You can look in the libplot directory for more info.

We now need to Rotate the plotfile, Scale it, convert it to the standard Unix Plot format.

plrot -a 90 -e 90 -g top.pl | pl-pl -S > top2.pl

The plot file is now ready to convert to a number of different formats and there are several converters, pl-tek Plot to Tektronix pl-ps Plot to Postscript pl-hpgl Plot to HP GL format pl-fb Plot to BRLCAD Frame buffer

If you want hpgl then do

pl-hpgl < top2.pl > top.hpgl

I tested the above including sending the top.hpgl to our Tektronix Phaser III in hpgl mode.

You will want to look at the man pages for details on each of the above programs.

The following script can be used to generate a side view of the database

and can be called by

side.sh m35.g component

----------------------------- side.sh ---------------------------

#!/bin/sh

PATH=/usr/brlcad/bin

rthide -s 512 -a 90 -e 0 $1 $2 | plrot -a 90 -e 0 -g \ | pl-pl -S | pl-hpgl

-----------------------------------------------------------------

Hope this helps.

-Paul

Date: Mon, 25 Jan 93 11:48:39 EST From: Mike Muuss <mike@brl> To: ACST@BRL.MIL cc: Jill@BRL.MIL, PHD@BRL.MIL Subject: Another NMG note Message-ID: <9301251148.aa10034@WOLF.BRL.MIL>

One major item which I forgot to mention on Friday was the creation of a new support module, nmg_visit.c, which handles recursive descent of the NMG data structures, invoking caller-provided functions at relevant stops along the way. This makes tasks like "visit all the vertices" (which can be reached 5 different ways) very simple to program. Best, -Mike

Date: Thu, 18 Feb 93 6:16:07 EST From: Mike Muuss <mike@brl> To: Jill@BRL, ACST@BRL, Davisson@BRL Subject: 2d NMG intersector Message-ID: <9302180616.aa20220@WOLF.BRL.MIL>

This evening I got the 2D (co-planar face) code to do it's first test case successfully, which is very encouraging.

Along the way I re-learned that eu->eumate_p->vu_p is not at all the same as RT_LIST_PNEXT_CIRC(edgeuse,eu)->vu_p -- the vu's UP pointer is in the faceuse of *opposite* orientation in the first case, and the correct orientation in the second case. Important difference, even if the first formula is easier to type.

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa27244; 19 Feb 93 1:40 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa12809; 19 Feb 93 1:23 EST Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa12807; 19 Feb 93 1:20 EST Date: Fri, 19 Feb 93 1:19:13 EST From: Mike Muuss <mike@BRL.MIL> To: joe edward meier <jem@bruker.com> cc: CAD@BRL.MIL Subject: Re: Getting some example models Message-ID: <9302190119.aa27182@WOLF.BRL.MIL>

> I just got my 4.0 documentation, and after just scanning through > it looks pretty impressive. I think everyone did a good job.

Thanks! It's also good to know that the boxes are making it through the mail, too.

> On to the actual topic. I was very impressed by the complexity of > some of the models displayed (created in mged), and I thought it would > be a big help in learning how to design complex models if I had one > or two of these to play with and see how they were built.

Probably the best way to gear up a staff for a large model building task would be to contact one of several companies which provide BRL-CAD training courses, and take a class. CSG model building is a little bit different than traditional modeling, and the current documentation is not oriented towards this.

A lack which we are aware of. There are plans afoot to have more documentation created, but it won't be in the hands of end-users for at least another year.

> So, is > it possible to get via ftp some of these models, like the M1A1 > and/or the Bradley.

There are some restrictions on what geometric models can be distributed, and there is a small handling fee associated with acquiring each model and it's supporting documentation. Please contact Keith Applin at N/A-N/A-NANA <xxx@xxx.xxx> for information about what models are available, and what the distribution arrangements are.

On the other hand, you might want to examine the "db/" directory in BRL-CAD Release 4.0 -- it contains a railroad tank car (db/tank_car.asc) and a Havoc 'chopper (db/havoc.asc), both very nice looking models which were provided courtesy of Harry Reed, Geometric Solutions Inc.

Best, -Mike Muuss

The US Army Research Laboratory APG, MD 21005-5068

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa27483; 19 Feb 93 2:33 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa12870; 19 Feb 93 2:04 EST Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa12864; 19 Feb 93 2:00 EST Date: Fri, 19 Feb 93 1:56:19 EST From: Mike Muuss <mike@BRL.MIL> To: joe edward meier <jem@bruker.com> cc: CAD@BRL.MIL Subject: Re: Does the ev command work in 4.0 Message-ID: <9302190156.aa27299@WOLF.BRL.MIL>

> From: joe edward meier <jem@bruker.com> > > Does the "ev" command work in the 4.0 version of meged. When I > use the command the whole program quits.

In the 4.0 Release, the "ev" command does occasionally work, but only on exceedingly simple cases. It is provided more so that interested developers can examine the code to learn more about how the NMG routines can be used, than to provide an end-user service.

We felt it important to ship Release 4.0 with a non-working NMG library so that users could take advantage of the many other improvements and optimizations it contains, rather than delaying the rest of the software a substantial length of time (years, as it has turned out). The maintenance release will provide a functional NMG library.

Expect this pattern to recur. Release 5.0 will probably have initial support for trimmed-NURBS (t-NURBS), and in Release 5.1 the t-NURBS support will be complete.

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa11367; 20 Feb 93 6:45 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa25352; 20 Feb 93 6:15 EST Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa25337; 20 Feb 93 6:13 EST Date: Sat, 20 Feb 93 6:02:58 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: nmg_esplit() arg change Message-ID: <9302200602.aa10899@WOLF.BRL.MIL>

In preparation for doing code review on the first set of modules which comprise the NMG support library, I encountered the routine nmg_esplit(), the function of which was difficult to describe.

To make the function more precise, easier to understand, and much easier for calling routines to use, the second argument was changed from being an edge to an edgeuse (of that edge), and the return code was changed from being an edge to an edgeuse, also.

The new calling sequence is:

struct edgeuse * nmg_esplit(v, eu) struct vertex *v; struct edgeuse *eu; { }

This routine was only used by internal routines, and in only a few places, so the change was not disruptive. Furthermore, in every instance, the previous call had been

nmg_esplit( v, eu->e_p );

so changing that to be

nmg_esplit( v, eu );

was no hardship. Since this routine is mentioned in the documentation, there is a slight chance that other code developers have written something which makes use of it. That is the purpose of this message, to warn of the impending change.

Both the compile time argument checking (on ANSI C compilers) and the customary NMG library's run-time argument checking (on all systems) will assist in swiftly isolating any non-library code which needs to be modified to deal with this change.

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa14914; 23 Feb 93 16:53 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa23400; 23 Feb 93 16:29 EST Received: from wumpus.brl.mil by WALRUS.BRL.MIL id aa23398; 23 Feb 93 16:26 EST Date: Tue, 23 Feb 93 16:18:50 EST From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> To: yih <ged@BRL.MIL> Subject: cross section areas Message-ID: <9302231618.aa17803@WUMPUS.BRL.MIL>

A question reached me about cross-section area in mged, and I was able to provide only a partial answer (i.e., I don't know of being able to cut a plane through a target and get the area showing up on that plane).

The partial answer was that I can do the "area" command within mged and get the presented area of the view that I am currently displaying.

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa00655; 24 Feb 93 13:13 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa27564; 24 Feb 93 10:31 EST Date: Wed, 24 Feb 93 10:20:27 EST From: "Edwin O. Davisson" (BVLD/VMB) <davisson@BRL.MIL> To: JOHN H SUCKLING <john@BRL.MIL> cc: Carl Moore <cmoore@BRL.MIL>, yih <ged@BRL.MIL> Subject: Re: cross section areas Message-ID: <9302241020.aa27130@WALRUS.BRL.MIL>

The presented area calculated with a view normal to the cutting plane would be the area of the cross-section provided that the projection of the rest of the object does not spill into places outside of the 2-d regions defined by the planar cut.

There may be elegant MGED solutions to this in place, but I don't know of them.

If you are planning to get a good approximation--one which avoids the problem mentioned above, you can make a second planar cut parallel and near to the first and subtract the backside of the region before making the presented area calculation. That will improve your chances of getting the area of the slice of baloney of interest.

Ed

Received: from walrus.brl.mil by WOLF.BRL.MIL id ac00655; 24 Feb 93 13:13 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id ab28267; 24 Feb 93 11:22 EST Received: from wumpus.brl.mil by WALRUS.BRL.MIL id aa28242; 24 Feb 93 11:19 EST Date: Wed, 24 Feb 93 11:12:17 EST From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> To: davisson@BRL.MIL cc: yih <ged@BRL.MIL> Subject: Re: cross section areas Message-ID: <9302241112.aa21765@WUMPUS.BRL.MIL>

Yes, I got the cross-section in a test I just ran with a 1-inch cube. At azim 0 & elev 0, I was looking head on at one of the faces (with another face being flush with the ground), and at that view "area" gave me 1 square inch. Then I went to azim 45 & elev 0, and "area" gave me square-root-of-two (about 1.414) square inches.

I also don't know what I'd do to pass a different cutting plane through. The best I could do would be to delete (using "d") objects which project beyond the area I want to see.

Another test with the cube was to go back to azim 0 & elev 0 and hollow out a portion of it so that what's left looked something like:

***** ***** * * instead of ***** ***** *****

and I still got 1 square inch. Notice that the face which is showing still has all its edges intact. I then expanded the subtraction so that part of one of those edges was chopped off:

* * * * *****

and that reduced what "area" gave me. "area" is obviously ignoring holes except for holes which cut into the outer edge.

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa18245; 1 Mar 93 17:30 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa17213; 1 Mar 93 16:55 EST Received: from waffle.brl.mil by WALRUS.BRL.MIL id aa17185; 1 Mar 93 16:45 EST Date: Mon, 1 Mar 93 16:43:31 EST From: Paul Stay <stay@BRL.MIL> To: huston@huston.mdc.com cc: CAD@BRL.MIL Subject: Re: Ray tracing of NURBS objects Message-ID: <9303011643.aa24667@WAFFLE.BRL.MIL>

Stu-

The algorithm which is used by the BRL-CAD software is based on algorithms found in the SigGraph 1990 paper "Ray Tracing Trimmed rational Surface Patches" by Nishita, Sederburg, Kamimoto, The routines are a combination of librt and libnurb. The libnurb routines are included in the librt library.

A sample data base can be generated by using the teapot program found in the proc-db directory.

Currently the Nurb raytracing routines do not handle trimmed nurbs. Eventually there will be support for trimmed nurbs as part of the NMG routines. At the time of the last BRL-CAD meeting the libnurb library routines were still in a state of change. I hope to have some documentation on the libnurb library before the next release.

-Paul

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa20193; 8 Mar 93 16:08 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa18544; 8 Mar 93 16:07 EST Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa18364; 8 Mar 93 16:00 EST Date: Mon, 8 Mar 93 15:53:51 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: Kodak Photo-CD Message-ID: <9303081553.aa19771@WOLF.BRL.MIL>

On Friday, I was able to test the program "hpcdppm" which I obtained from the network. It worked, allowing my Sun-4 workstation to read images off a Kodak Photo-CD CD-ROM.

It was short work to mutate that program into "pcd-pix", and that works too.

Basically, any machine that can mount a CD-ROM with High Sierra (ISO 9660) filesystem and retrieve files from there is likely to be able to use this program.

This represents a new way that experimental and field data can be digitized and brought into the computer for analysis. Best, -Mike

Received: from vat.brl.mil by WOLF.BRL.MIL id aa24502; 22 Mar 93 16:24 EST Date: Mon, 22 Mar 93 16:15:55 EST From: "John R. Anderson" (SLAD/BVLD/ASB) <jra@BRL.MIL> To: mike@BRL.MIL, jill@BRL.MIL cc: earl@BRL.MIL Subject: IGES/PDES Organization (IPO) Meeting Message-ID: <9303221615.aa07919@VAT.BRL.MIL>

Dr. Walbert has agreed to provide funding for me to TDY to the IPO meeting in Nashville the week of April 4. If both of you are agreeable, I would like to attend.

Mike, I haven't had a chance to talk to you about IGES, but there are a few problems with the standard for a hybrid system with boolean trees (like BRLCAD). One problem is that the CSG standard has a limited vocabulary of primitive solids, and in particular cannot handle our TGC, polysolid, or arb8's with non-right angles. When Earl and I heard about the BREP standard, we thought that these solids could be handled by making them BREP objects. Unfortunately, when the new standard came out, the CSG boolean trees were prohibited from containing BREP objects, so we are still stuck. It seems to us (Earl and me) that the solution is to remove the restriction on CSG boolean trees and possibly enrich the CSG vocabulary.

Another concern is that the same people who developed IGES are developing PDES. If we don't do something now, we are likely to end up with the same problems on PDES. This meeting in Nashville is a combined meeting of both the IGES and PDES people and is a convenient oppurtunity to start pushing those people around to "correct" thinking.

-John

Received: from spark.brl.mil by WOLF.BRL.MIL id aa00431; 24 Mar 93 0:35 EST Date: Wed, 24 Mar 93 0:34:58 EST From: Phil Dykstra <phil@BRL.MIL> To: acst@BRL.MIL cc: jgrosh@BRL.MIL Subject: Another Animation Fix Message-ID: <9303240034.aa19979@SPARK.BRL.MIL>

I put the defaulting into MGED where "preview" uses the current MGED view if none is given in the script. Lets you preview animations from any angle, and saves the need to put view specs in your scripts.

- Phil

Received: from sem.brl.mil by WOLF.BRL.MIL id aa07004; 24 Mar 93 9:44 EST Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa12156; 24 Mar 93 9:41 EST Received: from tbd2.brl.mil by SEM.BRL.MIL id aa12146; 24 Mar 93 9:40 EST Date: Wed, 24 Mar 93 9:34:19 EST From: "C. Cindy Sim" <cindys@BRL.MIL> To: x11@BRL.MIL cc: turek@BRL.MIL Subject: NCD rgb.txt Message-ID: <9303240934.aa11380@TBD2.BRL.MIL>

Here is a copy of NCD rgb.txt which contains lots of colors. Could you replace this file with one that we currently have for rdist?

Cindy

-------------------------------------------------------

    255 250 250		snow
    248 248 255		ghost white
    248 248 255		GhostWhite
    245 245 245		white smoke
    245 245 245		WhiteSmoke
    220 220 220		gainsboro
    255 250 240		floral white
    255 250 240		FloralWhite
    253 245 230		old lace
    253 245 230		OldLace
    250 240 230		linen
    250 235 215		antique white
    250 235 215		AntiqueWhite
    255 239 213		papaya whip
    255 239 213		PapayaWhip
    255 235 205		blanched almond
    255 235 205		BlanchedAlmond
    255 228 196		bisque
    255 218 185		peach puff
    255 218 185		PeachPuff
    255 222 173		navajo white
    255 222 173		NavajoWhite
    255 228 181		moccasin
    255 248 220		cornsilk
    255 255 240		ivory
    255 250 205		lemon chiffon
    255 250 205		LemonChiffon
    255 245 238		seashell
    240 255 240		honeydew
    245 255 250		mint cream
    245 255 250		MintCream
    240 255 255		azure
    240 248 255		alice blue
    240 248 255		AliceBlue
    230 230 250		lavender
    255 240 245		lavender blush
    255 240 245		LavenderBlush
    255 228 225		misty rose
    255 228 225		MistyRose
    255 255 255		white
      0   0   0		black
     47  79  79		dark slate gray
     47  79  79		DarkSlateGray
     47  79  79		dark slate grey
     47  79  79		DarkSlateGrey
    105 105 105		dim gray
    105 105 105		DimGray
    105 105 105		dim grey
    105 105 105		DimGrey
    112 128 144		slate gray
    112 128 144		SlateGray
    112 128 144		slate grey
    112 128 144		SlateGrey
    119 136 153		light slate gray
    119 136 153		LightSlateGray
    119 136 153		light slate grey
    119 136 153		LightSlateGrey
    192 192 192		gray
    192 192 192		grey
    211 211 211		light grey
    211 211 211		LightGrey
    211 211 211		light gray
    211 211 211		LightGray
     25  25 112		midnight blue
     25  25 112		MidnightBlue
      0   0 128		navy
      0   0 128		navy blue
      0   0 128		NavyBlue
    100 149 237		cornflower blue
    100 149 237		CornflowerBlue
     72  61 139		dark slate blue
     72  61 139		DarkSlateBlue
    106  90 205		slate blue
    106  90 205		SlateBlue
    123 104 238		medium slate blue
    123 104 238		MediumSlateBlue
    132 112 255		light slate blue
    132 112 255		LightSlateBlue
      0   0 205		medium blue
      0   0 205		MediumBlue
     65 105 225		royal blue
     65 105 225		RoyalBlue
      0   0 255		blue
     30 144 255		dodger blue
     30 144 255		DodgerBlue
      0 171 232		decwblue
      0 171 232		DECWBlue
      0 191 255		deep sky blue
      0 191 255		DeepSkyBlue
    135 206 235		sky blue
    135 206 235		SkyBlue
    135 206 250		light sky blue
    135 206 250		LightSkyBlue
     70 130 180		steel blue
     70 130 180		SteelBlue
    176 196 222		light steel blue
    176 196 222		LightSteelBlue
    173 216 230		light blue
    173 216 230		LightBlue
    176 224 230		powder blue
    176 224 230		PowderBlue
    175 238 238		pale turquoise
    175 238 238		PaleTurquoise
      0 206 209		dark turquoise
      0 206 209		DarkTurquoise
     72 209 204		medium turquoise
     72 209 204		MediumTurquoise
     64 224 208		turquoise
      0 255 255		cyan
    224 255 255		light cyan
    224 255 255		LightCyan
     95 158 160		cadet blue
     95 158 160		CadetBlue
    102 205 170		medium aquamarine
    102 205 170		MediumAquamarine
    127 255 212		aquamarine
      0 100   0		dark green
      0 100   0		DarkGreen
     85 107  47		dark olive green
     85 107  47		DarkOliveGreen
    143 188 143		dark sea green
    143 188 143		DarkSeaGreen
     46 139  87		sea green
     46 139  87		SeaGreen
     60 179 113		medium sea green
     60 179 113		MediumSeaGreen
     32 178 170		light sea green
     32 178 170		LightSeaGreen
    152 251 152		pale green
    152 251 152		PaleGreen
      0 255 127		spring green
      0 255 127		SpringGreen
    124 252   0		lawn green
    124 252   0		LawnGreen
      0 255   0		green
    127 255   0		chartreuse
      0 250 154		medium spring green
      0 250 154		MediumSpringGreen
    173 255  47		green yellow
    173 255  47		GreenYellow
     50 205  50		lime green
     50 205  50		LimeGreen
    154 205  50		yellow green
    154 205  50		YellowGreen
     34 139  34		forest green
     34 139  34		ForestGreen
    107 143  36		medium forest green
    107 143  36		MediumForestGreen
    107 142  35		olive drab
    107 142  35		OliveDrab
    189 183 107		dark khaki
    189 183 107		DarkKhaki
    240 230 140		khaki
    238 232 170		pale goldenrod
    238 232 170		PaleGoldenrod
    250 250 210		light goldenrod yellow
    250 250 210		LightGoldenrodYellow
    255 255 224		light yellow
    255 255 224		LightYellow
    255 255   0		yellow
    255 215   0 		gold
    238 221 130		light goldenrod
    238 221 130		LightGoldenrod
    235 235 173		medium goldenrod
    235 235 173		MediumGoldenrod
    218 165  32		goldenrod
    184 134  11		dark goldenrod
    184 134  11		DarkGoldenrod
    188 143 143		rosy brown
    188 143 143		RosyBrown
    205  92  92		indian red
    205  92  92		IndianRed
    139  69  19		saddle brown
    139  69  19		SaddleBrown
    160  82  45		sienna
    205 133  63		peru
    222 184 135		burlywood
    245 245 220		beige
    245 222 179		wheat
    244 164  96		sandy brown
    244 164  96		SandyBrown
    210 180 140		tan
    210 105  30		chocolate
    178  34  34		firebrick
    165  42  42		brown
    233 150 122		dark salmon
    233 150 122		DarkSalmon
    250 128 114		salmon
    255 160 122		light salmon
    255 160 122		LightSalmon
    255 165   0		orange
    255 140   0		dark orange
    255 140   0		DarkOrange
    255 127  80		coral
    240 128 128		light coral
    240 128 128		LightCoral
    255  99  71		tomato
    255  69   0		orange red
    255  69   0		OrangeRed
    255   0   0		red
    255 105 180		hot pink
    255 105 180		HotPink
    255  20 147		deep pink
    255  20 147		DeepPink
    255 192 203		pink
    255 182 193		light pink
    255 182 193		LightPink
    219 112 147		pale violet red
    219 112 147		PaleVioletRed
    176  48  96		maroon
    199  21 133		medium violet red
    199  21 133		MediumVioletRed
    208  32 144		violet red
    208  32 144		VioletRed
    255   0 255		magenta
    238 130 238		violet
    221 160 221		plum
    218 112 214		orchid
    186  85 211		medium orchid
    186  85 211		MediumOrchid
    153  50 204		dark orchid
    153  50 204		DarkOrchid
    148   0 211		dark violet
    148   0 211		DarkViolet
    138  43 226		blue violet
    138  43 226		BlueViolet
    160  32 240		purple
    147 112 219		medium purple
    147 112 219		MediumPurple
    216 191 216		thistle
    255 250 250		snow1
    238 233 233		snow2
    205 201 201		snow3
    139 137 137		snow4
    255 245 238		seashell1
    238 229 222		seashell2
    205 197 191		seashell3
    139 134 130		seashell4
    255 239 219		AntiqueWhite1
    238 223 204		AntiqueWhite2
    205 192 176		AntiqueWhite3
    139 131 120		AntiqueWhite4
    255 228 196		bisque1
    238 213 183		bisque2
    205 183 158		bisque3
    139 125 107		bisque4
    255 218 185		PeachPuff1
    238 203 173		PeachPuff2
    205 175 149		PeachPuff3
    139 119 101		PeachPuff4
    255 222 173		NavajoWhite1
    238 207 161		NavajoWhite2
    205 179 139		NavajoWhite3
    139 121	 94		NavajoWhite4
    255 250 205		LemonChiffon1
    238 233 191		LemonChiffon2
    205 201 165		LemonChiffon3
    139 137 112		LemonChiffon4
    255 248 220		cornsilk1
    238 232 205		cornsilk2
    205 200 177		cornsilk3
    139 136 120		cornsilk4
    255 255 240		ivory1
    238 238 224		ivory2
    205 205 193		ivory3
    139 139 131		ivory4
    240 255 240		honeydew1
    224 238 224		honeydew2
    193 205 193		honeydew3
    131 139 131		honeydew4
    255 240 245		LavenderBlush1
    238 224 229		LavenderBlush2
    205 193 197		LavenderBlush3
    139 131 134		LavenderBlush4
    255 228 225		MistyRose1
    238 213 210		MistyRose2
    205 183 181		MistyRose3
    139 125 123		MistyRose4
    240 255 255		azure1
    224 238 238		azure2
    193 205 205		azure3
    131 139 139		azure4
    131 111 255		SlateBlue1
    122 103 238		SlateBlue2
    105  89 205		SlateBlue3
     71  60 139		SlateBlue4
     72 118 255		RoyalBlue1
     67 110 238		RoyalBlue2
     58  95 205		RoyalBlue3
     39  64 139		RoyalBlue4
      0   0 255		blue1
      0   0 238		blue2
      0   0 205		blue3
      0   0 139		blue4
     30 144 255		DodgerBlue1
     28 134 238		DodgerBlue2
     24 116 205		DodgerBlue3
     16  78 139		DodgerBlue4
     99 184 255		SteelBlue1
     92 172 238		SteelBlue2
     79 148 205		SteelBlue3
     54 100 139		SteelBlue4
      0 191 255		DeepSkyBlue1
      0 178 238		DeepSkyBlue2
      0 154 205		DeepSkyBlue3
      0 104 139		DeepSkyBlue4
    135 206 255		SkyBlue1
    126 192 238		SkyBlue2
    108 166 205		SkyBlue3
     74 112 139		SkyBlue4
    176 226 255		LightSkyBlue1
    164 211 238		LightSkyBlue2
    141 182 205		LightSkyBlue3
     96 123 139		LightSkyBlue4
    198 226 255		SlateGray1
    185 211 238		SlateGray2
    159 182 205		SlateGray3
    108 123 139		SlateGray4
    202 225 255		LightSteelBlue1
    188 210 238		LightSteelBlue2
    162 181 205		LightSteelBlue3
    110 123 139		LightSteelBlue4
    191 239 255		LightBlue1
    178 223 238		LightBlue2
    154 192 205		LightBlue3
    104 131 139		LightBlue4
    224 255 255		LightCyan1
    209 238 238		LightCyan2
    180 205 205		LightCyan3
    122 139 139		LightCyan4
    187 255 255		PaleTurquoise1
    174 238 238		PaleTurquoise2
    150 205 205		PaleTurquoise3
    102 139 139		PaleTurquoise4
    152 245 255		CadetBlue1
    142 229 238		CadetBlue2
    122 197 205		CadetBlue3
     83 134 139		CadetBlue4
      0 245 255		turquoise1
      0 229 238		turquoise2
      0 197 205		turquoise3
      0 134 139		turquoise4
      0 255 255		cyan1
      0 238 238		cyan2
      0 205 205		cyan3
      0 139 139		cyan4
    151 255 255		DarkSlateGray1
    141 238 238		DarkSlateGray2
    121 205 205		DarkSlateGray3
     82 139 139		DarkSlateGray4
    127 255 212		aquamarine1
    118 238 198		aquamarine2
    102 205 170		aquamarine3
     69 139 116		aquamarine4
    193 255 193		DarkSeaGreen1
    180 238 180		DarkSeaGreen2
    155 205 155		DarkSeaGreen3
    105 139 105		DarkSeaGreen4
     84 255 159		SeaGreen1
     78 238 148		SeaGreen2
     67 205 128		SeaGreen3
     46 139	 87		SeaGreen4
    154 255 154		PaleGreen1
    144 238 144		PaleGreen2
    124 205 124		PaleGreen3
     84 139	 84		PaleGreen4
      0 255 127		SpringGreen1
      0 238 118		SpringGreen2
      0 205 102		SpringGreen3
      0 139	 69		SpringGreen4
      0 255	  0		green1
      0 238	  0		green2
      0 205	  0		green3
      0 139	  0		green4
    127 255	  0		chartreuse1
    118 238	  0		chartreuse2
    102 205	  0		chartreuse3
     69 139	  0		chartreuse4
    192 255	 62		OliveDrab1
    179 238	 58		OliveDrab2
    154 205	 50		OliveDrab3
    105 139	 34		OliveDrab4
    202 255 112		DarkOliveGreen1
    188 238 104		DarkOliveGreen2
    162 205	 90		DarkOliveGreen3
    110 139	 61		DarkOliveGreen4
    255 246 143		khaki1
    238 230 133		khaki2
    205 198 115		khaki3
    139 134	 78		khaki4
    255 236 139		LightGoldenrod1
    238 220 130		LightGoldenrod2
    205 190 112		LightGoldenrod3
    139 129	 76		LightGoldenrod4
    255 255 224		LightYellow1
    238 238 209		LightYellow2
    205 205 180		LightYellow3
    139 139 122		LightYellow4
    255 255	  0		yellow1
    238 238	  0		yellow2
    205 205	  0		yellow3
    139 139	  0		yellow4
    255 215	  0		gold1
    238 201	  0		gold2
    205 173	  0		gold3
    139 117	  0		gold4
    255 193	 37		goldenrod1
    238 180	 34		goldenrod2
    205 155	 29		goldenrod3
    139 105	 20		goldenrod4
    255 185	 15		DarkGoldenrod1
    238 173	 14		DarkGoldenrod2
    205 149	 12		DarkGoldenrod3
    139 101	  8		DarkGoldenrod4
    255 193 193		RosyBrown1
    238 180 180		RosyBrown2
    205 155 155		RosyBrown3
    139 105 105		RosyBrown4
    255 106 106		IndianRed1
    238  99	 99		IndianRed2
    205  85	 85		IndianRed3
    139  58	 58		IndianRed4
    255 130	 71		sienna1
    238 121	 66		sienna2
    205 104	 57		sienna3
    139  71	 38		sienna4
    255 211 155		burlywood1
    238 197 145		burlywood2
    205 170 125		burlywood3
    139 115	 85		burlywood4
    255 231 186		wheat1
    238 216 174		wheat2
    205 186 150		wheat3
    139 126 102		wheat4
    255 165	 79		tan1
    238 154	 73		tan2
    205 133	 63		tan3
    139  90	 43		tan4
    255 127	 36		chocolate1
    238 118	 33		chocolate2
    205 102	 29		chocolate3
    139  69	 19		chocolate4
    255  48	 48		firebrick1
    238  44	 44		firebrick2
    205  38	 38		firebrick3
    139  26	 26		firebrick4
    255  64	 64		brown1
    238  59	 59		brown2
    205  51	 51		brown3
    139  35	 35		brown4
    255 140 105		salmon1
    238 130	 98		salmon2
    205 112	 84		salmon3
    139  76	 57		salmon4
    255 160 122		LightSalmon1
    238 149 114		LightSalmon2
    205 129	 98		LightSalmon3
    139  87	 66		LightSalmon4
    255 165	  0		orange1
    238 154	  0		orange2
    205 133	  0		orange3
    139  90	  0		orange4
    255 127	  0		DarkOrange1
    238 118	  0		DarkOrange2
    205 102	  0		DarkOrange3
    139  69	  0		DarkOrange4
    255 114	 86		coral1
    238 106	 80		coral2
    205  91	 69		coral3
    139  62	 47		coral4
    255  99	 71		tomato1
    238  92	 66		tomato2
    205  79	 57		tomato3
    139  54	 38		tomato4
    255  69	  0		OrangeRed1
    238  64	  0		OrangeRed2
    205  55	  0		OrangeRed3
    139  37	  0		OrangeRed4
    255   0	  0		red1
    238   0	  0		red2
    205   0	  0		red3
    139   0	  0		red4
    255  20 147		DeepPink1
    238  18 137		DeepPink2
    205  16 118		DeepPink3
    139  10	 80		DeepPink4
    255 110 180		HotPink1
    238 106 167		HotPink2
    205  96 144		HotPink3
    139  58  98		HotPink4
    255 181 197		pink1
    238 169 184		pink2
    205 145 158		pink3
    139  99 108		pink4
    255 174 185		LightPink1
    238 162 173		LightPink2
    205 140 149		LightPink3
    139  95 101		LightPink4
    255 130 171		PaleVioletRed1
    238 121 159		PaleVioletRed2
    205 104 137		PaleVioletRed3
    139  71	 93		PaleVioletRed4
    255  52 179		maroon1
    238  48 167		maroon2
    205  41 144		maroon3
    139  28	 98		maroon4
    255  62 150		VioletRed1
    238  58 140		VioletRed2
    205  50 120		VioletRed3
    139  34	 82		VioletRed4
    255   0 255		magenta1
    238   0 238		magenta2
    205   0 205		magenta3
    139   0 139		magenta4
    255 131 250		orchid1
    238 122 233		orchid2
    205 105 201		orchid3
    139  71 137		orchid4
    255 187 255		plum1
    238 174 238		plum2
    205 150 205		plum3
    139 102 139		plum4
    224 102 255		MediumOrchid1
    209  95 238		MediumOrchid2
    180  82 205		MediumOrchid3
    122  55 139		MediumOrchid4
    191  62 255		DarkOrchid1
    178  58 238		DarkOrchid2
    154  50 205		DarkOrchid3
    104  34 139		DarkOrchid4
    155  48 255		purple1
    145  44 238		purple2
    125  38 205		purple3
     85  26 139		purple4
    171 130 255		MediumPurple1
    159 121 238		MediumPurple2
    137 104 205		MediumPurple3
     93  71 139		MediumPurple4
    255 225 255		thistle1
    238 210 238		thistle2
    205 181 205		thistle3
    139 123 139		thistle4
      0   0   0		gray0
      0   0   0		grey0
      3   3   3		gray1
      3   3   3		grey1
      5   5   5		gray2
      5   5   5		grey2
      8   8   8		gray3
      8   8   8		grey3
     10  10  10 		gray4
     10  10  10 		grey4
     13  13  13 		gray5
     13  13  13 		grey5
     15  15  15 		gray6
     15  15  15 		grey6
     18  18  18 		gray7
     18  18  18 		grey7
     20  20  20 		gray8
     20  20  20 		grey8
     23  23  23 		gray9
     23  23  23 		grey9
     26  26  26 		gray10
     26  26  26 		grey10
     28  28  28 		gray11
     28  28  28 		grey11
     31  31  31 		gray12
     31  31  31 		grey12
     33  33  33 		gray13
     33  33  33 		grey13
     36  36  36 		gray14
     36  36  36 		grey14
     38  38  38 		gray15
     38  38  38 		grey15
     41  41  41 		gray16
     41  41  41 		grey16
     43  43  43 		gray17
     43  43  43 		grey17
     46  46  46 		gray18
     46  46  46 		grey18
     48  48  48 		gray19
     48  48  48 		grey19
     51  51  51 		gray20
     51  51  51 		grey20
     54  54  54 		gray21
     54  54  54 		grey21
     56  56  56 		gray22
     56  56  56 		grey22
     59  59  59 		gray23
     59  59  59 		grey23
     61  61  61 		gray24
     61  61  61 		grey24
     64  64  64 		gray25
     64  64  64 		grey25
     66  66  66 		gray26
     66  66  66 		grey26
     69  69  69 		gray27
     69  69  69 		grey27
     71  71  71 		gray28
     71  71  71 		grey28
     74  74  74 		gray29
     74  74  74 		grey29
     77  77  77 		gray30
     77  77  77 		grey30
     79  79  79 		gray31
     79  79  79 		grey31
     82  82  82 		gray32
     82  82  82 		grey32
     84  84  84 		gray33
     84  84  84 		grey33
     87  87  87 		gray34
     87  87  87 		grey34
     89  89  89 		gray35
     89  89  89 		grey35
     92  92  92 		gray36
     92  92  92 		grey36
     94  94  94 		gray37
     94  94  94 		grey37
     97  97  97 		gray38
     97  97  97 		grey38
     99  99  99 		gray39
     99  99  99 		grey39
    102 102 102 		gray40
    102 102 102 		grey40
    105 105 105 		gray41
    105 105 105 		grey41
    107 107 107 		gray42
    107 107 107 		grey42
    110 110 110 		gray43
    110 110 110 		grey43
    112 112 112 		gray44
    112 112 112 		grey44
    115 115 115 		gray45
    115 115 115 		grey45
    117 117 117 		gray46
    117 117 117 		grey46
    120 120 120 		gray47
    120 120 120 		grey47
    122 122 122 		gray48
    122 122 122 		grey48
    125 125 125 		gray49
    125 125 125 		grey49
    127 127 127 		gray50
    127 127 127 		grey50
    130 130 130 		gray51
    130 130 130 		grey51
    133 133 133 		gray52
    133 133 133 		grey52
    135 135 135 		gray53
    135 135 135 		grey53
    138 138 138 		gray54
    138 138 138 		grey54
    140 140 140 		gray55
    140 140 140 		grey55
    143 143 143 		gray56
    143 143 143 		grey56
    145 145 145 		gray57
    145 145 145 		grey57
    148 148 148 		gray58
    148 148 148 		grey58
    150 150 150 		gray59
    150 150 150 		grey59
    153 153 153 		gray60
    153 153 153 		grey60
    156 156 156 		gray61
    156 156 156 		grey61
    158 158 158 		gray62
    158 158 158 		grey62
    161 161 161 		gray63
    161 161 161 		grey63
    163 163 163 		gray64
    163 163 163 		grey64
    166 166 166 		gray65
    166 166 166 		grey65
    168 168 168 		gray66
    168 168 168 		grey66
    171 171 171 		gray67
    171 171 171 		grey67
    173 173 173 		gray68
    173 173 173 		grey68
    176 176 176 		gray69
    176 176 176 		grey69
    179 179 179 		gray70
    179 179 179 		grey70
    181 181 181 		gray71
    181 181 181 		grey71
    184 184 184 		gray72
    184 184 184 		grey72
    186 186 186 		gray73
    186 186 186 		grey73
    189 189 189 		gray74
    189 189 189 		grey74
    191 191 191 		gray75
    191 191 191 		grey75
    194 194 194 		gray76
    194 194 194 		grey76
    196 196 196 		gray77
    196 196 196 		grey77
    199 199 199 		gray78
    199 199 199 		grey78
    201 201 201 		gray79
    201 201 201 		grey79
    204 204 204 		gray80
    204 204 204 		grey80
    207 207 207 		gray81
    207 207 207 		grey81
    209 209 209 		gray82
    209 209 209 		grey82
    212 212 212 		gray83
    212 212 212 		grey83
    214 214 214 		gray84
    214 214 214 		grey84
    217 217 217 		gray85
    217 217 217 		grey85
    219 219 219 		gray86
    219 219 219 		grey86
    222 222 222 		gray87
    222 222 222 		grey87
    224 224 224 		gray88
    224 224 224 		grey88
    227 227 227 		gray89
    227 227 227 		grey89
    229 229 229 		gray90
    229 229 229 		grey90
    232 232 232 		gray91
    232 232 232 		grey91
    235 235 235 		gray92
    235 235 235 		grey92
    237 237 237 		gray93
    237 237 237 		grey93
    240 240 240 		gray94
    240 240 240 		grey94
    242 242 242 		gray95
    242 242 242 		grey95
    245 245 245 		gray96
    245 245 245 		grey96
    247 247 247 		gray97
    247 247 247 		grey97
    250 250 250 		gray98
    250 250 250 		grey98
    252 252 252 		gray99
    252 252 252 		grey99
    255 255 255 		gray100
    255 255 255 		grey100

Received: from spark.brl.mil by WOLF.BRL.MIL id aa00247; 6 Apr 93 0:43 EDT Date: Tue, 6 Apr 93 0:43:12 EDT From: Phil Dykstra <phil@BRL.MIL> To: acst@BRL.MIL cc: jgrosh@BRL.MIL Subject: Another animimation bug - fixed Message-ID: <9304060043.aa24911@SPARK.BRL.MIL>

John found another bug today: If you change the view parameters from frame to frame, RT gives the wrong results (i.e. the wrong view), while MGED was correct.

What was happening was that since you can either set the width/height (via -n -w; or set width=xxx) or the cell_width/cell_height (via -g -G; or; opt -g -G), RT was checking for a zero value in one of these pairs (to see which the user set), and computing the OTHER pair based on the ones given. If neither was zero, it did nothing (assuming it has already been computed - which it was). However, in an animation, if you change the viewsize, or any of the above named parameters, these values need to be recomputed. This wasn't happening.

I added a cell_newsize flag to indicate when a new -g or -G was given, and then ALWAYS do the grid computation code, choosing the version based on cell_newsize. Changes are checked into rt/ext.h, opt.c, worker.c.

- Phil

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa23994; 5 Apr 93 16:49 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa28607; 5 Apr 93 16:45 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa28590; 5 Apr 93 16:43 EDT Received: from fidler.chinalake.navy.mil by WHARF.BRL.MIL id aa00762; 5 Apr 93 16:37 EDT Received: by fidler.chinalake.navy.mil (MX V3.2) id 228; Mon, 05 Apr 1993 13:38:20 PDT Date: Mon, 05 Apr 1993 13:38:18 PDT From: levine@fidler.chinalake.navy.mil To: cad@BRL.MIL Message-ID: <0096A940.084C0800.228@fidler.chinalake.navy.mil> Subject: BRL-CAD 4.1 MGED screen is BLACK ...

I have just installed BRL-CAD 4.1 on an SGI SKYWRITER (two graphics heads) running 4.0.5(A). The software was built to run in /data3/brlcad..... When I run MGED, useing one of the sample databases, the MGED window comes up, but no buttons show up on the left had side of the screen. When I issue the B command to draw the database, the figure flashes on the screen for about 1 scan then the contents of the window goes black. The same for left/center/right button - the figure appears for about 1 scan and then the window contents goes to black again. Any suggestions as to the cause/cure???

Michael N. LeVine Naval Air Weapons Station, China Lake, Ca 93555, USA Internet: levine@fidler.chinalake.navy.mil (619) 939-2614 avn 437-2614

"Waiter, there's a bug in my soup!" "No, Sir, it's not a bug, it's a feature!"

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa07525; 6 Apr 93 14:30 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa11852; 6 Apr 93 14:26 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa11730; 6 Apr 93 14:16 EDT Date: Tue, 6 Apr 93 14:12:15 EDT From: "Lee A. Butler" <butler@BRL.MIL> To: levine@fidler.chinalake.navy.mil cc: cad@BRL.MIL Subject: Re: BRL-CAD 4.1 MGED screen is BLACK ... Message-ID: <9304061412.aa07139@WOLF.BRL.MIL>

> I have just installed BRL-CAD 4.1 on an SGI SKYWRITER ... > When I issue the B command to draw the database, the figure >flashes on the screen for about 1 scan then the contents of the window >goes black. The same for left/center/right button - the figure >appears for about 1 scan and then the window contents goes to black >again. > Any suggestions as to the cause/cure???

The place to look is in "mged/dm-4d.c". The problem may have to do with the SKYWRITER's implementation of double/single buffered modes. Since I don't have one of these displays, I'm afraid I can't help much more than that.

Lee A. Butler Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200

Received: from vim.brl.mil by WOLF.BRL.MIL id aa19523; 7 Apr 93 8:18 EDT Received: from worm.brl.mil by VIM.BRL.MIL id aa28723; 7 Apr 93 8:13 EDT Date: Wed, 7 Apr 93 8:05:59 EDT From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> To: bvld@BRL.MIL Subject: [Gary S. Moss: Re: xpa utility] Message-ID: <9304070805.aa03491@WORM.BRL.MIL>

I thought that I had announced the availability of "xpa", but perhaps I never got around to it.

This is an official warning that the products and moments of inertia calculation has not undergone extensive validation. If someone has an alternative means for checking the numbers for some fairly complicated geometries, I would appreciate if they would report their findings back to me. I did check it against simple test cases for which the answer could be easily computed by hand.

----- Forwarded message # 1:

Date: Wed, 7 Apr 93 7:46:23 EDT From: Gary S. Moss (VLD/VMB) <moss@BRL> To: Carl Moore <cmoore@brl.mil> cc: moss@BRL.MIL Subject: Re: xpa utility Message-ID: <9304070746.aa03396@WORM.BRL.MIL>

# I am hearing of an "xpa" utility which can be used for cross-section area, # etc., from someone in the former TBD. Is there any documentation around for # it, as I had not heard of it before.

Carl, Xpa computes presented area, not cross-sectional area. It also computes volume, mass, centroids, moments and products of inertia.

Assuming you have /usr/X11/man in your MANPATH, you should be able to type "man xpa" to get the documentation on it. It is installed on the SGIs and Suns that have the X11 and vld software rdist distributions.

-Gary

----- End of forwarded messages

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa21544; 7 Apr 93 12:17 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa29133; 7 Apr 93 11:48 EDT Received: from vim.brl.mil by WALRUS.BRL.MIL id aa29039; 7 Apr 93 11:39 EDT Date: Wed, 7 Apr 93 11:39:41 EDT From: Ferd Brundick (BVLD/GSB) <fsbrn@BRL.MIL> To: cad@BRL.MIL Subject: Sun X11 problems Message-ID: <9304071139.aa01750@VIM.BRL.MIL>

Haah,

I'm running BRLCAD on an SGI with remote output to a color Sun running X11R4. MGED runs ok (except for some ugly color choices) and the fb commands I tried (rle-fb and cell-fb) run correctly. I manually started fbserv on the Sun like this:

vacation> fbserv -S 1024 0 /dev/X

with these variables set on the SGI:

DISPLAY=vacation.brl.mil:0.0 FB_FILE=vacation.brl.mil:0

Running rle-fb on an existing RLE file displays the proper image (I'm using cell-fb output and the spectrum at the bottom looks correct). The framebuffer window is using a private colormap. However, if I run fb-rle the new RLE file is always grayscale. I ran rlehdr on the original and new files and got identical results, altho the new files are about one half the size of the originals. I played around with the '-c' option and it didn't make any visual difference.

The problem with rt is more serious. If I run rt from within MGED or directly from the command line it *seems* to work but I never get an image in the framebuffer.

I grep'd on X11 in the BRLCAD man tree and only 4 files even metioned X11 -- mged (reminding people to define DISPLAY), pl-X (display UnixPlot in an X11 window), urt (getx11 program), and libfb (use -lX11 when linking X programs). There's nothing about defining FB_FILE to point to an X11 client, nor is there an fbserv man page.

Now that SGI has switched to X11, is there going to be a greater emphasis on X11 support in BRLCAD? People have been writing to this list saying they can run BRLCAD on their Suns under OpenWindows and other X-ish things, but distributed SGI->Sun support is weak.

dsw, fferd <fsbrn@brl.mil>

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa23426; 7 Apr 93 15:38 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa01589; 7 Apr 93 15:20 EDT Received: from spark.brl.mil by WALRUS.BRL.MIL id aa01540; 7 Apr 93 15:14 EDT Date: Wed, 7 Apr 93 15:17:12 EDT From: Phil Dykstra <phil@BRL.MIL> To: Ferd Brundick <fsbrn@BRL.MIL> cc: cad@BRL.MIL Subject: Re: Sun X11 problems Message-ID: <9304071517.aa07104@SPARK.BRL.MIL>

Ferd,

Remember "fbhelp", it will show you frame buffer options. Try /dev/Xm. The "m" means that it allocates a 24-bit memory buffer to hold the image info, even if the display has e.g. only 1-bit. This way pixel readback (such as fb-pix) will get the right values, otherwise the best you can do is read the scant bitplanes from the X server. [You might have found a real bug, but this may work around it.]

The other way to get 24-bit readback is to use /dev/mem. On the SGI, you could do:

fbserv -S1024 0 "/dev/mem vacation:0" & FB_FILE=0

[possibly with 'r' (pre-read), and/or 'w' (write-through) option on /dev/mem] What this will do is to make a pseudo 24-bit frame buffer on the SGI in memory, do all libfb operations there, and when an application exits (or closes the frame buffer) the image will be flushed to any attached frame buffers (in this case vacation:0). Doing this also means that readbacks will be far faster, since they now come from your SGI memory, rather than the Sun.

Yes, fbserv, /dev/mem, /dev/X, mged dm-X, aren't well documented. Point noted. I have a small tutorial somewhere on using fbserv. I'll see if I can find it and send it to the list.

About X support in MGED, little known features: In the drawing window, certain keystrokes do things for you. 0 zero "knobs" (translates and rotates) x, y, z translate X, Y, Z rotate f, t, b, l, r, R, 3, 4 preset-views (front, top, ...)

| Now that SGI has switched to X11, is there going to be a greater | emphasis on X11 support in BRLCAD?

On an SGI, GL still beats the pants off of X as the prefered way to do graphics. However, to do GUI's, X is the thing to do. There is a much much better MGED X driver in the works (which will also drive GL windows). Expect to see it this Summer.

- Phil

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa16522; 5 Apr 93 3:42 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa17654; 5 Apr 93 3:13 EDT Received: from spark.brl.mil by WALRUS.BRL.MIL id aa17619; 5 Apr 93 3:04 EDT Date: Mon, 5 Apr 93 3:00:12 EDT From: Phil Dykstra <phil@BRL.MIL> To: Patrick Haggard <ph@physiol.ox.ac.uk> cc: cad@BRL.MIL Subject: Combinations, Groups, and Regions Message-ID: <9304050300.aa01682@SPARK.BRL.MIL>

Combinations, Groups, and Regions

New users of MGED are often confused over the differences and relationships between "combinations", "regions", and "groups". The latter two are special cases of a combination. A lot of the confusion in the documentation results from the history by which we got to the present system. Here is a "modern" way of looking at the three(*).

The fundamental command for building combinations of objects is:

comb name <op1 member1> [<op2 member2> ...]

Where the members are either other combinations or primitives (single solids). The first <op> is meaningless. Many people use union (u), but some argue that intersect (+) should be used. [To distinguish this from a group perhaps?? I've never understood their reasoning.]

If all of the operations are unions, there is a shorthand version of the above to make what is called a "group" (a combination of all unions):

g name <member1> [<member2> ...]

The result of this command is *exactly* the same as having made a combination (comb) with all union (u) operations. I.e.

comb name <u member1> <u member2> ...

Finally, any combination can have a "bit" set (i.e. have a property of any combination enabled) that makes that combination what is known as a "region". The idea of a region is that it consists of one solid piece of material. That is, however it was constructed in the editor, by combining any number of levels of primitive solids and combinations together, this finally result is one identifiable piece (e.g. a machined part perhaps). A combination so identified as a region can have various properties associated with it: its color, the type of material it is made out of, a "region id", etc. There is a special form of the combination (comb) command that makes a combination with this region property set:

r name <op1 member1> [<op2 member2> ...]

An existing region or combination (where "combination" is used here to refer to a non-region, even though technically a region is still a combination) can have this "bit" turned on or off via:

edcomb name regionflag [regionid air los GIFTmater]

Other ways of editing regions include:

item name item# [air] to change the region_id and mater name [material] to change the material

[regdef item [air] [los] [GIFTmaterial] - sets defaults for next "r" cmd]

Speaking of historical confusion, note that the following names all refer to the SAME single value!:

"region id", "region ident", "ident", "ident code", "item number", "item".

(*) Why I call it modern, is that for quite some time only the "r" and "g" commands existed. "comb" was added much later, yet in this authors opinion, is the most fundamental of the three. You used to be able to be fast-and-loose about having regions that contain regions, so everything could be built with "r". When the ray tracer became more precise about not allowing two physical pieces of material to occupy the same space (overlapping regions), it became important to have combination nodes that did NOT have the region property turned on, and could thus be freely used as members in other combinations.

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa06675; 8 Apr 93 15:57 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa19474; 8 Apr 93 15:54 EDT Received: from spark.brl.mil by WALRUS.BRL.MIL id aa19414; 8 Apr 93 15:52 EDT Date: Thu, 8 Apr 93 15:46:08 EDT From: Phil Dykstra <phil@BRL.MIL> To: cad@BRL.MIL Subject: History of "comb" Message-ID: <9304081546.aa06338@SPARK.BRL.MIL>

In my note about Combinations, Groups, and Regions, I had said in the footnote:

| You used to be able to be fast-and-loose about having regions that | contain regions, so everything could be built with "r". When | the ray tracer became more precise about not allowing two physical | pieces of material to occupy the same space (overlapping regions), | it became important to have combination nodes that did NOT have | the region property turned on, and could thus be freely used as | members in other combinations.

Mike Muuss corrected me here. I remembered "comb" being added, in part when I complained "If you can't have regions within regions, how are you supposed to make a non-region combination?" My reasons for why it didn't used to be there were wrong however. Here is a better footnote:

(*) Why I call it modern, is that for quite some time only the "r" and "g" commands existed. "comb" was added much later, yet in this author's opinion, is the most fundamental of the three. VDECK and GIFT (the predecessor to RT) did not support things such as regions within regions, booleans above regions, and non-unions below regions. Therefore MGED did not have support for them. Adding "comb" to MGED generalized and increased MGED's expressive power, but it also allowed a diversion from GIFT compatible databases.

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa00791; 14 Apr 93 19:36 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa16853; 14 Apr 93 16:27 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa16663; 14 Apr 93 16:16 EDT Received: from mbv.mbvlab.wpafb.af.mil by WHARF.BRL.MIL id aa06116; 14 Apr 93 16:09 EDT Received: from nextclient3.mbvlab.wpafb.af.mil ([134.131.208.19]) by mbv.mbvlab.wpafb.af.mil (4.1/SMI-4.1) id AA06792; Wed, 14 Apr 93 16:09:51 EDT Received: by nextclient3.mbvlab.wpafb.af.mil (NX5.67c/NX3.0S) id AA00756; Wed, 14 Apr 93 16:01:21 -0400 Date: Wed, 14 Apr 93 16:01:21 -0400 From: Kevin Farrar (Sverdrup) <kfarrar@nextclient3.mbvlab.wpafb.af.mil> Message-Id: <9304142001.AA00756@nextclient3.mbvlab.wpafb.af.mil> Received: by NeXT.Mailer (1.87.1) Received: by NeXT Mailer (1.87.1) To: CAD@BRL.MIL Subject: Problem with mouse & mged Cc: pjoslin@mbvlab.wpafb.af.mil, kfarrar@mbvlab.wpafb.af.mil

I am having a problem with the mouse in mged installed on an HP9000 Model 750 HP-UX 8.05 attached to X. I must hit return at the mged> in the command window to get it to accept my mouse clicks.

Kevin Farrar E-mail: kfarrar@mbvlab.wpafb.af.mil Sverdrup Technology Voice: (513)255-1115

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa14380; 16 Apr 93 4:38 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa21276; 16 Apr 93 4:04 EDT Received: from spark.brl.mil by WALRUS.BRL.MIL id aa21021; 16 Apr 93 3:56 EDT Date: Fri, 16 Apr 93 3:57:26 EDT From: Phil Dykstra <phil@BRL.MIL> To: Kevin Farrar <kfarrar@nextclient3.mbvlab.wpafb.af.mil> cc: CAD@BRL.MIL, pjoslin@mbvlab.wpafb.af.mil, kfarrar@mbvlab.wpafb.af.mil Subject: Re: Problem with mouse & mged Message-ID: <9304160357.aa23871@SPARK.BRL.MIL>

Chances are that select() is not working correctly. Look in "libsysv/bsdselect.c". If you are falling into the generic System V code that does a "return(32-1)", you will see the problem you described. You need to see if your HP supports a real select system call and enable it by changing the ifdef's in that module.

- Phil

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa22499; 26 Apr 93 14:21 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa06700; 26 Apr 93 9:15 EDT Date: Mon, 26 Apr 93 9:05:02 EDT From: Susan Coates (BVLD) <scoates@BRL.MIL> To: jwb@swrinde.nde.swri.edu cc: cad@BRL.MIL, scoates@BRL.MIL Subject: Big E Command Message-ID: <9304260905.aa06261@WALRUS.BRL.MIL>

As far as I know you are not missing anything with reguards to mged. The 'big e' command has never worked (to the best of my knowledge) on a torus (or an ars). The error below is the normal reaction to 'big eing' a torus (or an ars). I don't know anything about the same error with rt. My experience with tori and rt is that everything seems to work.

Susan Coates

----- Forwarded message # 1:

Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa21299; 22 Apr 93 10:18 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa21076; 22 Apr 93 10:10 EDT Received: from swrinde.nde.swri.edu by WHARF.BRL.MIL id aa25089; 22 Apr 93 10:04 EDT Received: by swrinde.nde.swri.edu (5.64swri/1.34) id AA15798; Thu, 22 Apr 93 09:03:53 -0500 From: "Joseph W. Brophy" <jwb@swrinde.nde.swri.edu> Message-Id: <9304221403.AA15798@swrinde.nde.swri.edu> Subject: Error messages from MGED To: cad@BRL.MIL Date: Thu, 22 Apr 1993 09:03:53 -0500 (CDT) X-Mailer: ELM [version 2.4 PL3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 720

Forwarded message: We have run into the following error situation with MGED, attempts to use torus in combination with other primitives gives the folowing error with 'Big E' (and RT as well) > mged> E test04 > > proc_reg: Cannot draw solid type 16 (TOR) > Error in converting solid test04 to ARBN > E: 0 vectors in 0 sec > > > mged> tree test04 > > > test04/R > u torus2 > + cyl3 > > The problem is the inability to edit the "tor" solid or > a solid to be edited by a "tor" and disply the results > with "E" > > -tony > Is there a patch for MGED, or are we missing something fundamental about MGED's operation?

We are using a Sun Sparc workstation with XGL and SunOS 4.1.3.

JWBrophy@swrinde

----- End of forwarded messages

Date: Wed, 2 Jun 93 9:27:07 EDT From: John R. Anderson (VMB) <jra@BRL> To: mike@BRL.MIL cc: jill@BRL.MIL, acst@BRL.MIL Subject: BRLCAD to IGES translator Message-ID: <9306020927.aa23838@WOLF.BRL.MIL>

I have completed the coding of a BRLCAD-to-IGES translator (g-iges). The code has two mutually exclusive options (plus a few others):

-f for facets (each region is converted to NMG's prior to output in IGES format).

-c for CSG (each object is output in IGES format unless there is no corresponding IGES entity, in which case it is converted to NMG's and then output).

The -f option is essentially Markowski's g-jack converter with different output and some additions. This option is dependent on the successful implementation of NMG booleans. One major issue with this option is that IGES expects BREP objects to consist of one or more outer shells with zero or more inner void shells, while BRLCAD combines all of this into a single shell. This issue is being shelved until we know for sure whether BRLCAD will use the IGES version of shells.

The -c option has been exercised on two real models - the MH60 and MH47 helicopters. The 3.8 Mb mh47.g file produces a 39 Mb, 484,000 line IGES file with all the ARS solids, 65% of the ARB's and 10% of the TGC's converted to NMG's. Everything else is written to the IGES file without conversion. The 4.5 Mb mh60k.g file produced a 59 Mb, 735,000 line IGES file with similar statistics. There are a few issues here:

1. What to do with solids that are not in IGES and are not tesselated (like the half-space solid).

2. IGES cannot handle an object that is scaled. If a scaled object that has not been "pushed" is encountered, it is translated to IGES without the scale factor and the user is warned.

3. I have not implemented the IGES right angle wedge (RAW) solid. This is just a matter of whether it's worth the effort of developing code to recognize if a BRLCAD arb meets the criteria to be an IGES RAW.

Issue #1 was not encountered in either of the two models converted. Issue #2 was encountered in one region and safely handled by a "push" command in MGED and then re-running g-iges.

Both options produce an IGES file that includes object names (using the IGES "name" entity), colors (using the IGES color entity), and region flag, region id, air code, GIFT material code, los, material name, and material parameters are included using the IGES attribute entities. The attribute entity sort of a free for all entity to assign any attributes to any IGES object. No other IGES translator will understand my attribute entity unless they code my conventions into their translator.

Obviously, the only verification I have done on this is visual inspection of the output files. Given the size of the files, the possibility of overlooking a bug is not insignificant. I propose upgrading the existing iges-g translator to the same level as the new g-iges and using them to help debug each other. This would also give me a chance to become familiar with the nmg "make" routines.

-John

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa07350; 9 Jun 93 12:51 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa08523; 9 Jun 93 12:45 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa08440; 9 Jun 93 12:39 EDT Date: Wed, 9 Jun 93 12:38:14 EDT From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: vdeck on RS4000 Indigo Message-ID: <9306091238.aa07164@WOLF.BRL.MIL>

For those of you fans of VDECK, it was reported today that VDECK will not compile on an SGI R4000 Indigo machine. In the Release 4.1 sources this can be worked around by removing line 162, which states:

int sortFunc RT_ARGS((const void * a, const void *b));

In the Release 4.0 sources (which probably won't work on an Indigo anyway), remove line 137, which states:

static int sortFunc RT_ARGS((const genptr_t a, const genptr_t b));

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa10006; 25 Jun 93 10:27 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa02314; 25 Jun 93 9:47 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa02222; 25 Jun 93 9:41 EDT Date: Fri, 25 Jun 93 9:31:58 EDT From: "John R. Anderson" <jra@BRL.MIL> To: ali@archsci.arch.su.edu.au cc: cad@BRL.MIL Subject: Re: please add me to the mailing list Message-ID: <9306250931.aa09301@WOLF.BRL.MIL>

Ali writes:

> Also, I am trying to get BRL-CAD to work on a Sun > Sparcstation with SunOS 4.1.2 (and 4.1.3), under OpenWindows (not > SunView). I was wondering if anybody else had done this... >

I have compiled BRLCAD under OpenWindows some time ago. As I recall, the only changes I had to make were in the "Cakefile.defs" file. There is a section in that file for Sparcstations (look for "#if defined(sparc)"). The default is labelled with a comment: /* Bare Sun configuration */ You can switch to the OpenWindows support by changing the "if 1" for the bare sun configuration to an "if 0". This will enable the section labelled: /* Sun with X11 (aka "openwin"). Default for SunOS 4.1.1 */

Hope this helps,

-John

John R. Anderson Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: jra@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-7267

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa13741; 25 Jun 93 16:37 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa13658; 25 Jun 93 16:33 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa13597; 25 Jun 93 16:27 EDT Date: Fri, 25 Jun 93 16:18:49 EDT From: Mike Muuss <mike@BRL.MIL> To: Patrick Haggard <ph@physiol.ox.ac.uk> cc: ali@archsci.arch.su.edu.au, jra@BRL.MIL, cad@BRL.MIL Subject: Sun configurations Message-ID: <9306251618.aa13546@WOLF.BRL.MIL>

You know, you *are* allowed to edit the Cakefile.defs entries, if they don't suit your particular configuration. I've tried to provide a variety of useful selections via the #if mechanism, but once you have the baseline package working, if you want to make modifications, do feel free to do so! One of the benefits (and responsibilities) of getting software in source code form.

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa22308; 29 Jun 93 2:01 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa29328; 29 Jun 93 1:34 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa29274; 29 Jun 93 1:25 EDT Received: from archsci.arch.su.EDU.AU by WHARF.BRL.MIL id aa00020; 29 Jun 93 1:14 EDT Received: from whitton.arch.su.EDU.AU by archsci.arch.su.EDU.AU (5.61+/5.17) id AA07084; Tue, 29 Jun 1993 15:13:20 +1000 Received: from [127.0.0.1] by whitton.arch.su.EDU.AU (5.61+/SMI-4.1) id AA22133; Tue, 29 Jun 1993 15:13:18 +1000 Message-Id: <9306290513.AA22133@whitton.arch.su.EDU.AU> To: cad@BRL.MIL Subject: multi-user MGED Date: Tue, 29 Jun 93 15:13:17 +1000 From: ali@archsci.arch.su.edu.au

Hi, I'm interested in adding concurrent multi-user capability to MGED. I wanted to know if anybody had tried this, or if anybody had any tips on how I might go about it. I'm somewhat familiar with designing multi-user programs, but I am not familiar with mged yet. Any suggestions, warnings, etc would be greatly appreciated...

thanks,

-=> Ali

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa22520; 29 Jun 93 3:01 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa00014; 29 Jun 93 2:45 EDT Received: from spark.brl.mil by WALRUS.BRL.MIL id aa29949; 29 Jun 93 2:38 EDT Date: Tue, 29 Jun 93 2:33:58 EDT From: Phil Dykstra <phil@BRL.MIL> To: ali@archsci.arch.su.edu.au cc: cad@BRL.MIL Subject: Re: multi-user MGED Message-ID: <9306290233.aa08483@SPARK.BRL.MIL>

The new MGED user interface allows multiple X servers to be used to display geometry. The alternate displays are even mouse input sensitive. We have discussed the issue of whether or not to allow complete editing capability from every display, and issues such as whether or not to warp the mouse on one display as it is moved on another.

I personally don't see much utility in making it multi-user beyond seeing the output on multiple desktops and being able to interactively point out objects/actions to others. But I'm open to ideas. How would you use a multi-user geometric editor? In something other than a demonstration/teaching mode? How would you handle control, e.g. would all mouse clicks and key presses apply to every display in a first-come/first-serve fashion?

- Phil

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa22573; 29 Jun 93 3:14 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa00325; 29 Jun 93 3:15 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa00245; 29 Jun 93 3:07 EDT Received: from archsci.arch.su.EDU.AU by WHARF.BRL.MIL id aa01065; 29 Jun 93 3:00 EDT Received: from whitton.arch.su.EDU.AU by archsci.arch.su.EDU.AU (5.61+/5.17) id AA07800; Tue, 29 Jun 1993 16:59:51 +1000 Received: from [127.0.0.1] by whitton.arch.su.EDU.AU (5.61+/SMI-4.1) id AA22252; Tue, 29 Jun 1993 16:59:48 +1000 Message-Id: <9306290659.AA22252@whitton.arch.su.EDU.AU> To: Phil Dykstra <phil@BRL.MIL> Subject: Re: multi-user MGED Cc: cad@BRL.MIL In-Reply-To: Your message of Tue, 29 Jun 93 02:33:58 -0400. <9306290233.aa08483@SPARK.BRL.MIL> Date: Tue, 29 Jun 93 16:59:46 +1000 From: ali@archsci.arch.su.edu.au

Phil,

> The new MGED user interface allows multiple X servers to be used > to display geometry. The alternate displays are even mouse input > sensitive. We have discussed the issue of whether or not to allow > complete editing capability from every display, and issues such as > whether or not to warp the mouse on one display as it is moved on > another.

where could I get this new MGED UI? Sounds *very* much like what I'd want...

> I personally don't see much utility in making it multi-user beyond > seeing the output on multiple desktops and being able to interactively > point out objects/actions to others. But I'm open to ideas. How > would you use a multi-user geometric editor? In something other > than a demonstration/teaching mode? How would you handle control, > e.g. would all mouse clicks and key presses apply to every display > in a first-come/first-serve fashion?

well, that question has many long answers. The basic idea is collaborative design. That's my current area of research. There is alot of work being done in collaborative/multi-user programs, and there are several ways in which you can handle control. One solution is to do it the way it would be done in a meeting with a whiteboard. have one "pen" and allow only one person to edit at a time. Another way, (which, in my opinion is the way it should be done) is to allow people to have their own views of the 3D database, and allow them all to edit at the same time, but allow for "selection" of objects, and when somebody has something selected, nobody else can modify it. It would also be good to have a local instance running as well, which would allow users to work on a small part of the design outside of the main database, and then add it in when they want to show it to people. Of course, it would be very important for the designers to also be speaking to eachother to prevent problems. A masters student at MIT named Li Shu did a good piece of work on collaborative cad and had a paper in CSCW'92...

hope that answers part of your question...

-=> Ali

Date: Tue, 29 Jun 93 14:04:36 EDT From: "John R. Anderson" <jra@brl> To: phd@BRL.MIL cc: acst@BRL.MIL, wm@BRL.MIL, jill@BRL.MIL, seyfertw%ccmail@tacom-emh1.army.mil, earl@BRL Subject: Intergraph/BRLCAD Translator Message-ID: <9306291404.aa28542@WOLF.BRL.MIL>

I just talked to Bill Seyfert regarding the Intergraph/BRLCAD translator that TACOM and FSTC sponsored. He gave me a brief description of the status:

The translators were written for Intergraph version 1.4 and BRLCAD version 3.7. Translation to BRLCAD converts about a half dozen equivalent solids directly to BRLCAD and the remainder are facetized and converted as polysolids. The translators are now being upgraded to Intergraph version 2.1 and BRLCAD version 4.0, and that effort is nearly finished. The current software runs only on an Intergraph workstation, but Mr. Seyfert is procuring Intergraph software that will run on an SGI, and then intends to port the translators to the SGI platform. Translation to Intergraph is also possible. For a successful translation to BRLCAD, the Intergraph user must follow some simple rules in the construction of the Intergraph model. For example, the user must build a solid model (not just surfaces hanging in space), and the user must utilize Intergraphs layer capability to create groups with names in the resulting brlcad model.

-John

John R. Anderson Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: jra@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-7267

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa15181; 30 Jun 93 16:01 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa16236; 30 Jun 93 15:16 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa15910; 30 Jun 93 15:06 EDT Date: Wed, 30 Jun 93 14:57:09 EDT From: Mike Muuss <mike@BRL.MIL> To: ali@archsci.arch.su.edu.au cc: cad@BRL.MIL Subject: Re: multi-user MGED Message-ID: <9306301457.aa14048@WOLF.BRL.MIL>

Ali writes -

> I'm interested in adding concurrent multi-user capability > to MGED.

and Phil responded with some information about his new X interface to MGED.

I have taken another approach in my team's "Virtual Reality for CAD" project -- we support an arbitrary number of copies of MGED running, and coordinate them via a program called VRMGR (Virtual Reality Manager). This permits multiple people to wander within a single database, some using regular displays, some using stereo-capable workstations, some using a workstation pair driving an HMD, and some using an arbitrary number of workstations driving a "cave" display surface. Any combination is possible, and "overview" display stations can also be instantiated, to see how the users are moving through the virtual space.

Each MGED user has control over his own point of view, and can see the other users as a simple wireframe "eye" token.

A prototype of this much is more-or-less working now, the real issues of how to do distributed *editing* (rather than just viewing) remain to be tackled. Much of the infrastructure for that is already in place, but there are some key issues in interface design and in MGED internals that still need some work.

This is a low-priority project at the moment, but because it's fun it gets continuing attention, and I have some big plans for this effort, including integrating audio.

Naturally, a VR capability is most fun if you have polygons to render, which makes the "VR for CAD" project take a distinct second seat to the "finishing NMG Booleans" project....

There is a lot more that I could say about "VR for CAD". I hope that I've tantalized you a bit already!

Best, -Mike

Received: from wharf.brl.mil by WOLF.BRL.MIL id aa22873; 1 Jul 93 2:40 EDT Received: from archsci.arch.su.EDU.AU by WHARF.BRL.MIL id aa03224; 1 Jul 93 2:36 EDT Received: from whitton.arch.su.EDU.AU by archsci.arch.su.EDU.AU (5.61+/5.17) id AA07862; Thu, 1 Jul 1993 16:35:22 +1000 Received: from [127.0.0.1] by whitton.arch.su.EDU.AU (5.61+/SMI-4.1) id AA14552; Thu, 1 Jul 1993 16:35:18 +1000 Message-Id: <9307010635.AA14552@whitton.arch.su.EDU.AU> To: "John R. Anderson" <jra@BRL.MIL>, Mike Muuss <mike@BRL.MIL>, Patrick Haggard <ph@physiol.ox.ac.uk> Cc: cad@BRL.MIL Subject: brl-cad on Sun Sparcstations Date: Thu, 01 Jul 93 16:35:14 +1000 From: ali@archsci.arch.su.edu.au

Thanks for your help on compiling brl-cad on my sun sparcstation under openwindows. I modified the Cakefile.defs a slight bit to compile under the "Sun with X11 only" option, but I still have problems. mged works fine, except that it flickers horribly when rotating, zooming, etc. Is it true that it does not do double buffering because it's running under X? The main problem, however, is that rt doesn't work in mged. It just messes up the screen alot and leaves the screen in black and white mode when it stops. Then if I re-attach X (or type fix), everything goes back to normal, except that I have lots of debree left on the screen where rt popped up a "window".

I've included the part of the Cakefile.defs file that I think is relevant...

thanks,

-=> Ali

#if defined(sparc) /* Sun-4 "SparcStation" hardware */ # undef sun # undef sun4 # define MTYPE sun4 # define BSD 43 # define HAS_TCP 1 # define OPTIMIZER -O2 /*# define CC_DEFS -DAUTOSPEC /* What does this do? */ # define LIBMALLOC /* use vendor library */ # define LIBRT_TIMER timer42 # if 0 /* Bare Sun configuration */ # define LIBFB_OBJS if_remote if_sun # define LIBFB_CONFIG -DIF_REMOTE -DIF_SUN # define LIBFB_LIBES LIBPKG -lsuntool -lsunwindow -lpixrect # define LIBRT_TIMER timer42 # define MGED_OBJS dm-sun # define MGED_CONFIG -DDM_SUNPW # define MGED_LIBES -lsuntool -lsunwindow -lpixrect # else /* Sun with X11 (aka "openwin"). Default for SunOS 4.1.1 */ # define LIBFB_OBJS if_remote if_ab if_X if_sun # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB -DIF_SUN \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG -lsunwindow -lpixrect -lsuntool\ -L/usr/openwin/lib -lX11 # if 1 /* Sun with X11 only */ # define MGED_OBJS dm-sun dm-X # define MGED_CONFIG -DDM_SUNPW -DDM_X -I/usr/openwin/include # define MGED_LIBES -lsuntool -lsunwindow -lpixrect \ -L/usr/openwin/lib -lX11 # else /* Sun with X11 and XGL (an unbundled product) */ /* Note that at MSIC, -lgks may also be needed */ # define MGED_OBJS dm-xgl dm-X # define MGED_CONFIG -DDM_XGL -DDM_X -I/usr/openwin/include # define MGED_LIBES -lxgl -L/usr/openwin/lib -lX11 # endif # endif # if 0 /* "Unbundled" (i.e. "improved") compilers. Use if you have them */ # define CC /usr/lang/cc # define FC /usr/lang/f77 # endif #endif

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa23674; 1 Jul 93 4:05 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa26048; 1 Jul 93 3:48 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa26040; 1 Jul 93 3:47 EDT Date: Thu, 1 Jul 93 3:39:07 EDT From: Mike Muuss <mike@BRL.MIL> To: ali@archsci.arch.su.edu.au cc: Patrick Haggard <ph@physiol.ox.ac.uk>, cad@BRL.MIL Subject: Re: brl-cad on Sun Sparcstations Message-ID: <9307010339.aa23335@WOLF.BRL.MIL>

> The main problem, however, is that rt doesn't work in mged. It > just messes up the screen alot and leaves the screen in black and > white mode when it stops. Then if I re-attach X (or type fix), > everything goes back to normal, except that I have lots of debree > left on the screen where rt popped up a "window".

Sounds like you are using the raw Sun "pixrect" interface (/dev/sun), rather than the X11 interface to the framebuffer. You can verify that this is in fact the case by running "fbhelp" from the shell once, and examining the lower half of it's output (after the "=== Current Selection ===") message.

> I've included the part of the Cakefile.defs file that I think is > relevant...

This was very helpful. Thanks! Where you said:

/* Sun with X11 (aka "openwin"). Default for SunOS 4.1.1 */ # define LIBFB_OBJS if_remote if_ab if_X if_sun # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB -DIF_SUN \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG -lsunwindow -lpixrect -lsuntool\ -L/usr/openwin/lib -lX11

remove the if_sun, -DIF_SUN stuff, so that it now looks like this:

/* Sun with X11 (aka "openwin"). Default for SunOS 4.1.1 */ # define LIBFB_OBJS if_remote if_ab if_X # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG \ -L/usr/openwin/lib -lX11

This will prevent you from accidentally getting the SunTools interface by default.

Alternatively (requiring no recompilation), remember to set your environment variable FB_FILE before starting up MGED or other BRL-CAD tools.

csh: setenv FB_FILE /dev/X sh: FB_FILE=/dev/X; export FB_FILE

I hope this helps.

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa25105; 1 Jul 93 8:29 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa29940; 1 Jul 93 8:29 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa29623; 1 Jul 93 8:20 EDT Date: Thu, 1 Jul 93 8:12:24 EDT From: "John R. Anderson" <jra@BRL.MIL> To: ali@archsci.arch.su.edu.au cc: cad@BRL.MIL Subject: Re: brl-cad on Sun Sparcstations Message-ID: <9307010812.aa24961@WOLF.BRL.MIL>

Ali,

> Thanks for your help on compiling brl-cad on my sun sparcstation > under openwindows. I modified the Cakefile.defs a slight bit to > compile under the "Sun with X11 only" option, but I still have > problems. mged works fine, except that it flickers horribly when > rotating, zooming, etc. Is it true that it does not do double > buffering because it's running under X?

I believe that is just a characteristic of graphics under X.

> The main problem, however, is that rt doesn't work in mged. It > just messes up the screen alot and leaves the screen in black and > white mode when it stops. Then if I re-attach X (or type fix), > everything goes back to normal, except that I have lots of debree > left on the screen where rt popped up a "window".

Try setting your framebuffer to X. If you are using the Bourne shell do: FB_FILE=/dev/Xl export FB_FILE Or, if you use a csh do: setenv FB_FILE /dev/Xl

Also, try the "fbhelp" command for more info.

-John

John R. Anderson Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: jra@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-7267

Date: Tue, 6 Jul 93 15:45:31 EDT From: Mike Muuss <mike@brl.mil> To: Keith Applin <keith@brl> cc: Andre Joanisse <andrej@venus.resntl.bhp.com.au>, keith@BRL.MIL, mmonk@BRL.MIL, mike@BRL.MIL Subject: Re: BRL-CAD Getting Started Guide???? Message-ID: <9307061545.aa24578@WOLF.BRL.MIL>

I suspect that what Andre was really asking for was a pointer to the examples on how to use MGED.

In Vol IV (MGED User's Manual), try looking at chapters 13 and 14, then refer back to earlier chapters in that manual for details.

Best, -Mike

Date: Tue, 13 Jul 93 2:22:44 EDT From: Mike Muuss <mike@brl.mil> To: ali@archsci.arch.su.edu.au cc: mike@BRL.MIL, phil@BRL.MIL, cad@BRL.MIL Subject: Re: mu_mged (last one) Message-ID: <9307130222.aa28801@WOLF.BRL.MIL>

> Since I haven't been receiving *any* responses to my questions, this > will be the last time I will post a general mailing to cad@brl.mil.

Well, I answered at least one of your earlier messages, at least to say that you were welcome to ask away, and that the developers really could not commit to answering such detailed questions with any kind of promptness -- we have quite a few other things going on right now, and being only 4, can't invest too much time providing help to folks who obtained "no support" distributions.... I regret that we can't offer more help, but we can't. If we provided each of our 800 user sites even a few hours of help, we wouldn't have any time left for our own projects. I hope you can appreciate our limitation.

You are engaged in a difficult task (multi-user geometry editing). There are many different strategies that you might adopt for implementing this within MGED. You have not made it entirely clear what strategy you are considering, which makes it hard to provide concise suggestions.

> I also understand (I think) how the dbase works and when it is > accessed.

This is one of the main benefits that you obtain from having the source code -- you can study the code and figure things out for yourself. I'm glad it is yeilding some of it's secrets to you, already. :-)

> However, I am still in desperate need of getting in touch with > someone who "understands" how the actual memory management works and > perhaps why it was designed in certain ways in certain places...

I designed all the memory management; if you have a specific question that has a brief answer, I'll try to reply.

Much of the memory management code is more than 10 years old, and was designed to run on PDP-11 processors with limited address space. Thus, the notion of "database granules" (128 bytes each) which can be processed one at a time. This mode of operating is no longer necessary, but not all the code has been converted yet. So, you will see both the "old way" db_get()/db_put() usage, as well as the "new way" usage of db_get_external()/db_put_external() to move 'objects' between memory and the ".g" database file.

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa03028; 19 Jul 93 21:41 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa25126; 19 Jul 93 21:25 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa25098; 19 Jul 93 21:16 EDT Received: from archsci.arch.su.EDU.AU by WHARF.BRL.MIL id aa11248; 19 Jul 93 21:02 EDT Received: from young.arch.su.EDU.AU by archsci.arch.su.EDU.AU (5.61+/5.17) id AA02148; Tue, 20 Jul 1993 11:02:40 +1000 Received: from [127.0.0.1] by young.arch.su.EDU.AU (5.61+/SMI-4.1) id AA11556; Tue, 20 Jul 1993 11:02:38 +1000 Message-Id: <9307200102.AA11556@young.arch.su.EDU.AU> To: cad@BRL.MIL Subject: Re: converting dxf files to brl-cad files Date: Tue, 20 Jul 93 11:02:38 +1000 From: ali@archsci.arch.su.edu.au

Yes, I do realize that it would require major redesign, but I was hoping somebody had done it. Actually, I was right! Unfortunately, the price is not right...

-=> Ali

p.s. I don't really need it anymore, so I didn't reply to him...

------- Forwarded Message

Return-Path: olasov@cs.columbia.edu Received: from cs.columbia.edu by archsci.arch.su.EDU.AU (5.61+/5.17) id AA21686; Mon, 19 Jul 1993 08:58:26 +1000 Received: from ground.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad+jtt) with SMTP id AA21871; Sun, 18 Jul 1993 18:58:19 -0400 Received: by ground.cs.columbia.edu id AA03805 (5.65c/IDA-1.4.4.5/jba/jtt/ad for ali@archsci.arch.su.edu.au); Sun, 18 Jul 1993 18:58:13 -0400 Date: Sun, 18 Jul 1993 18:58:13 -0400 From: Benjamin Olasov <olasov@cs.columbia.edu> Message-Id: <199307182258.AA03805@ground.cs.columbia.edu> To: ali@archsci.arch.su.edu.au Subject: converting Autocad files to .asc files (from BRL-CAD)

My consulting company has an AutoCad -> BRL translator (.dwg -> .asc) which it sells commercially. The price is $500 US.

Ben

------- End of Forwarded Message

Date: Mon, 19 Jul 93 18:56:05 EDT From: Mike Muuss <mike@brl.mil> To: ali@archsci.arch.su.edu.au cc: Mike Muuss <mike@brl.mil>, ACST@BRL.MIL Subject: Re: selection/illumination Message-ID: <9307191856.aa01693@WOLF.BRL.MIL>

> In other words, how can I do something to the effect of "e > /tank/fuel" instead of either "e tank" or "e fuel" (which would > ignore matrices higher up in the tree)?

Ah, an easy one! How about just doing "e tank/fuel" (or whatever the partial path spec is). That works. Or, better still, see my remarks below.

> An even shorter short-ish mged hacking question: > from within db_put(), how can I find the complete pathname > of the solid being "put"?

You can't do it, that far down in the library. Best you can do is to get the name of the object being written (dp->d_namep). In any case, this is what you actually need, because you should then go and search the MGED solid table for all objects on the screen that refer to this database item, and redraw those "involved" solids. There is handy support for this operation in the form of subroutine replot_modified_solid() in file mged/dodraw.c

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa04448; 20 Jul 93 0:41 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa25586; 19 Jul 93 23:44 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa25583; 19 Jul 93 23:39 EDT Date: Mon, 19 Jul 93 23:27:28 EDT From: Mike Muuss <mike@BRL.MIL> To: ali@archsci.arch.su.edu.au cc: CAD@BRL.MIL Subject: Re: selection/illumination Message-ID: <9307192327.aa04119@WOLF.BRL.MIL>

Ali writes -

> Let's try a yes/no version of the question: when db_put stores s214, > from accepting changes on /tank/computer/r213/s214, does that mean that > all references to s214 are changed?

Alas, he didn't succeed in making it yes/no. Grin!

There are two kinds of editing in MGED: "solid edit", which transforms the parameters of a *leaf* node (solid) in the tree, and "object edit", which modifies the 4x4 transformation matrix stored along one *arc* of the tree.

So, if you did a solid edit on "s214", all instances of that solid would change. If you did an object edit on "/tank/computer/r213/s214" and replaced the matrix at the arc "r213/s214", then only that instance would change.

At present there is no way to specify changing an leaf-node's paramter(s) in an object edit. Instancing is primarily used for repeating many copies of identical parts. Some modelers (e.g. Harry Reed & crew) tend to avoid instances, while others (e.g. Jim Hunt & crew) couldn't live without them.

I agree that the instancing capability could be more flexible, but that leads the discussion in the direction of a non-global name space or an 'interpreted' database, neither of which are 'minor' changes to the design of the system. As it stands now, these lacks don't seem to be a serious hindrance, so this is not a 'hot topic', although we do kick it around from time to time.

Best, -Mike

Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa24107; 23 Jul 93 9:23 EDT Date: Tue, 20 Jul 93 9:31:50 EDT From: Carl Moore <cmoore@BRL.MIL> To: Mike Muuss <mike@BRL.MIL> cc: ali@archsci.arch.su.edu.au, CAD@BRL.MIL Subject: Re: selection/illumination Message-ID: <9307200931.aa01914@WUMPUS.BRL.MIL>

I noticed the comments on instancing. I have had cases where I "inherited" instancing in a description, and I started getting annoyed when I tried to display a low-level solid and it did not appear where I thought, due to my missing a transformation at a higher level in the tree. Solution: I set up at least one transformation-free path leading down to each solid.

Received: from vmb.brl.mil by WOLF.BRL.MIL id aa16792; 4 Oct 92 21:53 EDT Received: from VMB.BRL.MIL by VMB.BRL.MIL id aa20069; 4 Oct 92 21:32 EDT Received: from wharf.brl.mil by VMB.BRL.MIL id aa20048; 4 Oct 92 21:24 EDT Received: from relay1.UU.NET by WHARF.BRL.MIL id aa08733; 4 Oct 92 20:10 EDT Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA00151; Sun, 4 Oct 92 20:11:26 -0400 Received: from results.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 201007.22878; Sun, 4 Oct 1992 20:10:07 EDT Received: by results.com (5.64/A/UX-AMR-1.0) id AA11799; Sun, 4 Oct 92 20:08:40 EDT Date: Sun, 4 Oct 92 20:08:40 EDT From: BRL-CAD Users Conference <confer@results.com> Message-Id: <9210050008.AA11799@results.com> To: cad@BRL.MIL Subject: BRL-CAD Users Conference Regestration and Schedule

First Annual BRL-CAD Users Conference November 4-6, 1992 Omni International Hotel Inner harbor, Baltimore, Maryland, USA

This two and a half day conference will cover many topics of interest to users of the BRL-CAD Package. While other symposia have focused on presenting results of research and various theoretical applications, this conference will teach attendees how to use the power of BRL-CAD to accomplish their own tasks.

Presentations, papers, and tutorials will focus on a variety of subjects for users at all skill levels. Subject range from introductory materials for persons new to CSG to more esoteric subjects such as generation of synthetic images for the simulation of thermal and laser radar sensors. Intermediate topics will cover such practical considerations as printing images, animation, vulnerability analysis, and specific information on tools such as MUVES, FRED, LIBRT and others.

The conference fee includes a superb banquet of New York Strip Sirloin (vegetarian alternative available), spinach salad, crab bisque (A Maryland speciality), vegetables and potato, and a wonderful strawberry cheesecake, all served with red or white wine. Two lunches, three Continental breakfasts, numerous breaks, and a hospitality suite are also provided with equally handsome comestibles.

The Omni International Hotel provides a business center, gift shop, and exercise room, with skywalk access to the waterfront with its many historic sights, museums, theaters, restaurants, shops, and ships. within the hotel are Jackies Cafe which offers American cuisine and The Corner Bar with its Library of fine drink selections and complimentary hors d'oeuvres during week day happy hour.

----------------------------------------------------------------------- 1992 BRL-CAD USERS Conference Schedule

November 3rd, 1992

1200-1700 Check-In 2000-0100 Informal Reception hosted by RESULTS Now, Inc.

November 4th, 1992

0800-0900 Continental Breakfast. 0900-0915 Welcome and Announcements 0915-1000 "Practices and Standards in the Construction of BRL-CAD Target Descriptions", by Dr. Paul H. Deitz, Chief, Ballistic Vulnerability/Lethality Division, Army Research Laboratory and Mr. Keith A. Applin, Ballistic Vulnerability/Lethality Division, Army Research Laboratory. 1000-1015 Break 1015-1100 "Using BRL-CAD to Generate Synthetic Images for the Simulation of Thermal and Laser Radar Sensors", John Dome, Electro-Optics Division, U.S. Army Night Vision Laboratory 1105-1200 Three Short Presentations "Target Damage Modeling in EVA-3D", by R. Kathryn Tucker and Kellye C. Frew, Applied Research Associates, Inc. "Frangible Munition and the BRL-CAD Package; A Successful Combination", by Tom Keij, TNO Defense Research, Prins Maurits Laboratory "An Overview of the Modular Unix-Based Vulnerability Estimation Suite (MUVES)", by Karen R. Murray, Ballistic Vulnerability/Lethality Division, Army Research Laboratory 1200-1315 Lunch 1315-1400 "In-the-Field Modeling", by Harry J. Reed, Geometric Solutions, INC. 1405-1450 "Radar Range Profile Computation for BRL-CAD Models", Dr. S.W. Lee and David Reeves, University of Illinois, Dennis J. Andersh, USAF, C.L. Yu, Naval Pacific Missile Test Center 1450-1515 Break 1515-1600 "End-to-End Sensor Modeling Using BRL-CAD 4.0 with the Faceted Region Editor (FRED)" by Jack Jones, U.S. Army Tank Automotive Command 1605-1700 "Getting BRL-CAD Images Printed", by Christopher T. Johnson, Paladin Software 1800-1930 Banquet Dinner 1930-2000 Key Note Address, Dr. Richard Vitali, Acting Director, Army Research Laboratory 2000-0100 Hospitality Suite/Reception Hosted by RESULTS Now, Inc.

November 5, 1992

0800-0900 Continental Breakfast 0900-0915 Announcements 0915-1000 "Directions in the BRL-CAD Package" (Tentative Title), Michael J. Muuss, Ballistic Vulnerability/Lethality Division, Army Research Laboratory 1000-1015 Break 1015-1100 "Blueprints to BRL-CAD; The User Interface", Erik Lane, Student Contractor, Ballistic Vulnerability/Lethality Division, Army Research Laboratory 1105-1200 Three Short Presentations "Proliferation Concerns in Geometric Modeling", Victor Cericole, Jr. Geometric Solutions, INC. "I/EMS to BRL-CAD Translation: Converting from a B-REP Modeler to a CSG Modeler", Andrew J. Foglia, Intergraph Corporation, Federal Systems Division "Revision Control System (RCS) Configuration Management for BRL-CAD Target Descriptions", Susanne Muuss, Army Research Laboratory 1200-1330 Lunch 1330-1700 Tutorials (Concurrent Offerings)

1) "Animation with BRL-CAD", Christopher T. Johnson, Paladin Software 2) "How to Construct a Simple Model Using BRL-CAD", Victor Cericole, Jr., Geometric Solutions, INC. 3) "How to Use LIBRT, LIBWDB, and LIBFB", Harry J. Reed, Geometric Solutions, INC. 4) "Understanding Non-Manifold Geometry" (Tentative Offering)

2000-0100 Hospitality Suite/Reception Hosted by RESULTS Now, Inc.

November 6th, 1992

0800-0900 Continental Breakfast 0900-1230 Tutorials Repeated 1230-1300 Fare Well

Date: Fri, 13 Aug 93 14:26:39 EDT From: "Lee A. Butler" <butler@brl> To: Edwin O. Davisson <davisson@brl.mil> cc: mike@BRL, pjt@BRL, jra@BRL, stay@BRL, gdurf@BRL, butler@BRL Subject: Re: nearest edge algorithm Message-ID: <9308131426.aa26554@WOLF.BRL.MIL>

Ed,

> In your algorithm for classifying a point as in or out of a >face, Mike claims you look at the nearest edge. How do you find that >nearest edge? Do you assume the polygonal boundary is convex? If >you use a similar approach to what was being described on the sphere >yesterday, you may have a problem.

The current version of the algorithm is something like this:

Given: a "plane point" in the plane of a face, a set of edges in the plane

For each edge in the face, determine the point of closest approach (PCA) of the edge to the "plane point". Remember the edge/PCA pair with the smallest distance to the "plane point."

iff the "closest" edge has its PCA along the length of the edge, or the "plane point" is on the edge: A) if the "plane point" is on the edge, declare it to be "on" the face", otherwise.... B) Determine if the plane point is "left" of the use of the edge in the normal-ward use of the face. 1) form the "left vector" for the edgeuse. 2) form a vector from the endpoint of the edgeuse to the "plane point" 3) form the Dot product of these two vectors.

If the sign of the Dot product is positive or zero, the plane point is inside the surface area of the face, otherwise it is outside the surface area of the face.

iff the "closest" edge has its PCA at a vertex (end point) and the vertex is NOT coincident with the plane point: A) form the vector from the endpoint to the "plane point". B) for each edgeuse of the face which touches the vertex: form the unit "left" vector for the edgeuse, (which points in the direction of the face area WRT the edge). C) find the edgeuse whose left vector has the smallest Dot product with the vector to the "plane point."

If the sign of the Dot product is positive or zero, the plane point is inside the surface area of the face, otherwise it is outside the surface area of the face.

Date: Fri, 20 Aug 93 5:39:06 EDT From: Mike Muuss <mike@brl.mil> To: Anthony Giancola <kachina!tony@cs.unm.edu>, tony@ObjectSci.com cc: mike@BRL.MIL, tony@cs.unm.edu Subject: Re: BRL CAD under Solaris 2.2 Message-ID: <9308200539.aa28134@WOLF.BRL.MIL>

Sorry, we have not had any opportunity to bring BRL-CAD up under Solaris 2.2, that I am aware of. Your best bet would be to remove all LIBFB and MGED display options from Cakefile.defs, and proceed from there. Once you get that working, adding back (say) X windows support shouldn't be too hard.

That is to say, delete all lines starting with:

# if 1 /* Bare Sun configuration */ # define LIBFB_OBJS if_remote if_sun

down through

# endif # endif

Thats about 32 lines worth (judging by eye).

Best, -Mike Muuss

Date: Mon, 23 Aug 93 13:00:06 EDT From: "John R. Anderson" <jra@brl> To: acst@BRL.MIL Subject: New code in "nmg_misc" Message-ID: <9308231300.aa27795@WOLF.BRL.MIL>

I have added a routine called "nmg_break_long_edges" to "nmg_misc.c". This codes looks for situations as illustrated:

*------->*-------->*--------->* *<----------------------------*

where one long edgeuse (the bottom one above) and two or more shorter edgeusess (the tops ones) are collinear and have the same start and end vertices. The code breaks the longer edgeuse into ones that can be radials of the shorter ones. I ran into this situation in converting the "tankill" geometry.

-John

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa15809; 9 Sep 93 14:33 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa17804; 9 Sep 93 13:46 EDT Received: from worm.brl.mil by WALRUS.BRL.MIL id aa17588; 9 Sep 93 13:42 EDT Date: Thu, 9 Sep 93 13:35:40 EDT From: Susan Coates (VLD) <scoates@BRL.MIL> To: cad@BRL.MIL cc: scoates@BRL.MIL Subject: Rotating a Solid Message-ID: <9309091335.aa08483@WORM.BRL.MIL>

Sven Schroeter, tools-administrator. email schroeter@ls7.informatik.uni-dortmund.de

writes:

> i've just installed brl-cad on a sun4 system. > After compiling and installing everything right (?!), > i've got som problems : > 1. how can i rotate a single > solid, when i chose the rotate- > function in the edit-solid menu.

Choose the solid to edit. Select rotate with the mouse. Then type 'p x y z' Where x is the rotation about the x-axis, y is the rotation about the y-axis, and z is the rotation about the z-axis. For example 'p 0 0 -10' rotates the solid -10 degrees about the z-axis. I find it easier to rotate about one axis and accept the edit and then do a rotation about the next axis. I do this because I can not keep straight which rotation comes first (I want to say it is about the z-axis). Also I have trouble visualizing more than one rotation at a time. The rotation must be accepted before another rotation is typed in. For example if the following commands are issued. p 0 0 -10 p 0 0 -20 The result is that the solid is rotated -20 degrees about the z-axis not -30 degrees. An alternate way is to use the sliders. Select sliders and seven sliders appear at the top of the screen; xslew, yslew, zslew, zoom, xrot, yrot, zrot. The solid may be rotated using xrot, yrot, and zrot. Click the mouse to the left or right of the rotate sliders to get the solid to rotate. On my SUN this is extremely difficult I can't see the sliders (I had to log on to an sgi to read what they said). Select Zero Sliders to stop or click the mouse right in the middle of the slider.

I hope this answer helps. I don't know anything about the second problem you are experiencing. Susan Coates

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa16044; 9 Sep 93 15:00 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa19049; 9 Sep 93 14:19 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa18980; 9 Sep 93 14:16 EDT Received: from ATHENA-AS-WELL.MIT.EDU by WHARF.BRL.MIL id aa15343; 9 Sep 93 14:13 EDT Received: from W20-575-7.MIT.EDU by Athena.MIT.EDU with SMTP id AA19036; Thu, 9 Sep 93 14:12:51 EDT Received: by w20-575-7.MIT.EDU (5.0/4.7) id AA05685; Thu, 9 Sep 93 14:12:39 EDT Message-Id: <9309091812.AA05685@w20-575-7.MIT.EDU> To: Adm diverser tools <tools@frenet.informatik.uni-dortmund.de> Cc: CAD@BRL.MIL Subject: Re: brl-cad on sun4 In-Reply-To: Your message of Thu, 09 Sep 93 18:37:34 +0200. <9309091637.AA09999@frenet.informatik.uni-dortmund.de> Date: Thu, 09 Sep 93 14:12:37 EDT From: Ali Alavi <alialavi@athena.mit.edu> Content-Length: 724

Sven,

> 2. calling rt as key-command colors > the desktop black with red borders > to the windows, paints a picture > which is 50% right and 50% wrong > and returns to a b/w desktop. > The rt-window doesn't refresh.

I've had that problem before. the way you fix it is by typing "fbhelp" (which is in the fb directory). It should tell you how to set env options that should fix the problem. I know you're on a sun4, but what os version are you using? Sunview or OpenWindows or Solaris? What options did you compile with? I was running Openwindows...

-=> Ali

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa20123; 9 Sep 93 19:25 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa25041; 9 Sep 93 18:55 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa25026; 9 Sep 93 18:52 EDT Date: Thu, 9 Sep 93 18:48:47 EDT From: "Harry Reed Jr." (GSI|phd) <reed@BRL.MIL> To: tools@frenet.informatik.uni-dortmund.de cc: cad@BRL.MIL Subject: Problems Message-ID: <9309091848.aa18082@WHARF.BRL.MIL>

Sven Schroeter,

There is a problem with selecting solids on a SUN machine using the current version of BRL-CAD. The general process of selecting a solid for rotation is:

1) Display the items on the screen that you want to edit or will need for determining how the solid of interest should be processed. For example, if you want to rotate a cylinder and translate it to rest on the side of a box, then it may be interesting to not only display the cylinder, but the box as well. When the cylinder is modified, then the immediate feedback of the box and cylinder (in its new rotation and orientation) will uickly confirm that the processing action on the cylinder was either a success or a failure.

2) Select "solid edit" from the pop down menu. This action will place you in solid edit state rather than the initial (base) viewing state.

3) Since many different solids can be illuminated at one time, MGED expects you to select a particular solid for editing. One selects a particular solid by moving the cursor up and down until the desired solid outline is either changed in color (red to white on an SGI machine) or is redrawn with a tripple line thickness.

Once the solid you want to edit is highlighted by either of the previously mentioned methods, simply click on the center mouse button once to inalize the selection.

4) Select rotate from the pop down menu and either type in the desired X, Y, or Z axis rotation, or use the sliders or graphics station peripheral control knobs. Please note that if you type in an X, Y, or Z axis rotation value, you must exit rotation mode and re-enter rotation mode if a further rotation is desired. Otherwise, the old (previous) rotation will be replaced by the new rotation as if the old rotation never occurred.

5) Once rotated correctly, select the accept edit field in the pop down menu an the solid edit is complete.

Two final points, I hope that you understand the difference between solids, regions, and groups in a BRL-CAD CSG target description and that you are not referring to regions or group items as some complex surface editors often do. Secondly, there are more direct and sometimes easier to use methods for editing solids such as MGED's "sed" command that were not discussed here. As always, each method has its strengths and weaknesses.

For a more indepth answer to your problem (if you want one), feel ffree to call us at 1-800-598-BRLCAD (2752).

Thanks,

Harry J. Reed Geometric Solutions, INC.

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa03013; 10 Sep 93 8:08 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa01517; 10 Sep 93 7:26 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa01514; 10 Sep 93 7:24 EDT Received: from sun2.nsfnet-relay.ac.uk by WHARF.BRL.MIL id aa03656; 10 Sep 93 7:13 EDT Via: uk.ac.oxford.prg; Fri, 10 Sep 1993 12:12:37 +0100 Received: from oxphys.physiol (oxphys-gate.physiol) by prg.oxford.ac.uk id AA06515; Fri, 10 Sep 93 12:12:23 +0100 Received: from galen.physiol.physiol by uk.ac.oxford.physiology (4.1/physiol 1.2m (20-Jun-90)) id AA22393; Fri, 10 Sep 93 12:01:40 BST Date: Fri, 10 Sep 93 12:01:40 BST From: Patrick Haggard <ph@physiol.ox.ac.uk> Message-Id: <9309101101.AA22393@uk.ac.oxford.physiology> To: alialavi@athena.mit.edu, reed@BRL.MIL Subject: Re: brl-cad on sun4 Cc: cad@BRL.MIL

Er, yes, but the problem with the X interface is that you seem to need xgl _v2.0_, which a lot of sites don't have (it's unbundled), and which is not upwards compatible with the current xgl (v3.0). This was a sufficient deterrent to send me back to suntools. Patrick Haggard --- ph@physiol.ox.ac.uk [WORLD] ph@uk.ac.ox.physiol [JANET]

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa01661; 15 Sep 93 20:54 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa09323; 15 Sep 93 20:11 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa09243; 15 Sep 93 20:01 EDT Date: Wed, 15 Sep 93 19:47:52 EDT From: "Harry Reed Jr." (GSI|phd) <reed@BRL.MIL> To: M.Brand@fel.tno.nl cc: cad@BRL.MIL Subject: FRED Message-ID: <9309151947.aa20278@WHARF.BRL.MIL>

Dr.M.G.E.Brand

In response to your questions concerning the FRED tool, we find it interesting, although not the most mathematically complete approach, but uite useful for general application none the less. Perhaps you would like to speak directly with the creator of FRED at TACOM. His name is Jack Jones (a good friend of mine) and his number is (313)574-7654 USA. If I can answer more questions about the methods we at GSI use to convert BRL-CAD databases into FACETS or B-surfaces, or why you may want to wait for NMG technology to be completed, please call us at 1-800-598-BRLCAD (2752).

Thanks, Harry J. Reed Geometric Solutions, INC

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa20573; 25 Sep 93 11:26 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa23334; 25 Sep 93 11:24 EDT Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa23283; 25 Sep 93 11:16 EDT Date: Sat, 25 Sep 93 11:13:57 EDT From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: LIBFB Interface Change on ANSI compilers Message-ID: <9309251113.aa20302@WOLF.BRL.MIL>

This evening, in an attempt to start porting BRL-CAD to our new SGI Power Challenge machine running IRIX 5, I once again had to wrestle with the issue of ANSI function prototypes for the routines in LIBFB. We had previously said that routines like fb_write() took arguments of type RGBpixel[]. RGBpixel was a typedef for an unsigned char[3] array. As Doug Gwyn pointed out when I brought this up the last time, arrays are not fundamental types in C, and so this construction can be a bit awkward.

With the necessity for (and desireability of) using function prototypes upon us, the difficulty presented by the old method was just too great. So, in the name of simplicity, I converted all the pixel parameters to type (unsigned char *), which more simply describes the "packed byte array" in which pixels are stored. This is better than saying "RGBpixel pp[]" everywhere, which would have had to be dereferenced as pp[i][RED].

I've changed h/fb.h, all of libfb/, all of fb/, all of util/, and odds and ends elsewhere to account for this change. Next time I need a break from working on NMGs I'll try to recompile all the sources, and chase down any other code that needs to be modified as a result of this.

Not surprisingly, a lot of the fb/ code was already using arrays of chars, so making this is proper way to do things actually fits well with a nice chunk (but certainly not all) of our current practice.

I'm sure that there are some of you who will find this change to be disturbing, because it implies that some existing code might not work with the new LIBFB interface. First, let me note that if you are not using an ANSII C compiler, this is an invisible change. And, if you *are* using an ANSII C compiler, you can't get the benefits of function prototypes without this change. Function prototypes are no panacea, but I'm sufficiently pleased with their utility to insist that they be used on all major interfaces.

I converted about 60 complete source modules in the course of about 6 hours, so in general changing a source file or two shouldn't take long. I really didn't want this change, I'm not looking for change just for the sake of change. This is something that is being forced upon us by the increasing availability of ANSI C compilers.

I think I've gotten everything in LIBFB except the X Windows module (libfb/if_X.c) ported to IRIX 5 already -- and X is only complaining about one thing (dpy->fd reference). Should be easy to fix.

Best, -Mike

Received: from vgr.brl.mil by WOLF.BRL.MIL id aa06906; 27 Sep 93 15:21 EDT Date: Mon, 27 Sep 93 19:15:08 GMT From: Doug Gwyn (ACISD/MCSB) <gwyn@BRL.MIL> To: Mike Muuss <mike@BRL.MIL> cc: CAD@BRL.MIL Subject: Re: LIBFB Interface Change on ANSI compilers Message-ID: <9309271915.aa19756@VGR.BRL.MIL>

The only reasonable alternative would be to change RGBpixel to be a structure type, but that means each RGBpixel could have from zero to five additional unusable "padding" bytes (most likely 1 byte) added by the compiler, which would (a) waste space and (b) be incompatible with existing code that handles pixel data as a packed byte array. Thus, while (a) might be deemed acceptable when designing new software (especially since it might lead to faster generated code), consideration (b) pretty much forces the solution Mike chose.

The "flavor" of code using constructs like pp[i][RED] can be retained by defining suitable macros, e.g.:

typedef unsigned char RGBpixel[3]; /* still useful! */ #define RED 0 #define GREEN 1 #define BLUE 2

#define PIX(a,i,c) ((RGBpixel *)(a))[i][c] #define PIX_RED(a,i) PIX(a,i,RED) #define PIX_GREEN(a,i) PIX(a,i,GREEN) #define PIX_BLUE(a,i) PIX(a,i,BLUE)

#define PP(i,c) PIX(pp,i,c)

PIX(pp,i,RED) /* was: pp[i][RED] */ PIX_RED(pp,i) /* ditto */ PP(i,RED) /* ditto */

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa06606; 22 Sep 93 16:21 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa17879; 22 Sep 93 15:42 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa17703; 22 Sep 93 15:34 EDT Received: from Sun.COM by WHARF.BRL.MIL id aa19755; 22 Sep 93 15:27 EDT Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA18018; Wed, 22 Sep 93 12:27:08 PDT Received: from East.Sun.COM by snail.Sun.COM (4.1/SMI-4.1) id AA29970; Wed, 22 Sep 93 12:27:05 PDT Received: from spdev.East.Sun.COM (spdev-gw.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1) id AA25051; Wed, 22 Sep 93 15:27:03 EDT Received: by spdev.East.Sun.COM (4.1/6.1-spdev1) id AA17096; Wed, 22 Sep 93 15:26:53 EDT Date: Wed, 22 Sep 93 15:26:53 EDT From: "Timothy G. Smith - Special Projects" <tgsmith@sun.com> Message-Id: <9309221926.AA17096@spdev.East.Sun.COM> To: cad@BRL.MIL Subject: 4.0 on Solaris 2.X (and other porting/misc issues)

Folks,

I am in the process of getting 4.0 up and running on Solaris 2.3. I have a fair amount of stuff already working and am on the way towards getting the rest of it working and have a couple of questions that someone out there might be able to answer.

I am not on the mailing list so if I am asking questions that have been discussed before (or discussed to death) please kindly refer me to the archives (if there are any) and excuse my interruption.

- The code classifies the world into two interface camps (BSD and SYSV). While historically this has been a good way to do things the days of vanilla BSD versus SYSV are waning. It looks like most vendors are going to hybrid systems that support a number of interfaces. Are there any plans to try adapt to the brave new hybrid world any time soon? I am going to have to butcher the code to make a number of things work properly and am not looking forward to perpetrating such bogosity if it can be avoided.

As an aside, I have worked on a couple of projects where we have taken the approach of using a single OS define to select a the right set of interfaces to use on a given platform. It has been my experience that this really cuts down on the "ifdef soup" in large projects and makes it fairly quick and painless to port to a new platform. It would be great to see the cad source set up like this although it would require a boat load of work.

- Is anyone using shared libraries? I have not really done any memory profiling yet but shared libraries usually tend to be a win and do not require too much extra effort.

- Is there any tentative release data for the next version yet and is there a working list of what will be in the next release?

- Is BRL interested in taking back diffs for solaris support and integrating them into the next release?

- When I worked at BRL the platform of choice for running the cad package was from SGI. I assume this is still true. Can someone fill me in on the config and performance numbers of typical SGI being used for CAD work? I would like to put together a similarly configured sun to see how it performs.

thanks, --tim

PS: Please make sure to include me, tgsmith@sun.com, directly in any replies since I am not on the cad mailing list.

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa19109; 30 Sep 93 14:23 EDT Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa21622; 30 Sep 93 14:17 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa21565; 30 Sep 93 14:12 EDT Received: from cs.ida.org by WHARF.BRL.MIL id aa16485; 30 Sep 93 14:01 EDT Received: from omni.ida.org by ida.org (4.1/SMI-DDN) id AA04385; Thu, 30 Sep 93 14:01:14 EDT Received: from oed-u1.ida.org by omni.ida.org (4.1/SMI-4.1) id AA13674; Thu, 30 Sep 93 14:01:13 EDT Received: from bturner-pc.ida.org by oed-u1.ida.org (4.1/SMI-4.1) id AA22076; Thu, 30 Sep 93 14:01:11 EDT Date: Wed, 29 Sep 1993 14:00:15 From: Ben Turner <bturner@ida.org> To: cad@BRL.MIL Subject: Axes, Automating Repetitive MGED Chores Message-Id: <QCA9CD30@bturner-pc>

Thomas Browder writes: > >A great aid in MGED would be a constant XYZ coord. system >orientation aid, say a small set of labeled unit vectors >in the lower right corner of the screen. >

Axes are not automatically available in MGED but can easily be built as an added element to a .g database. "The MGED User's Manual", Volume IV of the BRL-CAD Release 4.0 Documentation describes building coordinate axes in Chapter 13. Once built, the axes may be included in any output to aid in orientation and to provide scale.

Repetitive chores like adding coordinate axes, placing multiple copies of objects into databases (ex. illustrating burst points around a ground target), or generating a depiction of a shotline given impact coordinates and final azimuth/elevation can all be all be automated. Commands from a file can be redirected or commands from a program can be piped into MGED avoiding the repetitious interactive input.

ex: #mged test.g <build_test.cmd or #build_test <build.dat | mged test.g

The creator of the file or the program anticipates the needed MGED command sequence. MGED opens the database with null display, echoes the prompts the user would otherwise see and terminates on EOF.

The following shell and awk files provide a quick kludge to automate the process of adding a single set of coordinate axes to a .g database where the user specifies an offset (in model coordinates) and axis size parameters. The shell script simplifies parameter passing to awk. The awk script generates mged commands which can be piped to mged. Three cylinders are generated at the specified intersection, defined as regions, color coded (rgb <==> xyz) and grouped as __axes. If needed __axes may be object edited to a better location or they can be removed with "killtree __axes" and regenerated with more desirable properties. A sample of the input generated for MGED is also included.

- beginning of shell file "gen_axes.sh" - #!/bin/sh #shell file to invoke awk program to generate # mged commands to build coordinate axes # (shell file simplifies parameter passing) # #usage: sh gen_axes.sh x0 y0 z0 length diameter|mged db.g # invokes: # awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5 # where: x0 y0 z0 define the offset from the origin to place axes # length of the cylinders making up the axes and # diameter of the cylinders # and output is fed to mged to add to db.g # # ex: sh gen_axes.sh 0 -3000 0 1000 10|mged test.g # would generate axes in test.g 1 meter long, 1 cm diameter # with an intersection displaced -3 meters in y on the X/Y plane # # brute force (simple hard coding) employed, decorate at leisure # solids are named __axes_x.s __axes_y.s __axes_z.s # regions are named __axes_x.r __axes_y.r __axes_z.r # the group is named __axes ################################################################### awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5 - end of shell file "gen_axes.sh" -

- beginning of awk file gen_axes.awk - ################################################################### #awk program to generate mged commands to build coordinate axes # #usage: sh gen_axes.sh x0 y0 z0 length diameter # where gen_axes.sh invokes # awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5 # where: x0 y0 z0 define the offset from the origin to place axes # length of the cylinders making up the axes and # diameter of the cylinders # # ex: sh gen_axes.sh 0 -3000 0 1000 10|mged test.g # would generate axes in test.g 1 meter long, 1 cm diameter # with an intersection displaced -3 meters in y on the X/Y plane # # brute force (simple hard coding) employed, decorate at leisure # solids are named __axes_x.s __axes_y.s __axes_z.s # regions are named __axes_x.r __axes_y.r __axes_z.r # colors are reddish (x), greenish (y), and bluish (z) # the group is named __axes ###################################################################

END{ radius = diam/2

printf("regdef 19997\n") #setup arbitrarily for idents 19997-9

# X axis printf("in __axes_x.s rcc %f %f %f", x0, y0, z0) #name, rcc, origin printf(" %f %f %f", len, 0, 0) #length along x printf(" %f\n", radius) #radius of rcc printf("r __axes_x.r u __axes_x.s\n") #region def printf("mater __axes_x.r\nplastic\n\n250 150 150\n\n") #color

# Y axis printf("in __axes_y.s rcc %f %f %f", x0, y0, z0) printf(" %f %f %f", 0, len, 0) printf(" %f\n", radius) printf("r __axes_y.r u __axes_y.s\n") printf("mater __axes_y.r\nplastic\n\n150 250 150\n\n")

# Z axis printf("in __axes_z.s rcc %f %f %f", x0, y0, z0) printf(" %f %f %f", 0, 0, len) printf(" %f\n", radius) printf("r __axes_z.r u __axes_z.s\n") printf("mater __axes_z.r\nplastic\n\n150 150 250\n\n")

# group printf("g __axes __axes_x.r __axes_y.r __axes_z.r\n")

} - end of awk file gen_axes.awk -

- sample of output that would be sent to mged for example given (\ is cont) - grendel 31% sh gen_axes.sh 0 -3000 0 1000 10 regdef 19997 in __axes_x.s rcc 0.000000 -3000.000000 0.000000 1000.000000 0.000000\ 0.000000 5.000000 r __axes_x.r u __axes_x.s mater __axes_x.r plastic

250 150 150

in __axes_y.s rcc 0.000000 -3000.000000 0.000000 0.000000 1000.000000\ 0.000000 5.000000 r __axes_y.r u __axes_y.s mater __axes_y.r plastic

150 250 150

in __axes_z.s rcc 0.000000 -3000.000000 0.000000 0.000000 0.000000\ 1000.000000 5.000000 r __axes_z.r u __axes_z.s mater __axes_z.r plastic

150 150 250

g __axes __axes_x.r __axes_y.r __axes_z.r - end of sample output -

----------------------------------------------------------------------- Dr. Benjamin W. Turner bturner@ida.org Operational Evaluation Division Office: (703) 845-6931 Institute for Defense Analyses Autovon: 289-1980 1801 N. Beauregard Street FAX: (703) 845-6911 Alexandria, VA 22311-1772 Verify: (703) 845-2544 -----------------------------------------------------------------------

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa25758; 17 Nov 93 12:04 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa20898; 17 Nov 93 11:01 EST Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa20700; 17 Nov 93 10:49 EST Received: from relay1.UU.NET by WHARF.BRL.MIL id aa08850; 17 Nov 93 10:31 EST Received: from bruker.com (via bii.BRUKER.COM) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14781; Wed, 17 Nov 93 10:32:48 -0500 Received: by bruker.com (4.1/SMI-4.1) id AA00425; Wed, 17 Nov 93 10:28:45 EST From: joe edward meier <jem@bruker.com> Message-Id: <9311171528.AA00425@bruker.com> Subject: Problems dublicating Animation tutorial To: BRL-MIL <CAD@BRL.MIL> Date: Wed, 17 Nov 93 10:28:45 EST X-Mailer: ELM [version 2.3 PL0]

I was trying to duplicate the things in the "Animation Techniques in BRL-CAD" WWEB file. Most everything went fine except when I tried to preview the animation script in "mged", in which case "mged" just quit on me when I typed the command "preview moss.rtanim". This happend in both the 4.1 and 4.2 version of BRL-CAD. Below is the output from meged:

50 jake/fj/jem_files/brl-cad4.2/db> mged moss.g BRL-CAD Release 4.2 Graphics Editor (MGED) Tue Nov 16 13:25:19 EST 1993, Compilation 18 jem@crim1:/disk4/jem_files/brl-cad4.2/mged

attach (nu|tek|tek4109|ps|plot|sgi|X)[nu]? sgi ATTACHING sgi (SGI 4d) Gary Moss's "World on a Platter" (units=mm) mged>preview moss.rtanim eyepoint at (0,0,1) viewspace rt_do_cmd(orientation): command not found command failed: orientation mat_inv: error! fabs(y)=0 MATRIX singular matrix: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 200.000

mat_inv: singular matrix

The "moss.rtanim" script seems fine to me, because it works fine when I create the Postage stamp animations. Does any one know why this is not working? I am running on a 4D/35 with Irix 4.0.5.

I also have a few more questions. The first is how the mpeg movie for the animations in this paper were created? Is there some public domain software which can convert the BRL-CAD pix files into a MPEG file? Finally, whay are the main new features of the 4.2 version. Is it just a improved X11 version of "mged"? I could sure use the NURB editting capability that is being worked on. Any plans on a beta relase of this stuff?

Thanks,

Joe --

Joseph Meier, Ph.D. Senior NMR Software Scientist

Bruker Instruments Inc. USA Billerica, MA. 01821

Phone: 508-667-9580 Fax: 508-663-9177

jem@bii.bruker.com Internet !{uunet,ulowell}!bii!jem UUCP

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa09408; 22 Nov 93 17:21 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa04043; 22 Nov 93 16:15 EST Received: from admii.arl.army.mil by WALRUS.BRL.MIL id aa03947; 22 Nov 93 16:11 EST Date: Mon, 22 Nov 93 15:58:02 EST From: Glenn Gillis <gillis@BRL.MIL> To: cad@BRL.MIL Subject: SURVIAC BRL-CAD User's Group Meeting, 29 September 1993 Message-ID: <9311221558.aa11901@ADMII.ARL.ARMY.MIL>

Attendees:

Jeff Foulk SURVIAC ASO (410) 273-7794 Carla Moyer SURVIAC ASO (410) 273-7794 Bob Strausser SURVIAC ASO (410) 273-7794 Jack Benkert SURVIAC BA&H (703) 280-8239 Ed Hathaway SURVIAC BA&H (703) 902-5829 Carl Hutzler SURVIAC BA&H (703) 902-5830 Dr. Paul Dietz ARL (410) 278-6282 Bill Mermagen, Jr. ARL (410) 278-8740 Joseph Silverstein ARL (301) 394-3170 Kellye C. Frew Applied Research Associates (505) 883-3636 Chris Johnson Geometric Solutions Inc. (410) 273-7058 George Anderson IDA (703) 845-2539 Ben Turner IDA (703) 845-6931 Carole Keyser Ketron (410) 583-8386 Steve McKay Pacific-Sierra Research Corp. (703) 516-0235 Bud Bruenning Sverdrup Technology (904) 729-6497

The SURVIAC BRL-CAD User's Group Meeting was held at the Booz- Allen Hamilton facilities in McLean, Virginia. Mr. Jeff Foulk, SURVIAC Aberdeen Satellite Office (ASO) project manager, welcomed the attendees, presented the purpose of the meeting, and provided an overview of the SURVIAC organization. The thrust of the meeting was presentation of uses for BRL-CAD, program updates, and discussion of user problems and ideas.

Ms. Carla Moyer, SURVIAC ASO administrative manager, presented the function of the SURVIAC ASO regarding BRL-CAD. SURVIAC full support includes distributing the BRL-CAD source code and documentation, providing telephone support for installation and operation technical inquiries, distributing maintenance release updates, and maintaining a mailing list database of users. Points of contact for BRL-CAD 4.0 are no longer relevant. Mr. Bob Strausser, SURVIAC ASO BRL-CAD technical POC, presented an overview of technical inquiries over the last 9 months. Inquiries were primarily administrative (67%) with the balance divided between installation and operation questions.

During the Technical Inquiry overview, Dr. Dietz stressed that the vdeck conversion program and gift shotlining program are obsolete. The principal problem with using vdeck lies with the expansion of BRL-CAD primitives beyond the supported primitives of the old comgeom format (generated by vdeck). This can result in the loss of data by the conversion back into the comgeom era. Joseph Silverstein is using vdeck and gift to interface between BRL-CAD geometries and the schrim radar signature program. Dr. Deitz and Bill Mermagen, Jr. recommended using rtrayhist and xpatch as better tools than the gift / schrim pair. The vdeck and gift programs are also used to feed hevart because the sequence of shotlines provided by rtg3 is not compatible with hevart's input requirements. Carole Keyser recommended using shotb2g, it converts rtg3 output into a format compatible with hevart. Contact John Anderson at ARL (278-7267) for copies of the shotb2g program.

Mr. Bob Strausser also presented a status update on the patch-g conversion program. This program provides initial conversion of FASTGEN faceted geometry descriptions into BRL-CAD format. The updated program has been sent to Bill Mermagen, Jr. for review and release.

Bill Mermagen, Jr. presented an overview of BRL-CAD status and plans. The next release of BRL-CAD anticipated Summer 1994, will have a production version of the N-manifold Geometry (NMG) capability. This will permit use of polygonal representations for import, export, and visualization and will provide better support for faceted-geometry dependent analysis codes. Along with the NMGs, new primitives (i.e.. elliptical tori, paraboloids, and hyperboloids) will be available. A second task area has been revising the MGED graphical user interface (GUI) to make the system more user friendly. Two GUIs are in development as replacements for the current interface. One GUI (being developed by Phil Dykstra) is based on MOTIFF and X-windows. The other GUI (being developed by Mike Muuss) is vendor independent (depart from X-window dependency). The BRL-CAD team (primarily Mike Muuss) is also examining the possibility of using virtual reality. The third task area has provided more conversion routines for importing foreign CAD geometries into BRL- CAD.

The importance of BRL-CAD's need to support faceted geometries (the NMG / tessellation upgrade) was reinforced by Kellye Frew , Applied Research Associates (ARA). She indicated that ARA is involved with an effort to generate a 3-D mesh to interface with epic. BRL-CAD was used for Phase I of this program.

Mr. Bud Bruenning, Sverdrup Technology, presented an overview of how he is using BRL-CAD and enhancements he would like to see. The highest priority was a simple tutorial document. He would also like some new image generation capabilities (cross sectional cuts, automated component id number labeling, easier overlays). Lesser issues concerned improvements to patch-g and better support from the developers. Dr. Dietz suggested that Bud visit with ARL for a "working group" session on generating images and plots. Any one interested in participating in an imaging working group, please contact the SURVIAC ASO (Resalee Bilka).

Geometric Solutions, Inc. (GSI) presented a report on the addition of joint information to BRL-CAD models. This new ability, as outlined by Chris Johnson, GSI, will allow users to change the configuration of targets with a simple click and drag interface.

This new capability is being integrated with BRL-CAD and will be available to all in the next BRL-CAD release. More information is available from Victor Cericole, Jr., GSI Software Director, 1-800- 598-BRLCAD (2752).

Mr. Steve McKay, Pacific-Sierra Research Corp., expressed an interest in accessing a model description database. He is aware of several and was wondering if any coordination existed between these databases. Information concerning geometry model databases would be appreciated as the SURVIAC ASO researches this issue.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Prepared by Bob Strausser, SURVIAC Aberdeen Satellite Office, (410) 273-7794.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Date: Wed, 22 Dec 93 7:07:30 EST From: Mike Muuss <mike@brl.mil> To: Jim Hunt <jehunt@brl.mil> cc: acst@BRL.MIL, Jill@BRL.MIL, PHD@BRL.MIL Subject: Re: rt_free( rt_i ) ??? Message-ID: <9312220707.aa28241@WOLF.BRL.MIL>

> BTW, I had been using rt_malloc, [...]

Good, I'm glad it has been useful.

> Now, I have another question. The interactive program I am developing > may import many different BRL-CAD data bases during a single session. > Each may optionally be raytraced any number of times. When I am done > each raytrace, I am finished with the struct rt_i that rt_dirbuild > gave me. Is there a (kosher) way to free the memory allocated for this > rt_i and its members?

The answer is: YES. I already thought of that. :-) It's broken out in several pieces, so you can free different parts at different times.

/* Release dynamic storage */ rt_vlist_cleanup(); /* if you use vlist */

rt_clean( rtip ); /* eliminate prepping, but not db */ db_close( rtip->rti_dbip ); /* eliminate all db info */

#if MEMORY_LEAK_CHECKING rt_prmem("After complete processing"); #endif

I noticed that there was no way to dispose of the rt_i structure itself, so I've added:

rt_free_rti( rtip ); /* does rt_clean, db_close, rt_free */

Also note that if you are not changing the database, and not doing any articulations, you can just keep using the existing rt_i structure. No need to re-prep.

If you are doing articulations, you can rt_clean(), change articulation, and then just call rt_gettrees() and rt_prep().

If you are going to be changing databases in mid-stream, there is probably some additional minor library support that you will need. (Such as routines like rt_new_rti(), and perhaps reference counts on the db_i structures). I have always intended for this to be possible, but I've never actually tried it, so you know what that means. Please let me know what you have in mind, so we can support it.

> I'm already peeking (poking) at struct region > to put criticality information in the reg_udata member. Is that even > kosher?

reg_mfuncs and reg_udata are pointers for you to set as you need. It's entirely kosher for you to make them point at your own data structures. (Just don't serve them on the same plates as the Swiss cheese.)

> Maybe I should make a (short) list of the rules I am breaking > (especially w.r.t. union record) and see if you guys can come up with > an alternative for me (either a better way for me to do it, or new > library calls to be maintained outside of application code.)

That sounds like a very good idea. If there is some operation that you need to be able to do to the data structures, probably somebody else will have a similar need in the future. So it would be best to minimize special LIBRT interface code built into your application. Unless it turns out to be really hard, I'd rather just make sure that the library gives you all the support that you need. So speak up. :-)

So, now I'm curious: what are you doing to "union record"? That structure defines the on-disk database format, and is _the_ most difficult to change.... Hopefully you meant "union region"?

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa21595; 11 Jan 94 17:32 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa27960; 11 Jan 94 16:44 EST Received: from admii.arl.army.mil by WALRUS.BRL.MIL id aa27908; 11 Jan 94 16:41 EST Date: Tue, 11 Jan 94 16:39:06 EST From: Glenn Gillis <gillis@BRL.MIL> To: akekesi@nvl.army.mil cc: cad@BRL.MIL Subject: RE: BRL-CAD newsletter Message-ID: <9401111639.aa23469@ADMII.ARL.ARMY.MIL>

In response to:

>Date: Mon, 3 Jan 94 09:04 EST >From: Alex Kekesi <akekesi@nvl.army.mil> >Subject: BRL-CAD newsletter > >Hi, > > I understand there is an e-mail newsletter for BRL-CAD >users. I would be very interested in joining if such a >newsletter exists. > >Thanks in Advance! > >B.A. Kekesi >

Alex,

The SURVIAC ASO is currently providing a BRL-CAD newsletter for both SURVIAC and FTP registered users of BRL-CAD. It is published quarterly and mailed to the users. The December issue was mailed last week. If you do not receive it shortly, forward your name and address to me for addition to the mailing list(or I can e-mail it to you).

The newsletter was originally intended as an extension to this e-mail forum, providing announcements of events and extracts from the e-mail for non-E-mail users. All contributions and / or suggestions for topics of discussion are welcome.

Bob Strausser SURVIAC ASO Technical Rep

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa13822; 28 Jan 94 11:22 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa10915; 28 Jan 94 10:22 EST Received: from worm.brl.mil by WALRUS.BRL.MIL id aa10621; 28 Jan 94 10:11 EST Date: Fri, 28 Jan 94 10:06:33 EST From: "Jill H. Smith, Ch., Vuln. Meth. Br." <jill@BRL.MIL> To: jim montgomery <monty@mensa.usc.edu> cc: cad@BRL.MIL Subject: Re: BRL-CAD classes Message-ID: <9401281006.aa14687@WORM.BRL.MIL>

Jim,

ARL is not currently sponsoring courses on BRL-CAD, however, there are at least two commercial vendors in our area that offer BRL-CAD training:

Geometric Solutions Inc. 100 Custis St. Aberdeen, MD 21001 (410) 273-7058

Survice Engineering Co. 1003 Old Phila. Rd. Aberdeen, MD 21001 (410) 273-7722

Hope this helps.

Jill Smith Chief Vulnerability Methodology Br. ARL

Received: from worm.brl.mil by WOLF.BRL.MIL id aa02107; 25 Jan 94 19:28 EST Date: Tue, 25 Jan 94 19:25:24 EST From: "Jill H. Smith, Ch., Vuln. Meth. Br." <jill@BRL.MIL> To: mdelapp@mcl.bdm.com cc: mike@BRL.MIL, stay@BRL.MIL, jra@BRL.MIL, phd@BRL.MIL Subject: BRL-CAD as Interim PDES/STEP standard Message-ID: <9401251925.aa04336@WORM.BRL.MIL>

To mdelapp,

BRL-CAD has been proposed as an AMC standard for geometric system data exchange through the AMC Functional Coordinating Group for Computer Interoperability and Interchange (FCG-CII). PDES/STEP are ultimately tackling a much broader spectrum of data, such as plumbing and sheet-metal-folding data, than what BRL-CAD represents. BRL-CAD however offers an OPEN (i.e. government owned) format for exchange of geometric information and associated properties at a level of information sufficient for most of the engineering analyses performed within AMC. No commercial CAD/CAE package can meet all the requirements for geometry representation/interrogation to meet the analysis needs of this community - hence the proliferation of different CAD/CAE systems.

BACKGROUND. The issue of geometric target data exchange came up between ARL (old BRL), ARDEC, Benet and TACOM when it was pointed out that each organization used a different modeling system. For efficient design, evaluation and integration of Army systems it would be of benefit if these organizations could exchange system information in electronic format. MICOM also asked to be included on the Technical Working Group to address these issues, since within MICOM they had as many or more different/non-compatible modeling systems as the rest of us put together. Most of the commercial modeling systems have proprietary data representations and although you can build geometric target descriptions in these modelers and perform various analyses, most do not allow you to export the geometry and associated information such as material properties. Additionally, the underlying mathematical representations of the data, if available, may not be compatible. That is, a format for exchange does not handle translation of data from one mathematical form to another.

CURRENT STATUS. PDES/STEP addresses only the problem of exchange, not translation. That is, if two modeling systems represent the geometric information in the same mathematical form - say splines, then PDES/STEP specifies the format for exchange. However, the PDES/STEP standardization effort is still fairly young and not all geometric entities are yet specified for exchange. For example, in the area of solids, there is no specification for the exchange of a truncated general cone, elliptical torus, paraboloid of one sheet, etc.

Within AMC we have both problems, that is, the underlying mathematical representations of the geometry are not the same and not all geometric representations are covered by exchange specifications. BRL-CAD, used by ARL, is a Constructive Solid Geometric modeling system with Boolean trees. Intergraph, used by TACOM, is believed to be a spline-based system, although the specific data representations are proprietary. Translators, which may be approximations, must be developed to transfer data between these systems.

TRANSLATORS

BRL-CAD <=> Intergraph. The Foreign Science and Technology Center and the Tank Automotive Command jointly sponsored BRL-CAD <=> Intergraph translators through a contract with Intergraph. The Intergraph => BRL-CAD translation is accomplished by converting GIFT (Geometric Information For Targets) and Booleans into the corresponding BRL-CAD representations. Any solid not represented in the GIFT format is tessellated and transferred as a polysolid. The Intergraph => BRL-CAD translator works reasonably well, when Intergraph models have been constructed following certain stylistic rules peculiar to the translator, however the BRL-CAD=> Intergraph translator has a much greater loss of information.

PATCH-G. The patch-g translator was developed by BRL (now ARL) under sponsorship by the Air Force. Patch-g translates FASTGEN2/FASTGEN3 target descriptions into BRL-CAD .g format. Plate-mode facets are difficult to convert.

Jack-G. Jack is an articulated human figure package developed by the University of Pennsylvania under the sponsorship of the Human Engineering Laboratory (now Human Research & Engineering Directorate, Army Research Laboratory). ARL/SLAD developed the jack-g translator to import articulated human figures into vehicles.

ACAD <=> BRL-CAD. ACAD is the geometric modeling system developed by General Dynamics in the Fort Worth office (this branch has since been sold to one of the aircraft companies). ACAD has developed and distributes the ACAD <=> BRL-CAD translators. ARL has no experience with the use of these translators.

BRL-CAD <=> Euclid. Euclid is a geometric modeling system developed by Matra Datavision of France. The underlying data representation is believed to be cubic Bezier patches (the simplest subset of B-splines), however, the users with whom we are coordinating the effort, have access to only a polygonal boundary representation of their geometry. ARL is currently extending our valid data representations to include N-Manifold Geometry (NMG) data structures. In the initial implementation, NMGs will include polygonal boundary representations and the associated topological information. We are currently able to import Euclid polygons into BRL-CAD and view them using the polygon fill hardware of the SGI, but cannot interrogate (i.e., raytrace) the geometry. Conversion routines for CSG to NMG forms must be completed to export BRL-CAD to Euclid.

BRL-CAD <=> IGES. The IGES=> BRL-CAD converter has been developed in-house (by ARL) and has recently been upgraded to include the IGES BREP (boundary representation) objects into N-Manifold Geometry (NMG) data structures for planar faces and IGES drawings (2D lines) to BRL-CAD NMG's. The iges-g converter translates IGES Constructive Solid Geometry (CSG) files into BRL-CAD CSG files with approximations for IGES solids of revolution and solids of linear extrusion. The g-iges translator allows for two types of IGES output from BRL-CAD. 1) A 100% facetized representation can be selected where each region is facetized to an NMG object before output as an IGES "Manifold Solid BREP Object (MSBO)", or 2) a mostly CSG file can be produced where each region is output as an IGES "Boolean Tree" entity and each solid is output as the corresponding IGES solid. In cases where there is no corresponding IGES solid (truncated general cone, elliptical torus, etc.), a facetized approximation of the BRL-CAD solid is output as an IGES MSBO. The efforts described here depend on the current NMG work mentioned in the previous paragraph. We expect the NMG work and translators to be available in the next BRL-CAD release.

Target descriptions in BRL-CAD format are a deliverable from the contractor on most ground system development programs. Since the BRL-CAD format is government developed and open, it can be specified as a deliverable in a contract. This facilitates the transfer to Intergraph for analyses by TACOM and directly feeds the vulnerability/lethality analyses required by ARL.

The Intelligence Community Modeling Group is also relying on BRL-CAD geometry both as input to various signature codes (e.g. Xpatch, TSAR) and also as an intermediate file format for exchange. We are currently investigating extending our geometry representations to include a "height field" data type to facilitate terrain modeling in support of a DMSO proposal for signature generation and automatic target recognition.

I have included below a note from one of our users who uses BRL-CAD specifically as an interface between other CAD tools.

Received: from wharf.brl.mil by WORM.BRL.MIL id aa05299; 5 Jan 94 12:18 EST Received: from VARMIT.MDC.COM by WHARF.BRL.MIL id aa06915; 5 Jan 94 12:18 EST Received: from huston.mdc.com by varmit (4.1/SMI-4.1) id AA05709; Wed, 5 Jan 94 09:12:39 PST Message-Id: <Chameleon.940105092059.huston@huston.mdc.com> Date: Wed, 5 Jan 94 09:16:56 PST Reply-To: Stu Huston <huston@huston.mdc.com> From: Stu Huston <huston@huston.mdc.com> To: "Jill H. Smith, Ch., Vuln. Meth. Br." <jill@BRL.MIL> Subject: RE: Dual Use

At Mcdonnell Douglas, we are using BRL-CAD as an interface between other CAD tools (such as Unigraphics, PATRAN, and SMART) and radiation transport codes to calculate the radiation dose in space (e.g., from solar flare protons or cosmic ray heavy ions). The ray tracing capabilities of BRL-CAD are what led us to this configuration. As we gain experience with the package, we may use it as more of a total integrated product development tool (e.g., for determining mass properties, etc.). So far, we are very pleased with tho package.

Future uses for the radiation transport work include medical imaging and therapy, and risk calculations for the High-Speed Civil Transport.

-------------------------------------------------------- Stuart L. Huston McDonnell Douglas Aerospace 5301 Bolsa Ave. M/S 13-3 Huntington Beach, Calif. 92647 phone (714) 896-4787 fax (714) 896-6930 -------------------------------------------------------- huston@huston.mdc.com

If you have questions or require more information, please feel free to contact me.

Jill H. Smith Chief Vulnerability Methodology Branch (jill@arl.army.mil) 410-278-6644

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa07794; 24 Jan 94 11:03 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa20254; 24 Jan 94 10:14 EST Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa20083; 24 Jan 94 10:09 EST Received: from relay1.UU.NET by WHARF.BRL.MIL id aa20886; 24 Jan 94 10:04 EST Received: from bruker.com (via bii.BRUKER.COM) by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwaga08346; Mon, 24 Jan 94 10:01:01 -0500 Received: by bruker.com (4.1/SMI-4.1) id AA21660; Mon, 24 Jan 94 09:55:31 EST From: joe edward meier <jem@bruker.com> Message-Id: <9401241455.AA21660@bruker.com> Subject: proc-db/pipetest.c questions To: BRL-MIL <CAD@BRL.MIL> Date: Mon, 24 Jan 94 9:55:30 EST X-Mailer: ELM [version 2.3 PL0]

I was trying to figure out how to use the pipe generating code, by playing around with pipetest.c, but it seems like all the pipes are generated with a infinitly small diameter. Even, if I try to change the id and od parameters. The pipes that are generated by the program cannot be zoomed in on. How do I increase the diameters of the pipes? I tried using the following for: { {(long)WDB_PIPESEG_MAGIC, 0, 0}, 0, 1, 0, 0, 0, 0, 500.10, 900.5, WDB_PIPESEG_TYPE_LINEAR }, From my understanding this should give an id=500.10 mm and an od=900.5, but I still cannot zoom in on the resulting pipe.

Also, how does one specify bends greater than 90 degrees (like say 180 degreees)?

--

Joseph Meier, Ph.D. Senior NMR Software Scientist

Bruker Instruments Inc. USA Billerica, MA. 01821

Phone: 508-667-9580 Fax: 508-663-9177

jem@bii.bruker.com Internet !{uunet,ulowell}!bii!jem UUCP

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa19076; 28 Jan 94 20:30 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa22450; 28 Jan 94 19:38 EST Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa22448; 28 Jan 94 19:34 EST Date: Fri, 28 Jan 94 19:26:08 EST From: Mike Muuss <mike@BRL.MIL> To: joe edward meier <jem@bruker.com> cc: BRL-MIL <CAD@BRL.MIL> Subject: Re: proc-db/pipetest.c questions Message-ID: <9401281926.aa18007@WOLF.BRL.MIL>

Joseph Meier wrote -

> I was trying to figure out how to use the pipe generating code, by > playing around with pipetest.c, but it seems like all the pipes are > generated with a infinitly small diameter.

The old Television saying applies here: "The Problem is Not in Your Set".

The support for PIPE solids is very rudimentary. What you see was done as part of the proposal for a joint project with Air Systems Branch that was not funded. The data structures are defined, and the import/export routines exist, but the PIPEs can not be ray-traced. They can't really be edited in MGED either, and when drawn, only the centerline is displayed.

So, what you are seeing is not that the diameter is not being stored in the database, but instead that the drawing routine is not drawing the exterior of the pipes.

It is unlikely that anyone in ARL will be fleshing out the PIPE solid, at least not within this FY. If you wish to complete the code yourself, the changes are restricted to one file: librt/g_pipe.c. In the alternative, you might be able to use cylingders and spheres, as is often done now.

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa20681; 28 Jan 94 23:54 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa22879; 28 Jan 94 23:04 EST Received: from wolf16.brl.mil by WALRUS.BRL.MIL id aa22870; 28 Jan 94 22:54 EST Date: Fri, 28 Jan 94 22:48:33 EST From: Mike Muuss <mike@BRL.MIL> To: CAD@BRL.MIL Subject: Irix 5 GL // LIBFB bug Message-ID: <9401282248.aa19808@WOLF.BRL.MIL>

Those of you with Silicon Graphics machines running recent versions of the operating system (Irix 5) have probably noticed how programs linked with -lgl (most notably all the BRL-CAD programs that use LIBFB) won't work unless $DISPLAY is pointing to a GL-capable workstation.

Well, in the release notes for Irix 5.2, they make mention of this:

You can work around this in one of two easy ways:

1. Set your DISPLAY environment variable to a GL- capable system.

2. Set an environment variable called __SGI_NO_REMOTE_GL before executing the program. This prevents you from rendering remotely should you try to do so. The DISPLAY environment variable is always interpreted as rendering to local host.

I've added a reminder to my .login file:

# SGI Irix 5 bug workaround # setenv __SGI_NO_REMOTE_GL 1

This isn't something to set all the time, because there are occasions when using remote GL windows *is* what you intend to do.

Best, -Mike

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa14472; 31 Jan 94 18:45 EST Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa28290; 31 Jan 94 18:34 EST Received: from admii.arl.army.mil by WALRUS.BRL.MIL id aa28281; 31 Jan 94 18:32 EST Date: Mon, 31 Jan 94 18:29:55 EST From: Phil Dykstra (ACISD/ACD) <phil@BRL.MIL> To: browder jr <browder@use1.eglin.af.mil> cc: cad@BRL.MIL Subject: Re: transformations Message-ID: <9401311829.aa16439@ADMII.ARL.ARMY.MIL>

In the cad distribution, see "doc/anim.txt" and "doc/matrix.txt" for a short discussion of BRL-CAD matricies and how to use them in animation.

Also, see the online paper on "Animation Techniques in BRL-CAD" via Mosaic at

http://www.arl.army.mil/reports/tr-313/index.html

- Phil

Received: from whim.brl.mil by WOLF.BRL.MIL id aa00935; 10 Feb 94 6:59 EST Date: Thu, 10 Feb 94 6:56:50 EST From: Jim Hunt <jehunt@BRL.MIL> To: cmoore@BRL.MIL cc: acst@BRL.MIL, jehunt@BRL.MIL Subject: [Carl Moore: edpix error messages] Message-ID: <9402100656.aa02191@WHIM.BRL.MIL>

This occurs when you run across the network--running edpix on another machine using your workstation as the window server. It wasn't designed to do this and couldn't under Irix 3.3. Now, Irix 4+ permits this using X, but it is far from a smooth interface. I recommend only running on your local workstation.

--jim

PS; thanks for the fixxes to the man page :)

----- Forwarded message # 1:

Received: from wolf16.brl.mil by WHIM.BRL.MIL id aa03549; 8 Feb 94 16:51 EST Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa22008; 8 Feb 94 13:34 EST Date: Tue, 8 Feb 94 13:33:47 EST From: Carl Moore <cmoore@BRL.MIL> To: acst@BRL.MIL Subject: edpix error messages Message-ID: <9402081333.aa13049@WUMPUS.BRL.MIL> Resent-Date: Tue, 8 Feb 94 16:48:27 EST Resent-From: Mike Muuss <mike@BRL.MIL> Resent-To: jehunt@BRL.MIL

For test purposes, I did an "edpix" run consisting only of "edpix -f filename.pix" and then immediately exiting. What would cause a slew of messages "dgl error (pup): too many callbacks" to appear? (I noticed those messages after leaving edpix.) Would you like to look at the file with that problem? It seems to behave normally otherwise. Let me know and I can supply a path to that file.

----- End of forwarded messages

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa29681; 16 Feb 94 23:01 EST Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa08515; 16 Feb 94 22:54 EST Received: from wolf16.brl.mil by WALRUS.ARL.ARMY.MIL id aa08380; 16 Feb 94 22:48 EST Date: Wed, 16 Feb 94 22:46:46 EST From: Mike Muuss <mike@brl.mil> To: CAD@brl.mil Subject: pixmatte fix for -w1 Message-ID: <9402162246.aa29433@WOLF.BRL.MIL>

Several people noted that the "pixmatte -w1" alternative that I added to Lee's EBM paper didn't work. Programmer's plus-or-minus one problem bites again. Here is the fix, in "diff -c" format, suitable for use with PATCH.

Best, -Mike

*** /usr/tmp/,RCSt1a29429 Wed Feb 16 22:44:01 1994 --- pixmatte.c Wed Feb 16 22:43:18 1994 *************** *** 171,178 **** break; case 'w': c = atoi(optarg); ! if( c > 1 && c < sizeof(pconst) ) width = c; break; default: /* '?' */ usage("unknown option\n", 1); --- 171,180 ---- break; case 'w': c = atoi(optarg); ! if( c >= 1 && c < sizeof(pconst) ) width = c; + else + usage("Illegal width specified\n", 1); break; default: /* '?' */ usage("unknown option\n", 1); *************** *** 349,355 **** exit(1); } } ! fprintf( stderr, "pixmatte: %d element comparisons true, %d false\n", ! true_cnt, false_cnt ); return(0); } --- 351,357 ---- exit(1); } } ! fprintf( stderr, "pixmatte: %d element comparisons true, %d false (width=%d)\n", ! true_cnt, false_cnt, width ); return(0); }

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa14268; 17 Feb 94 14:04 EST Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa24995; 17 Feb 94 13:15 EST Received: from wharf.brl.mil by WALRUS.ARL.ARMY.MIL id aa24821; 17 Feb 94 13:08 EST Date: Thu, 17 Feb 94 12:49:26 EST From: "Harry Reed Jr." (GSI|phd) <reed@brl.mil> To: batman@nvl.army.mil cc: cad@brl.mil Subject: Number of solids in the GSI T62A Tank Message-ID: <9402171249.aa25291@WHARF.BRL.MIL>

Dear John,

The target description in question contains 16,000 solids, regions, and groups. We can reduce this amount if we remove the slotted screws holding down the cupolas and reducing the number of solids per link well below 39.

Please note that the description is only an exterior description. Adding the interior will probably increase it by another 12,000. Thanks.

By the way, the target contains battle damage such as dents, third country effects (non-standard detail items), and test repair items such as surrogate storage boxes.

Thanks, Harry Reed Geometric Solutions, INC 1-800-598-BRLCad (2752)

Received: from walrus.brl.mil by WOLF.BRL.MIL id aa10611; 3 Mar 94 18:46 EST Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa16862; 3 Mar 94 18:06 EST Received: from waffle.brl.mil by WALRUS.ARL.ARMY.MIL id aa16844; 3 Mar 94 17:59 EST Date: Thu, 3 Mar 94 17:55:06 EST From: Paul Stay <stay@brl.mil> To: cad@brl.mil Subject: Images and Geometry Wanted Message-ID: <9403031755.aa02691@WAFFLE.BRL.MIL>

BRLCAD users-

We are looking for images and geometry showing dual-use technology with BRL-CAD. Dual Use Technology is technology that is of use to the Defense Department and to other organizations for non-defense applications. We are looking for BRL-CAD images and or geometry that show a non-defense application in any one of these areas:

Computer Aided Design (CAD) Computer Aided Manufacturing (CAM) Animation Visualization Image Processing Graphic Arts Architectural Design Education Medical Technology Other (please elaborate)

All of the images and or geometry will be properly credited, and will not be distributed or displayed the to the general public unless you state otherwise. We will use these to help defend our budget and to show how BRL-CAD is being used by a large and diverse community. We may also want to use them for a brochure announcing a future BRL-CAD users conference (Spring of 1995). If you have further questions, or would like to contribute, please send me e-mail (stay@arl.army.mil). I can take images and or geometry from the network, or you can send them to me via regular postal mail. Let me know and we can work out the details.

Thanks, Paul Stay

p.s. I am unable to compensate any organization or individuals for images and or geometry that are sent.

p.s.s. Don't send mail asking me about the future conference, since the only thing we currently know is that it will be sometime in the spring of 1995.

Received: from walrus.brl.mil by WOLF.ARL.MIL id aa08338; 14 Mar 94 5:41 EST Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa20418; 14 Mar 94 5:36 EST Received: from wharf.brl.mil by WALRUS.ARL.ARMY.MIL id aa20346; 14 Mar 94 5:25 EST Received: from godot.lysator.liu.se by WHARF.BRL.MIL id aa29613; 14 Mar 94 5:06 EST Received: from maxwell (gorry@maxwell.lysator.liu.se [130.236.254.170]) by godot.lysator.liu.se (8.6.6.Beta2/8.6.6.Beta2) with SMTP id LAA02977 for <cad@brl.mil>; Mon, 14 Mar 1994 11:05:39 +0100 Received: by maxwell (4.12/1.34/Lysator-3.1) id AA13778; Mon, 14 Mar 94 11:04:38 -0100 (unknown) Date: Mon, 14 Mar 94 11:04:38 -0100 From: G|ran Rydqvist <gorry@lysator.liu.se> Message-Id: <9403141004.AA13778@maxwell> To: cad@brl.mil Subject: Missing makekey on non-US Sun Solaris

Previously I asked for assistance to unpack the BRL distribution using Solaris 2.3, as makekey is missing. I have checked things with Sun Sweden. Makekey is only included in the Solaris Encryption kit which is not exported from the USA. I solved the problem as follows: Insert SunOS 4.1.1 CD ln -s /cdrom/cdrom0/s0/export/exec/sun4_sunos_4_1_1/usr ~/brl-dir cd ~/brl-dir tar xvf usr ./lib/makekey Further enigma.c need to be modified to use a local makekey by changing one of the paths to ./makekey. if (fork()==0) { close(0); close(1); dup(pf[0]); dup(pf[1]); execl("./makekey", "-", 0); execl("/usr/lib/exec/makekey", "-", 0); /* BSDI */ Thanks for all the help I received. - Goran Rydqvist CadCal Design

Received: from walrus.brl.mil by WOLF.ARL.MIL id aa20570; 5 May 94 12:38 EDT Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id ab16296; 5 May 94 11:58 EDT Received: from wolf.arl.mil by WALRUS.ARL.ARMY.MIL id aa16196; 5 May 94 11:54 EDT Date: Thu, 5 May 94 11:54:22 EDT From: "John R. Anderson" <jra@ARL.ARMY.MIL> To: Yoav Oreg <phr22yo@phys4.technion.ac.il> cc: cad@brl.mil Subject: Autocad to BRLCAD Conversion Message-ID: <9405051154.aa20174@WOLF.ARL.MIL>

Yoav Oreg writes:

> what I tried to do is to build a simple object in auto-cad out of > primitive solids for instance a box and a cone, translate them to > IGES format (my autocad supports IGES 4.0) and then by using the > iges-g module translate the IGES file to brl-cad format. > everything seemed to be going fine until I applied iges-g. > The routine started working by counting the number of lines in the > objects but when it reached the part where it counts the number of > solids/regions it counted 0 (zero).

While IGES 4.0 supports solid models, what Autocad produced for you was an IGES "drawing" of the object you built, not a solid model. The key is that iges-g says it found no solids or regions in the IGES file. BRLCAD is a solid modeller, so it needs solid objects to operate on. The iges-g converter distributed with BRLCAD converts only IGES CSG (Constructive Solid Geometry) objects to BRLCAD format. Converting a drawing of a solid object (as Autocad provided) to a real solid model of that object is something people have been dreaming of for years, but so far it takes human intelligence in the loop. If Autocad would support the IGES CSG portion of IGES 4.0, then the conversion you attempted would work.

> can someone please give an answer to the problem :what kind (if > any) of objects made in autocad can be translated via IGES files to brlcad > and HOW CAN I DO IT?

As I mentioned above, if there is a version of Autcad that will produce IGES 4.0 CSG files, then you can convert them to BRLCAD. One other possibility is if Autocad can produce IGES 128 entities (NURBS), the iges-g converter will convert these entities to BRLCAD spline solids by combining all the 128's in the IGES file into a single spline solid. Note that this will not work for trimmed NURBS yet.

The next release of BRLCAD will include an improved iges-g converter that will also handle IGES BREP (Boundary Representation) solid models (restricted to planar-faced objects). There will also be a "dxf-g" to convert Autocad's DXF format to BRLCAD, however this will also be limited to 3D objects (3DFACES and 3DMESH objects) and 2D drawing entities will be ignored.

Hope this helps,

-John

John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058

Received: from walrus.brl.mil by WOLF.ARL.MIL id aa21089; 5 May 94 13:42 EDT Received: from walrus.arl.army.mil by WALRUS.ARL.ARMY.MIL id aa19332; 5 May 94 13:39 EDT Received: from wharf.arl.mil by WALRUS.ARL.ARMY.MIL id aa19206; 5 May 94 13:32 EDT Received: from uv2.eglin.af.mil by WHARF.BRL.MIL id aa25905; 5 May 94 13:17 EDT Date: 5 May 94 12:18:00 CST From: "Allen R." <REYNOLDS@uv2.eglin.af.mil> Subject: RE: Modeling Question To: cad <cad@brl.mil> Message-ID: <9405051317.aa25905@WHARF.BRL.MIL>

E G L I N A F B

From: MILFORD A. REYNOLDS Date: 05-May-1994 12:11pm CST REYNOLDS Tel No: 904 862 4188 Dept: 46TW/EALV*ASI

TO: (List Suppressed - Enter SH to read list. Use US SWC to remove suppression.)

Subject: RE: Modeling Question

Glenn, The only time we've had to deal with pointy-headed ogives we made do with an RCC at the end with a near-zero radius. In fact, a series of RCC's with appropriately decreasing radii might make a better approximation than an ellipsoid. Allen Reynolds ASI Sys Intn'l

Date: Sat, 14 May 94 22:08:52 EDT From: Mike Muuss <mike@arl> Subject: new command line parser To: mike Message-ID: <9405142208.aa27571@WOLF.ARL.MIL>

A New Command-Line Option Parser for BRL-CAD

ACST Team Meeting 18-Feb-1994

--- GOALS ---

*) Backwards compatability with current getopt() style command usage, so that e.g. "pix-fb -hizs32" is understood as a series of 1-char options.

*) Opportunity for more options than with present getopt(), e.g. long option names a.la. X-windows (including abbreviated forms), while also retaining 1-char options.

*) Each 1-char option should have the opportunity for a long option that does exactly the same thing.

*) Eliminate redundancy. One table should suffice for usage message, arg/no-arg flagging ("g:"), verbose help message. It would be nice to also eliminate the getopt() style switch() statement, perhaps by including pointers to the variable to be set and/or by having a hooked function pointer in the table.

*) It would be nice to (a) check for proper number of positional arguments, and (b) perhaps parse them into variables as well.

*) It would be nice to have "supplemental text" to supplement the usage message with, tucked into the same table. (Perhaps as part of the NULL entry at the end?)

*) It would be nice to have a routine that could print out (or perhaps return a string with) a command-line which completely represented the state of the program's options, including showing the values for all options that were defaulted.

--- ISSUES ---

*) How to mix long and short forms? One proposal is to have all long forms start with a double-minus, e.g.:

pix-fb --width 32 -s128 --inverse foo.pix

This is not incompatible with the getopt() usage of "--" to mark end of option list, but it is a nuisance to type two minus signs.

*) How to determine the minimum acceptable abbreviation for long option names. The X strategy of taking the shortest unique substring is convenient for the programmer, but means that adding new options may break old shell scripts, e.g. -geometry abbreviated as -geo in a script would no longer work when a -geodesic flag was added. The VMS style alternative would require the programmer to designate the minimum acceptable substring, which seems preferable. For example, either "-geom*etry", or "-GEOMetry" could both be used.

*) Long argument names should be case insensitive. Shouldn't they?

Received: from walrus.brl.mil by wolf.arl.mil id aa06864; 31 May 94 15:14 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19580; 31 May 94 14:16 EDT Date: Tue, 31 May 94 13:54:39 EDT From: Bob Strausser (SURVICE ENG. | Jill ) <strssr@ARL.MIL> To: merlin <merlin@neuro.usc.edu> cc: cad@ARL.MIL Subject: iges-g malloc error Message-ID: <9405311354.aa18963@WALRUS.ARL.MIL>

AJ,

The following message should allow you to fix the malloc error in the iges-g converter. You still need "valid" geometry formats (IGES type 128, I think) for a valid imported spline.

Bob Strausser SURVIAC ASO

forwarded message: -----------------

Date: Mon, 7 Jun 93 13:39:21 EDT From: "John R. Anderson" <jra@brl> To: Shung-Wu Lee <u10480@u2.ncsa.uiuc.edu> cc: cad@BRL Subject: [John R. Anderson: BUG in iges-g]

There is a small bug is the "iges-g" code that causes it to die on an rt_malloc error in "rt_nurb_new_snurb".Here is a context diff for the fix:

*** spline.c.old Mon Dec 21 15:46:51 1992 --- spline.c Mon Dec 21 15:50:07 1992 *************** *** 89,95 **** b_patch = rt_nurb_new_snurb( m1+1, m2+1, n1+2*m1+1, n2+2*m2+1, ! k2+1, k1+1, 4); /* U knot vector */ for (i = 0; i <= n1+2*m1; i++) { --- 89,95 ---- b_patch = rt_nurb_new_snurb( m1+1, m2+1, n1+2*m1+1, n2+2*m2+1, ! k2+1, k1+1, MAKE_PT_TYPE( 4 , 2 , 0 ) ); /* U knot vector */ for (i = 0; i <= n1+2*m1; i++) {

************************************ John R. Anderson Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: jra@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-6674

--------------------- end forwarded message

Received: from walrus.arl.mil by wolf.arl.mil id aa16836; 20 Jun 94 14:59 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13701; 20 Jun 94 13:34 EDT Received: from worm.arl.mil by WALRUS.ARL.MIL id aa13471; 20 Jun 94 13:26 EDT Date: Mon, 20 Jun 94 13:24:39 EDT From: "Gary S. Moss" (BVLD/VMB) <moss@ARL.MIL> To: browder jr <browder@use1.eglin.af.mil> cc: cad@ARL.MIL Subject: Re: BRL-CAD and IRIX 5.2 Message-ID: <9406201324.aa27660@worm.arl.mil>

> My problem now is: What and or where are <bsd/sys/types.h> and > <bsd/sys/time.h>? (Required in fbed/empty.c)

The use of <bsd/sys/whatever> in fbed/empty.c was to get to the BSD- flavored stuff under older IRIX releases (probably IRIX 3.x). Under IRIX 4.x the BSD stuff was apparently integrated into /usr/include, so you just want to use <sys/types.h> and <sys/time.h>, but the /usr/include/bsd directory was still there for backward compatibility. This compatibility was apparently removed in IRIX 5, so no /usr/ include/bsd anymore.

In your case, I would just change the CPP directives at the top of empty.c to always include <sys/types.h> and <sys/time.h>. I'm not sure what the politically-correct solution is for the official BRL-CAD copy. For instance, making rash statements like, if someone is still running IRIX 3 or earlier, they probably [...various things could go in here...], may not be acceptible policy. ;^)

-Gary

Received: from walrus.arl.mil by wolf.arl.mil id aa16857; 20 Jun 94 14:59 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa14923; 20 Jun 94 14:05 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14841; 20 Jun 94 14:02 EDT Date: Mon, 20 Jun 94 13:58:16 EDT From: "John R. Anderson" <jra@ARL.MIL> To: Yoav Oreg <phr22yo@phys4.technion.ac.il> cc: cad@ARL.MIL Subject: Re: conversion to BRL-CAD Message-ID: <9406201358.aa15527@wolf.arl.mil>

Yoav Oreg <phr22yo@phys4> writes:

> This is a follow up question to my last letter concerning conversion from > AUTOCAD to BRLCAD. I have been talking to some CAD people and for > some reason they keep on telling me that even if you have a CAD package > that works with solids, when you convert a solid to IGES format, the solid > is broken into wire frame which doesn't keep the solid properties. I am quite > confused now, since I was told last time that IGES does support solid entities? > could someone enlighten me?

The IGES specification includes support for both CSG and BREP solid models. It is up to the CAD vendor to decide how much of the IGES spec they are willing to support. Users of solid modelling CAD systems should let their vendors know that they expect to be able to exchange solid models via IGES without rebuilding the model from wireframe or just a collection of surfaces in space.

> also if ,as I understand importation of solids via IGES is possible,does > any one Know if it is possible to do it from UCLID,UNIGRAPHICS or CATIA? > and if it's possible than how?

The current BRL-CAD distribution include an "iges-g" that will import IGES CSG solids into the BRL-CAD format. This means IGES files that contain entities such as cones, cylinders, blocks, wedges, etc, along with the CSG specific entities such as Boolean trees, solid assemblies, and solid instances.

The next release of BRL-CAD will include an improved "iges-g" that will also handle IGES BREP files of a limited variety. These files must contain IGES FACE, EDGE, LOOP, and VERTEX entities (the first release of this converter will be limited to planar faces).

> Iam asking this in order to save me a few months work of rebuilding a vehicle > built in UCLID.

The next release of BRL-CAD will also include a EUCLID-G converter that converts what EUCLID calls a "decoded" file into the BRL-CAD format. This decoded file contains an ASCII representation of a facetted approximation of the solid model.

Neither of these converters are available until the next release. Both will be producing a variety of NMG objects that are not supported in the current release.

Hope this helps, -John

John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058

Received: from walrus.arl.mil by wolf.arl.mil id aa19158; 20 Jun 94 17:39 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa20328; 20 Jun 94 16:28 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa20177; 20 Jun 94 16:21 EDT Date: Mon, 20 Jun 94 16:17:36 EDT From: "John R. Anderson" <jra@ARL.MIL> To: "John C. Stauffer" <13746sta@kcu303.bv.com> cc: cad@ARL.MIL Subject: Re: B-Rep's from BRL-CAD Message-ID: <9406201617.aa18195@wolf.arl.mil>

John C. Stauffer <13746sta@kcu303.bv.com> writes:

> Have there been any proposals to allow for the creation of BRL-CAD model BReps? > I realize that there would probably be a lot of work involved (and I'm > expecting a negative reply), but I was curious if any thought had been given to > B-Reps at all. Is there anyone else out there that would like to see this?

As Gomer would say "Surprise, Surprise, Surprise!!!". The BRL-CAD development team is hard at work on NMG's. This new type of BRL-CAD solid will allow BRL-CAD users to create BREP objects. Initially, we will be limited to planar-face objects, but plans are already being made for extending that to Trimmed-NURB faces. The next release is expected to include planar-face NMG's.

-John

Received: from walrus.arl.mil by wolf.arl.mil id aa13886; 21 Jul 94 17:32 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24899; 21 Jul 94 16:36 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24733; 21 Jul 94 16:25 EDT Date: Thu, 21 Jul 94 20:21:25 GMT From: Mike Muuss <mike@ARL.MIL> To: Mary Foster <foster@gdls.com> cc: cad@ARL.MIL Subject: Re: Changing color of MGED display window on SGI Message-ID: <9407211621.aa08722@wolf.arl.mil>

> When we go into the MGED editor, our default window display is black. > This makes it difficult to see our menu bar and the model in our display > window. Is there a way to change the color of the display window ?

There is currently no way to change the background in MGED to anything other than black. However, it should be easy to see the border of the window and MGED menus, which are drawn in yellow. The default drawing color for an object is full-brightness red, which should be easy to see.

Something else may be going wrong.

> BRLCAD is installed on our Silicon Graphics workstation.

What kind of SGI, running what version of the operating system? What release of BRL-CAD are you running? 4.2? (MGED prints this as it's first message).

If problems persist, please include the output of the SGI 'hinv' command, so that we can see what kind of CPU and graphics hardware you have.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa18765; 21 Jul 94 22:54 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa27276; 21 Jul 94 22:00 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa27270; 21 Jul 94 21:52 EDT Date: Fri, 22 Jul 94 1:50:47 GMT From: Mike Muuss <mike@ARL.MIL> To: Joel Lazewatsky <lazewajl@lldmpc.dnet.dupont.com> cc: cad@ARL.MIL Subject: Re: Ray-trace intensity Message-ID: <9407212150.aa18012@wolf.arl.mil>

> We are creating models of gamma camera collimators in MGED:

Sounds pretty cool!

> This seems to work well for point sources, but when we tried to go to > more complicated light sources, we discovered that the intensity of the > shadow cast by the collimator dropped dramatically as the source size > increased.

This is a general problem with modeling area light sources when ray-tracing. The general strategy that I implemented in RT is to represent the light region as a cube (described simply by the radius of the inscribed sphere). When firing light visibility rays, the aim point is perturbed off the centroid of the light region by drawing three random numbers and perturbing the X Y and Z components of the aim point separately. This is sometimes called "dithering the light visibility ray aim points".

Sampling area lights with only one ray per pixel tends to produce very poor (noisy) results in the penumbra areas. And, you guessed it....

> Is there a way to increase the number of rays used by rt?

Yes. Use the -H# command line option, to "hypersample". The positive integer argument ("#") indicates how many _additional_ rays to fire for each pixel. Note that this automaticly causes "-J1" to be set, to cause the start point of the rays to be dithered (which is an entirely different matter from dithering the light aim points).

-H causes a simple average of the collected samples to be stored for each pixel. This is not the best strategy, but is useful when output file size is an issue. (More below).

How many extra rays will be needed depends on how much noise you are willing to tolerate, and how large your light source is. The larger the light source, the more rays you will probably need to get a "good" penumbra.

Typical values for -H range from -H3 to -H15. Note that this also results in a linear increase in runtime. If the runtime for -H0 is X, then the runtime for -Hnnn is (nnn+1)*X.

A more satisfying solution is to increase the resolution of the pixel grid appropriately, and then set -H0 and -J1. This stores one ray per pixel, but with full dithering enabled. After the image has been written, low pass filter the result and decimate. One cheap, dirty, and fast program for doing this is PIXHALVE, which uses a simple 5x5 filter pyramid, and reduces image size by half in both dimensions.

More sophisticated filter techniques can also be implemented.

If disk space for the (perhaps 4x or 16x larger) initial .pix file is not a problem, this strategy gives much better results than the comparable -H3 or -H15 approach, at identical runtime. (Not counting the one or two passes of PIXHALVE, which doesn't add much).

Why not experiment with -H and/or the filter & decimate strategies, and see if that meets your needs.

I'd love to see an image of one of your collimators sometime. Sounds like a fascinating application!

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa07893; 26 Jul 94 11:22 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa00155; 26 Jul 94 9:49 EDT Received: from smokey.arl.mil by WALRUS.ARL.MIL id aa00047; 26 Jul 94 9:40 EDT Date: Tue, 26 Jul 94 9:33:25 EDT From: Bob Parker <bparker@ARL.MIL> To: gda@msic.dia.mil cc: cad@ARL.MIL Subject: Re: coordinate information in xmged Message-ID: <9407260933.aa10388@SMOKEY.ARL.MIL>

Glenn,

Located in the menu bar is the FILE menu which contains an item called "Show Info". Selecting this will bring up an information window that will display everything about the current solid/object.

I hope this helps.

-Bob

Received: from walrus.arl.mil by wolf.arl.mil id aa09963; 2 Aug 94 17:50 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa08939; 2 Aug 94 16:46 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa08899; 2 Aug 94 16:41 EDT Date: Tue, 2 Aug 94 16:34:32 EDT From: "John R. Anderson" <jra@ARL.MIL> To: Harry Campbell <harry@delphi.dseg.ti.com> cc: jra@ARL.MIL, cad@ARL.MIL Subject: Re: Pro/Engineer Conversion Message-ID: <9408021634.aa08293@wolf.arl.mil>

Harry Campell writes: > Here at TI we do a lot of modelling with Pro/Engineer. I would be very > interested in hearing how you convert those models into BRL-CAD, and the > code that allows you to do that. > > Thanks.

There are actually two codes invloved in conversion from Pro/Engineer to BRL-CAD. The first is a Pro/Develop code. This code uses the Pro/Develop library that you only get with the Pro/Develop option of Pro/E. The resulting executable, however, may be used by other Pro/E sites without a Pro/Develop license. This code installs an additional menu item (labelled "BRL-CAD") under Pro/E's "export" menu. Selecting this menu option activates the code. It then traverses the current object in the Pro/E session and writes assembly information (member names and transformation matrices) to an ascii file. Assemblies and sub-assemblies are handled this way. Parts (the actual solids in a Pro/E model) are output to the same ascii file in render format using the same routine that Pro/E uses to output objects in render format (render format is a variety of triangulated facets). One might ask, "Why not just use Pro/E's render export option?". This was my first idea also, but as it is implimented in Pro/E, the entire model is exported as a single solid made up of lots of triangular facets. I wanted to get the individual parts as seperate objects and the assemblies as groupings of these objects.

The second code converts this ascii file to the BRL-CAD format. It reads the assembly information and creates BRL-CAD groups. The parts (solids) are converted to BRL-CAD NMG or polysolid objects according to a command line option. A region is constructed for each part and any color assigned to the part in Pro/E is assigned to the region.

Note that the resulting BRL-CAD objects are facetted approximations of the actual Pro/E model. The quality of the approximation can be controlled on a scale from 1 to 10, where a quality of 1 may approximate a cylinder as a rectangular parallelepiped and a quality of 10 might break the cylinder surface into 20 rectangular facets. It's not that simple as the Pro/E routine actually uses a combination of chord height (distance from actual surface to facet approximation) and an angle control that provides additional improvement along curves with small radii.

Other properties that are used in a BRL-CAD region or group (such as ident number, los, material code, etc) could be set as user parameters in Pro/E and detected and assigned to the BRL-CAD group or region. This has not yet been implimented, and would require a list of user parameter names to be agreed upon.

Hope this answers your question.

-John

John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058

Received: from walrus.arl.mil by wolf.arl.mil id aa16351; 4 Aug 94 13:19 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa01153; 4 Aug 94 12:13 EDT Received: from vgr.arl.mil by WALRUS.ARL.MIL id aa01032; 4 Aug 94 12:02 EDT Received: from odo.amherst.com by VGR.ARL.MIL id aa06533; 4 Aug 94 15:56 GMT Received: by amherst.com (5.0/SMI-SVR4) id AA24910; Thu, 4 Aug 94 11:54:12 EDT Date: Thu, 4 Aug 1994 11:51:25 -0400 (EDT) From: John P Doughtie <jpd@amherst.com> Subject: Re: Problem with BRL-CAD 4.2 Install To: cad@ARL.MIL, john dome <batman@nvl.army.mil> Cc: John P Doughtie <jpd@amherst.com> In-Reply-To: <m0qW4Wg-0004vtC@nvl.client> Message-Id: <Pine.3.07.9408041123.H24236-8100000@odo> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII content-length: 246

On Thu, 4 Aug 1994, john dome wrote:

> try setting your MANDIR to /xxx/brlcad/man/man and give it a go! > works for us. hope you find the package useful.

Thanks. That worked just fine. Sorry about the duplicate post on this subject.

John

Date: Tue, 9 Aug 94 15:58:34 GMT From: Paul Tanenbaum <pjt@arl.mil> To: mike@arl.mil, butler@arl.mil, jra@arl.mil, stay@arl.mil, gdurf@arl.mil cc: pjt@arl.mil Subject: MGED(1) source command Message-ID: <9408091158.aa27624@wolf.arl.mil>

I just implemented one using mged_source_file().

Usage: source file/pipe (read and process file/pipe of commands)

Like MSG(1), it decides whether to use POPEN(2) or FOPEN(2) by checking whether arg[1][0] is '|'. Is there anybody else I should inform about it?

Paul

Received: from walrus.arl.mil by wolf.arl.mil id aa24426; 7 Aug 94 17:08 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa05497; 7 Aug 94 15:51 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa05484; 7 Aug 94 15:44 EDT Date: Sun, 7 Aug 94 15:36:35 EDT From: "John R. Anderson" <jra@ARL.MIL> To: Harry Campbell <harry@delphi.dseg.ti.com> cc: cad@ARL.MIL Subject: Re: Pro/Engineer Conversion Message-ID: <9408071536.aa24062@wolf.arl.mil>

Harry Campbell writes:

> You sent me some information about software that will convert > Pro/Engineer databases into BRLCAD databases. Let me make sure that I > understood you correctly. > > I need to have the Pro/Develop library. This I assume is a purchased > add-on to the Pro/Engineer package.

No, You do not need any additional Pro/Engineer modules. You will obtain the executable from us (ARL), and you will create a small ascii file called "prodev.dat" that informs Pro/Engineer about the BRL-CAD Application. The Pro/Develop library is only required if you are going to write your own Pro/Develop applications.

> I need to have this second piece of > software that converts the ascii output from Pro/Engineer into a BRLCAD > database. I will guess that this second file is going to be freely > available with the BRLCAD software distribution?

Yes, that is correct.

Hope this clears things up! -John

John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058

Received: from walrus.arl.mil by wolf.arl.mil id aa28962; 21 Aug 94 21:09 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa09517; 21 Aug 94 20:25 EDT Received: from vgr.arl.mil by WALRUS.ARL.MIL id aa09515; 21 Aug 94 20:21 EDT Received: from rumors.delta.edu by VGR.ARL.MIL id aa00369; 22 Aug 94 0:06 GMT Received: by rumors.delta.edu (AIX 3.2/UCB 5.64/4.03) id AA07738; Sun, 21 Aug 1994 19:58:03 -0400 Date: Sun, 21 Aug 1994 19:58:03 -0400 From: laut@rumors.delta.edu Message-Id: <9408212358.AA07738@rumors.delta.edu> To: cad@brl.mil Subject: Re:Suggestion for LIBRT

>> The thing which inspired this: I was playing around today with sh_marble.c, >> trying to create a link in a chain out of a couple of tori and cylinders, >> and noticed that a change in region caused the turbulence to change. > >As an alternative, perhaps the origin of the texture could optionally be >anchored to a point in space. Either specified numerically, or >symbolically, something like a/b/crod.r/foo.cyl[TIP]. > >That would seem like a more direct method of achieving the control sought. > >> My proposed suggestion: For the next release of BRL-CAD, could you please >> add a field to "struct region" in raytrace.h which points to the directory >> entry from which the region was created, [...] > >It's encoded in the reg_name, in an inconvient format. Perhaps instead >of storing the name, the db_full_path info should be kept instead. Takes >about the same amount of space either way. An rt_vls_??? routine to >format the db_full_path info into a VLS string would be the only thing >needed to make the interface clean. > > Thoughts? >

After posting my suggestion, I developed a workaround that basically does the same thing. In the case of sh_marble, it involves adding an "identification" integer to marble_specific, in order to group marble regions by some arbitrary, MATPARM-specified value. IE,

struct marble_specific { struct marble_specific *forw; int ident; ... };

static struct marble_specific *Marble_Chain;

and

struct structparse marble_parse[] ={ {"%d", 1, "id", MARB_O(ident), BU_STRUCTPARSE_FUNC_NULL }, ... };

When the regions are being set up, the Ident field is inspected to see if a non-zero value was returned by rt_structparse(). If so, it is added to a singly-linked list headed by "Marble_Chain". The list is then scanned to find all regions which match the Ident, and VMIN/VMAX is called against all of them to find a bounding RPP which encloses all regions of note. Once the scan is completed, the results of VMIN/VMAX are then propogated to all matching regions. This can obviously be improved, but it presently gets the job done.

An example of this has been uploaded to wolf:/incoming/link.pix.Z. "Link" is a 512x512 raytraced image of a link out of a chain, using the modified marble shader to produce the body color and an experimental dielectric shader to do shadowing (although the specular reflection did get overexposed in order to better contrast the turbulence). With the exception of the upper right joint, the results are nice and smooth.

From a modelling perspective, this approach wins hands down over changing LIBRT, because it allows the modeller to explicitly tell the shader which *combinations*, taken together, are "cut from the same stone."

Finally, I can see where this approach would be useful in rendering sculpted CSG glass by allowing you to explicitly declare which regions are of the same composite material, so that refract.c doesn't have to guess which regions are continuations of one another. An example of what I am referring to are the "Hurricane Lamps" on page 24 of the April 1994 issue of Computer Graphics World, and the seams which show up at the top of the lamps where the tori joins the body but not elsewhere.

-Bill

Date: Mon, 22 Aug 94 20:26:31 GMT From: Mike Muuss <mike@arl.mil> To: acst@arl.mil, AYoung@arl.mil, Jill@arl.mil, PHD@arl.mil, PJT@arl.mil, Davisson@arl.mil, WM@arl.mil, GDurf@arl.mil, Moss@arl.mil cc: wbowman@arl.mil, gillis@arl.mil, reed@arl.mil, CJohnson@camelot.com Subject: RT timing on IRIX 5 Message-ID: <9408221626.aa21854@wolf.arl.mil>

I fixed a bug in rt_get_timer()/rt_read_timer() that was resulting in improper performance measurements of runtime on SGI systems.

I upgraded rt/do.c to use rt_get_timer() in place of rt_read_timer() so that I could get wallclock as well as CPU time. And then upgraded the RT statistics output to display the statistics in *all* the different ways that are commonly interesting:

Frame 0: 65536 pixels in 3.04 sec = 21551.98 pixels/sec Frame 0: 76479 rays in 3.04 sec = 25150.67 rays/sec (RTFM) Frame 0: 76479 rays in 12.16 sec = 6287.67 rays/CPU_sec Frame 0: 76479 rays in 3.17 sec = 24157.05 rays/sec (wallclock)

The first two are conventional (and now are correct!), while the second two are new.

The "rays/sec" figure is a measure of the performance of the SYSTEM (presumably "all" CPUs running), while the "rays/CPU_sec" figure is a measure of the efficiency of the system. "rays/sec (wallclock)", on an unloaded system, is an indicator of actual results, and takes into account I/O speeds, paging, OS overhead, etc.

One of the most important bugs pending for this release has now been fixed! Onward to the rest of them.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa16088; 16 Aug 94 14:51 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa29107; 16 Aug 94 13:48 EDT Date: Tue, 16 Aug 94 13:42:02 EDT From: Bob Strausser (SURVICE ENG. | Jill ) <strssr@ARL.MIL> To: Robert Coderre <rcoderre@cals1.belvoir.army.mil> cc: cad@ARL.MIL Subject: BRL-CAD on IRIX 5.2 Message-ID: <9408161342.aa28929@WALRUS.ARL.MIL>

Robert,

You are running into problems with changes in the IRIX operating system. The errata are for the IRIX 4.0.5 operating system but you are using IRIX 5.2.

The Cakefile.defs need to be edited for the current BRL-CAD release to compile on IRIX 5.2. The following comments were extracted / edited from email traffic concerning the install:

If you set the SGI_CC environment to -cckr This should fix your problems.

setenv SGI_CC -cckr

Also take a look at the Cakefile.defs and see the new CFLAGS definitions (Irix 5.2 uses the R4000; in the Cakefile.defs the following under machinetype 5d is found)

/* For R4000 machines you might want to include -KPIC -kpicopt -mips2 on the next line */ /* instead of -G 15 */ # define GFLAG -KPIC -kpicot -mips2 /*# define GFLAG -G 15 */ /* ANSI+POSIX mode is used over ANSI, to get fdopen(), etc, defined. */ /*# define CC_OPTS GFLAG -ansiposix -DXLIB_ILLEGAL_ACCESS=1 */ # define CC_OPTS -cckr GFLAG -DXLIB_ILLEGAL_ACCESS=1

Bob Strausser SURVIAC ASO

Received: from walrus.arl.mil by wolf.arl.mil id aa25349; 8 Sep 94 9:40 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa06998; 8 Sep 94 9:39 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa06814; 8 Sep 94 9:28 EDT Date: Thu, 8 Sep 94 9:26:21 EDT From: "John R. Anderson" <jra@ARL.MIL> To: laut@rumors.delta.edu cc: cad@brl.mil Subject: Re: CATIA translator Message-ID: <9409080926.aa25172@wolf.arl.mil>

B. Laut asks:

> Is there a translator for converting CATIA to BRL-CAD and/or vice-versa?

Not directly, but the next release of BRL-CAD will include a Pro/Engineer to BRL-CAD converter, and Pro/Engineer can eat CATIA models.

-John

Date: Sat, 10 Sep 94 9:02:13 GMT From: Mike Muuss <mike@arl.mil> To: acst@arl.mil, AYoung@arl.mil, Jill@arl.mil, PHD@arl.mil, PJT@arl.mil, Davisson@arl.mil, WM@arl.mil, GDurf@arl.mil, Moss@arl.mil, BParker@arl.mil Subject: vertexuse attribute normals Message-ID: <9409100502.aa16715@wolf.arl.mil>

If there are vertexuse attribute normal vectors in an NMG, "ev -w -n" will now draw them as little hairs, just like the face normal vectors.

John's additions to the sphere tessellator to *calculate* the vertexuse attribute normals works very nicely, for the one case I tried. Good show, John!

Best, -Mike

Received: from wumpus.arl.mil by wolf.arl.mil id aa00442; 14 Sep 94 10:20 EDT Date: Wed, 14 Sep 94 10:15:05 EDT From: Carl Moore <cmoore@ARL.MIL> To: acst@ARL.MIL cc: cad@ARL.MIL Subject: mged -- long-name failure for idents command Message-ID: <9409141015.aa23148@WUMPUS.ARL.MIL>

It has come to my attention THROUGH A COLLEAGUE'S PROBLEM that using a long file name in mged's "idents" command is causing a strange failure (unexplained "sh" message and the idents file getting only the first half of its normal output). So I got a test case which I am including twice in this message (for the sake of readability, the second one has capital letter X replacing the word "supercalifragilisticexpialidocioius"). The colleague got the problem when he used a full directory path in the filename argument.

Here is the original display of my test case:

mged> idents supercalifragilisticexpialidocioussupercalifragilisticexpialidocious compartment Summary written in: supercalifragilisticexpialidocioussupercalifragilisticexpialidocious Processed 1614 Regions sh: isticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocious: not found mged>

Here is the display with X edited in place of the long word:

mged> idents XX compartment Summary written in: XX Processed 1614 Regions sh: isticexpialidociousXX: not found mged>

If the command is going to fail because of a long file name, please make sure it fails in a sensible way. Thanks.

Received: from walrus.arl.mil by wolf.arl.mil id aa08148; 14 Sep 94 14:42 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa12893; 14 Sep 94 13:18 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id ab12605; 14 Sep 94 13:08 EDT Date: Wed, 14 Sep 94 17:07:53 GMT From: Mike Muuss <mike@ARL.MIL> To: Carl Moore <cmoore@ARL.MIL> cc: cad@ARL.MIL Subject: Re: mged -- long-name failure for idents command Message-ID: <9409141307.aa05710@wolf.arl.mil>

Carl Moore wrote about -

> long file name in mged's "idents" command is causing a strange failure

I have tracked this down to some ancient string handling code in mged/utility1.c which was using small pre-allocated arrays to hold the file name. (Does the number 80 characters ring any bells for people?)

I replaced the code with new code using rt_vls (variable length string) calls, and it works fine now. I also had mged print out the Shell commands it was running, so you could see what it was up to.

The fix will be available in the Alpha release, Real Soon Now.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa23518; 20 Sep 94 3:04 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa25556; 20 Sep 94 2:18 EDT Received: from admii.arl.mil by WALRUS.ARL.MIL id aa25504; 20 Sep 94 2:14 EDT Date: Tue, 20 Sep 94 2:04:57 EDT From: Phil Dykstra <phil@ARL.MIL> To: Timothy G Smith - Special Projects <tgsmith@sun.com> cc: cad@ARL.MIL Subject: Re: if_X.c Message-ID: <9409200204.aa00484@ADMII.ARL.MIL>

| Are there any plans to fix/replace/significantly change libfb or | if_X.c in TNR?

Libfb and if_X.c have changed very little since the last release.

| I am halfway through implementing 24 bit support and would rather not | put much more effort into this if I am only going to have to redo | things for TNR.

We would be happy to get your code. It shouldn't be very hard to merge with our version.

| I only have True Color 24 bits framebuffers so I don't have to worry | about 24 bit color maps. How common are Direct Color framebuffers?

Libfb implements a Direct Color model (since back when real frame buffers were all 24-bit + colormaps and X didn't exist yet). So to do full libfb semantics on a True Color display you need to do software color mapping. The SGI X servers provide both True Color and Direct Color (though we don't use X for 24-bit color on the SGI's). I don't know how many other servers provide Direct Color.

- Phil

Received: from walrus.arl.mil by wolf.arl.mil id aa20900; 19 Sep 94 20:32 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa23722; 19 Sep 94 19:46 EDT Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa23664; 19 Sep 94 19:36 EDT Received: from Sun.COM by wharf.arl.mil id aa23673; 19 Sep 94 19:05 EDT Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA19401; Mon, 19 Sep 94 16:09:17 PDT Received: from spdev.East.Sun.COM (spdev-gw.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1) id AA06777; Mon, 19 Sep 94 19:08:47 EDT Received: from spot.East.Sun.COM by spdev.East.Sun.COM (5.0/6.1-spdev1) id AA05570; Mon, 19 Sep 1994 19:07:49 +0500 Received: by spot.East.Sun.COM (5.x/SMI-SVR4) id AA02141; Mon, 19 Sep 1994 19:08:44 -0400 From: Timothy G Smith - Special Projects <tgsmith@sun.com> Message-Id: <9409192308.AA02141@spot.East.Sun.COM> Subject: if_X.c To: cad@ARL.MIL Date: Mon, 19 Sep 1994 19:08:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 676

Are there any plans to fix/replace/significantly change libfb or if_X.c in TNR?

I am halfway through implementing 24 bit support and would rather not put much more effort into this if I am only going to have to redo things for TNR. I have things working well enough that I can now squirt 24 bit pix files to the screen which is all I need to get done for a demo on Wednesday.

I am currently going through all of the routines adding a switch to handle the 24, 8, and 1 bit code paths but don't know if I will finish it.

I only have True Color 24 bits framebuffers so I don't have to worry about 24 bit color maps. How common are Direct Color framebuffers?

thanks, --tim

Received: from walrus.arl.mil by wolf.arl.mil id aa25477; 21 Sep 94 19:35 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15001; 21 Sep 94 19:34 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14974; 21 Sep 94 19:29 EDT Date: Wed, 21 Sep 94 23:26:59 GMT From: Mike Muuss <mike@ARL.MIL> To: Pierluigi Barabino <scazzola@relay.marconi.it> cc: cad@ARL.MIL Subject: Re: BRL-CAD on IRIX 5.2 Message-ID: <9409211926.aa25396@wolf.arl.mil>

> I run now in some problems running mged and xmged: > - mged attached to sgi displays a black window, program output flashes on > refresh so I think it could be a color map problem (?)

Inside cad/mged/dm-4d.c, you might need to add a few more "case" statements, so that the code looks something like this:

case INV_VGX: case INV_VGXT: /* VGX Turbo and SkyWriter */ case INV_GMDEV: /* GT graphics */ case INV_CG2: ir_is_gt = 1; ir_has_zbuf = 1; ir_has_rgb = 1; ir_has_doublebuffer = 1; break;

> - mged attached to X seems to work, on moss.g "ev all.g" works but the command > "facetize new.g all.g" causes a segmentation fault.

This is a known bug. BRL-CAD Release 4.0 and 4.2 will die like that on all platforms.

This is fixed in the development version of the software. We are in the final throes of getting the 4.4 Alpha release ready. 4 weeks after Alpha (internal tests) we will have a Beta release (for interested sites), and 4 weeks after that we will have a formal BRL-CAD 4.4 release.

> - xmged (on X) on the same command gives the messages: > "mged_nmg_doit: bad op 0" (repeated 6 times) > "facetize: no resulting region, aborting" > while "ev all.g" gives the same 6 bad op msgs and then core dumps writing > "db_free_tree: bad op". > > - xmged attached to sgi doesn't show the colormap problem but the NMG related > problems remains.

The fact that XMGED gives different error messages is disturbing. I would have expected it to fail in exactly the same way as MGED. :-) I'll check into this.

> BTW what's the difference between the 4.0 and 4.2 releases?

BRL-CAD 4.2 contains a small handful of patches, to keep up with SGI's continuously evolving and (only slightly) incompatible versions of IRIX.

Best, -Mike Muuss

Received: from walrus.arl.mil by wolf.arl.mil id aa28828; 30 Sep 94 20:14 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa18869; 30 Sep 94 20:12 EDT Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa18708; 30 Sep 94 20:02 EDT Received: from ghost.camelot.com by wharf.arl.mil id aa04465; 30 Sep 94 19:32 EDT Received: by camelot.com (931110.SGI/-A/UX-AMR-1.0) id AA20077; Fri, 30 Sep 94 19:32:18 -0400 From: "Christopher T. Johnson" <cjohnson@camelot.com> Message-Id: <9409302332.AA20077@camelot.com> Subject: Re: Closed Bug#75: librt prep of database with > 100,000 solids is very slow (fwd) To: cad@ARL.MIL Date: Fri, 30 Sep 1994 19:32:16 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4471

This was first sent to the bugs list for the alpha test. I'm forwarding it to the main list because I'm more than a little impressed with what Mike has done to improve the speed of processing large models and also because there might be some people intrested in the discussion of swapping, paging and large models. Chris

Mike wrote: > The real problem here is that the subroutine rt_find_identical_solid() > has an O((nsolid/128)**2) search, in order to check to see if a new > solid about to be prepped is really an instance of an existing solid at > the same location and orientation. The reason for it being (nsolid/128) > and not (nsolid) is because there are 128 different solid hashes, > and rti_solidheads[128] heads 128 different linked lists of struct > soltabs. This reduces the search time by a constant factor, but does > not change the basic n**2 order of the search.

Very good point, I noticed the improvement when this code was installed. About an 8 or 10 times speed up in this stage of the prep code. Call it 12+ cpu minutes to 1.25 minutes. Now to track down the next slow part.

> This issue had come up once before, in terms of prep time for large > models. I had addressed this issue by speeding up the matrix > comparisons, and by permitting the rt_find_identical_solid() search to > spread across up to three processors. That provided perfectly > acceptable performance for models of O(5000) solids on ARL's multi-CPU > SGI machines.

Also, most of Mike's machines have a little more memory than mine. So the O(n**2) problem, while being very real, did not show the devistating VM crawl that shows up on a small memory machine.

> Chris is running on a single-CPU machine, has O(110,000) solids, and > lots of instancing, so this issue has returned. What is called for is a > less expensive algorithm. The current code searches the list of already > prepped solids to find other instances of the current solid.

As of last night O(500,000) and moving up. Each tree is O(2000) solids with out leaves and O(4000) with leaves, each target of interest is O(8000) solids. We are moving towards a scene with O(120,000) trees, O(500) targets of interest, O(10000) detail items (Telephone poles, roads, fences, dogs, cats, bears, sheds, churches et so forth).

We hope to be generating this sort of image sometime in the next two weeks. Oh yea, this doesn't include the 192 square kilometers of terrain data. That is also included.

Some comments on generating large models:

The size of our models are fairly large, but generally of O(10000) solids. It is only when we start combining them in interesting ways that the total size of the data base become large.

All of the large scale database generation is driven by control files describing placement of targets within the environment. I.e. where each tree goes, where each target goes, where each detail item goes.

These control files also describe transformations that help hide the fact that there are a limited number of types. For example, we only have 5 types of trees right now, but those trees get twisted, squashed, expanded, tilted and moved explicitly for each placement.

Each target can be individuly configured after the fact with anim scripts.

MEMORY: Somebody said: Swapping is BAD. This is not true. PAGING is bad.

The time to trace my complex images in a small memory box is not much different than the time to trace the same images in a large memory box. The reason for this is one Mike Muuss. The actuall raytracing is very memory coheasive. There is NO noticable PAGING going on during the tracing of a 180MB scene (Total size of rt process) in a 64MB machine.

The PREP time, on the other hand is very nasty and is memory dependent. The doubly linked list that Mike just added reduced the paging enormously while building the tree. The next step in the process seems to be doing an O(n^2) process as well, but I have not instrumented the code enough to be able to determine where this is happening.

Many thanks and Ataboys to Mike and his team.

> > By the way, this work was pretty easy, thanks to the new "multiple > rt_list per structure" support I added to rtlist.h a few weeks ago. > Without that support, this new algorithm would have been a pain to > code. Power tools!

Yes, a very nice addition. Now we can have cross threaded doubly linked lists to confuse the best of them. *GRIN* But this is a needed addition, thanks again.

Chris

Received: from walrus.arl.mil by wolf.arl.mil id aa19613; 15 Nov 94 13:07 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa04473; 15 Nov 94 11:58 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa04330; 15 Nov 94 11:49 EST Date: Tue, 15 Nov 94 11:45:13 EST From: "John R. Anderson" <jra@ARL.MIL> To: joe edward meier <jem@bruker.com> cc: BRL-MIL <CAD@brl.mil> Subject: Re: Changing View with adc Message-ID: <9411151145.aa18422@wolf.arl.mil>

From joe edward meier <jem@bruker.com>:

> If I am editting a large object/solid and I have the Angle Distance > Cusor (adc) showing and placed at say one end of the object, how can > I then change the view so that I see mostly the other end of the object, > without the adc moving also? I have not been able to figure out how > to do that.

Not sure exactly what you mean by this, but the ADC will not move when the view is changed. If you want to keep the ADC over a particular point in your model, you can use "adc xyz x_coord y_coord z_coord". This will position the ADC in front of the specified coordinates. You will need to execute the same command every time the view changes. Do an "adc help" for more info.

> I also was wondering how one does object selection via the keyborad? > If you have alot of objects displayed, then it can be imbossible to select > the object you want via the "object illum" command? > "press oill" will put you in object illuminate mode. "ill object" will illuminate the specified object and allow you to select which matrix along the path should be modified. One problem with this approach is that if the object appears in more than one path, you will get the message "object multiply referenced" and the "ill" command will fail. You can use "paths object" to see what paths the object appears in.

Hope this helps, -John John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058

Received: from walrus.arl.mil by wolf.arl.mil id aa18861; 15 Nov 94 12:37 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa05275; 15 Nov 94 12:30 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa05126; 15 Nov 94 12:20 EST Date: Tue, 15 Nov 94 12:19:07 EST From: "John R. Anderson" <jra@ARL.MIL> To: "Bruce C. Patterson" <pattersb@uy1.eglin.af.mil> cc: cad@ARL.MIL Subject: [Mike Muuss: Re: [Marlon Harris: ACAD conversion codes]] Message-ID: <9411151219.aa18720@wolf.arl.mil>

from Bruce C. Patterson (pattersb@uy1.eglin.af.mil):

> The ultimate goal is to use the Irma 3.2 USAF developed software package to > create images for optical filter construction. Irma 3.2 currently uses the > Advanced Computer Aided Design (ACAD) faceted model discription. Most of the > target models we require have been designed using BRL-CAD or FASTGEN. What > we need is an avenue that allows us to move BRL-CAD and FASTGEN models into > ACAD for internal component removal and facetization. What is the simplest > way to accomplish this?

"patch-g" will convert FASTGEN to BRL-CAD, but we don't have any ACAD converters. See forwarded message below:

-John

----- Forwarded message # 1:

Date: Wed, 10 Aug 94 23:01:23 GMT From: Mike Muuss <mike@arl.mil> To: Marlon Harris <harris@batman.dynetics.com> cc: John R. Anderson <jra@arl> Subject: Re: [Marlon Harris: ACAD conversion codes] Message-ID: <9408102301.aa26227@wolf.arl.mil>

> I would also like to find out if anyone has developed a code that can > convert ACAD models to BRL-CAD component models. We have used ACAD to > convert a file to BRL-CAD format, however when it was loaded into > BRL-CAD it turned out to be one solid object instead of a component > model.

Tools to convert between BRL-CAD and ACAD in both directions are provided by the ACAD group at Lockheed (formerly General Dynamics), not as part of BRL-CAD. You should probably address your difficulties to J.P. Abalane (unsure of spelling) in the ACAD group. Sorry I can't provide more information.

Best, -Mike Muuss

Leader, Advanced Computer Systems Team Survivability and Lethality Assessment Directorate The US Army Research Laboratory APG, MD 21005-5068 USA

<Mike @ ARL.MIL>

410-278-6678 Voice 410-278-5058 FAX

----- End of forwarded messages

Received: from walrus.arl.mil by wolf.arl.mil id aa00206; 19 Nov 94 5:47 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24839; 19 Nov 94 5:02 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24816; 19 Nov 94 4:52 EST Date: Sat, 19 Nov 94 9:41:03 GMT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: No new registration needed for BRL-CAD 4.4 Message-ID: <9411190441.aa29487@wolf.arl.mil>

Several people have recently asked whether they will have to re-register with us or send in a new copy of the agreement form in order to obtain a copy of BRL-CAD Release 4.4.

The answer to this question for FTP ("free") users is ---> NO <---.

Release 4.4 is a maintenance release, and is covered by your existing agreement. The files for anonymous FTP will be encrypted using the same encryption key as Release 4.0 and 4.2 were.

For folks who purchased the mag-tape version from SURVIAC, I don't know whether there will be an additional tape-copying fee or not.

We anticipate undertaking a complete re-registration, with slightly updated and streamlined agreement forms, for BRL-CAD Release 5.0, which is scheduled for the end of FY95 (e.g. October 95, if not before).

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa29997; 19 Nov 94 5:25 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24784; 19 Nov 94 4:50 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24779; 19 Nov 94 4:41 EST Date: Sat, 19 Nov 94 9:35:42 GMT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: Beta test of BRL-CAD Release 4.4 now available Message-ID: <9411190435.aa29446@wolf.arl.mil>

I'm pleased to announce that the Beta-test version of BRL-CAD Release 4.4 (numbered 4.3 to distinguish it from the final Release) is now available.

All current BRL-CAD users are invited to FTP the Beta test materials from host FTP.ARL.MIL, directory brl-cad/Rel4.3/src, where you will find these files:

-r--r--r-- 1 mike graphics 7228576 Nov 19 04:13 cad4.3.tar-a.Z -r--r--r-- 1 mike graphics 2136727 Nov 19 04:15 cad4.3.tar-b.Z -r--r--r-- 1 mike graphics 1696243 Nov 19 04:15 cad4.3.tar-c.Z -r--r--r-- 1 mike graphics 2134725 Nov 19 04:16 cad4.3.tar-d.Z -r--r--r-- 1 mike graphics 1063147 Nov 19 04:16 cad4.3.tar-e.Z -r--r--r-- 1 mike graphics 745347 Nov 19 04:17 cad4.3.tar-f.Z -r--r--r-- 1 mike graphics 1892694 Nov 19 04:17 cad4.3.tar-g.Z

The encryption key for these files is the same as was used for Release 4.0 files.

There is a mailing list which is being used for discussion of bugs and issues uncovered in the Beta test period. This list is <cad-beta@arl.mil>, and you are welcome to subscribe to it even if you are not planning to Beta-test the software. Send E-mail to <cad-beta-request@arl.mil> to join the list.

The Beta release contains a shell script "cadbug.sh" which all Beta-testers are encouraged to use to report bugs in Release 4.3 with.

I apologize for the 3 week delay in getting the Beta release out. The arrival of our first SGI "TFP" system with R8000 cpus caused far more work in porting and bug hunting than had been anticipated. During the Alpha test period more than 175 bug reports were filed. Of those, only 21 remain open as we enter the Beta test period. I'm confident that this will be a very successful release, even in light of the substantial amount of new code since Release 4.2 (more than 200,000 lines!)

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa08658; 22 Nov 94 13:39 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa14957; 22 Nov 94 12:22 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14896; 22 Nov 94 12:17 EST Date: Tue, 22 Nov 94 12:10:30 EST From: "John R. Anderson" <jra@ARL.MIL> To: cad@ARL.MIL cc: muves-tech@ARL.MIL Subject: New Sketch Capability in BRL-CAD's MGED Message-ID: <9411221210.aa07525@wolf.arl.mil>

Using a method suggested by Mike Muuss, I have added a rudimentary sketch capability to MGED. This allows a user to build a sketch (limited to a single loop currently) in MGED, and then extrude that loop linearly in any direction (except parallel to the plane of the loop). The sketch is actually an n-Manifold Geometry (NMG) loop and when extruded, it becomes an NMG solid.

The user begins by creating a nearly empty NMG using the "make" command in MGED. The only geometry in an NMG created this way is a single "wire" loop, consisting of a single edge that runs to and from the same vertex.

After selecting this new NMG for editing (you may have to use the "sed" command, since the new NMG is very tiny - one vertex), the user selects the only edge by using the "pick edge" menu item and selecting with the mouse anywhere in the MGED window (the only edge will be selected).

Next, the user may select "split edge" and then use the mouse to indicate where the new vertex should be positioned. The first mouse selection, splits the selected edge and places the new vertex at the mouse location creating a loop of two edges (looks like a single line). The currently selected edge automatically shifts to the new edge, and the user may select another location. This selection splits the current edge and moves the new vertex to the selected location, creating a triangular loop. The user may continue to build the sketch by repeatedly selecting points with the mouse or using the "p" command.

There is also a "delete edge" menu item that will delete the currently selected edge, and a "move edge" menu item to allow moving an edge perpendicular to its length.

The sketch is mantained always as a loop, and when the user is satisfied with the sketch, the "extrude loop" menu item may be selected to produce an extruded solid. This works similar to other solid editing items as the user may use any number of mouse point selections or "p" commands to produce different extrusions until the desired effect is accomplished. Then the usual "ACCEPT" or "REJECT" menu item is selected.

The "split edge" and "delete edge" menu items are currently restricted to use on "wire" loops or "wire" edges. They will not work on solid NMG objects. "Move edge" will work on simple NMG solids as well as "wire" edges, and the "extrude loop" will only work on NMG's that contain a single "wire" loop.

Most of these capabilities are in the current BETA release, but the "extrude loop" wasn't completed until last night (Nov 21). It will appear in any new BETA releases and in the final 4.4 release.

-John

Received: from walrus.arl.mil by wolf.arl.mil id aa23161; 23 Nov 94 9:01 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa04134; 23 Nov 94 8:55 EST Date: Wed, 23 Nov 94 8:48:15 EST From: Bob Strausser (SURVICE ENG. | Jill ) <strssr@ARL.MIL> To: cad@ARL.MIL Subject: BRL-CAD (4.3 / 4.4) acquisition - SURVIAC users Message-ID: <9411230848.aa03981@WALRUS.ARL.MIL>

SURVIAC full support users have two choices for acquiring the version 4.4 release (beta and final). Either:

1. Download the source files from the ftp site in the encrypted form and contact the SURVIAC ASO for the decryption key

phone: (410) 273-7794 fax: (410) 272-6763

or

2. Forward a 1/4" cartridge tape or a 4mm DAT tape to the SURVIAC ASO to have the files written to the tape and mailed back. The mailing address is:

SURVIAC ASO 1003 Old Philadelphia Road Suite 103 Aberdeen, Maryland 21001-4026

Bob Strausser SURVIAC ASO

Received: from wolf.arl.mil by wolf.arl.mil id aa07148; 22 Nov 94 11:32 EST Date: Tue, 22 Nov 94 16:30:33 GMT From: "John R. Anderson" <jra@arl.mil> To: CAD-Beta@arl.mil Subject: Closed Bug#168: mged NMG editing Message-ID: <9411221130.aa06788@wolf.arl.mil>

Using a method suggested by Mike Muuss, I have added a rudimentary sketch capability to MGED. This has been accomplished by including NMG's to the "make" command, allowing the creation of a nearly empty NMG. The only geometry in an NMG created this way is a single "wire" loop, consisting of a single edge that runs to and from the same vertex. New menu items have been added to the NMG solid edit menu that allow splitting edges. The user may select "split edge" and then use the mouse to indicate where the new vertex should be positioned. The user may continue to build the sketch by repeatedly selecting points with the mouse or using the "p" command. There is also a "delete edge" menu item that will delete the currently selected edge, and a "move edge" menu item to allow moving an edge perpendicular to its length. Note that these menu items will not currently work for the typical NMG solid, but only "wire" loops. The "move edge" will work for simple NMG solid objects. The sketch is mantained always as a loop, and when the user is satisfied with the sketch, the "extrude loop" menu item may be selected to produce an extruded solid. This works similar to other solid editing items as the user may use any number of mouse point selections or "p" commands to produce different extrusions until the desired effect is accomplished. Then the usual "ACCEPT" or "REJECT" menu item is selected.

-John

Received: from walrus.arl.mil by wolf.arl.mil id aa29330; 2 Dec 94 3:07 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa16448; 2 Dec 94 1:45 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa16446; 2 Dec 94 1:40 EST Date: Fri, 2 Dec 94 6:34:05 GMT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: 4.3 Beta2 Message-ID: <9412020134.aa26885@wolf.arl.mil>

Based upon the feedback we have received since the Beta test period has started, a number of small but important improvements have been made, primarily in the realm of portability, but also some new features.

The most notable new features are courtesy of Timothy Smith and the crew at Sun Microsystems, who have contributed a really nice X11 module for LIBFB which supports 24, 8, and 1 bit visuals. They have also contributed improved Sun XGL support for MGED which is compatible with Solaris and can take advantage of Sun graphics accelerator hardware.

Sun is working hard to make their systems run BRL-CAD "as well as an SGI does". While they still have some work to do in the area of graphics performance, their RT performance is astonishingly good. In my very rough initial testing, a 50 MHz (each) 4-CPU Hyper-SPARC SS10BSX system with Solaris 2.4 (summary RTFM=178.69) ran more than 2.5 times as fast as a 1-CPU 150 MHz R4400 based SGI Indigo**2 with Irix 5.2 (summary RTFM=63.89). More than just MegaHertz matters!

As before, the beta test sources can be found on host FTP.ARL.MIL in the directory "brl-cad/Rel4.3/src":

-r--r--r-- 1 mike graphics 7233902 Dec 2 00:32 cad4.3.tar-a.Z -r--r--r-- 1 mike graphics 2146289 Dec 2 00:33 cad4.3.tar-b.Z -r--r--r-- 1 mike graphics 1706300 Dec 2 00:33 cad4.3.tar-c.Z -r--r--r-- 1 mike graphics 2136811 Dec 2 00:34 cad4.3.tar-d.Z -r--r--r-- 1 mike graphics 1007393 Dec 2 00:35 cad4.3.tar-e.Z -r--r--r-- 1 mike graphics 744433 Dec 2 00:35 cad4.3.tar-f.Z -r--r--r-- 1 mike graphics 1893163 Dec 2 00:36 cad4.3.tar-g.Z

Please report any difficulties you might encounter, using the "cadbug.sh" script.

Enjoy! -Mike

Received: from wharf.arl.mil by wolf.arl.mil id aa05844; 2 Dec 94 12:32 EST Received: from Sun.COM by wharf.arl.mil id aa12527; 2 Dec 94 12:22 EST Received: from East.Sun.COM (east.East.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA18655; Fri, 2 Dec 94 09:21:53 PST Received: from spdev.East.Sun.COM (spdev-gw.East.Sun.COM) by East.Sun.COM (4.1/SMI-4.1) id AA26888; Fri, 2 Dec 94 12:21:48 EST Received: by spdev.East.Sun.COM (5.0/6.1-spdev1) id AA09137; Fri, 2 Dec 1994 12:20:55 +0500 From: Timothy G Smith - Special Projects <tgsmith@sun.com> Message-Id: <9412021720.AA09137@spdev.East.Sun.COM> Subject: Re: 4.3 Beta2 To: Mike Muuss <mike@arl.mil> Date: Fri, 2 Dec 1994 12:20:54 -0500 (EST) Cc: CAD@arl.mil In-Reply-To: <9412020134.aa26885@wolf.arl.mil> from "Mike Muuss" at Dec 2, 94 06:34:05 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1197

If I'm not mistaken, Mike Muuss said: < Date: Fri, 2 Dec 94 6:34:05 GMT < From: Mike Muuss <mike@ARL.MIL> < To: CAD@ARL.MIL < Subject: 4.3 Beta2 < < Sun is working hard to make their systems run BRL-CAD "as well as an SGI < does". While they still have some work to do in the area of graphics < performance, their RT performance is astonishingly good. In my very < rough initial testing, a 50 MHz (each) 4-CPU Hyper-SPARC SS10BSX system < with Solaris 2.4 (summary RTFM=178.69) ran more than 2.5 times as fast < as a 1-CPU 150 MHz R4400 based SGI Indigo**2 with Irix 5.2 (summary < RTFM=63.89). More than just MegaHertz matters!

Thanks for all of the nice words, Mike.

One minor correction: The system you have has 4 SuperSPARC processors, not 4 hyperSPARC processors. The hyperSPARC was just recently introduced and only FCSed yesterday. It is a 100MHz part that is roughly a third faster (according to the SPEC numbers) than the SuperSPARC processors you currently have. I have not had a chance to benchmark the hyperSPARC yet but hope to soon. The hyperSPARC has a smaller cache than the SuperSPARC so it will be interesting to see how it compares on the RT benchmark.

--tim

Received: from walrus.arl.mil by wolf.arl.mil id aa13812; 9 Nov 94 18:10 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa02530; 9 Nov 94 17:03 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa02367; 9 Nov 94 16:52 EST Date: Wed, 9 Nov 94 16:45:42 EST From: "John R. Anderson" <jra@ARL.MIL> To: cad@ARL.MIL Subject: BRL-CAD 4.4 and FASTGEN Message-ID: <9411091645.aa13033@wolf.arl.mil>

A new release of BRL-CAD is coming soon, so for those of you who have been using FASTGEN, here is an update on what to expect in the new release.

PATCH-G has been updated to take advantage of the new NMG capabilities in BRL-CAD. Plate mode components in FASTGEN are described as triangular faces with a specified thickness. These triangles are converted to NMG triangular faces and then extruded by the thickness of the plate to create a true solid in BRL-CAD. Previously, these components were converted by building an ARB6 (an extruded triangle) for each triangle in the plate mode object. This resulted in cracks or overlaps where two adjacent triangles were not coplanar. The new method extrudes the entire surface of triangles to produce a single solid with no cracks or overlaps for the plate mode object. Volume mode component in FASTGEN may also be described using triangular faces. These are also converted to BRL-CAD NMG solids. There is a user option to have the final BRL-CAD NMG solids written to the database as polysolids rather than as NMG's. The NMG's are more flexible and carry more information about the solid (topology as well as geometry), but for most current vulnerability analyses the polysolids will be adequate. The remainder of the FASTGEN object types are converted to corresponding BRL-CAD solids in the same manner as the previous release.

A FASTGEN4 to BRL-CAD converter has been added to the BRL-CAD package. This code was described in an earlier note to this list. It converts the new NASTRAN-like FASTGEN4 to BRL-CAD in a manner similar to the PATCH-G converter.

FASTGEN users reading this should also be aware of the BURST code written by Gary Moss. This code produces shotline output for parallel ray grids or for bursting (disribution of rays emanating from a single point). This output may be used with the Air Force Point Burst Damage Assessment Model (PDAM), and is is in a format suitable for filtering to an unformatted file to mimic FASTGEN output. Leonard "Bud" Bruenning <bruennin@uv3.eglin.af.mil> is the keeper of the BURST code if you need more information.

There is also an RTG3 code to produce parallel ray shotlines from a BRL-CAD model in a form like that produced by the old GIFT code (3 components per line). This shotline output is compatible with the COVART family of vulnerability anaysis codes.

-John

John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058

Date: Thu, 10 Nov 94 13:37:41 EST From: "John R. Anderson" <jra@arl> To: J. Terrence Klopcic <klopcic@arl.mil> cc: phd@arl.mil, lex@arl.mil, mike@arl.mil, jehunt@arl.mil, jnw@arl.mil, jake@arl.mil Subject: Re: BRL-CAD 4.4 and FASTGEN Message-ID: <9411101337.aa27289@wolf.arl.mil>

> John, > > Great work. As someone who is constantly representing BRL-CAD to > the outside world (JTCG, TILV, etc., etc.), I really appreciate > the importance - political as well as technical - of your > accomplishment. Thanks for making my job much easier.

My pleasure, Thanks! > I had a thought (unaccustomed as I am ....): In the process of > bisecting the "cracks" or "overlaps" between plates, you had to > determine the intersection line between the plates on the top and > bottom surfaces, right? That means that - at that time - you new > where the edges of the plates were. Well, I would like to point > out that lots of people would really like the ability to determine > just that: folks who are trying to propagate ballistic shock, > folks that are trying to determine the extent of panels for blast > loading, folks that are trying to establish zones for combined > blast-fragment synergistic effects, etc. Is there potential > spin-off here?

Maybe, but let me give you a few more details. Then you can tell me if we are talking about the same thing.

The plate mode objects in a FASTGEN description are typically described as a series of triangles, each with an assigned thickness. This method is normally used for shapes that cannot be described any other way in FASTGEN. Things like aircraft skin, tank turrets, ... anything that is not a box, cylinder, cone, sphere, ellipsoid, or torus. In the previous version of the "patch-g" converter, each triangle was converted to an individual solid by extruding each triangle individually. The resulting solids produced the "cracks" or "overlaps" with their neighbors. The method I used, does not require bisecting these "cracks" or "overlaps". I combine all the triangles from one component into a single NMG surface (the surface consists of the triangles from the FASTGEN component). I then make a copy of this surface, calculate new plane equations for triangular faces (translating each plane by the assigned thickness in the appropriate direction), and (using the new plane equations) calculate new vertices at the intersection of the faces (much detail omitted here). More faces are added to connect the outer edges of the original surface and the extruded copy, resulting in a true NMG solid.

So, the "cracks" or "overlaps" had been occurring where two triangles of a plate mode component adjoined. This is just a artifact of the method used to describe the component (triangular facets used to approximate smooth surfaces). I doubt that is what you are looking for.

However, the new NMG capability in BRL-CAD may be what you want. As well as storing geometry, the NMG objects contain topology as well. If I have a face of an NMG object, I can easily get a list of its edges and vertices. It is simple to go on from there to find neighboring faces and their edges and vertices. The entire object can be traversed in this way. Also, edges in an NMG object are labelled as "real" if they represent real edges and are not just the result of tessellation. For example, a pilots head might be described as an ellipsoid. Currently, if this is converted to an NMG object, it will be approximated by a series of facets. None of the edges in this NMG will be flagged as "real" edges. If, however, his head was described as a box, all the edges in the corresponding NMG would be "real".

Just to be sure you are aware of what's coming, we are currently working to extend NMG objects to allow TNURB (Trimmed Non-Uniform Rational B-spline) faces instead of just planar faces. When this is complete, tank turrets, a/c skin, (and pilot heads, too) may be described without approximating facets.

I think I got carried away with this response, but does this sound like what you are looking for??

-John

Received: from walrus.arl.mil by wolf.arl.mil id aa13513; 7 Sep 94 9:20 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab16187; 7 Sep 94 9:15 EDT Received: from worm.arl.mil by WALRUS.ARL.MIL id aa16049; 7 Sep 94 9:10 EDT Date: Wed, 7 Sep 94 13:00:55 GMT From: "Jill H. Smith, Ch., Vuln. Meth. Br." <jill@ARL.MIL> To: cad@ARL.MIL Subject: [John R. Anderson: FASTGEN4 to BRL-CAD Progress] Message-ID: <9409070900.aa02285@worm.arl.mil>

The JTCG/ME ATV Subgroup task to develop a FASTGEN4 to BRL-CAD geometry translator has been completed. This capability will be distributed in the next BRL-CAD release.

The FASTGEN4 CHEX1, CQUAD, and CTRI elements (in plate-mode or volume-mode) are converted to the users choice of BRL-CAD NMG's or polysolids. In rare cases, the method used to create NMG's from plate-mode elements fails. When this happens, the converter makes a second attempt to convert the component by reverting back to the methodology used in earlier "patch-g" converters, i.e., each triangle in the plate-mode object is converted to an "arb6". CCONE1 and CCONE2 elements are converted to BRL-CAD "gentgc" solids with internal "gentgc" solids subtracted if necessary. CSPHERE elements are converted to BRL-CAD "genell" solids with interior "genell" solids subtracted for the plate-mode cases. CHEX2 elements are converted to BRL-CAD "arb8" solids. CLINE elements are converted to BRL-CAD "gentgc" solids with inner "gentgc" solids subtracted in the plate-mode cases. CLINE elements that share endpoints with other CLINE elements in the same component are connected by spheres ("genell" solids) at the common endpoints (again, with interior spheres subtracted in plate-mode). These "genell" solids have the same radii as the connecting CLINE elements. HOLE and WALL elements are handled by region subtraction in BRL-CAD.

Unique names are assigned to all the resulting BRL-CAD components. If the FASTGEN4 model includes $NAME records, that text information is used to build a name within the constraints of the BRL-CAD name-space. If no $NAME record is found for a component, a name is constructed from the group and component numbers. The user may specify a "-w" flag on the command line to get a warning for every component that does not have a $NAME record. The components are grouped according to the FASTGEN4 "group" number, and a top level group named "all" (containing all the other groups) is created.

BRL-CAD "region id" numbers are constructed as the FASTGEN4 "group number" times 1000 plus the FASTGEN4 "component number".

A BRL-CAD manual page has been prepared and is included in the BRL-CAD distribution along with the FASTGEN4 to BRL-CAD converter ("fast4-g").

This converter has been tested using two models received from Mr. Marty Lentz - the F4E and the MH60. Of the 954 components in the F4E, 918 are converted on the first try and an additional 32 are converted on the second try (using "arb6" solids). This leaves 4 components that failed to convert. The MH60 has 1016 components, 1006 converted on the first pass and 8 more converted as collections of "arb6" solids. Two components of the MH60 failed to convert. All six of the components that failed to convert can be attributed to errors in the FASTGEN4 model. The original MH60 FASTGEN4 model was modified during the development of this converter to eliminate some of the FASTGEN4 errors, and the results quoted are for the modified model. The F4E was not modified in any way.

-John

John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058

Received: from walrus.arl.mil by wolf.arl.mil id aa02300; 7 Dec 94 14:58 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa23896; 7 Dec 94 14:02 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa23640; 7 Dec 94 13:50 EST Date: Wed, 7 Dec 94 13:40:26 EST From: "John R. Anderson" <jra@ARL.MIL> To: browder jr <browder@use1.eglin.af.mil> cc: cad@ARL.MIL Subject: Re: brl-cad 4.3 Message-ID: <9412071340.aa01133@wolf.arl.mil>

The HyperText Markup Language (HTML) files may be viewed using NCSA Mosaic. Available via FTP from: ftp.ncsa.uiuc.edu or unofficial mirror sites: ---------------------------------------------------------------------------- USA: site: sunsite.unc.edu location: /pub/packages/infosystems/WWW (all versions) Australia: site: miriworld.its.unimelb.edu.au location: /pub/clients/ (all versions) Europe: site: ftp.luth.se location: /pub/infosystems/www/ncsa (all versions)

site: ftp.sunet.se location: /pub/mac/Mosaic (mac version) /pub/pc/windows/www/Mosaic/ (pc version) /pub/www/Mosaic (X version)

Hope this helps, -John

John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058

Received: from walrus.arl.mil by wolf.arl.mil id aa07535; 7 Dec 94 22:20 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa29315; 7 Dec 94 22:17 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa29313; 7 Dec 94 22:16 EST Date: Thu, 8 Dec 94 3:06:03 GMT From: Mike Muuss <mike@ARL.MIL> To: "Joseph E. Meier" <jem@sonic.bruker.com> cc: CAD@brl.mil Subject: Re: tutorial for NMG Message-ID: <9412072206.aa07284@wolf.arl.mil>

Hi Joe -

In your letter you didn't mention which version of BRL-CAD you are working with. That makes something of a difference. If you are running Release 4.0, 4.1, or 4.2, the NMG support is not very robust.

As of now, there are very few NMG-related commands in MGED, although those few deliver a lot of functionality. You can use MGED's built-in "help" command to give you a 1-line summary of each:

ev evaluate combinations into polygons for display. facetize evaluate region into an NMG solid, and store in database.

In addition, the "make" command will now (in 4.3beta2) allow you to create an NMG which is a loop of a single vertex and a single edge ("make name.s nmg"), which you can then select for solid editing ("sed name.s"). Using the solid editing menu, you can then use the "pick edge", and "split edge" items to sketch out a 2-D curve in the plane of the current view. Select another view, pick "extrude loop" from the menu, and then *voila!*, you have built yourself an NMG solid! The extrusion can also be controlled via the "p" command, where you specify the XYZ coordinates of a point to lie on the plane of the extruded face.

There are a few other commands that interact with the NMG support, such as "fracture", which can be useful for debugging, and "debugnmg".

For a fascinating visual display of how the NMG boolean library implementes the "ev" command, say "debugnmg 3" before running the "ev" command.

Suggestions for additional NMG support in MGED are welcomed. I've got plenty of ideas, myself. Contributions of code implementing those suggestions are even more welcome! :-)

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa11749; 8 Dec 94 5:12 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa02186; 8 Dec 94 4:38 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa02182; 8 Dec 94 4:31 EST Date: Thu, 8 Dec 94 4:29:38 EST From: "Lee A. Butler" <butler@ARL.MIL> To: browder jr <browder@use1.eglin.af.mil> cc: cad@ARL.MIL Subject: Re: brl-cad 4.3 Message-ID: <9412080429.aa11458@wolf.arl.mil>

>a quick qestion for a novice -- what do i need to use the "html" files? > >(and is there a freeware source on line?)

The most popular browser for WWW/html documents is "Mosaic" available from ftp.ncsa.uiuc.edu. It requires motif to compile, or you have to trust the binary they have out for ftp (ugh).

If you don't have motif and don't want to trust the NCSA binary out for ftp (and why should you?), I'd suggest getting a copy of "chimera" from ftp.cs.unlv.edu. It only requres X and the athena widget set to compile.

Lee

Received: from walrus.arl.mil by wolf.arl.mil id aa25101; 11 Sep 94 11:26 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa20833; 11 Sep 94 10:44 EDT Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa20806; 11 Sep 94 10:32 EDT Received: from rumors.delta.edu by wharf.arl.mil id aa02857; 11 Sep 94 10:21 EDT Received: by rumors.delta.edu (AIX 3.2/UCB 5.64/4.03) id AA05419; Sun, 11 Sep 1994 10:15:29 -0400 Date: Sun, 11 Sep 1994 10:15:29 -0400 From: laut@rumors.delta.edu Message-Id: <9409111415.AA05419@rumors.delta.edu> To: nemiroal@fenris.com, phil@ARL.MIL Subject: Re: Another BRL 4 Linux question. Cc: cad@ARL.MIL

| Yes. There is an enhanced version of MGED known as XMGED that requires | Motif in order to compile and run. Regular MGED continues to be available | and supports X based on libx11 alone, but has a much more primitive | interface. We may someday build an XMGED that does not depend on Motif, | depending on how users like the current one and where they think it should | go (e.g. Mike's group is playing with a Tcl/Tk MGED).

It -is- a nice feature of BRL-CAD that it does not entirely depend upon Motif to work. Some vendors (read DEC) still insist upon "nickel-and-diming" you at every opportunity, and for awhile their Motif upgrade was big, BIG, $$$. Although, in fairness, they have become more reasonable of late.

If applications such as XMGED become the norm, then it would be nice to see BRL-CAD eventually adopt a standard metaphorically akin to LIBPKG which would allow the utilities to support differing windows technologies (ie, plain X, X-with-Motif, X-under-Windows, Windows-NT, etc).

Perhaps a better metaphor would be LIBFB instead of LIBPKG. Actually, maybe expanding LIBFB to include windowing might be a consideration. Have LIBFB return to the application the graphics ability of the "frame buffer," and there decide whether or not to support a windowing option. And, if selected, let LIBFB absorb all of the hardware/vendor-dependent stuff.

Thoughts?

-Bill

Received: from wolf.arl.mil by wolf.arl.mil id aa04761; 21 Dec 94 11:03 EST Date: Wed, 21 Dec 94 15:57:44 GMT From: Paul Tanenbaum <pjt@arl.mil> To: CAD-Beta@arl.mil cc: Chris Hunt <cahunt@arl.mil> Subject: Closed Bug#249: NIRT needs LOS option added Message-ID: <9412211057.aa04585@wolf.arl.mil>

I implemented a new output item called "scaled_los" to complement the existing output item "los". The values of these two output items are

los line-of-sight distance through the current partition, equivalent to (d_in - d_out). This is unchanged from previous versions of NIRT(1).

scaled_los scaled line-of-sight distance through the current partition, the product of los and the region's solidity (also known variously as its percent LOS, thickness factor, and volumetric percentage of material (!)). This is a brand-new feature.

I would have called the new output item "weighted_los", but apparently that might have caused confusion in the MUVES community, where weighting an LOS means multiplying it by the region's solidity AND ITS DENSITY. Of course, to use this new output item one must tailor the output formats as explained in the man page nirt.1. Paul

Date: Wed, 21 Dec 94 20:18:54 GMT From: Mike Muuss <mike@arl.mil> To: Mike Muuss <mike@arl.mil> cc: CAD@ARL.MIL Subject: Re: BRL-CAD Release 4.3beta3 now available Message-ID: <9412211518.aa11211@wolf.arl.mil>

Those of you trying to compile the 4.3beta3 release on IRIX 5.2 will need to modify the Cakefile.defs file. There are bad side effects from using -Wl,-w2 -- if *any* warning message is printed by the loader, it seems to abort the load. This wasn't the intention.

For the time being -Wl,-w1 seems to be having the desired effect.

The whole "-w" option on LD is not documented by SGI at all, but their Hotline suggested using it in place of the documented "-S" option, which does not work. Sorry about the blundering around in the dark.

Best, -Mike

Date: Wed, 21 Dec 94 21:28:46 GMT From: Mike Muuss <mike@arl.mil> To: ACST@arl.mil Subject: Irix 5.2 -Wl,-w values Message-ID: <9412211628.aa11380@wolf.arl.mil>

Per Chris Johnson:

Hello, here is the exhostive 0-15 on -w options. only the valuses 1-3 are acceptable. 1 = surpress all warnings plus all errors (default) 2 = error off on any warning or error 3 = surpress all warnign s plus all errors AND error off on any warning or error.

Looks like -w1 is the best we can do, then.

-Mike

Date: Thu, 22 Dec 94 3:02:13 GMT From: Mike Muuss <mike@arl.mil> To: acst@arl.mil, Lex@arl.mil, Jill@arl.mil, PHD@arl.mil, PJT@arl.mil, Davisson@arl.mil, WM@arl.mil, GDurf@arl.mil, Moss@arl.mil, BParker@arl.mil cc: wbowman@arl.mil, gillis@arl.mil, reed@arl.mil, CJohnson@camelot.com Subject: No #elif, please Message-ID: <9412212202.aa16596@wolf.arl.mil>

When writing portable BRL-CAD code, please do not use the #elif preprocessor directive. This is new with ANSI C, and can not be processed by earlier, non-ANSI compilers.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa10955; 27 Dec 94 15:54 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa03991; 27 Dec 94 15:08 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa03989; 27 Dec 94 15:07 EST Date: Tue, 27 Dec 94 19:58:06 GMT From: Mike Muuss <mike@ARL.MIL> To: merlin <merlin@neuro.usc.edu> cc: cad@brl.mil Subject: Re: BRLCAD for US citizen employed in United Kingdom Message-ID: <9412271458.aa07806@wolf.arl.mil>

AJ wrote -

> I will be traveling to work in the United Kingdom (University College > London) for two years beginning in May 1995. I gather it would not be > proper to just take a take of the current version of BRLCAD with me to > England. I also understand it would not be proper to just ftp a new > copy (without some prior formal arrangement for permission acquire new > versions by anonymous ftp and decrypt the package in another country). > > Approaching the British Foreign Office to obtain a copy of BRLCAD for > a United States national seems a bit awkward. Nevertheless, it may be > the proper approach to obtaining permission to use BRLCAD in England. > > So, I would appreciate advice about the appropriate procedure to follow > to obtain BRLCAD for use in England.

Congratulations on your foreign appointment! UCL is a cool place, and I'm sure you will have a splendid time there.

Thanks for asking what the proper procedure is. It is no longer necessary to involve the Foreign Office for overseas distribution. Fortunately we were able to eliminate that step many years ago.

BRL-CAD agreements are executed either by (a) a private individual, when their use is for personal use, or (b) a corporation or institution. In your case, I believe that your current agreement is executed by your current University. Since you are temporarily changing affiliations, simply fill out and return an agreement through UCL, and rest easy.

Since you already have the BRL-CAD materials, and UCL is (will be) a registered site, you are free to take whatever materials you like along with you in whatever manner is most convenient to you. Your associates here in the States can continue to work with your original set.

That's all there is to it! Hopefully sending in the one form won't be much of an inconvenience to you. It will be a big help to us!

THE BIG PICTURE

I was recently informed that BRL-CAD is the U.S. Army's #1 "Technology Transfer Product". It's also the only one that is still available without charge to any who want it. These are both points of pride for those of us who developed it.

In this time of downsizing, it is important that the usefulness of our BRL-CAD work continue to be recognized, to help us protect our funding line. The "survey" form that you return with your BRL-CAD agreement is our primary source of documentation to support our position.

Over the years I have worked to streamline the agreement process as much as possible. I like to believe that the procedure and forms we have been using since Release 4.0 started are not overly burdensome. As we come up on Release 4.4 Mary Monk and I will be working on an improved version of the forms and procedures to further streamline distribution to foreign sites.

My thanks to all of you, the BRL-CAD users, for making BRL-CAD a success!

Happy Holidays! -Mike Muuss

Received: from wolf.arl.mil by wolf.arl.mil id ab19080; 23 Dec 94 19:47 EST Date: Sat, 24 Dec 94 0:38:55 GMT From: Mike Muuss <mike@arl.mil> To: Cad-Beta@arl.mil Subject: per-vertex surface normals Message-ID: <9412231938.aa19032@wolf.arl.mil>

This evening, while tracking a performance issue on the Sun XGL display manager relating to drawing speed of dot-dashed lines in MGED, I added two new options to the "e" and "ev" command in MGED:

-s Draws all subtraction and intersection solids with solid lines, rather than using the usual dot-dash pattern.

-v When used with EV, shade polygons with per-vertex surface normals, rather than flat-shading them with the face normal. This makes much "prettier" looking curved shapes, for presentations.

Best, -Mike

Received: from wolf.arl.mil by wolf.arl.mil id aa25349; 27 Dec 94 22:53 EST Date: Wed, 28 Dec 94 3:52:41 GMT From: Mike Muuss <mike@arl.mil> To: CAD-Beta@arl.mil Subject: Closed Bug#65: libfb/if_remote fails to implement rem_setcursor() Message-ID: <9412272252.aa25329@wolf.arl.mil>

I don't know why the remote framebuffer library never had a routine to support remotely defining the shape of the cursor. However, Sue Coates' bug report is quite accurate -- it doesn't work. I defined a new kind of remote framebuffer PKG to implement the missing routine: MSG_FBSETCURSOR.

In order to prevent having a new LGT get stuck waiting forever for the MSG_RETURN package when using an old RFBD framebuffer server, I made if_remote.c send the request with flag MSG_NORETURN. This way old framebuffer servers will log the message "pkg_dispatch: no handler for message type 131, len 20" and harmlessly ignore it, without hanging the user application (like LGT).

libfb/if_remote.c revision 9.20, libfb/pkgtypes.h revision 9.4, fbserv/fbserv.c revision 10.7, fbserv/fbserv.h revision 10.3, rfbd/rfbd.c revision 10.7.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa24466; 27 Dec 94 21:47 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab07932; 27 Dec 94 21:20 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id ab07826; 27 Dec 94 21:16 EST Date: Wed, 28 Dec 94 2:09:39 GMT From: Mike Muuss <mike@ARL.MIL> To: Bob Strausser <strssr@ARL.MIL> cc: Dane Kottke <dkottke@sanders.com>, cad@ARL.MIL Subject: Re: XMGED editing of NURBs Message-ID: <9412272109.aa22021@wolf.arl.mil>

Bob wrote -

> As far as I am aware, there is no current editing capability in either > MGED or XMGED for NURBS. I believe the current beta release does permit > some editing of an NMG but not NURBs.

In the Beta release (BRL-CAD Release 4.3), there exists some modest MGED editing capability for *both* planar NMGs and the existing NURBS solids. In the case of NURBS solids, the editing is restricted to moving control points around using the mouse. This is probably acceptable for simple "by eye" touch-up, but is a far cry from "sophisticated" B-spline editing.

Best, -Mike

< mike@arl.mil >
Release notes for other versions of BRL-CAD