# rel5.0

Received: from walrus.arl.mil by wolf.arl.mil id aa10907; 31 Jan 95 20:23 GMT Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab09855; 31 Jan 95 19:13 GMT Received: from worm.arl.mil by WALRUS.ARL.MIL id aa09831; 31 Jan 95 19:11 GMT Date: Tue, 31 Jan 95 19:05:30 GMT From: Lisa Garriques (SURVICE|mermagen) <lisag@ARL.MIL> To: cad@ARL.MIL Subject: SURVIAC BRL-CAD Training Message-ID: <9501311905.aa28008@worm.arl.mil>

/*******************************************************************/ /* REMINDER * REMINDER * REMINDER * REMINDER * REMINDER * REMINDER */ /*******************************************************************/

SURVIAC will be offering its two introductory BRL-CAD training courses according to the following schedule:

BRL-CAD COURSE | DATES ----------------------------------------------|------------------------------ 101 Construction, Interrogation, and Imaging | 22-23 Feb 95 17-18 May 95 102 Geometry Conversion | 24 Feb 95 19 May 95

Advanced courses are available upon request to address in-depth BRL-CAD topics and specific student requirements. For additional information, contact Lisa Garriques at the SURVIAC Aberdeen Satellite Office via the routes provided below.

*************************************************************************** * __ __ ___ __ __ __ __ __ * * |__ | | |_/ \ / | |__| | |__| |__ | | * * __| |__| | \ \/ _|_ | | |__ | | __| |__| * * * *************************************************************************** * The DoD-sponsored Survivability/Vulnerability Information Analysis * * Center (SURVIAC) Aberdeen Satellite Office (ASO), located adjacent to * * the Aberdeen Proving Ground in Maryland, provides full service * * distribution and support for the BRL-CAD model for a $500 fee. This * * includes the initial distribution of the model and documentation, * * installation support, maintenance release updates, technical support, * * and future activities information. Additionally, we sponsor an annual * * BRL-CAD User's Group Meeting each fall. Training courses are also * * offered periodically each year. * * * * SURVIAC provides the DoD community with a one-stop resource for all * * aspects of nonnuclear survivability, lethality, and mission * * effectiveness, which includes dissemination of information and models * * to support this community. * *************************************************************************** * SURVIAC Aberdeen Satellite Office Phone: (410) 273-7794 * * 1003 Old Philadelphia Road FAX: (410) 272-6763 * * Suite 103 E-mail: cad-dist@arl.mil * * Aberdeen, MD 21001-4011 lisag@arl.mil * ***************************************************************************

Received: from walrus.arl.mil by wolf.arl.mil id aa20031; 1 Feb 95 3:27 GMT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa16065; 1 Feb 95 2:59 GMT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa16062; 1 Feb 95 2:57 GMT Date: Wed, 1 Feb 95 2:52:16 GMT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL cc: STOVALL@eglin.af.mil Subject: "BURST" now available with BRL-CAD 4.4 Message-ID: <9502010252.aa19129@wolf.arl.mil>

To our Air Force and Navy users: good news! ARL has been authorized to directly distribute the "BURST" code (see attachment). BURST provides FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files.

BURST will be a standard item in the next full BRL-CAD distribution. If you require a version of BURST for use with BRL-CAD Release 4.4, please drop a line to John Anderson <jra@arl.mil> or FAX 410-278-5058 to alert him to your need. I imagine that as an interim measure we will provide a supplemental encrypted TAR file on the anonymous FTP server as our primary means of making this software available to the community.

Please join me in saying a warm "Thank-You" to Mr. Stovall!

Best, -Mike

----- Forwarded message # 1:

Date: Fri, 27 Jan 1995 15:56:57 -0600 (CST) From: "STOVALL, ROBERT L." <STOVALL@eglin.af.mil> Subject: Burst Release Authority

Dr Deitz and Mr Anderson,

Recently, the CHICKEN LITTLE program office has received another request for the "burst" code. We have reassessed our previous need to maintain control over this code and have determined that it would be in the best interests of the DOD Vulnerability/Lethality community to release control of this code to you for inclusion and distribution with the BRL-CAD package if you see fit. If you have any questions, please contact me at DSN 872-9243 [(904) 882-9243) or my technical representative, Mr. Bud Bruenning, (904) 729-6497.

Mr. Robert Stovall Joint Munitions T&E Program Office

----- End of forwarded messages

Received: from worm.arl.mil by wolf.arl.mil id aa01625; 1 Feb 95 13:31 GMT From: "Gary S. Moss" <moss@arl.mil> Message-Id: <9502010828.ZM4599@arl.mil> Date: Wed, 1 Feb 1995 08:28:04 -0500 In-Reply-To: Mike Muuss <mike@ARL.MIL> ""BURST" now available with BRL-CAD 4.4" (Feb 1, 2:52am) References: <9502010252.aa19129@wolf.arl.mil> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: Mike Muuss <mike@arl.mil>, CAD@arl.mil Subject: Re: "BURST" now available with BRL-CAD 4.4 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: moss@arl.mil

On Feb 1, 2:52am, Mike Muuss wrote: > Subject: "BURST" now available with BRL-CAD 4.4 > > To our Air Force and Navy users: good news! ARL has been authorized to > directly distribute the "BURST" code (see attachment). BURST provides > FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files. > > BURST will be a standard item in the next full BRL-CAD distribution. If > you require a veOn Feb 1, 2:52am, Mike Muuss wrote: > Subject: "BURST" now available with BRL-CAD 4.4 > > To our Air Force and Navy users: good news! ARL has been authorized to > directly distribute the "BURST" code (see attachment). BURST provides > FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files.

Mike, This is perhaps an oversimplification. ;-) BURST provides Shotline files and Burst Point Library files which contain the same information used by the PDAM code and previously provided by PGEN from FASTGEN descriptions. In any case, the format of BURST's output files are syntactically different, so a conversion is necessary to read them from codes like PDAM. The file burst/burst.format describes the file formats so that it is straightforward to write a Fortran or C routine to read them. They are much easier to for a human to read than the compressed Fortran format previously used.

-Gary

--

"Sometimes nothing fails like success." - W. Wayt Gibbs [Scientific American, Sep 1994, "Software's Chronic Crisis"]

Received: from walrus.arl.mil by wolf.arl.mil id aa21886; 15 Feb 95 20:20 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa09216; 15 Feb 95 19:23 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa09209; 15 Feb 95 19:17 EST Date: Wed, 15 Feb 95 19:10:47 EST From: Mike Muuss <mike@ARL.MIL> To: browder jr <browder@use1.eglin.af.mil> cc: cad@ARL.MIL Message-ID: <9502151910.aa20663@wolf.arl.mil>

> When attempting to select a region in "Object Illum", we get an error > message in mged that says: > > rt_id_solid: u_id=x43 > rt_nul_import unimplemented > init_objedit(<region name>) > > The sequence ALWAYS occurs when we do the following in mged: > > E <region name> > E: <n> vectors in <m> sec > > > Then select "Object Illum" > highlight the region, select with the middle mouse button. > > Are we doing something wrong, though. Perhaps we shouldn't be editing > using E instead of e, or...?

Yes, editing only works if you view the object using the "e" command. The "E" command and the "ev" command evaluate things below the region level, and are not compatible with either Solid or Object editing.

I admit that it isn't a good error message. Formerly there was a better message, someone needs to find out why it no longer prints. Probably some new checking code got inserted before the old checking code.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa16638; 23 Feb 95 9:40 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id ad27737; 23 Feb 95 9:20 EST Date: Thu, 23 Feb 95 9:12:45 EST From: "W. Keith Bowman" (SURVICE|keith) <wbowman@ARL.MIL> To: Glenn Allison <gda@msic.dia.mil> cc: cad@ARL.MIL Subject: Re: CAD4.4 compilation problems Message-ID: <9502230912.aa27285@WALRUS.ARL.MIL>

Glenn, The messages you are getting are from 'rld' the run time linker which resolves dynamic shared objects. Under Irix5* the default build uses shared libraries, which will really save you a lot of disk space. The BRLCAD4.4 should be adding the '-rpath' option on the link command followed by a path specifying where to find the DSO's. Check to make sure that this this option is being used and if so, check to make sure the path looks correct. If this option is not being used run the the 'sh machinetype.sh -v' script and make sure your machine is being recognized as 'MACHINE=6d'. If the path looks incorrect check the setting of LIBDIR in 'Cakefile.defs'. If you are not installing in the default '/usr/brlcad' directory make sure to run the 'newbindir.sh' script which will replace '/usr/brlcad' with new correct install location in several places including 'Cakefile.defs'. Using the '-rpath' option on the load command puts the DSO resolve path in the executable so be sure not to move your libraries after the build. There are other ways to tell 'rld' where to look but I think fixing the install is the best approach.

- Keith

Received: from walrus.arl.mil by wolf.arl.mil id aa17606; 1 Mar 95 15:52 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab06961; 1 Mar 95 14:44 EST Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa06912; 1 Mar 95 14:32 EST Received: from 136.205.45.50 by wharf.arl.mil id aa25825; 1 Mar 95 14:08 EST Received: by msic.dia.mil (4.1/SMI-4.1) id AA01695; Wed, 1 Mar 95 12:59:13 CST Date: Wed, 1 Mar 1995 12:58:54 -0600 (CST) From: Glenn Allison <gda@msic.dia.mil> Subject: mged fb problem To: cad@ARL.MIL Message-Id: <Pine.3.89.9503011240.B1671-0100000@msic.dia.mil> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

I am trying to get BRL-CAD running on a SUN SPARC 10 running SunOS 4.3.1. The program compiles without any errors and mged works without any trouble. I can create models with mged. I can ray-trace the models without errors but when I try to display the pix file in the frame buffer I get the following error:

fb_open (0x8c70, "/dev/debug", 1024, 1024) fb_write (0x8c70, 0, 0, 0x8d50, 1024) the last line is repeated for every line in the pix file.

any suggestions about this problem.

--Glenn Allison, MSIC, (205) 313-6251

Received: from walrus.arl.mil by wolf.arl.mil id aa13765; 14 Mar 95 9:20 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa14710; 14 Mar 95 8:21 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14631; 14 Mar 95 8:19 EST Date: Tue, 14 Mar 95 8:10:47 EST From: "John R. Anderson" <jra@ARL.MIL> To: Steve Pennock <pennock@wichita.llnl.gov> cc: CAD@ARL.MIL Message-ID: <9503140810.aa12724@wolf.arl.mil>

> We have been using the ProE to BRL converter in the latest release of > the BRL-CAD package, and greatly appreciate its being included. Now > the question has arisen as to whether anyone has developed a > capability to import BRL models into ProE.

Not yet, but I hope to provide such a capability in the not too distant future.

> We got a ProE model of an airplane from one of the airframe > manufacturers, converted it to MGED, then added a number of internal > features. We'd like to ship those internal features back to ProE, > without having to re-create them in ProE. Has anyone written anything > to allow this to be done? > You might try "g-iges" and then try importing the IGES file into Pro-Engineer. That won't work on the version of Pro/E that I am running (I still have version 13!!!), it expects only surface files, not solid models. If Pro/E has improved its IGES capability beyond what was available in version 13, there might be a chance.

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 aa25612; 30 Mar 95 18:29 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24849; 30 Mar 95 17:36 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24823; 30 Mar 95 17:33 EST Date: Thu, 30 Mar 95 17:29:59 EST From: "Lee A. Butler" <butler@ARL.MIL> To: glewis@pcocd2.intel.com cc: cad@arl.army.mil Subject: Re: BRL questions X-URL: http://ftp.arl.mil/~butler/index.html Message-ID: <9503301729.aa24737@wolf.arl.mil>

>1) Does XMGED support RIB output for RenderMan?

There is an outboard program to convert NMG solids to RIB polygons. It's called "nmg-rib".

>2) Is there a port of XMGED for Linux boxes (without Motif)?

You'll have to run "mged". XMGED requires MOTIF.

>3) Are any models created for BRL-CAD available for viewing? >(Specifically, that Tank car on the BRL WWW pages look >really cool... and any other train-related ones?)

Look in the "db" directory of your distribution. The ".asc" files there can be turned into BRL-CAD binary databases using the asc-g program.

>4) Since I am already a registered user of BRL-CAD, how can I >get the crypt key for the latest version?

I think your 4.0 decryption key will work on the 4.4 distribution.

Lee Butler

Received: from walrus.arl.mil by wolf.arl.mil id aa16099; 17 Apr 95 10:47 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab10494; 17 Apr 95 10:08 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa10490; 17 Apr 95 10:06 EDT Date: Mon, 17 Apr 95 10:05:49 EDT From: "John R. Anderson" <jra@ARL.MIL> To: URBANOWICZ@lvs-emh.lvs.loral.com cc: cad@brl.mil Subject: Re: BRLCAD rtg3 question Message-ID: <9504171005.aa15704@wolf.arl.mil>

Jim Urbanowicz asks:

> Is millimeters the only output unit of measure for rtg3?

No. Actually, inches is the only output unit for RTG3.

> If I call up a model inmged, and set the local units to inches, > then run the model through rtg3, will the line of sight thicknesses > for each ray trace be output in inches? Thanks.

Yes. See above. Note that the "units" command in MGED only affects what you see while running MGED. It specifies what units you want to work with while using MGED with that particular model. The model is assumed to be stored in mm and RTG3 uses a conversion factor to produce inches.

-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 aa28403; 18 Apr 95 9:25 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24873; 18 Apr 95 8:42 EDT Received: from smokey.arl.mil by WALRUS.ARL.MIL id aa24823; 18 Apr 95 8:37 EDT Date: Tue, 18 Apr 95 8:34:00 EDT From: Bob Parker <bparker@ARL.MIL> To: james@delphi.dseg.ti.com cc: cad@ARL.MIL Subject: Re: xmged Message-ID: <9504180834.aa21746@SMOKEY.ARL.MIL>

James,

You can fix this by adding

XMged*fontList: fixed

to an Xresource file (i.e. .Xdefaults) and then using "xrdb -load .Xdefaults" to load this info into the X server. Or you can edit dm-X.h by changing the corresponding value in the fallback_resources and then recompiling.

Brl-cad release 4.4 already has these modifications. If you haven't already done so, I'd recommend getting the latest release. I hope this helps.

-Bob

Received: from walrus.arl.mil by wolf.arl.mil id aa23155; 25 Apr 95 16:26 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13520; 25 Apr 95 15:31 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa13311; 25 Apr 95 15:21 EDT Date: Tue, 25 Apr 95 15:16:48 EDT From: "John R. Anderson" <jra@ARL.MIL> To: COOK-KM-KATHY <cookkm@lvs-emh.lvs.loral.com> cc: cad@ARL.MIL Subject: Re: using NMG Message-ID: <9504251516.aa22155@wolf.arl.mil>

Kathryn M. Cook writes:

> > I am familiar with creating BRLCAD models using the standard primitives. I have > seen references in the mail traffic about NMG solids. I have not been able to > locate any documentation on how to create and work with these solids. Can they > be created and edited in xmged?

The NMG solids are still experimental and not fully supported yet. You can make an NMG solid of extrusion in MGED. The same should work in XMGED, but I don't think it does. Here is the procedure:

After starting MGED, make a nearly empty NMG solid by "make s.nmg nmg". Replace "s.nmg" with any solid name you like. Then use the mouse to select "Solid Ilum" (or type "press sill"). This will get you into Solid Edit Mode. Then use the middle mouse button to select your NMG solid (or type "ill s.nmg"). This selects the new NMG solid for editing. Next, select "pick edge" from the Solid Edit Menu and move the mouse to the MGED display window (not in the menu) and click the middle mouse button. This selects the only edge in the newly created NMG. Now select "split edge" from the Solid Edit Menu. You may now draw a loop of edges by clicking the middle mouse button at the locations of the desired points (or use the "p" command). The result is a closed loop of edges. You may continue to select edges, split edges, deletes edges, and move edges until you have the shape you desire. When you are satisfied with the loop you have created, you can extrude it by changing your viewing direction and selecting "extrude loop". Clicking the middle mouse button will extrude the loop to the selected point. You may continue selecting different points until you are satisfied with the final NMG solid. Then select "Accept Edit" (or "press accept").

> Is there any documentation on creating > polysolids (I also seen reference to these)? I am familiar with FASTGEN > triangles and SHAZAM points and faces. Do they work in a similar manner? I > have used patch-g to translate my FASTGEN models but I can't figure out how to > edit the resulting faceted components or how to add additional similar > components.

There is no way in MGED to create a polysolid, but you can write a program that uses "libwdb" to create polysolids. You would need the following routines: mk_id() to create an ID record for the new model. mk_polysolid() to make a header record for the polysolid mk_poly() or mk_fpoly() to make each face. See libwdb/poly.c for these routines.

The BRL-CAD polysolid is similar to the FASTGEN triangles in that they both describe a solid by listing the vertices of planar faces. The polysolid may have up to 5 vertices per face and does not have the sequencing complication that FASTGEN triangular facets do. The polysolid faces must have their vertices listed in CCW order (use the right-hand rule) so that the outward normal is well defined.

> Thanks,

You're welcome. I 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 aa03436; 2 May 95 20:40 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13656; 2 May 95 20:37 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa13565; 2 May 95 20:29 EDT Date: Tue, 2 May 95 20:20:19 EDT From: Mike Muuss <mike@ARL.MIL> To: Cheong Mei Teng <cmeiteng@trantor.dso.gov.sg> cc: CAD@ARL.MIL Subject: Re: latest BRLCAD Message-ID: <9505022020.aa02843@wolf.arl.mil>

> > This is possible even in release 4.0, using the '-X80000000' option > > to RT and sending the output to "pl-sgi" or to a file, and then > > viewing with "pl-sgi" or with the "overlay" command in "mged". > > > > The platform that we are working on is Sun Sparc server 10, solaris 2.3. I created a mged file trial.g containing a box and I tried to raytrace it using the following command: > > rt -a90 -e0 -s32 trial.g box > output.pix > > Next, I tried to see the interception animation by typing > pix-fb output.pix > > I do not get an image file. Instead, I got only lines of fb_open, fb_write and fb_close commands. I had also tried viewing the pix file in mged using overlay command, but I still do not get any image. Would appreciate very much if you could assist.

The problem here is that environment variable FB_FILE has not been properly set. Run "man brlcad" and read the section on FB_FILE. Considering you are using Solaris, I suggest that you will get much better results using the new versions of the display software in BRL-CAD Release 4.4.

What this will show you is the optical image of the box. In order to see the ray history file, which is what I think you mean when you say "interception animation", you need to do what I wrote earlier. Try:

rt -P1 -X80000000 -a90 -e0 -s32 -o output.pix trial.g box > output.pl

Then view the ray history file in MGED like this:

mged trial.g e box overlay output.pl

And then rotate the view as you please.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa27279; 3 May 95 11:13 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19584; 3 May 95 9:59 EDT Date: Wed, 3 May 95 9:48:46 EDT From: Bob Strausser (SURVICE Eng | SURVIAC ASO) <strssr@ARL.MIL> To: Rick Grote <grote@ARL.MIL> cc: ged@ARL.MIL Subject: Material ID Codes Message-ID: <9505030948.aa19404@WALRUS.ARL.MIL>

Rick,

The problem isn't with the geometries having different codes, its the assessment models which use different codes. For example ...

MATERIAL VAST COVART HEIVAM -------- ------ -------- -------- 1 steel steel(BHN 100) magnesium 2 rha steel(BHN 150) aluminum 3 fha steel(BHN 200) titanium 4 cast iron steel(BHN 250) cast iron 5 aluminum steel(BHN 300) fha 6 magnesium steel(BHN 350) steel 7 copper titanium rha etc.

So the material assigned in the target description is correct for a given assessment model but if another analyst wants to use that geometry with a different assessment model, all of the material code assignments must be checked against the alternate model's understanding of what a material code number of xx is. This is also true for updated versions of assessment codes (COVART 4 brought HEVART and HEIVAM internally so the material definitions had to be made common).

This being the case, even with the ability to read the material ids from the geometry database, the codes must still be verified to match whatever assessment model is being used (and a conversion utility must still know what id table was used in the geometry so it knows what id numbers to swap to get to the desired id table).

Too good to pass up my two cents worth,

Bob Strausser SURVICE Engineering

Received: from walrus.arl.mil by wolf.arl.mil id aa21785; 4 May 95 20:11 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15906; 4 May 95 19:33 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa15875; 4 May 95 19:24 EDT Date: Thu, 4 May 95 19:21:04 EDT From: Mike Muuss <mike@ARL.MIL> To: iedsp@agt.gmeds.com cc: CAD@ARL.MIL Subject: Re: BRLCAD Message-ID: <9505041921.aa20232@wolf.arl.mil>

Dave asks -

> Is the free unsupported version of brlcad the same as the supported > version (the source code)?

The software provided is identical in either case. The only difference is human time and supplies:

*) Select the FREE distribution if (a) you have InterNet FTP access +and+ (b) you don't need assistance installing/configuring/using the software.

*) Select the SUPPORTED distribution if (a) you need the software on tape -or- (b) you desire assistance installing/configuring/using the software.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa18774; 13 Jun 95 11:05 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab13094; 13 Jun 95 11:03 EDT Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa12948; 13 Jun 95 10:53 EDT Received: from cs.ida.org by wharf.arl.mil id aa04699; 13 Jun 95 10:39 EDT Received: from oed-u1.oed.ida.org by ida.org (4.1/SMI-4.1) id AA01981; Tue, 13 Jun 95 10:38:56 EDT Received: from bturner-pc (bturner-pc.oed.ida.org) by oed-u1.oed.ida.org (4.1/SMI-4.1) id AA05857; Tue, 13 Jun 95 10:38:54 EDT From: Ben Turner <bturner@ida.org> Message-Id: <9506131039.ZM10807@bturner-pc> Date: Tue, 13 Jun 1995 10:39:28 -0400 In-Reply-To: Mike Muuss <mike@ARL.MIL> "Re: HTML to PS?" (Jun 12, 5:42pm) References: <9506121742.aa19876@wolf.arl.mil> X-Mailer: ZM-Win (3.2.1 09Sep94) To: iedsp@agt.gmeds.com Subject: Re: HTML to PS? Cc: cad@ARL.MIL Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19506131039.ZM10807.bturner-pc"

--PART-BOUNDARY=.19506131039.ZM10807.bturner-pc Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u

On Jun 9, 9:46am, David S. Pesetsky wrote: > Subject: HTML to PS? > I'm looking for a way to convert the HTML pages that come with the > distribution to postscript so I can print them all at once. >-- End of excerpt from David S. Pesetsky

You may find Jan K=E4rrman's html2ps perl script useful. I've used it with perl versions 5.001 and 4.0 (the latter is distributed with SGI IRIX 5.3). This script does not handle in-line images (substitutes [IMAGE]).

Exerpt from the html2ps info page <http://www.tdb.uu.se/~jan/html2ps.html>: | The Perl script html2ps is an HTML-to-PostScript converter. Perl is | available from any comp.sources.misc archive. | | The latest version of html2ps is available via anonymous ftp from | ftp.tdb.uu.se in /pub/sources/html2ps as a tar file: | html2ps_0.1beta.tar. You can also fetch the files individually from | the same directory: README, html2ps,, html2ps.1 (a manual page) and | manpage.txt (a plaintext version of the manual page).

Best, Ben

--PART-BOUNDARY=.19506131039.ZM10807.bturner-pc--

Received: from walrus.arl.mil by wolf.arl.mil id aa07260; 16 Jun 95 10:47 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa03695; 16 Jun 95 9:25 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa03616; 16 Jun 95 9:20 EDT Date: Fri, 16 Jun 95 9:20:09 EDT From: Glenn Durfee <gdurf@ARL.MIL> To: ZEROMOLD@aol.com cc: cad@ARL.MIL Subject: Re: tmged not working Message-ID: <9506160920.aa03482@wolf.arl.mil>

Phil Cogan (ZEROMOLD@aol.com) writes: > I've been using mged for a couple of months and recently tired compiling > tmged. The compile went smoothly, however when I went to run tmged, all I > got was was a blank window itled Tkmged and the standard mged window. > > All the tcl/Tk demos work flawlessly. > > What did I do wrong?

To try out the sample user interface, you need to do the following: Find "tmged.tcl" (it should be in the tmged directory. For this example, we will assume it is in the subdirectory "../tmged"). Then, at the mged> prompt, type "source ../tmged/tmged.tcl" (or whatever path is appropriate). You should then get the sample interface (a button menu and an interaction window).

The main reason the interface is not loaded automatically is that users may wish to write their own, customized, interfaces in Tcl/Tk for use in tmged.

If you want this to be loaded automatically each time you start tmged, copy "tmged.tcl" to "~/.tmgedrc" (or put the "source foo/tmged.tcl" command in your ~/.tmgedrc file).

Hope this helps, Glenn

Received: from walrus.arl.mil by wolf.arl.mil id aa05039; 15 Jul 95 5:05 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa12899; 15 Jul 95 4:26 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa12892; 15 Jul 95 4:16 EDT Date: Sat, 15 Jul 95 4:07:51 EDT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: near-real-time raytracing Message-ID: <9507150407.aa03596@wolf.arl.mil>

This evening I got the prototype versions of RTSYNC and RTNODE running. Right now I've got 3 systems with a total of 38 CPUs rendering the viewpoint from my MGED session as fast as they can into a shared framebuffer. I'm getting about 0.5 frames/sec, at 512x512, and that isn't close to the final number of CPUs....

I set the MGED to spinning, and it's really cool to watch the framebuffer flipping up a new image every other second, fully ray-traced.

Until the HIPPI framebuffer gets installed, I think I'm going to be Ethernet limited.... Ugh.

Progress! -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa15170; 27 Jul 95 18:45 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24370; 27 Jul 95 17:59 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24368; 27 Jul 95 17:54 EDT Date: Thu, 27 Jul 95 17:51:22 EDT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: pathlist command added to MGED Message-ID: <9507271751.aa13107@wolf.arl.mil>

This evening I added the "pathlist" command to MGED at the request of Glenn Durfee. This new command makes it easy for TCL functions to build menus containing the list of paths below a given combination.

With Glenn working on TCL/Tk "power functions" for creating new geometry, and with PJT working on a TCL/Tk "power function" for point-n-click solid editing, I'm really excited about where MGED is heading!

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa29758; 28 Jul 95 3:57 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa28373; 28 Jul 95 3:50 EDT Received: from vapor.arl.mil by WALRUS.ARL.MIL id aa28363; 28 Jul 95 3:44 EDT Date: Fri, 28 Jul 95 3:36:59 EDT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: OED cmd added to MGED Message-ID: <9507280336.aa16976@VAPOR.ARL.MIL>

This evening I added the "OED" command to MGED, allowing a direct transition from VIEW state to ObjectEdit state in one step, without having to go through the steps of "press oill", "ill leaf", and "matpick a/b".

This should further improve our ability to drive MGED from TCL scripts.

Usage is "oed path_lhs path_rhs"

Examples: "oed all.g box.r/box.s" and "oed all.g/box.r box.s"

The matrix which will recieve the object edit transform is located at the implicit slash where the space between path_lhs and path_rhs.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa06456; 24 Aug 95 3:47 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa06609; 24 Aug 95 2:43 EDT Received: from vapor.arl.mil by WALRUS.ARL.MIL id aa06607; 24 Aug 95 2:38 EDT Date: Thu, 24 Aug 95 6:29:08 GMT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: TCL MGED mouse bindings Message-ID: <9508240629.aa03301@VAPOR.ARL.MIL>

In the experimental version of TCL MGED I've changed the internal handling of the left and right mouse buttons. They now generate "L" and "R" commands with the same syntax as the "M" middle-mouse command. The default bindings are for zoom-in and zoom-out as before, but this new arrangement allows users to re-bind the mouse buttons as they wish. For example, to make all three buttons act as the middle mouse has always done, these two commands would suffice:

proc L {up x y} {_mged_M $up $x $y} proc R {up x y} {_mged_M $up $x $y}

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa04944; 23 Oct 95 17:58 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa22696; 23 Oct 95 17:15 EDT Date: Mon, 23 Oct 95 17:08:26 EDT From: Bob Strausser (SURVICE Eng | SURVIAC ASO) <strssr@ARL.MIL> To: COOK-KM-KATHY (156791) <cookkm@lvs-emh.lvs.loral.com> cc: cad@ARL.MIL Subject: rtweight program Message-ID: <9510231708.aa22428@WALRUS.ARL.MIL>

Kathy,

The rtweight program is part of the distribution but it is not compiled in the default configuration. The reference program is in the "rt" directory called "viewweight.c". You will need to modify the cakefile to compile the program. It compiles and runs on the SGI without problem.

reposted for your information: ******************************************************************** Date: Thu, 12 Jan 95 12:31:32 GMT From: Jim Hunt <jehunt@arl.mil> Subject: Re: rtweight Message-ID: <9501120731.aa07047@whim.arl.mil>

Rtweight was a piece of sample code to show one way that weights and centroids can be calculated using librt. It is not very "portably" written and thus not part of a standard compile. Find it under your source tree in the rt directory (file name "viewweight.c"). Here is the patch for the Cakefile if you want to try to compile it:

*** Cakefile.orig Thu Jan 5 08:56:04 1995 --- Cakefile Thu Jan 12 07:27:14 1995 *************** *** 8,14 **** #define SRCDIR rt #define PRODUCTS rt rtrad rtpp rtray rtshot rtwalk rtcheck \ rtg3 rtcell rtxray rthide rtfrac rtrange \ ! rtregis rtscale #define SRCSUFF .c #define MANSECTION 1 --- 8,14 ---- #define SRCDIR rt #define PRODUCTS rt rtrad rtpp rtray rtshot rtwalk rtcheck \ rtg3 rtcell rtxray rthide rtfrac rtrange \ ! rtregis rtscale rtweight #define SRCSUFF .c #define MANSECTION 1 *************** *** 40,45 **** --- 40,52 ---- CC CFLAGS -c vers.c CC LDFLAGS RT_OBJ vers.o LIBRT LIBFB LIBFB_LIBES LIBRT_LIBES LIBES -o rt + + #define RTWEIGHT_OBJ RTUIF viewweight.o + + rtweight: RTWEIGHT_OBJ LIBRT_DEP LIBFB_DEP + sh ../newvers.sh version "RT Weight" + CC CFLAGS -c vers.c + CC LDFLAGS RTWEIGHT_OBJ vers.o LIBRT LIBFB LIBFB_LIBES LIBRT_LIBES LIBES -o rtweight #define RTRAY_OBJ RTUIF viewray.o wray.o ********************************************************************

Bob Strausser SURVIAC ASO

Received: from walrus.arl.mil by wolf.arl.mil id aa18339; 30 Nov 95 23:17 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19124; 30 Nov 95 22:09 EST Received: from warp.cs.unc.edu by WALRUS.ARL.MIL id aa19095; 30 Nov 95 21:59 EST Date: Thu, 30 Nov 95 21:59:37 EST From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: LIBNURB data structure conversion Message-ID: <9511302159.aa04906@WILSON.ARL.MIL>

Today Paul Stay and I converted all the routines in LIBNURB over to using the t-NURBS data structures from the NMG package. Thus, all "snurb" structures are now "face_g_snurb", and all "cnurb" structures are now "edge_g_cnurb".

This means that routines in MGED and LIBRT can directly use the LIBNURB routines for processing t-NURBS NMG objects. This has been imporant for us to have in furthering our trimmed-NURBS capability, and is an (overdue) good thing to do.

For those of you who may have programmed using the old LIBNURB data structures, when you get the new code (currently found only in the development tree), you can use the attached "ed" script to convert your code over to the new form.

Best, -Mike

f g/u_knots/s//u/gp g/v_knots/s//v/gp g/struct cnurb/s//struct edge_g_cnurb/gp g/struct snurb/s//struct face_g_snurb/gp g/ cnurb/s// edge_g_cnurb/gp g/ snurb/s// face_g_snurb/gp g/knots/s//__KNOTS__/g g/\\.knot/s//.k/gp g/->knot/s//->k/gp g/__KNOTS__/s//knots/g f w q

Received: from walrus.arl.mil by wolf.arl.mil id aa14196; 3 Dec 95 16:39 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa14152; 3 Dec 95 15:54 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa14138; 3 Dec 95 15:47 EST Date: Sun, 3 Dec 95 15:44:25 EST From: Mike Muuss <mike@ARL.MIL> To: Arthur Blair <blair@mkserv.dseg.ti.com> cc: cad@ARL.MIL Subject: Re: trouble with raytracer. Message-ID: <9512031544.aa11086@wolf.arl.mil>

The key to your difficulty is highlighted by the message:

fb_open( 0x3e000, "/dev/debug", 512, 512 )

This means that you neglected to set your FB_FILE environment variable.

Check out "man brlcad", and "man 3 libfb". You might also try running the "fbhelp" program to get it's (extensive) help message.

Best, -Mike

Received: from smokey.arl.mil by wolf.arl.mil id aa17032; 4 Dec 95 9:25 EST Date: Mon, 4 Dec 95 9:25:49 EST From: Jim Rapp <rapp@ARL.MIL> To: jjs@mech2.snu.ac.kr cc: mike@ARL.MIL Subject: Optimetrics Contact Message-ID: <9512040925.aa20185@SMOKEY.ARL.MIL>

The FRED code distribution is handled out of the Dayton, Ohio office of Optimetrics. The point-of-contact for FRED distribution is Susie Pryce. Her phone number is 513-264-1466. The FAX number there is 513-264-1414.

I hope this information helps.

Jim Rapp

Received: from vapor.arl.mil by wolf.arl.mil id aa08426; 15 Dec 95 0:40 EST Date: Fri, 15 Dec 95 0:36:46 EST From: Mike Muuss <mike@ARL.MIL> To: ACST@ARL.MIL cc: Phil@ARL.MIL Subject: pixhalve improved Message-ID: <9512150036.aa02554@VAPOR.ARL.MIL>

I've updated the source to pixhalve, so that it now converts from RGB to YUV, then applies a 3x3 filter to Y and a 5x5 filter to U and V, so as to preserve the maximum amount of detail when the destination is NTSC television, the main application of this tool.

It does make a difference, but for the Bradley image that I tried it on, it's very subtle. Perhaps in other images it will be more beneficial. In any case, I'm leaving the code installed.

Best, -Mike

Received: from vapor.arl.mil by wolf.arl.mil id aa12025; 15 Dec 95 1:30 EST Date: Fri, 15 Dec 95 1:21:50 EST From: Mike Muuss <mike@ARL.MIL> To: ACST@ARL.MIL cc: Phil@ARL.MIL, CJohnson@camelot.com Subject: pix-yuv, yuv-pix Message-ID: <9512150121.aa02819@VAPOR.ARL.MIL>

I've created two new utilities, pix-yuv and yuv-pix. They write Abekas-compatible .yuv files. This provides some additional options for dealing with Abekas files.

It uses the same code as libfb/if_ab.c

Best, -Mike

Date: Fri, 15 Dec 95 8:38:23 EST From: Paul Tanenbaum <pjt@arl.mil> To: acst@arl.mil Subject: bary(1) Message-ID: <9512150838.aa11349@wolf.arl.mil>

I've created a new utility, called bary, to compute weighted sums of points in 3-space. You specify "sites" on the command line and then in the input stream you give lines of one-weight-per-site. It has options to normalize the weights (thus giving you barycentric combinations of the sites) and to copy unmolested any/all fields beyond the first three. The motivation was PHD's request for a ray-traced plot of unit cube data into an equilateral triangle. I can easily imagine other such visualization applications where the tool would be of use. And, most surprising, it even has a man page. Paul

Received: from walrus.arl.mil by wolf.arl.mil id aa20444; 27 Dec 95 10:22 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa23511; 27 Dec 95 9:01 EST Date: Wed, 27 Dec 95 8:49:15 EST From: Bob Strausser (SURVICE Eng | SURVIAC ASO) <strssr@ARL.MIL> To: jung jinsoo <jjs@mech2.snu.ac.kr> cc: cad@ARL.MIL Subject: BRL-CAD from IGES5.1 Message-ID: <9512270849.aa23266@WALRUS.ARL.MIL>

The IGES5.1 support is designed for basic solid entities and for spline surfaces. It will also import an IGES5.1 drawing entity (option -d) which you can position to use as a view template. A minimum of two templates (front and side, top and side, back and bottom, etc.) are required to provide the l-w-h data for each of the solids you will build from the templates. The templates if viewed from its "side" will be a single line (like the edge of a piece of paper) but from its "face" will provide a transparent line drawing guide (with dimensions if in the original IGES5.1 drawing).

Bob Strausser The SURVIAC ASO

Date: Tue, 20 Feb 1996 09:30:58 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: acst@arl.mil Subject: New command in MGED Message-ID: <Pine.SGI.3.91.960220092249.27009A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jra@arl

I have added a new command to MGED. The command is "nmg_simplify" This takes an existing NMG solid and attempts to represent it as a simpler BRL-CAD primitive and build that simpler solid. Currently, it can recognize arb4's through arb8's and circular cross section cones and cylinders. The syntax is:

nmg_simplify [arb|tgc|poly] new_solid existing_nmg_solid

The default behavior is to attempt to build and arb first, if that is not possible, it attempts a tgc, and if that is also not possible, the last resort is to build a polysolid. If an optional arguement is provided, then only that particular type of solid is attempted.

This command was inspired by a request from Bill Hruz and uses routines developed for the Pro/E to BRL-CAD translater.

-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 aa12099; 22 Feb 96 16:32 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13191; 22 Feb 96 15:02 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa13123; 22 Feb 96 14:55 EST Date: Thu, 22 Feb 1996 14:51:11 -0500 (EST) From: "Lee A. Butler" <butler@ARL.MIL> To: "David J. Yemc" <yemc@aplcore.jhuapl.edu> cc: cad@ARL.MIL Subject: Re: HF solids In-Reply-To: <9602212230.AA22519@aplcore.jhuapl.edu> Message-ID: <Pine.SGI.3.91.960222143909.21188A-100000@wolf.arl.mil> X-URL: http://ftp.arl.mil/~butler/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: butler@ARL.MIL

On Wed, 21 Feb 1996, David J. Yemc wrote: > I am trying to work with the HF solid in BRL-CAD, v4.4 running on a DEC alpha. ... > Can anyone point me in the proper direction?

I've worked with the hf. There are some problems with ray-tracing the hf with the released version.

My height field is a 257x257 array of unsigned shorts (2 byte int).

mged> in hff.s hf dfile="01.hf" fmt="us" w=257 n=257 shorts=1 file2mm=31.25 v=0,0,0 x=1,0,0 y=0,1,0 xlen=256000 ylen=256000 zscale=1

That should all be typed in on one line, but I've broken the line for readability. As far as I can tell this means:

dfile="01.hf" The data is in the file "01.hf" fmt="us" The data is unsigned shorts w=257 257 samples wide n=257 257 samples long shorts=1 1 short per sample file2mm=31.25 heights are multiplied by 31.25 to get mm size v=0,0,0 origin of HF is at 0,0,0 x=1,0,0 X axis aligned along 1,0,0 y=0,1,0 Y axis aligned along 0,1,0 xlen=256000 X axis is 256000mm ylen=256000 Y axis is 256000mm zscale=1 Heights are not scaled

Lee Butler

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

Received: from walrus.arl.mil by wolf.arl.mil id aa22013; 12 Mar 96 12:36 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13426; 12 Mar 96 12:33 EST Received: from worm.arl.mil by WALRUS.ARL.MIL id aa13316; 12 Mar 96 12:24 EST From: "Gary S. Moss" <moss@ARL.MIL> Message-Id: <9603121219.ZM3159@arl.mil> Date: Tue, 12 Mar 1996 12:19:12 -0500 In-Reply-To: "Thomas M. Browder Jr." <browder@eglin.af.mil> "burst" (Mar 12, 9:32am) References: <199603121532.JAA06062@use1.eglin.af.mil> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: "Thomas M. Browder Jr." <browder@eglin.af.mil>, cad@ARL.MIL Subject: Re: burst Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: moss@ARL.MIL

On Mar 12, 9:32am, Thomas M. Browder Jr. wrote: > Subject: burst > I am having trouble trying to produce the documents available with the > burst package. Is it possible to have a README file, or something similar, > to give the instructions for the proper syntax for appropriate troff > commands? The same goes for the 'talk' subdirectory where it appears there > is an interesting paper, but no clue for novices about how to produce it.

Tom, It's been lots of years since typesetting of these documents has been attempted by me (the author), and I can't test it out conveniently because I'm no longer familiar with how/which TROFF fonts and macro packages are configured on our various workstations and servers. However, if you have a troff capability, it used to work as follows:

1) For burst/paper, typeset with a command like:

"troff -mm -T[printer] paper.mm"

where the [printer] selects the target printer type (ie -Ti300 for an 300 DPI Imagen). This assumes that the ".tbl" files have been preprocessed with there ".mm" source files (ie "tbl ids.tbl > ids.mm"). Note that "paper.mm" sources all other needed files.

2) For burst/talk, you need to use the "mv" macros instead of "mm" on and run troff on each ".mv" source file:

"troff -mv -T[printer] *.mv"

If you have a "domv" script in that directory, it is intended to be used like so:

"domv [file]"

where [file] is missing the ".mv" suffix. This script would need to be changed to select the proper printer, etc. Currently it pipes the output through "dimp" which is a Device Independent Troff preprocessor for the Imagen printers, and then it pipes the result to "ipr" which is our Imagen spooler.

If you have problems, perhaps someone who still uses TROFF can be of more help. NOTE that the burst paper is published in at least one BRL-CAD Symposium Proceedings and if you have the set of blue manuals that came out with BRL-CAD Release 4.0 and beyond, it's in Volume III, The BRL-CAD Applications, on a page marked "88" at the bottom, also "V3S07A00" in the lower right corner (the page numbering is extremely not useful in this document).

Hope this helps, -Gary

--

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Gary S. Moss email: moss@arl.mil _/ _/ Computer Scientist WWW: http://web.arl.mil/~moss _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Received: from walrus.arl.mil by wolf.arl.mil id aa04801; 6 Jun 96 10:23 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa11402; 6 Jun 96 10:18 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa11392; 6 Jun 96 10:16 EDT Date: Thu, 6 Jun 1996 10:08:59 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: "COOK-KM-KATHY (156791)" <cookkm@lvs-emh.lvs.loral.com> cc: cad@ARL.MIL Subject: Re: BRLCAD to VRML/IV converter In-Reply-To: <9606051330.ZM25120@daggit.lvs.loral.com> Message-ID: <Pine.SGI.3.91.960606095327.1305A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jra@ARL.MIL

On Wed, 5 Jun 1996, COOK-KM-KATHY (156791) wrote:

> Does there exist any method or routine to convert a BRLCAD geometry to > VRML/Open Inventor(*.iv) format? The platform indepentent VRML viewers and > open inventor routines (which come with SGIs) would provide a convienent way to > display/present a solid read-only representation of a BRLCAD model without > ray-tracing multiple views. > > SGIs Showcase software will allow open inventor files to be embedded into a > presentation. The geometric model can then be positioned to any convienent > view at will using the mouse. Future versions of other presentation software > will probably allow insertion of VRML objects. > > Are there any plans to develop such a tool in a future release of BRLCAD? I > assume this would require exporting a representation of the evaluated objects > in a form similar to nmg.

There is a primitive "g-vrml" converter that will be in the next release of BRL-CAD. It is primitive in that it does not take advantage of all the capabilities of VRML. It does handle the geometry, and colors, but all light sources are reduced to point sources. Also relfection, transparency and textures are not handled yet (I don't recall how much of that VRML will actually do). You are correct in your expectation that this would require exporting a representation of the evaluated objects in a form similar to nmg. In fact, the converter produces NMG objects, then outputs them in VRML format. This means that "g-vrml" will only convert what our NMG codes can successfully handle, and while this is not 100%, recently we have seen about 95% success.

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa24473; 8 Jun 96 12:06 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa11643; 8 Jun 96 10:57 EDT Received: from admii.arl.mil by WALRUS.ARL.MIL id aa11636; 8 Jun 96 10:51 EDT Received: from NORMAN.VI.RI.CMU.EDU by ADMII.ARL.MIL id aa00190; 8 Jun 96 10:44 EDT Received: from nageela.vi.ri.cmu.edu by NORMAN.VI.RI.CMU.EDU (8.6.10/NX3.0M) id KAA10200; Sat, 8 Jun 1996 10:44:32 -0400 From: Robert Thibadeau <rht@norman.vi.ri.cmu.edu> Message-Id: <199606081444.KAA10200@NORMAN.VI.RI.CMU.EDU> Received: by nageela.vi.ri.cmu.edu (8.6.10/NX3.0X) id KAA07320; Sat, 8 Jun 1996 10:44:31 -0400 Date: Sat, 8 Jun 1996 10:44:31 -0400 To: cad@ARL.MIL Subject: html on net

I wrote some software and have made it free to download at www.ontv.com called "webfetcher" that should work for anybody that needs to download large manual/code sets from the web. It runs on most all platforms. Not pretty, but it should work pending a CD run. I am a serious fan of not cutting down trees.

Date: Wed, 12 Jun 1996 09:53:30 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.mil> To: acst@ARL.mil Subject: New field in application structure Message-ID: <Pine.SGI.3.91.960612094353.27971A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: jra@arl

I have added an "a_ray_length" field to librt's application structure. This is intended to work similar to "a_onehit", and has been implemented in much the same way. If this field is set to a non-zero value, then ray tracing is stopped as soon as we get beyond the "a_ray_length". The raytracing is done in increments of the space partitions, so this will not stop at exactly "a_ray_length", but it will stop before raytracing any space partition beyond "a_ray_length". I tested this out on the bradley and found that it works as I expected and does in fact reduce the time. Of course, if this is used on a very simple model, you will actually increase the raytrace time.

Both "a_ray_length" and "a_onehit" can be specified and raytracing will stop as soon as either one is satisfied.

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa09181; 15 Jul 96 14:55 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa04828; 15 Jul 96 13:30 EDT Received: from admii.arl.mil by WALRUS.ARL.MIL id aa04625; 15 Jul 96 13:21 EDT Received: from dfw-ix6.ix.netcom.com by ADMII.ARL.MIL id aa12839; 15 Jul 96 13:05 EDT Received: from [205.186.74.81] (ven-ca2-17.ix.netcom.com [205.186.74.81]) by dfw-ix6.ix.netcom.com (8.6.13/8.6.12) with SMTP id KAA08237 for <cad@brl.mil>; Mon, 15 Jul 1996 10:05:04 -0700 X-Sender: MWarner1@popd.ix.netcom.com (Unverified) Message-Id: <v01540b00ae0f5384fb45@[205.186.74.73]> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 15 Jul 1996 10:11:29 -0700 To: cad@brl.mil From: Matt Warner <MWarner1@ix.netcom.com> Subject: Free Unix now on Apple PPC machines

For anyone out there using BRL-CAD, there is finally a Unix flavor available natively for the PowerPC-based Apple Macintosh. Specifically, it is mklinux running on a Mach microkernel. Currently, it only runs on PPC601 chips (PM 6100, 7100, 8100), and the official release is in September. It is possible to purchase a reference release on CD for $10 now or download the rather large files online. Anyone interested should see these sites:

http://www.mklinux.apple.com and http://www.gr.osf.org/~stephen/linux.html

If anyone does successfully port BRL-CAD to MkLinux, please let me know.

Matt Warner

Your unOfficial Macintosh Guy

Received: from walrus.arl.mil by wolf.arl.mil id aa23183; 19 Jul 96 23:56 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa25005; 19 Jul 96 23:54 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa24992; 19 Jul 96 23:44 EDT Date: Fri, 19 Jul 96 23:43:06 EDT From: Mike Muuss <mike@ARL.MIL> To: Henri Lelong <lelong@logique.jussieu.fr> cc: CAD@brl.mil Subject: Re: mged Message-ID: <9607192343.aa22277@wolf.arl.mil>

> I got the embarrassing problem of having .g files, but no adequate version of > g2asc for them, although I still have the right machine (a SGI iris3130) ! > My .g files were made with mged version 3.7, and I do not have this version > handy.

It turns out that you are in luck -- I grew up in an IBM mainframe envirnoment (long ago), and upwards compatability is something that I work hard to maintain in BRL-CAD.

Binary ".g" databases from BRL-CAD Release 2.0, 2.3, 3.0, 3.7, 4.0, and 4.4 are all upwards compatible, meaning that databases created on software with a smaller number can be read with more recent software.

(The reverse is sometimes, but NOT ALWAYS true -- if you write a database on a higher numbered version of the software, it may or may not be readable by a lower numbered version, depending on whether you happen to invoke any of the newer features or not.)

Also, the ".g" format databases are directly binary compatible between SGI 3030, SGI "4-D", Sun-3, Sun-4 (SPARC), and Alliant computers.

So you can just move your old ".g" file from the SGI 3030 onto a modern SGI or Sun workstation running Release 4.4, and pick up where you left off.

Best, -Mike Muuss

Senior Computer Scientist Ballistic Vulnerability/Lethality Division Survivability and Lethality Analysis Directorate The U.S. Army Research Laboratory Attn: AMSRL-SL-BV APG, MD 21005-5068 USA

My E-mail is <Mike @ ARL.MIL> My World-Wide-Web URL is http://ftp.arl.mil/~mike/

410-278-6678 Voice 410-278-6656 Secretary 410-278-5058 FAX

Received: from walrus.arl.mil by wolf.arl.mil id aa12211; 25 Jul 96 18:57 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19199; 25 Jul 96 18:04 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa19164; 25 Jul 96 17:54 EDT Date: Thu, 25 Jul 96 17:53:24 EDT From: Mike Muuss <mike@ARL.MIL> To: Carl Moore <cmoore@ARL.MIL> cc: cad@ARL.MIL Subject: Re: function keys Message-ID: <9607251753.aa08076@wolf.arl.mil>

Carl wrote -

> In mged (at least the way I have it here at ARL), there are some functions > available on the Function keys on a Silicon Graphics terminal.

> I do not see any description of these in the on-line help provided in mged.

These are SGI-specific features.

On an SGI, you can get information about any of the buttons and knobs in MGED by pressing and holding the HELP button on the button box (upper left button), then pressing the button or twisting the knob you want help on.

Here is a quick summary:

F1 Toggle depthcueing F2 Toggle Z-clipping F3 Toggle perspective on/off F4 Toggle Z-buffering F5 Toggle Lighting model (flat -vs- smooth shaded polygons) F6 Select next perspective angle from list: 30, 45, 60, 90 degrees F7 Toggle MGED faceplate off/on F8 Toggle menu F12 Zaps knobs/sliders back to zero

You can ascertain the status of the vendor-specific features currently in effect by running the command "dm set" -- that will print the vendor-specific settings of the current display manager.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa10044; 20 Aug 96 18:21 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa26972; 20 Aug 96 16:00 EDT From: "Bill Mermagen Jr." <wm@ARL.MIL> Message-Id: <9608201551.ZM12622@arl.mil> Date: Tue, 20 Aug 1996 15:51:46 -0400 In-Reply-To: wm@arl.mil (Bill Mermagen Jr.) "Re: Patch-g bug report" (Aug 14, 4:18pm) References: <199608082134.QAA20549@use1.eglin.af.mil> <9608141618.ZM3553@arl.mil> X-Mailer: Z-Mail (3.2.0 26oct94 MediaMail) To: kelsey@eglin.af.mil Subject: Re: Patch-g bug report Cc: cad@ARL.MIL Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: wm@ARL.MIL

Ken,

I have added the support for plate mode wedges as described below in patch-g.

> 2. 'inside' solids were NOT generated and subtracted for 'plate' mode > wedges. Inside solids were generated/subtracted for all OTHER plate > mode objects. > This should cover your bug report for the patch-g convertor. We should make arrangements to get the updated source or executable to you.

-Bill

-- Bill Mermagen Jr.

Received: from walrus.arl.mil by wolf.arl.mil id aa02705; 28 Aug 96 9:43 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa13565; 28 Aug 96 8:55 EDT Received: from smokey.arl.mil by WALRUS.ARL.MIL id aa13456; 28 Aug 96 8:46 EDT Date: Wed, 28 Aug 96 8:45:26 EDT From: Bob Parker <bparker@ARL.MIL> To: urbanowi@vs.lmco.com cc: cad@ARL.MIL Subject: Re: Use of "area" in xmged Message-ID: <9608280845.aa28486@SMOKEY.ARL.MIL>

James Urbanowicz wrote: >I'm having problems with the "area" command in xmged. When I "E" an object, >then try to use "area" on it, all that is displayed is a line that says >something about area, but there is no output value displayed. Any ideas?

You've uncovered a bug. The output is going to stdout via another process (i.e. cad_parea) instead of being captured and stuffed into XMGED's command window. For now, you can look in the window in which XMGED was started to see the return value.

-Bob

Received: from walrus.arl.mil by wolf.arl.mil id aa29869; 29 Aug 96 8:38 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa28174; 29 Aug 96 3:07 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa28141; 29 Aug 96 3:00 EDT Date: Thu, 29 Aug 96 2:50:32 EDT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: LIBRT booleans: more bu_ptbl's Message-ID: <9608290250.aa08984@vm.arl.mil>

This evening I converted the last of the old-style bit-vectors in raytrace.h over to a bu_ptbl variable-length pointer array. This affected the pt_solhits field in the partition structure; it's new name is pt_solids_hit, and it is now a bu_ptbl.

This means that when rt_boolfinal() needs to evaluate the boolean trees for the regions containing the solids found in each partition, rather than having to scan a bit vector of length "nsolids" for non-zero bits, it can just read the elements of a compact array. For models with more than about 80 solids this should be much faster. I don't have any time comparisons yet, because my development version is compiled -g (full debug, no optimization) while the 4.4 version is compiled -O (optimized), and that makes a big difference in runtime.

This change, combined with yesterday's work to eliminate the bit vectors from the soltab and region structures, the overall memory (RAM) consumption of LIBRT should be reduced, especially on larger models. To test this theory, I compared memory use on the benchmark run of the M35 truck. This database is very small, having 1126 solids in 893 regions.

Stage (VAX Ref) Release 4.4 Development Savings

initial 907472 262144 262144 0 GETTREE 1352576 1048576 1179648 -131072 PREP 658960 393216 262144 131072 SHOT 41752 655360 524288 131072

Total 2960760 2359296 2228224 131072

The column marked "VAX Ref" is from the "pix" directory in Release 4.4, but it looks like it may actually represent Release 4.0 memory use. The pattern of "savings" between the development and 4.4 versions looks like it might be an artifact of the system malloc() routine obtaining memory from UNIX in bigish chunks, perhaps 128Kbytes at a gulp. I find the 6% savings of 128Kbytes to be of value, although I had hoped for something more dramatic. For models 50 times larger the savings should be substantial.

The 25% reduction in size over the old "VAX Ref" run shows that we continue to travel in the proper direction!

Best, -Mike

Date: Wed, 28 Aug 96 22:14:30 EDT From: Mike Muuss <mike@arl.mil> To: ACST@arl.mil Subject: RT -J2 Message-ID: <9608282214.aa08703@vm.arl.mil>

I've made the effects of the -J2 flags much more subtle, with the amplitude reduced in half, from +/- 1/2 pixel width to +/- 1/4 pixel width, and with period lengthened from 2 seconds to 10 seconds.

I'd be curious to see a "stationary camera" sequence calculated with this new code.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa23294; 28 Aug 96 7:52 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa11192; 28 Aug 96 6:24 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa11190; 28 Aug 96 6:17 EDT Date: Wed, 28 Aug 96 6:11:20 EDT From: Mike Muuss <mike@ARL.MIL> To: CAD@ARL.MIL Subject: More LIBBU news Message-ID: <9608280611.aa08337@vm.arl.mil>

This evening I've moved two more sets of fundamental data-structure support routines into LIBBU: a nicely generalized version of the variable-length bit-vector routines from LIBRT, and a slightly improved version of that workhorse variable-length pointer-table-array routine: nmg_tbl() from the NMG library.

Delving into how rt_shootray() and rt_boolfinal() use bit vectors, I discovered that with the new bu_ptbl() at my disposal, I was able to make the partition boolean code *much* more efficient, particularly when large numbers of regions are involved. Code that had been O(nsolids)*O(nregions) became O(nsolids)*O(7) in runtime, and I think I see a way to make that still faster, to roughly O(7)*O(7).

Having the bu_ptbl() routines handy, I was also able to plug a "memory leak", regarding the "union cutter" structures not being properly freed from frame to frame in an animation. The problem had been that they were "bulk allocated" and diced up, after which time it was impossible to tell which items on the freelist corresponded to the head of the blocks (and thus should be handed to bu_free()), and which ones were "interior" to the blocks and should just be ignored. With the new routines handy, it was a simple matter to just collect a table of the things to be freed using bu_ptbl_ins(), and then free up all the items in the table at the proper moment.

Having power-tools like variable-length-strings and variable-length pointer arrays makes life so much simpler!

Onwards! -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa27069; 3 Sep 96 20:56 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa26678; 3 Sep 96 20:07 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa26654; 3 Sep 96 19:58 EDT Date: Tue, 3 Sep 96 19:58:24 EDT From: Mike Muuss <mike@ARL.MIL> To: Paul DiCaprio <pauld@kmrmail.kmr.ll.mit.edu> cc: CAD@ARL.MIL Subject: Re: BRLCAD 4.4 build on IRIX 6.2 R8000 -- Progress (fwd) Message-ID: <9609031958.aa22714@wolf.arl.mil>

Paul of MIT asked -

> is RT automatically dividing between both processors in the benchmark?

By default, RT will use all the processors installed in the machine. It prints a message letting you know about this, right at the beginning. Here is an example:

BRL-CAD Release 4.5 Ray-Tracer Sat Aug 31 07:40:28 EDT 1996, Compilation 1691 mike@vapor.arl.mil:/m/cad/.rt.6d Planning to run with 24 processors <<<<<---------- db title: Gary Moss's "World on a Platter"

So if your machine has 2 CPUs installed, the default benchmark would use both CPUs. You can specify the -P flag to RT to select a different number of processors, a negative number indicates to use "all but" that many processors. For example, -P -4 on a 24-processor machine would indicate using 20 processors.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa27568; 4 Sep 96 11:48 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab10130; 4 Sep 96 11:40 EDT Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa10013; 4 Sep 96 11:33 EDT Received: from teas.eglin.af.mil by wharf.arl.mil id aa27814; 4 Sep 96 11:33 EDT Return-Path: bruennin@teas.eglin.af.mil Received: by teas.eglin.af.mil (UCX V2.0-22) Wed, 4 Sep 1996 10:26:13 -0500 Comments: Authenticated sender is <bruennin@teas.eglin.af.mil> From: Bud Bruenning <bruennin@ARL.MIL> To: cad@ARL.MIL Date: Wed, 4 Sep 1996 10:40:32 +0000 Subject: BRL-CAD and IRIX 6.2 Return-receipt-to: "Bud Bruenning" <bruennin> Priority: normal X-mailer: Pegasus Mail for Windows (v2.01) Message-ID: <9609041133.aa27814@wharf.arl.mil>

This is probably so obvious to most it doesn't need to be said, but I may not be as swift as some others and maybe there are some others like me.

While waiting for the new release that will work on IRIX 6.2, I simply copied the binaries and other files in my /usr/brlcad directory (and sub directories) from my SGI Personal IRIS 4D35 running IRIX 5.3 to a tar tape and moved them to my new Indigo 2, Impact 10000 running IRIX 6.2 and all that I've used so far (except patch-g) work quite nicely. As a matter of fact, some utilities like fb-pix that complained of a "sgi_getmem" error on my PI don't pesent such errors on the new Indy. (Perhaps the old PI is starting to wear out.) Anyway, for those who need a SIMPLE SOLUTION and DO NOT NEED TO COMPILE new code, this seems to work.

Bud Bruenning VOICE: (904) 729-6497 FAX: (904) 729-6400 214 Government Street, Niceville, FL 32578 e-mail: bruennin@eglin.af.mil (official business) bruennin@gnt.net (personal-unofficial)

Received: from walrus.arl.mil by wolf.arl.mil id aa23415; 5 Sep 96 22:47 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa12445; 5 Sep 96 21:46 EDT Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa12416; 5 Sep 96 21:37 EDT Received: from cleese.nas.com by wharf.arl.mil id aa22123; 5 Sep 96 21:36 EDT Received: from deliverator(really [198.182.208.46]) by cleese.nas.com via sendmail with smtp id <m0uypoa-000CzzC@cleese.nas.com> for <cad@arl.army.mil>; Thu, 5 Sep 1996 18:34:36 -0700 (PDT) (Smail-3.2 1996-Jul-4 #3 built 1996-Jul-12) Message-Id: <2.2.32.19960906013059.002ff778@cleese.nas.com> X-Sender: gary@cleese.nas.com (Unverified) X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 05 Sep 1996 18:30:59 -0700 To: MHGETMAN@concentric.net, okie@nwidt.com, kcheng@jupiter.risc.rockwell.com, Randys9932@aol.com, CBoth@earthlink.net, cindy.liebeck@vlsi.com, bobt@vnet.ibm.com, kmorimo@ebina.hitachi.co.jp, VincentHuang@acer.com.tw, shkoh@jupiter.info.samsung.co.kr, shaw@scf-fs.usc.edu, mukherje@cup.hp.com, soosoo@hitel.kol.co.kr, hhwu@alpha.ee.ufl.edu, 100015.1632@compuserve.com, rurban@sbox.tu-graz.ac.at, dennis.shinn@saug.wa.com, josgood@frame.com, wammack@aps.anl.gov, joel_orr@mcimail.com, 169932@hdo.com, cecilia@hndol.com, 171403@hdo.com, marks@hndol.com, webmaster@ic.eecs.berkeley.edu, Rudy@finelinemicro.com, Mik.Ferran@cern.ch, pmfdj@crnvma.cern.ch, Nils.Hoimyr@cern.ch, f.vanslooten@wb.utwente.nl, rodmur@ecst.csuchico.edu, cad@ARL.MIL, jules@cs.man.ac.uk, webmaster@igsrsparc2.er.usgs.gov, bob@soest.hawaii.edu, kroenke@soest.hawaii.edu, brown@diego.cecer.army.mil, plewe@acsu.buffalo.edu From: "Gary B. Rohrabaugh" <gary@softsource.com> Subject: Supporting AutoCAD and DXF drawings on your WEB site

Here is the information you need to enable your Web site (server) to allow viewing of AutoCAD or DXF drawings online with industry standard Netscape & Internet Explorer plug-ins.

MIME Types

MIME types are how the Internet applications know what type a file is This is similar to associating an application with a file on a Macintosh or associating a program with a file extension under Windows. In order for browsers to recognize AutoCAD drawing and DXF files so the appropriate action can take place (e.g. for the proper plug-in to be run in Netscape), the server needs to have a MIME type associated with the proper files. Contact your system administrator for more information on how to do this.

extensions Official MIME types

AutoCAD drawing .DWG or .dwg image/vnd.dwg

DXF .DXF or .dxf image/vnd.dxf

NOTE: On April 4, 1996 the IANA (Internet Assigned Numbers Authority) officially registered the following new Media Types, content-type/subtype pairs to SoftSource: image/vnd.dwg, and image/vnd.dxf.

After adding MIME types, your server may need to be restarted. Additionally, Netscape may have cached any images and associated MIME types you have previously viewed, so you may need to clean out the local cache before retrying images.

See the FAQ in the SoftSource Files plugin page for Optional Tags settings to control display of AutoCAD and DXF drawings at your site.

http://www.softsource.com/plugins/faq.html http://www.softsource.com

Received: from walrus.arl.mil by wolf.arl.mil id aa21668; 13 Sep 96 16:21 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa09322; 13 Sep 96 15:10 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa09288; 13 Sep 96 15:06 EDT Received: from localhost by wolf.arl.mil id aa16975; 13 Sep 96 15:00 EDT Date: Fri, 13 Sep 1996 15:00:49 -0400 (EDT) From: "Lee A. Butler" <butler@ARL.MIL> To: "Daniel J. Rinald" <rinald@ngic.osis.gov> cc: cad@brl.mil Subject: Re: rt In-Reply-To: <9609131130.AA12183@spock.ngic.osis.gov> Message-ID: <Pine.SGI.3.95.960913145645.16480A-100000@wolf.arl.mil> X-URL: http://ftp.arl.mil/~butler/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 13 Sep 1996, Daniel J. Rinald wrote:

> 1. What is the current status on an mged to vrml(inventor) translator?

Look at "http://ftp.arl.mil/~jra/" and you will find that John Anderson has done some work in this area. Alas, VRML and BRL-CAD use radically different modeling constructs. It is therefore not always possible to build an elegant VRML representation of a BRL-CAD object. I suspect John's converter will be in the next release.

> 2. I wish to have an emissive target, i.e., no shiny reflections from ambient > lighting. Is this possible? I have tried setting material properties to > plastic, diffuse -> 1.0, reflect -> 0.0, and the rt ambient light option > A -> 0, but I still seem to get a strong reflective light back from > perpendicular facets to the eye. I even tried using "rt -l 1". Any thoughts?

Look at the "light" shader. It does essentially what you seek.

Lee

Received: from walrus.arl.mil by wolf.arl.mil id aa29203; 13 Sep 96 9:59 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa00836; 13 Sep 96 9:58 EDT Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa00830; 13 Sep 96 9:55 EDT Received: from survice.com by wharf.arl.mil id aa10879; 13 Sep 96 9:55 EDT Received: from 206.181.114.201 by fudge.survice.com via SMTP (940816.SGI.8.6.9/940406.SGI) id JAA12308; Fri, 13 Sep 1996 09:55:39 -0400 Message-ID: <32396884.6F03@survice.com> Date: Fri, 13 Sep 1996 09:58:31 -0400 From: Bob Strausser <bobs@survice.com> Organization: The SURVICE Engineering Co. / SURVIAC ASO X-Mailer: Mozilla 3.0 (Macintosh; I; PPC) MIME-Version: 1.0 To: "Daniel J. Rinald" <rinald@ngic.osis.gov>, cad@ARL.MIL Subject: RT without the bright spot Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit

Daniel,

Concerning, the raytracing problem. The only way I know of getting rid of the eyepoint bright spot is to put your own light into the model. This of course creates a bright spot relative to the position of your light and its color.

I placed a sphere in a sample geometry, used the mater command to assign the material "light" and a color of black (0 0 0). I placed it below my geometry objects in the display and raytraced the view with ambient lighting set to 100%. This gave a very nice flat image without any bright spots from any light sources.

Without setting the color to black and setting ambient lighting to 0% gave a very nice halo effect image. A similar halo occurs with the default level of ambient lighting. Setting ambient lighting to 100% once again gives a nice non-spotlighted image. The black light source with zero ambient lighting gives a completely black image of course.

Bob Strausser SURVIAC ASO

Received: from admii.arl.mil by wolf.arl.mil id aa12010; 22 Sep 96 0:33 EDT Received: from ms.ha.md.us by ADMII.ARL.MIL id aa29216; 22 Sep 96 0:16 EDT Received: from hawks.ha.md.us by ms.ms.ha.md.us id aa09761; 21 Sep 96 23:27 EDT Received: (from butler@localhost) by hawks.ha.md.us (8.7.4/8.7.3) id XAA20179; Sat, 21 Sep 1996 23:27:10 -0400 (EDT) Date: Sat, 21 Sep 1996 23:27:09 -0400 (EDT) From: Lee Butler <butler@hawks.ha.md.us> To: bsdi-users@bsdi.com Subject: CPU Performance: Cyrix vs. Intel Message-ID: <Pine.BSI.3.91.960921224647.20110A-100000@hawks.ha.md.us> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Date: Sun, 22 Sep 96 0:12:11 EDT Resent-From: Mike Muuss <mike@ms.ha.md.us> Resent-To: mike@ARL.MIL

I've recently had both the CyrixP166+ and the Intel Pentium166 in a Tyan Tomcat motherboard. I thought I'd pass on what I've learned to the list.

First of all, both parts performed flawlessly. I had no unexpected reboots or hangs.

The short of it is this:

Code Cyrix Intel -------------------------------------- Boot Delay Multiplier 5644 4244 RT Benchmark 26 43

Price (US$) 273 427

In both benchmarks a bigger number indicates faster operation.

The "Boot Delay Multiplier" calculation is an entirely integer process. Here the speed advantage of the Cyrix chip is clear. The speculative execution and/or branch prediction hardware pays off big. This is especially true since the Cyrix chip is running at 133Mhz internally, instead of 166Mhz.

The "RT Benchmark" is a raytracing application and does a relatively large amount of floating point operations in addition to some complex coding structures. While the Cyrix chip does well at optimizing the branching and looping conditions, the floating point unit just isn't a match for the Intel part. Floating point performance on the 133Mhz Cyrix is roughly equal to a Pentium90.

Certainly if you are running an ISP and just serving web pages and running E-mail boxes, I'd seriously consider the Cyrix part. Better, faster, cheaper for that type of application. It's also a bit faster at typical GUI painting for X-workstations (mostly integer bit shuffling).

There are two things that recommend the Intel part. The first is if you do more than a little floating point computation. If you're doing anything like scientific computing, I'd go with the Intel chip.

The second is if you want to run multiple CPU's on one motherboard. While Cyrix cpu's can support multi-processor motherboards, they use a different standard than the (proprietary) one that Intel uses. I've heard that dual CPU motherboards will soon be available for the Cyrix chips, but they don't seem to be out there today.

Lee Butler butler@hawks.ha.md.us

As nightfall does not come at once, neither does oppression. In both instances, there is a twilight when everything remains seemingly unchanged. And it is in such twilight that we all must be most aware of change in the air--however slight--lest we become unwitting victims of the darkness. --- Justice William O. Douglas

Received: from localhost by wolf.arl.mil id aa14780; 24 Sep 96 9:10 EDT Date: Tue, 24 Sep 1996 09:10:51 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: "Fredrick V. Heitkamp" <heitkafv@aa.wpafb.af.mil> cc: Mike Muuss <mike@ARL.MIL>, jra@arl Subject: Re: BRL CAD Raytracer Question In-Reply-To: <960923092855.20793@ethel.aa.wpafb.af.mil.0> Message-ID: <Pine.SGI.3.95.960924090500.13728A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 23 Sep 1996, Fredrick V. Heitkamp wrote:

> Mike, > > Thanks for the reply. I have yet another question. Is there a way presently, > to > convert IGES 114 to BRL-CAD?

No, the IGES 114 is a parametric spline surface, and we haven't done any support for that yet. You may be able to find some software to convert the 114 entities to 128 entities (NURBS) which we can import from IGES. Check at http://www.eeel.nist.gov/iges/igesTools.htm. They have some free tools available there.

-John

> Fred Heitkamp > WL/AAJS (formerly WL/AARI-1) > WPAFB OH > 513 255 5922 x271 > > > > >The BRL-CAD ray-tracer is rather nice. > > > >We have a BRL-CAD to ACAD geometry converter. I know that a flat-facet > >ACAD to BRL-CAD converter is "in the works", I don't know if it's done > >yet or not. It's a small project, about 10 pages of code. > > > > Best, > > -Mike Muuss > > > > Senior Computer Scientist > > Ballistic Vulnerability/Lethality Division > > Survivability and Lethality Analysis Directorate > > The U.S. Army Research Laboratory > > Attn: AMSRL-SL-BV > > APG, MD 21005-5068 USA > > > > My E-mail is <Mike @ ARL.MIL> > > My World-Wide-Web URL is http://ftp.arl.mil/~mike/ > > > > 410-278-6678 Voice > > 410-278-6656 Secretary > > 410-278-5058 FAX >

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

AMC says that my views do not represent an official Government position.

Received: from vapor.arl.mil by wolf.arl.mil id aa28218; 27 Sep 96 4:34 EDT Date: Fri, 27 Sep 96 4:34:53 EDT From: Mike Muuss <mike@ARL.MIL> To: ACST@ARL.MIL cc: wbowman@ARL.MIL, gillis@ARL.MIL, reed@ARL.MIL, CJohnson@camelot.com Subject: h/sed4 Message-ID: <9609270434.aa24265@VAPOR.ARL.MIL>

I've created a file in h/sed4 which you can use to feed to ED to mostly automatically convert a C source file written for Release 4.4 to the new bu.h and bn.h routines for Release 5.0.

I've run it on the NMG code in LIBRT, it required minimal hand-tweeking afterward.

Best, -Mike

Date: Sat, 28 Sep 96 19:32:04 EDT From: Mike Muuss <mike@arl.mil> To: Mike Muuss <mike@arl.mil> cc: ACST@ARL.MIL, wbowman@ARL.MIL, gillis@ARL.MIL, reed@ARL.MIL, CJohnson@camelot.com Subject: Re: h/sed4 Message-ID: <9609281932.aa27413@wolf.arl.mil>

Just to clarify: It is NOT necessary to apply h/sed4 to C source in order to get it to work with Release 5.0; the h/compat4.h header file is auto-included by raytrace.h, and provides 100% source compatability.

It just seemed appropriate to me that the libraries be internally converted, rather than relying on h/compat4.h.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa19515; 15 Oct 96 11:07 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa09314; 15 Oct 96 9:37 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa09230; 15 Oct 96 9:22 EDT Received: from localhost by wolf.arl.mil id aa12737; 15 Oct 96 9:08 EDT Date: Tue, 15 Oct 1996 09:08:15 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: eorddyo@techunix.technion.ac.il cc: CAD@ARL.MIL Subject: Re: Xmged help In-Reply-To: <Chameleon.4.01.961014120122.Yoav@Yoav Oreg.technion.ac.il> Message-ID: <Pine.SGI.3.95.961015090531.11568B-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 14 Oct 1996 eorddyo@techunix.technion.ac.il wrote:

> Hello all, > I have some problems doing some things in Xmged I hope you will help me with,I am stuck in the > middle of a big project so fast replies will be greatly appreciated. > > 1)"rotobj" rotates an object a specified angle around the objects key point.I need to rotate an > objectaround a point of my choice, I thought "qorot" will do it but it doesn't seems to rotate > the object the way I wish. I may be doing something wrong???

"Qrot" allows you to rotate an object about an arbitrary axis. The regular "rotobj" rotates about the "X", "Y", or "Z" axes only.

> 2)is it possible to redefine an obejct's key point?

Yes, see the "keypoint" command"

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa04942; 23 Oct 96 23:32 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa20557; 23 Oct 96 22:53 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa20554; 23 Oct 96 22:47 EDT Date: Wed, 23 Oct 96 22:41:35 EDT From: Mike Muuss <mike@ARL.MIL> To: "Richard S Sandmeyer { Chief, VMB-BVLD-SLAD-ARL }" <richsand@ARL.MIL> cc: Cad@ARL.MIL Subject: rt_comb_v4_export Message-ID: <9610232241.aa01870@wolf.arl.mil>

Hi Rich -

> OK, I'll bite. What are v4/v5 (version numbers)? You've > got so many BRL-CAD irons in the fire that I'm not sure to which > new capability this message refers.

Oops, yes, that's likely to be confusing without context. Here I'm referring to the geometry database format. v1, v2, and v3 were the original ".g" (aka ".vg") formats for GED (pre MGED, pre BRL-CAD), v4 has been the production ".g" format for BRL-CAD since 1985, v5 is the fabled "new database" format that we've been talking about for the past year or so.

I realize these numbers are confusing, as there is also BRL-CAD Release 4.4 (production and 5.0 (development), FASTGEN 4 and FASTGEN 5, COMGEOM 4 and COMGEOM 5, SunOS 4 and SunOS 5, etc.etc. Seems to be "the time" for 4 and 5 as version numbers in mature products. *grin*

Anyway, the progress report was just to let you know that important pieces of the v5 database are beginning to solidify into actual working C code, rather than just being specifications on a Web page.

http://ftp.arl.mil/~mike/papers/brlcad5.0/newdb.html for the specs. :-)

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa12855; 4 Nov 96 9:56 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19902; 4 Nov 96 8:37 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa19840; 4 Nov 96 8:29 EST Received: from localhost by wolf.arl.mil id aa07841; 4 Nov 96 8:24 EST Date: Mon, 4 Nov 1996 08:24:37 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: "ndaglis@acs.itd.uts.edu.au" <ndaglis@acs.itd.uts.edu.au> cc: CAD@ARL.MIL Subject: Re: newbie needs help. In-Reply-To: <199611040512.QAA24513@acacia.itd.uts.edu.au> Message-ID: <Pine.SGI.3.95.961104082222.7364A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 4 Nov 1996, ndaglis@acs.itd.uts.edu.au wrote:

> Hi, > I've gotten brlcad to compile on my Linux box, and subsequently > hit a solid wall at every turn. My configuration is: > > Linux kernel 2.(something) > Motif 2.0 > X11 R6 - xfree3.1.2 > > The biggest problem I think I have is that when I do > xmged world.g all > > I get an error about the world.g file not being in the right form - > it says its lacking the header or something. > > Also xmged dumps core straight after it gives this error. > > > I'm that new to this that I don't now what it is I don't know about > getting this to work. > > Perhaps someone could direct me to a modern compiled version of > brlcad for linux. ie ELF, recent C libs, X11R6 etc. > > thanks ndaglis@acs.itd.uts.edu.au >

Here is a message I posted to "cad" earlier this year:

From jra@ARL.milMon Aug 12 14:50:57 1996 Date: Wed, 5 Jun 1996 08:27:43 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.mil> To: Dwight M Evers <evers@plains.nodak.edu> Cc: cad@ARL.mil Subject: Re: [Q] Who has installed BRL on a linux box???

On 4 Jun 1996, Dwight M Evers wrote:

> Could someone give some helpful hints on installing brl-cad R4.4 on a > linux box??? > > -TIA > > ============================================================================ > | "...peace is a thing which a person > Dwight M. Evers | must be willing to fight for..." > evers@plains.NoDak.edu | > NDSU | -Abe Lincoln > ============================================================================ > ---------- Forwarded message ---------- Date: Thu, 28 Dec 1995 12:10:13 -0500 (EST) From: John R. Anderson (USARL/SLAD/BVLD/VMB) <jra@arl.mil> To: ged@walrus.arl.mil Subject: BRL-CAD 4.4 under Linux 1.2.8

I finally got around to installing BRL-CAD 4.4 on my PC. I am running Linux 1.2.8 on a Packard Bell with a Pentium 75 Mhz Processor and 16Mb of memory. My compiler is gcc version 2.6.3. I needed to make a few changes to get BRL-CAD compiled, here they are:

1. The makefile for cake ("cake/Makefile") calls lex to process "cake_s.l". There are some ifdefs in "cake_s.l" to account for the fact that "flex" (the GNU version of lex) does not define "yylineno". However, under this version of Linux, "lex" is defined as "flex -l". The "-l" option to "flex" tells it to be compatible with the orignal AT&T "lex". The result of all this is that the ifdefs are trying to correct for differences that aren't there. The easy fix here is to replace "lex" in the cake "Makefile" with "flex".

2. In libplot3, version 2.6.3 of gcc cannot compile plot3.c with the default O2 optimization. This has been reported to MIT as a compiler bug. The fix is to compile plot3.c with no optimization or use GCC version 2.7.2.

3. After compilation, "mged" worked fine, but "rt" complained: "db_scan ERROR: File is lacking a proper MGED database header". I'm not yet sure of the basic problem behind this, but it has to do with opening a file twice (once to get a file descriptor and once to get a FILE pointer). In "librt/db_open.c" there is a block of code :

if( !dbip->dbi_inmem && sb.st_size <= INMEM_LIM ) { dbip->dbi_inmem = rt_malloc( sb.st_size, "in-memory database" ); if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) goto fail; if(rt_g.debug&DEBUG_DB) rt_log("db_open: in-memory file\n"); }

This reads the entire database file into memory if it is small enough. Later "db_scan" rewinds the database file and looks for the "proper MGED database header" using "fread" (note that "db_open" used "read") . It appears that under Linux 1.2.8 there is some missing communication between the file descriptor and the FILE pointer. The "fread" call in "db_scan" returns "0" and "foef" returns true. This means that even though the file was just rewound, it is still at EOF. The fix for this one is to just replace

if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) in "db_open.c" with

if( fread( dbip->dbi_inmem, sb.st_size, 1, dbip->dbi_fp ) != 1 )

With this last change, "rt" now works. I ran the benchmark and got the following:

Abs 4021.12 1963.12 1752.41 1630.53 1995.19 2272.47 Thu Dec 28 01:41:28 EST 1995 *vgr 29.34 29.27 31.25 30.55 28.22 29.72

Not bad for 75 Mhz Pentium!!! (I verified a couple of the timings by hand)

---------- Forwarded message ---------- Date: Wed, 14 Feb 1996 09:22:45 -0500 (EST) From: John R. Anderson (USARL/SLAD/BVLD/VMB) <jra@arl.mil> To: "Thomas M. Browder Jr." <browder@eglin.af.mil> Cc: cad@ARL.MIL Subject: Re: Linux version of BRL-CAD (mged)

On Tue, 13 Feb 1996, Thomas M. Browder Jr. wrote:

> we have a working installation of Linux BRL-CAD, and everything seems > to be working (or at least usable) except one thing: > > in mged, the concat command finds an error with the model data base > one is trying to concatenate > > the model data base checks out ok independently, and it can be opened > with dbopen, it just cannot be merged inside the primary model > > the actual lines from a session are as follows: > > mged> concat model.g > concat: Enter prefix string or / for no prefix: / > db_read(model.g) ERROR offset=128, count=128, dbi_eof=-1 > Database read error, aborting > mged> > > Any help would be appreciated. > > Tom Browder > ASI Systems International

I suspect the problem is one I mentioned in a message I posted when I first installed BRL-CAD on my Linux system:

----------------------------- 3. After compilation, "mged" worked fine, but "rt" complained: "db_scan ERROR: File is lacking a proper MGED database header". I'm not yet sure of the basic problem behind this, but it has to do with opening a file twice (once to get a file descriptor and once to get a FILE pointer). In "librt/db_open.c" there is a block of code :

if( !dbip->dbi_inmem && sb.st_size <= INMEM_LIM ) { dbip->dbi_inmem = rt_malloc( sb.st_size, "in-memory database" ); if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) goto fail; if(rt_g.debug&DEBUG_DB) rt_log("db_open: in-memory file\n"); }

This reads the entire database file into memory if it is small enough. Later "db_scan" rewinds the database file and looks for the "proper MGED database header" using "fread" (note that "db_open" used "read") . It appears that under Linux 1.2.8 there is some missing communication between the file descriptor and the FILE pointer. The "fread" call in "db_scan" returns "0" and "foef" returns true. This means that even though the file was just rewound, it is still at EOF. The fix for this one is to just replace

if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) in "db_open.c" with

if( fread( dbip->dbi_inmem, sb.st_size, 1, dbip->dbi_fp ) != 1 ) -----------------------------

Looking at the code just now, I notice that this block of code seems to be missing a line setting the value of "dbip->dbi_eof". This could be the cause of the error. I would try adding a "dbip->dbi_eof =sb.st_size;" in the same block of code discussed above as shown:

if( !dbip->dbi_inmem && sb.st_size <= INMEM_LIM ) { dbip->dbi_inmem = rt_malloc( sb.st_size, "in-memory database" ); if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) goto fail; dbip->dbi_eof = sb.st_size; if(rt_g.debug&DEBUG_DB) rt_log("db_open: in-memory file\n"); }

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa27477; 21 Jan 97 10:32 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa00118; 21 Jan 97 9:02 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa00077; 21 Jan 97 8:44 EST Received: from localhost by wolf.arl.mil id aa20174; 21 Jan 97 8:32 EST Date: Tue, 21 Jan 1997 08:32:49 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: eorddyo@techunix.technion.ac.il cc: cad@ARL.MIL Subject: Re: xmged problems In-Reply-To: <Chameleon.4.01.970120151330.Yoav@Yoav Oreg.technion.ac.il> Message-ID: <Pine.SGI.3.95.970121081703.18109A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 20 Jan 1997 eorddyo@techunix.technion.ac.il wrote:

> Hi all, > I"ve encounterd some problems using xmged: > after building an object which is a group composed of two regions > I tried to make a mirror image of it using yjr "mirror" comand. The copy was created, I then > tried placing it in the right place but when I placed "accept edit" the object I moved jumped to > it's original location and I got a message sayin the objects could not be reploted. > I encountered this phenomenon using the "copy" comand as well. > any sugestions?

I tried this myself and couldn't duplicate this behavior. When the mirror command is applied to a group or region, it does not create a new copy of the underlying objects. Only the new object mentioned on the "mirror" command line is created. The new combination (group or region) references the same underlying objects, but uses transformation matrices to position them. If you edit the underlying objects, they will change in both the original and the copy, but the relationship between the original and the copy will stay the same. What you really want to do is to use "object edit". The first step in doing an object edit (after selecting "Object Illum" on the menu) is to pick the object you want to edit. Move the mouse vertically to highlight different solids from the objects on the screen until you find the one you want in the object you want to edit. After you click the mouse to select the object, you will be in "OBJ PATH" mode. In this mode, you move the mouse vertically to select which transformation matrix to edit. Place the "[MATRIX]" directly above the object you want to move. This will typically be the new object that you created with the mirror command.

> P.S. > there may be something wrong with my subscription since I have recieved no mail from cad@ARL.MIL > since the begining of November, please resubscribe me if nesesary and e-mail me answers directly > untill I can be sure I"m back on the general mailing list > thanks Yoav

Yes, I removed your old address from the email list after getting numerous failed mail messages. I have placed your new email address back in the "cad" list.

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa00468; 22 Jan 97 13:05 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15915; 22 Jan 97 11:08 EST Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa15903; 22 Jan 97 11:03 EST Received: from localhost by wolf.arl.mil id aa21293; 22 Jan 97 10:51 EST Date: Wed, 22 Jan 1997 10:51:00 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: "C. D. Turner" <cdturne@sass206.tpa.sandia.gov> cc: cad@ARL.MIL Subject: Re: vdeck In-Reply-To: <199701211959.MAA02441@sass193.> Message-ID: <Pine.SGI.3.95.970122104733.20989A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 21 Jan 1997, C. D. Turner wrote:

> The included file (created with brlcad 4.4) contains one region, box.r. When I > attempt to convert to gift using vdeck rev 11.1 (from brlcad 4.4) I get the > following: > > --------------------------------- > zia% ~/cad/bin/vdeck test.g > > command( ? for menu )>> insert box.r > > command( ? for menu )>> list > box.r > > command( ? for menu )>> deck > > ERROR: bad pointer x39070: s/b union tree(x91191191), was NULL(x0), file > ../librt/db_tree.c, line 908 > ---------------------------------- > > When I use the old rev of vdeck, 10.2 (from brlcad 4.0) it works fine. > Any suggestions? > > Thanks, > David Turner > SNL/A

Yes, a line needs to be added to vdeck.c near the end of the routine gettree_leaf(). The "magic" number for the curtree structure is not getting set. The existing code is:

GETUNION( curtree, tree ); curtree->tr_op = OP_SOLID; curtree->tr_a.tu_stp = stp; curtree->tr_a.tu_regionp = (struct region *)0;

return(curtree);

It should be changed to:

GETUNION( curtree, tree ); curtree->magic = RT_TREE_MAGIC; curtree->tr_op = OP_SOLID; curtree->tr_a.tu_stp = stp; curtree->tr_a.tu_regionp = (struct region *)0;

return(curtree);

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa01008; 26 Jan 97 9:44 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa10422; 26 Jan 97 9:41 EST Received: from admii.arl.mil by WALRUS.ARL.MIL id aa10395; 26 Jan 97 9:31 EST Received: from relay4.UU.NET by ADMII.ARL.MIL id aa12017; 26 Jan 97 9:09 EST Received: from news.ziplink.net by relay4.UU.NET with ESMTP (peer crosschecked as: news.ziplink.net [199.232.240.5]) id QQcaea24621; Sun, 26 Jan 1997 09:09:23 -0500 (EST) Received: (from news@localhost) by news.ziplink.net (8.7.6/8.6.12) id JAA01194; Sun, 26 Jan 1997 09:08:46 -0500 (EST) To: info-brl-cad@uunet.uu.net Path: localhost!nobody From: Craig Earls <NoSpam@my.house> Newsgroups: info.brl-cad Subject: BRL-CAD on Linux Date: 26 Jan 1997 09:01:11 -0500 Organization: MIT/US Navy Lines: 19 Message-ID: <m0lo9g4jtk.fsf@my.house> NNTP-Posting-Host: lowell-ip241.ziplink.net X-Newsreader: Gnus v5.2.25/XEmacs 19.14

Does anyone have a patch to compile BRL-CAD under a more recent release of Linux? The patch available at SUNSITE is from 1995 and appears to depend on some fairly old versions of libraries. Just wondering if anyone has already slogged through this, before I start the trudge:)

I am running Linux 2.0.28 libc 5.4.17 libg++2.7.2.1 XFree86 3.2

Thanks for any assistance

----------------------------------------------------------------- Craig P Earls cpearls@ziplink.net LT US Navy, MIT Ocean Engineering cpearls@mit.edu -----------------------------------------------------------------

Received: from walrus.arl.mil by wolf.arl.mil id aa11439; 27 Jan 97 8:16 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa18975; 27 Jan 97 8:13 EST Received: from whim.arl.mil by WALRUS.ARL.MIL id aa18856; 27 Jan 97 8:04 EST From: jehunt@ARL.MIL To: cad@ARL.MIL In-reply-to: <m0lo9g4jtk.fsf@my.house> (message from Craig Earls on 26 Jan 1997 09:01:11 -0500) Subject: Re: BRL-CAD on Linux Date: Mon, 27 Jan 97 7:57:49 EST Sender: jehunt@ARL.MIL Message-ID: <9701270757.aa22275@whim.arl.mil> Source-Info: From (or Sender) name not authenticated.

> From: Craig Earls <NoSpam@my.house> > Newsgroups: info.brl-cad > Date: 26 Jan 1997 09:01:11 -0500

> Does anyone have a patch to compile BRL-CAD under a more recent > release of Linux? The patch available at SUNSITE is from 1995 and > appears to depend on some fairly old versions of libraries. Just > wondering if anyone has already slogged through this, before I start > the trudge:)

Someone should look into getting that old patch off of sunsite. It is obsolete. The latest patch for BRLCAD 4.4 comes courtesy of John Anderson, attached.

--jim

---------- Forwarded message ---------- Date: Thu, 28 Dec 1995 12:10:13 -0500 (EST) From: John R. Anderson (USARL/SLAD/BVLD/VMB) <jra@arl.mil> To: ged@walrus.arl.mil Subject: BRL-CAD 4.4 under Linux 1.2.8

I finally got around to installing BRL-CAD 4.4 on my PC. I am running Linux 1.2.8 on a Packard Bell with a Pentium 75 Mhz Processor and 16Mb of memory. My compiler is gcc version 2.6.3. I needed to make a few changes to get BRL-CAD compiled, here they are:

1. The makefile for cake ("cake/Makefile") calls lex to process "cake_s.l". There are some ifdefs in "cake_s.l" to account for the fact that "flex" (the GNU version of lex) does not define "yylineno". However, under this version of Linux, "lex" is defined as "flex -l". The "-l" option to "flex" tells it to be compatible with the orignal AT&T "lex". The result of all this is that the ifdefs are trying to correct for differences that aren't there. The easy fix here is to replace "lex" in the cake "Makefile" with "flex".

2. In libplot3, version 2.6.3 of gcc cannot compile plot3.c with the default O2 optimization. This has been reported to MIT as a compiler bug. The fix is to compile plot3.c with no optimization or use GCC version 2.7.2.

3. After compilation, "mged" worked fine, but "rt" complained: "db_scan ERROR: File is lacking a proper MGED database header". I'm not yet sure of the basic problem behind this, but it has to do with opening a file twice (once to get a file descriptor and once to get a FILE pointer). In "librt/db_open.c" there is a block of code :

if( !dbip->dbi_inmem && sb.st_size <= INMEM_LIM ) { dbip->dbi_inmem = rt_malloc( sb.st_size, "in-memory database" ); if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) goto fail; if(rt_g.debug&DEBUG_DB) rt_log("db_open: in-memory file\n"); }

This reads the entire database file into memory if it is small enough. Later "db_scan" rewinds the database file and looks for the "proper MGED database header" using "fread" (note that "db_open" used "read") . It appears that under Linux 1.2.8 there is some missing communication between the file descriptor and the FILE pointer. The "fread" call in "db_scan" returns "0" and "foef" returns true. This means that even though the file was just rewound, it is still at EOF. The fix for this one is to just replace

if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) in "db_open.c" with

if( fread( dbip->dbi_inmem, sb.st_size, 1, dbip->dbi_fp ) != 1 )

With this last change, "rt" now works. I ran the benchmark and got the following:

Abs 4021.12 1963.12 1752.41 1630.53 1995.19 2272.47 Thu Dec 28 01:41:28 EST 1995 *vgr 29.34 29.27 31.25 30.55 28.22 29.72

Not bad for 75 Mhz Pentium!!! (I verified a couple of the timings by hand)

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

AMC says that my views do not represent an official Government position.

---------- End forwarded message ----------

Date: Fri, 7 Feb 97 11:39:29 EST From: Paul Tanenbaum <pjt@arl.mil> To: moss@arl.mil, karen@arl.mil cc: acst@arl.mil Subject: New previously existing capability Message-ID: <9702071139.aa02573@wolf.arl.mil>

Dear MUVES types, You may recall that some while ago (probably in the early stages of AGS) we discussed various ideas about component kill algorithms that might want to know which face of an object got hit--so one could treat the front of a radio differently from its bottom, say. We kicked around several solutions, including building/converting the component to NMG so you could have faces as explicitly modeled entities. We also talked about MUVES supporting yet another outboard file that would specify an orientation for each component, so an EM could look at an entry or exit normal and infer what face was involved. Well, in a discussion with Mike yesterday about improvements to our texture-map shader, I learned that BRL-CAD already makes available pretty much exactly what you need. The (struct hit) has a member of type int called hit_surfno, which encodes the surface of the solid in question. BTW, for each partition you get a pair of (struct hit)s, one each for entry and exit. There is a convention for naming the surfaces of solids of various types, for instance,

ARB8 TGC --------------------- --------------------- Surface # Face Surface # Face --------------------- --------------------- 0 1234 1 5678 1 side 2 1485 2 top cap 3 2376 3 bottom cap 4 1265 --------------------- 5 4378 ---------------------

In the case of the ARB, the modeler even has some control over which face gets assigned which surface number: some time ago I implemented a permute command in MGED that allows one to rearrange the vertex labels of an ARB. The bad news is that not all the solid types currently report surface numbers (e.g. the ARS). And of course for others, like the SPH or TOR, there is only one face. But it shouldn't be too much work for us to police up all the misbehaving solid types and teach them how to report something sensible. So if an EM wanted to be able to treat particular faces of components differently, one approach would be to support an outboard file mapping lists of ordered pairs of the form (solid_name, surfno) to component surfaces. One caution... any such EM would then have an unprecedented sensitivity to details of the .g file. For example, if you create one ARB by mirroring another, they really are mirror images, so their surface numbers will be mirror image, too. To further support this approach, I've enhanced nirt by adding two output items, surf_num_in and surf_num_out. This way somebody preparing target files for MUVES would not have to know the vagaries of the surface encoding conventions, he can just get in mged, point nirt at the spot he's interested in, and read off the required surface number(s). Paul

Received: from localhost by wolf.arl.mil id aa12237; 11 Mar 97 11:36 EST Date: Tue, 11 Mar 1997 11:36:30 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: lynch@whim.arl.mil cc: ayoung@ww2.arl.mil, scoates@wumpus.arl.mil, ~pjt@wolf.arl.mil, ~pjt@worm.arl.mil, mike@wolf.arl.mil, bparker@smokey.arl.mil, ~richsand@whale.arl.mil, ~richsand@wharf.arl.mil Subject: Useful commands in developmental version of MGED Message-ID: <Pine.SGI.3.95.970311111642.11405A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

David,

We discussed two useful utilities that I thought might be handy for your conversions and re-conversions of Pro/E models:

1. Capability to assign idents, air codes, material codes and los numbers to BRL-CAD models from a file. The developmental version of MGED has an "rcodes" command that will read just such a file and assign the codes. The format is nearly the same as the output from the "idents" command, but with the first column of "region numbers" deleted. (I don't know why the formats are not exactly the same). You could do an "idents" command on a model already converted from Pro/E (after you have invested the time to assign the codes), then edit that file to eliminate the first column (see the Unix "cut" command). The result would be useful to assign idents to the next version of the Pro/E model that comes down the pike. Note that the names of regions would have to be the same between the two models.

2. Capability to create a "trail" file that could be fed to MGED to re-do all the commands that were performed in an earlier session. There is a "journal" command in the developmental version of MGED that stores your keyboard commands in an ascii file. This script can later be fed to MGED to run the same commands again. Not all commands end up in the "journal" file. Solid and object editing and mouse/knob/button commands are not included. And I'm sure that commands requiring user interaction (like "edcodes", "red", or "ted") will also not be in the "journal" file. However, commands, like "r" commands that you would use to correct overlaps, would be in the file and could then be run on another file.

These capabilities exist only in the developmental version, but will be in the next release. I suspect we can arrange something if you think these capabilities are needed for the Crusader project.

-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

AMC says that my views do not represent an official Government position.

Received: from localhost by wolf.arl.mil id aa26879; 11 Mar 97 16:56 EST Date: Tue, 11 Mar 1997 16:56:29 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: acst@wolf.arl.mil Subject: New 'E' command in MGED Message-ID: <Pine.SGI.3.95.970311164433.26321A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

I have re-written the 'E' command in MGED using the algorithm I sent out last week. I modified the algorithm slightly in the process. Originally, I intended to do it all with NMG's, but this was much too slow. I ended up alowing an option to the 'E' command.

With no options, it does it the fastest way, by using the NMG edges to plot the solids and intersecting the face planes to get the solid intersection lines, but shooting rays at the original solids. This is about as fast as the old 'E' command (I believe), but since the NMG edge/faces don't exactly match the real solid (in curved surfaces), edges often don't quite match up. In most cases, this is not a problem.

When an option is supplied (actually ANY option, but the command syntax says '-s'), a polysolid version of the solid is used for the raytracing so that the edges and faces agree exactly with the NMG version, so edges match. This is still very much faster than than my original attempt using NMG's all the way, but considerably slower than with no options.

This nearly completes the conversion of MGED to a database format independent code. There are still a few references to db.h MACROS, and the code to handle the color tables (based on ident numbers) still uses 'union record'. But that's all, I believe.

-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

AMC says that my views do not represent an official Government position.

Received: from localhost by wolf.arl.mil id aa11926; 15 Apr 97 13:29 EDT Date: Tue, 15 Apr 1997 13:29:15 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: Bob Strausser <bobs@survice.com> cc: acst@wolf.arl.mil Subject: Re: NASTRAN to BRL-CAD In-Reply-To: <33539F86.C5B@survice.com> Message-ID: <Pine.SGI.3.95.970415125048.10124A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 15 Apr 1997, Bob Strausser wrote:

> Good morning John, > > I spoke with Ron Dexter today (apparently my email didn't get to him > about the PSHELL record). Based on the "real" -60B NASTRAN file, Ron > guesses that the PSHELL record could be considered as a plate mode > indicator. It only exists (in the -60B) for skin elements and all > occurrences have a thickness assigned. Hes not sure that a zero > thickness would actually be valid in a true NASTRAN file even though > CATIA outputs a meshed NASTRAN file with a zero thickness entry (the > sample files).

Sounds reasonable to me. Perhaps CATIA is doing just a "surface" mesh as opposed to a "solid" mesh.

> He will be sending copies of the latest sample files hes been working > with and some excerpts from the -60B NASTRAN file. I'll pass them along > when they come in.

Great, I'll be looking forward to seeing them.

> The CATIA meshed outputs are still CTRIA3 elements > but I've asked for some other element types from the -60B file. Based > on our initial conversion samples, Ron has several questions concerning > the NASTRAN conversion you're working: > > 1. What is ARL planning / doing concerning the file sizes (NMG and > polysolid) which are unacceptably large (not practical for working > with)? He converted a control rod and had a BRL-CAD file (polysolids) > that was over 225Kb. He's noticed that CATIA handles its large file > sizes fairly well (response times) but BRL-CAD tends to bog down (on the > same hardware) when its file sizes get to be large (>15 Mb).

Both the NMG and the polysolid are very sensitive to tessellation tolerances. It is very easy to create an outrageously large NMG or polysolid file from a simple curved surface primitive, just by selecting a very small tolerance. The polysolid is more compact than the NMG solid, just a list of polygons. If the files come from CATIA, then CATIA is creating the polygons.

We are investigating the possibility of using some compression methods which could be applied to these situations, but that will definitely not be in the next release.

My experience has been that MGED will bog down when you try to display too much geometry, but otherwise runs fairly nicely even with very large databases. The two important memory users in MGED are the display list and the directory of objects. You can have a database containing only a single object that creates millions of vectors in the display list when displayed. You may also have a database that contains millions of objects that create no vectors in the display list when edited. The large display list can potentially slow down the graphics. The large number of objects in the database can potentially slow down everything. When I have seen this behavior it was due to excessive swapping (not enough memory on the system). We have been looking at a new database format for BRL-CAD, perhaps a more compact form for NMG's and/or polysolids could be considered.

> 2. How does ARL plan to handle the non-geometry data in the NASTRAN > file, given that NASTRAN (as used at Sikorsky) models load paths not > necessarily physical geometry? Will the converter be caveated like the > IGES / AutoCad converters that only XX portions are processed?

Currently, the plan is to ignore non-geometry. However, we might use material ID nunbers from NASTRAN somehow in assigning materials in BRL-CAD.

> 3. Who is ARLs sponsor for the NASTRAN conversion / what are they > expecting to get out of the NASTRAN file conversion (ties in with the > non-geometry data aspects)? Ron is wondering if Sikorsky uses NASTRAN > differently from other companies - is Sikorsky the only company whose > NASTRAN files don't "match the physical geometry" of the vehicle (for > anything but portions of the structure / skin). If this is an in-house > effort, Ron may be willing to support with limited file samples.

This is an entirely in-house effort. Our FASTGEN competitors have been touting their capability to convert NASTRAN to FASTGEN as a reason why they don't want to use BRL-CAD, so we are attempting to quiet that excuse. I am certainly not a NASTRAN expert, but from what I have read, it is fairly common for the NASTRAN geometry not to match the physical geometry. I would appreciate any sample NASTRAN files that I could get my hands on.

-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

AMC says that my views do not represent an official Government position.

Received: from localhost by wolf.arl.mil id aa13728; 30 May 97 11:45 EDT Date: Fri, 30 May 1997 11:45:50 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: Federico Carminati <Federico.Carminati@eet.cern.ch> cc: acst@wolf.arl.mil Subject: Re: X-Window interface In-Reply-To: <n1347110523.8812@EET.CERN.CH> Message-ID: <Pine.SGI.3.95.970530114401.12696A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On 30 May 1997, Federico Carminati wrote:

> Reply to: X-Window interface > > Good Morning, > one remark on the X-window interface. As you know is very slow, but it can > be made several times faster changing the line width from 1 to 0. Width 0 > means the hardware default, which is 1 pixel, but much faster (for some > reason!). All you have to do is to change the third argument of > XsetLineAttributes in dm-X.c in mged anx xmged. Regards, Carminati > >

Thanks!!! We tried your suggestion an it does make a significant improvement. That change will be in the next release.

Thanks again, -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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa10390; 30 May 97 10:13 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa25519; 30 May 97 8:45 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa25477; 30 May 97 8:35 EDT Received: from localhost by wolf.arl.mil id aa06018; 30 May 97 8:32 EDT Date: Fri, 30 May 1997 08:32:35 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: Federico Carminati <Federico.Carminati@eet.cern.ch> cc: ged@walrus.arl.mil Subject: Re: BUG in BRL? In-Reply-To: <n1347290506.81631@EET.CERN.CH> Message-ID: <Pine.SGI.3.95.970530081504.5189B-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On 28 May 1997, Federico Carminati wrote:

> Reply to: RE>>BUG in BRL? > > Good morning, > thank you for your quick answer. In fact I was not sure, so I continued > investigating in the problem. Now I do have the right answers, but I still do > not understand why. I have a box with a hole, and in the hole a cylinder which > fills it completely. I have constructed it with the following input: > > killall * > press reset > title TARC Lead Block > units m > in block.s box -0.075 -0.075 -0.075 0.15 0 0 0 0.15 0 0 0 0.15 > in hollow.s rcc 0 0 -0.080 0 0 0.160 0.032 > in hole.s rcc 0 0 -0.075 0 0 0.150 0.032 > regdef 1 > r block.r + block.s - hollow.s > r hole.r + hole.s > g block.g block.r hole.r > size 0.5 > B block.g > > Then I wrote a very simple application which, given a ray (inside the model!) > returns the distance to the first (i.e. closest) hit. And I set onehit=1. What > happens then is that all rays starting in the quadrant x>-0.032 y>-0.032 > intersect the cylinder correctly, while all the other do not see it and go > directly to the border of the box. > If I set onehit=2, I still have one only hit in the hit routine, and I can > tell because p->part_forw->part_forw == p, but this time it is the right one! > The fact is that I want only the first hit, so I thought that onehit should be > one. So now it works but I do not see why. Regards and thank you again for > your help. Carminati

It looks like you are confusing ``partitions'' withs ``hits''. Each ``partition'' structure has pointers to two ``hits''. A ``hit'' is an intersection between the ray and an object surface. A ``partition'' is a length of the ray that is entirely within an object. The ``partition'' extends from an entrance ``hit'' (pt_inhit) to an exit ``hit'' (pt_outhit).

The ``onehit'' flag sets the desired number of ``hits''. If ``onehit'' is set to one, then only the first ``pt_inhit'' is valid.

Another consideration is that if you fire a ray from within a solid object, then the ray will also be traced backward to find the ``pt_inhit'' point, as well as forward to find the ``pt_outhit''. Note that, in this case, the ``hit_dist'' for the ``pt_inhit'' will be less than zero. However, if ``onehit'' is one, only the ``pt_inhit'' will be valid.

If you set ``onehit'' to two, you should only get one ``partition'' (which is two hits), and both hits will be valid.

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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa05898; 13 Jun 97 17:15 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa00891; 13 Jun 97 16:06 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa00857; 13 Jun 97 15:57 EDT Received: from localhost by wolf.arl.mil id aa02539; 13 Jun 97 15:54 EDT Date: Fri, 13 Jun 1997 15:54:04 -0400 (EDT) From: "Lee A. Butler" <butler@ARL.MIL> To: gdpayne@dra.hmg.gb cc: cad@ARL.MIL Subject: Re: BRLCAD r5 In-Reply-To: <9706130855.aa13035@wharf.arl.mil> Message-ID: <Pine.SGI.3.95.970613154638.2138A-100000@wolf.arl.mil> X-URL: http://ftp.arl.mil/~butler/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 13 Jun 1997 gdpayne@dra.hmg.gb wrote:

> Now that it looks like BRLCAD release 5 is coming over the horizon, > is it possible to get a copy of the expected feature list for the new > version ?

The most significant changes that you will notice are: completeley new mged (better than xmged) based upon Tcl/Tk no xmged OpenGL support for both framebuffer and mged. greatly improved booleans of NMG's new converters VRML - can convert from BRL-CAD to VRML only This conforms to VRML 1.0.

ACAD - can convert from BRL-CAD to ACAD only The ACAD format used is entirely triangular facets.

Laser scan - can convert from laser scan data to BRL-CAD only This code is currently limited to Cyberware Digitizer Data in cylindrical scan format and is limited to simple shapes only.

Wavefront - can export polygons in Wavfront .obj format

new shaders camo cammoflage air/fog (homogenous mist) noise (fBm/turbulence effects on color/surface_normal) cloud Noise-based "solid cloud" shader fire reminicient of brush-fire type flames

librt extensively reorganized new utility and numerical handling libraries (broken out from librt)

> We are particularly interested in the BRLCAD to polygon convertor > which was expected to form part of the new release. How well does > this work ?

It's still not foolproof. But it does a better job now.

> Are we likely to see online / downloadable manuals for the new > version? Online manuals for the old version seemed to wither away > after the first few elements were completed.

There is a fair bit of documentation that has been written for the new release. Especially on the new mged. We are doing what we can to extend and improve the documentation. It will be available online, and as a part of the distribution. Summary: The documentation will be better, but it still won't be ... what I wish it was.

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

As nightfall does not come at once, neither does oppression. In both instances, there is a twilight when everything remains seemingly unchanged. And it is in such twilight that we all must be most aware of change in the air--however slight--lest we become unwitting victims of the darkness. --- Justice William O. Douglas

Received: from walrus.arl.mil by wolf.arl.mil id aa21381; 23 Jun 97 21:31 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15194; 23 Jun 97 20:54 EDT Received: from wharf.arl.mil by WALRUS.ARL.MIL id aa15169; 23 Jun 97 20:49 EDT Received: from trantor.dso.org.sg by wharf.arl.mil id aa12887; 23 Jun 97 20:49 EDT Received: from demerzel.dso.org.sg (demerzel.dso.org.sg [192.190.204.8]) by trantor.dso.org.sg (8.8.5/8.8.5) with ESMTP id IAA20207 for <cad@arl.mil>; Tue, 24 Jun 1997 08:57:09 +0800 (SST) Received: (from cmeiteng@localhost) by demerzel.dso.org.sg (8.8.5/8.8.5) id IAA21160 for cad@arl.mil; Tue, 24 Jun 1997 08:49:22 +0800 (SGT) From: Cheong Mei Teng <cmeiteng@dso.org.sg> Message-Id: <199706240049.IAA21160@demerzel.dso.org.sg> Subject: BRL-CAD questions To: cad@ARL.MIL Date: Tue, 24 Jun 1997 08:49:22 +0800 (SGT) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit

I am currently using BRL-CAD Ver 4.0 and AutoCad Release 12. My intention is to use AutoCad to generate either an IGES-file or DXF-file, and ask BRL-CAD to read it as a G-file. I have problems in both cases. 1. I exported a 3-D drawing into an IGES-file from AutoCad 12.The drawing does not contain any solids, everything is in terms of lines and mesh. Then i used iges-g -o file.g file.igs the program ran, but it gave me a flattened 2-D drawing in mged. it appears that the 3rd dimension is not being taken care of. i tried it with other flags, but to no avail. the help file for iges-g indicates that the program recognises only the IGES 5.1. i think AutoCad 12's IGES is not 5.1. what do you think is the problem here? is it the IGES version which is the culprit? do you know of any CAD drawers whose IGES is compatible with BRL-CAD? 2. I repeated the same procedure with a DXF-file from AutoCad 12. the help did indicate that the dxf-g works for Autodesk greater than 10 (i think). i tried dxf-g -i file.dxf -o file.g and an error indicates that an unexpected EOF is detected in input file. i removed the EOF line in the input file, still the same error. i tried dxf-g <file.dxf> file.g the program ran, but an empty G-file was created, in a sense, no drawing was shown in mged. what do you think is the problem here? is it a version thing again? if it is, do you know of any CAD drawers which will work with their dxf files?

Thank You ! >

Received: from walrus.arl.mil by wolf.arl.mil id aa15802; 24 Jun 97 8:26 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa19600; 24 Jun 97 8:25 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa19477; 24 Jun 97 8:14 EDT Received: from localhost by wolf.arl.mil id aa15058; 24 Jun 97 8:09 EDT Date: Tue, 24 Jun 1997 08:09:15 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: Cheong Mei Teng <cmeiteng@dso.org.sg> cc: cad@ARL.MIL Subject: Re: BRL-CAD questions In-Reply-To: <199706240049.IAA21160@demerzel.dso.org.sg> Message-ID: <Pine.SGI.3.95.970624080201.14561A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 24 Jun 1997, Cheong Mei Teng wrote:

> I am currently using BRL-CAD Ver 4.0 and AutoCad Release 12. > My intention is to use AutoCad to generate either an IGES-file or DXF-file, > and ask BRL-CAD to read it as a G-file. I have problems in both cases. > > 1. I exported a 3-D drawing into an IGES-file from AutoCad 12.The drawing > does not contain any solids, everything is in terms of lines and mesh. Then > i used > iges-g -o file.g file.igs > the program ran, but it gave me a flattened 2-D drawing in mged. it appears > that the 3rd dimension is not being taken care of. i tried it with other > flags, but to no avail. the help file for iges-g indicates that the program > recognises only the IGES 5.1. i think AutoCad 12's IGES is not 5.1. > what do you think is the problem here? is it the IGES version which is the > culprit? do you know of any CAD drawers whose IGES is compatible with BRL-CAD?

This is the correct result. When AutoCad exports a drawing to IGES, it flattens it.

> 2. I repeated the same procedure with a DXF-file from AutoCad 12. the help > did indicate that the dxf-g works for Autodesk greater than 10 (i think). i > tried > dxf-g -i file.dxf -o file.g > and an error indicates that an unexpected EOF is detected in input file. i > removed the EOF line in the input file, still the same error. i tried > dxf-g <file.dxf> file.g > the program ran, but an empty G-file was created, in a sense, no drawing was > shown in mged. > what do you think is the problem here? is it a version thing again? if it > is, do you know of any CAD drawers which will work with their dxf files?

Our DXF to BRL-CAD converter only considers 3DFACES and 3DMESH objects in the DXF file. A drawing (2D or 3D) will not have either of these.

BRL-CAD is solid modeling system with very little support for "drawings". Generally, all objects in a BRL-CAD model are solids. You might try creating a solid model in AutoCad and converting that to BRL-CAD via either DXF or IGES.

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa14639; 23 Jul 97 10:27 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa01613; 23 Jul 97 9:44 EDT Received: from admii.arl.mil by WALRUS.ARL.MIL id aa01555; 23 Jul 97 9:37 EDT Received: from survice.com by ADMII.ARL.MIL id aa12363; 23 Jul 97 9:11 EDT Received: from 206.181.114.201 by server.survice.com via SMTP (940816.SGI.8.6.9/940406.SGI) id JAA09027; Wed, 23 Jul 1997 09:14:57 -0400 Message-ID: <33D6037C.5A59@survice.com> Date: Wed, 23 Jul 1997 09:13:44 -0400 From: Bob Strausser <bobs@survice.com> Organization: The SURVICE Engineering Co. / SURVIAC ASO X-Mailer: Mozilla 3.01 (Macintosh; I; PPC) MIME-Version: 1.0 To: frost <jlseagul@world-net.net> CC: cad@ARL.MIL Subject: Re: brlcad-startup/display References: <199707230211.VAA22387@ns1.world-net.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit

on 22 Jul 1997, frost wrote: > When I startup brlcad's mged I use for an example:

> cd /usr/brlcad/db # this puts me in the sample dir. > mged cube.g # to start the editor using cube.g > attach (nu|tek|tek4109|ps|plot|X|)[nu] # what it asks me > X # my answer (I think this uses the "X" display) > Xdisplay [:0.0]? # what it asks me > "enter" # I hit enter in responce

> At this point the editor pulls up, but all that can be seen is a dot > in the center of the screen. I've tried zooming in using the slide > bar, but this seems to do nothing. Is this normal, is there > something I not doing, Is there something I need to check.

Yes that is normal behavior.

What you have accomplished at this point is opening a geometry database and attaching a graphic display window.

The program is now waiting for you to tell it what to do. You have a text window to type commands into and a graphic window for wireframe displays and mouse commands. The white dot (in the graphic display) is the location of the 'center' of the 'camera - eyepoint' focus. Its X/Y/Z coordinate value in three dimensional space should be listed in the lower left corner of the graphical display.

You can list the commands by typing "?" (no quote symbols) and pressing return. Typing "help" and pressing return includes the usage syntax for the commands (scrolling your window). Typing "help command" (replace command with one of the commands from the list) will echo to the text window the usage syntax for just that command.

Since you opened an existing geometry database, you should type "tops" and press return. This will list all of the database objects which are on the top level (not members in a group or region). For the cube.g file the top level objects are:

all.g/ cloud.r.bak/R light.r/R

where all.g is a group of regions and groups, cloud.r.bak is a region containing solids, and light.r is a region (with a single solid) which has been defined as a light source (internal to the geometry as opposed to the default 'camera - eyepoint' light sources).

Typing "e all.g"<return> will display the object all.g on the graphic display window as a wireframe representation of all the solids at the root of the all.g heirarchical tree. This is identified as 'viewing' mode. You can use the mouse in the graphic window or commands typed in the text window to change the viewing angle, size, and location.

Solid edit mode will permit you to change the individual coordinate parameters which define a solid object - its individual length, width, height, radius, location in space, and orientation.

Object edit mode will permit you to change a collection of region and group objects with regard to their location, orientation, and overall size in space. The solids which are the defining root of the regions and groups still retain the same (original) coordinate data defined in their respective individual solid edit mode sessions. Object edit changes may be pushed to the root solids (changing the solids' coordinate data) if there are no conflicts. A conflict occurs when a solid is used in multiple regions and the regions (or groups containing those regions) have been object edited to different locations/orientations/scales.

Bob Strausser SURVIAC Aberdeen Satellite Office

Received: from walrus.arl.mil by wolf.arl.mil id aa29474; 23 Jul 97 16:19 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa06125; 23 Jul 97 15:26 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa06091; 23 Jul 97 15:16 EDT Received: from wolf.arl.mil by wolf.arl.mil id aa26653; 23 Jul 97 15:12 EDT Date: Wed, 23 Jul 1997 15:12:02 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: RDexter@zoomit.sikorsky.com cc: cad@ARL.MIL Subject: Re: How to quickly remove edcodes assigned data In-Reply-To: <0000bdbxfhjf.0000amyywkio@zoomit.sikorsky.com> Message-ID: <Pine.SGI.3.95.970723150808.26169A-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On 23 Jul 1997 RDexter@zoomit.sikorsky.com wrote:

> Is there a quick way to remove all of the edcode assigned > colors, materials, etc. from within a model database to > "clean-up" a description? > > Thanks in advance. > > >> Ron Dexter > Survivability & Low Observables > Sikorsky Aircraft Corporation > PH: (203) 386-7922 FX: (203) 386-5925 > EM: rdexter@sikorsky.com > > >

Ron,

The easiest way I know of (using the distributed MGED) is to use the "idents" command to get the current data in a file, then edit that file into a list of "edcomb" commands to accomplish whatever you want with the edcodes info. Then use execute MGED using that file for redirected input.

By the way, "edcodes" does not set the color, just ident, air code, GIFT material code, and LOS.

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa11052; 12 Sep 97 9:55 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa03997; 12 Sep 97 8:45 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa03941; 12 Sep 97 8:36 EDT Received: from wolf.arl.mil by wolf.arl.mil id aa07320; 12 Sep 97 8:24 EDT Date: Fri, 12 Sep 1997 08:24:03 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: Tom Browder <tbrowde@asi-fwb.com> cc: cad@ARL.MIL Subject: Re: Cake and gen.sh In-Reply-To: <Pine.LNX.3.95.970911141746.4580A-100000@tomtom.asi-fwb.com> Message-ID: <Pine.SGI.3.95.970912081956.6540B-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 11 Sep 1997, Tom Browder wrote:

> Is there any easy way to get the BIG > compilation process to HALT at the first > compile error? > > Thanks. > > Tom Browder > > > >

In the file "gen.sh" at about line #297, you will find the section of the script which drives the "BIG" compilation ("cake all"). You might try changing "cake -k" to "cake -a". The "-k" option says "don't abort" while the "-a" option says "abort the whole run if cake sees an action return with a nonzero status".

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by wolf.arl.mil id aa25548; 2 Oct 97 18:59 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa18244; 2 Oct 97 17:34 EDT Received: from wolf.arl.mil by WALRUS.ARL.MIL id aa18206; 2 Oct 97 17:24 EDT Received: from wolf.arl.mil by wolf.arl.mil id aa21639; 2 Oct 97 17:22 EDT Date: Thu, 2 Oct 1997 17:22:11 -0400 (EDT) From: "Lee A. Butler" <butler@ARL.MIL> To: Tom Browder <tbrowde@asi-fwb.com> cc: cad@ARL.MIL Subject: Re: mged and inmem data base In-Reply-To: <Pine.LNX.3.95.970930132822.5103A-100000@tomtom.asi-fwb.com> Message-ID: <Pine.SGI.3.95.971002161003.18673A-100000@wolf.arl.mil> X-URL: http://ftp.arl.mil/~butler/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 30 Sep 1997, Tom Browder wrote: > We are working on larger and larger models, and > see slower and slower results during typical > mged operations such as 'tops', 'e', etc. > We are using PC Linux and SGI IRIX hosts and the > behavior is seen on both. > It sounds as if mged goes to the disk for > each mged data base command, even if nothing > is changed. The question is, is this behavior > correct?

This is correct. The original design goals for MGED included that the database file should always be in a stable state. All actions on the database are as atomic as we could make them. Thus if the machine went down in the middle of an edit, you would loose very little.

Modern practice for editors (text and otherwise) tends to emphasize speed at the cost of reliability. As a result the tendecy is to read the whole file into memory, operate on it, and only write to disk under direct user guidance. This has limitations in terms of the size and complexity of the database to be edited.

Both approaches have drawbacks.

Realize that the "tops" command has to process each item in the database. Ergo, the larger the database, the longer tops will take. As for "e", that should only slow down when the number of objects you are displaying goes up. If you "e" up 1000 solids, it's going to take longer than if you "e" up 10.

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

As nightfall does not come at once, neither does oppression. In both instances, there is a twilight when everything remains seemingly unchanged. And it is in such twilight that we all must be most aware of change in the air--however slight--lest we become unwitting victims of the darkness. --- Justice William O. Douglas

Date: Tue, 23 Dec 97 4:05:01 EST From: Mike Muuss <mike@arl.mil> To: ACST@arl.mil cc: CJohnson@netgsi.com Subject: bn_mat_ck() Message-ID: <9712230405.aa04509@vm.arl.mil>

There is a new LIBBN routine called bn_mat_ck() which can be used to ensure that a rotation matrix preserves axis perpendicularity and doesn't have a scale factor of zero. Handy when your matricies are getting corrupted and you aren't sure where it's happening.

Best, -Mike

Received: from vapor.arl.mil by wolf.arl.mil id aa13640; 23 Dec 97 5:12 EST Date: Tue, 23 Dec 97 5:05:42 EST From: Mike Muuss <mike@ARL.MIL> To: ACST@ARL.MIL cc: lorenzo@nvl.army.mil, russ@nvl.army.mil, mbaldwin@nvl.army.mil, dflorek@nvl.army.mil, dtidrow@nvl.army.mil, CJohnson@netgsi.com Subject: mged displaylist updating Message-ID: <9712230505.aa15453@VJ.ARL.MIL>

This evening, after a tremendous amount of infrastructure work in librt/db_tree.c, I've finally been able to fix on the bug in MGED, whereby adjusting the color of a region and giving the "redraw_vlist" command gets the color updated on the screen.

Also, if I "B" or "e" the object after changing it, the screen shows the new color.

Here is an example of how to reproduce it:

19 vj> ./mged -n ../.db.6d/moss.g BRL-CAD Release 4.5 Graphics Editor (MGED) Tue Dec 23 04:40:51 EST 1997, Compilation 6633 mike@vapor.arl.mil:/m/cad/.mged.6d

Gary Moss's "World on a Platter" (units=mm) attach (nu|X|ogl|glx)[nu]? glx mged> e light.r 51 vectors in 0.001403 sec mged> .inmem adjust light.r rgb {0 255 0} mged> redraw_vlist light.r light.r/LIGHT

The light sphere turns green. Yay!

This also means that the "sun" turns yellow in the MGED window in "dynamic geometry" demo, just like it does in the ray-traced view. A very important bit of progress, as much will be built on this.

Best, -Mike

Received: from vapor.arl.mil by wolf.arl.mil id aa06743; 6 Jan 98 23:28 EST Date: Tue, 6 Jan 98 23:18:48 EST From: Mike Muuss <mike@ARL.MIL> To: ACST@ARL.MIL Subject: mged "shader" cmd changed Message-ID: <9801062318.aa11605@VJ.ARL.MIL>

>> Modified "shader" command so that it returns current shader if >> a new material string isn't given. >> Even on a read-only database.

Probably a number of other commands ought to work like that too, to make them more useful in building Tcl scripts.

Best, -Mike

Received: from wolf.arl.mil by wolf.arl.mil id aa28831; 16 Jan 98 15:49 EST Date: Fri, 16 Jan 1998 15:49:42 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: ~jill@slad.arl.mil, ~jill@wharf.arl.mil, Jill_Smith@mail.arl.mil cc: acst@wolf.arl.mil Subject: Slow BRL-CAD Raytracing Message-ID: <Pine.SGI.3.95.980116152819.27969B-100000@wolf.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

Jill,

Mark Burdeshaw (now of ARA) asked me to stop by to discuss the problem that some SURVICE people were having with BRL-CAD raytracing (someone claimed BRL-CAD was ~400 times slower than FASTGEN, I believe).

SURVICE is developing a sort of "seeker" model for AJEM (funded by JTCG). They are using a FASTGEN model (converted to BRL-CAD) as the target being seeked. The seeker model uses librt raytracing to simulate whatever the real seeking technique is, so many rays are fired in the direction of the target. It turns out that when the target was converted from FASTGEN (using patch-g), it was converted into NMG solids. Remember that we are talking release 4.4 here, NMG raytracing was still experimental and extremely slow. It was easy to spot this problem (their profile listing showed "rt_isect_faceuse" as a big time consumer). I suggested that they re-convert the FASTGEN model using the "-p" option to patch-g (this creates polysolids rather than NMG solids). Just using polysolids instead of NMG solids should improve their raytracing performance immensely.

I should point out that the documentation for patch-g does not mention the "-p" option (an oversight on my part). In the next release(?), patch-g will produce polysolids by default, and the user will be required to provide an option to get NMG solids.

-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

AMC says that my views do not represent an official Government position.

Received: from vapor.arl.mil by wolf.arl.mil id aa11775; 22 Jan 98 21:12 EST Date: Thu, 22 Jan 98 21:11:20 EST From: Mike Muuss <mike@ARL.MIL> To: ACST@ARL.MIL Subject: rt -j flag Message-ID: <9801222111.aa01537@VJ.ARL.MIL>

This afternoon John and I implemented the -j flag to RT, allowing the specification of a sub-rectangle within screen space to be specified. Ray-tracing is limited to those pixels within the sub-rectangle.

This support was needed so that Bob could implement the "sweep out a rectangle for ray-tracing" capability in MGED.

Dynamic scanline buffering and full load-balanced parallel support are working. Incremental mode (-i) isn't working yet.

Man page has been updated.

Best, -Mike

Date: Tue, 27 Jan 98 22:15:31 EST From: Mike Muuss <mike@arl.mil> To: John R. Anderson <jra@arl.mil> cc: Mark Becker <mbecker@sunmil1.uml.edu>, pjt@arl.mil, mike@arl.mil Subject: Re: mged.ps in reverse order? Message-ID: <9801272215.aa21481@wolf.arl.mil>

Mark wrote -

> Umm... mged.ps was generated with some kind of reverse-page option > such the first printed page is the last page of the document.

Yes, it was intended to be that way. Something to do with the way that Bill's Apple LaserWriter handled the paper.

On some printers, you can flip down a door to have the pages stacked in the other order.

> Do you have the TeX (or LaTeX) source for mged.ps available on-line? > I'd like to generate the .ps file for double-sided printing and > correct ordering.

Sure, the TeX version is a standard part of the distribution, as a SHAR archive in doc/mged.tr, feel free to print from that instead.

The whole reason I provided the .ps file was because some folks were having difficulty printing the TeX files on a modern version of TeX.

Best, -Mike

Received: from walrus.arl.mil by wolf.arl.mil id aa24950; 17 Mar 98 8:30 EST Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa26800; 17 Mar 98 8:19 EST Received: from worm.arl.mil by WALRUS.ARL.MIL id aa26771; 17 Mar 98 8:16 EST Received: from worm.arl.mil by WORM.ARL.MIL id aa04745; 17 Mar 98 8:14 EST Date: Tue, 17 Mar 1998 08:14:22 -0500 (EST) From: "Gary S. Moss (BVLD/VMB) <moss>" <moss@ARL.MIL> To: cad@ARL.MIL Subject: Re: lgt and pixfile size In-Reply-To: <9803061452.aa14708@WUMPUS.ARL.MIL> Message-ID: <Pine.SGI.3.95.980317080341.4558A-100000@worm.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

Carl,

Sorry to take so long to respond, but as you surmise, LGT assumes a square frame buffer. This is a throwback from it's origin using square standalone frame buffers rather than workstations with built-in graphics. Except for very minor porting to new OS releases, LGT has undergone virtually no change in 10 years or more and it shows.

-Gary

On Fri, 6 Mar 1998, Carl Moore wrote:

> I used a script which ran lgt and made an outline drawing in black which > was put onto a white background in a .pix file. There is a slight incon- > venience, since I usually work with full-screen .pix files: the .pix file > from said lgt run was 1024 x 1024. The workaround to get it into a full- > screen (1280 x 1024) size file is to bring the 1024 x 1024 .pix file into > my frame buffer, then run fb-pix with the 1280 x 1024 size selected in its > parameters. > > Did I miss something or did I see that lgt could only create square (i.e. > same number of pixels horizontal & vertical) .pix files? >

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Gary S. Moss email: moss@arl.mil _/ _/ Computer Scientist WWW: http://web.arl.mil/~moss _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Received: from vapor.arl.mil by wolf.arl.mil id aa28682; 26 Mar 98 23:15 EST Date: Thu, 26 Mar 98 23:07:44 EST From: Mike Muuss <mike@ARL.MIL> To: acst@ARL.MIL cc: Kermit@ARL.MIL, Keith@ARL.MIL, Phil@ARL.MIL Subject: rfbd dropped, guts moved to LIBFB Message-ID: <9803262307.aa16316@VJ.ARL.MIL>

This evening I decided to eliminate the RFBD program; nobody uses it any more, it's been replaced by FBSERV.

I've also moved the guts (event handlers) of FBSERV to libfb/server.c. I was going to try and get MGED to use the LIBFB routines, but couldn't because of the way Bob had to #define the fbp variable to make it part of the current dm context. Oh well, was worth a try.

Best, -Mike

Received: from wolf.arl.mil by CAD.ARL.MIL id aa08874; 15 Apr 98 1:28 EDT Received: from vapor.arl.mil by wolf.arl.mil id aa22823; 15 Apr 98 1:20 EDT Date: Wed, 15 Apr 98 1:18:55 EDT From: Mike Muuss <mike@arl.mil> To: Lamas@arl.mil Subject: bu_parallel() got extra arg Message-ID: <9804150118.aa04962@VJ.ARL.MIL>

This evening I modified the calling sequence to libbu/bu_parallel() so that threads are started with one additional parameter, a caller-supplied genptr_t, which can be used to pass in a private state structure.

This allowed me to eliminate some ugly use of global state variables in db_tree.c and cut.c, and allowed me to make db_walk_tree() fully recursive even in parallel mode, which is something that Lee and I have been wanting for a long time, and I need to have now to hit one of my TAPES bullets. :-)

If you encounter something I didn't convert, the extra arg may safely be provided as NULL.

Best, -Mike

Received: from walrus.arl.mil by CAD.ARL.MIL id aa06460; 21 May 98 15:53 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id ab01990; 21 May 98 15:45 EDT Received: from admii.arl.mil by WALRUS.ARL.MIL id aa01935; 21 May 98 15:42 EDT Received: from sunmil2.uml.edu by ADMII.ARL.MIL id aa19766; 21 May 98 15:29 EDT Received: (from mbecker@localhost) by sunmil2.uml.edu (8.8.8/8.8.8) id PAA13296; Thu, 21 May 1998 15:29:58 -0400 (EDT) Date: Thu, 21 May 1998 15:29:58 -0400 (EDT) Message-Id: <199805211929.PAA13296@sunmil2.uml.edu> From: Mark Becker <mbecker@sunmil2.uml.edu> To: CAD@ARL.MIL Subject: AutoCAD and BRL-CAD Reply-to: mbecker@sunmil2.uml.edu

Hello * -

For the past couple of weeks I've been trying to find a combination of AutoCAD and BRL-CAD tools to permit the exchange of images between the two systems.

My test drawing (in the AutoCAD world) is of a cube with a small rectangular cavity in one side. My most recent success has been in setting AutoCAD to output the drawing in "B-REP solid with analytical surfaces" and using iges-g to translate to BRL-CAD g-format.

This works.. partway. In an attempt to raytrace the object, 'rt' runs for a while, emits a message "This better be a 2-manifold surface" and dumps core (Platform: UltraSparc 2 with Solaris 2.5.1, running BRLCAD 4.5).

The same behaviour occurs when dealing with a "B-REP solid with NURB surfaces."

Another curiousity is that modelling the cube-with-cavity in BRLCAD shows the cavity with dotted-lines (indicating a subtraction?) but modelling the AutoCAD-modelled cube-with-cavity has solid cavity lines.

Suggestions?

Your time is appreciated.

Regards,

Mark

Received: from walrus.arl.mil by CAD.ARL.MIL id aa04004; 2 Jun 98 18:59 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa23132; 2 Jun 98 18:04 EDT Received: from cad.arl.mil by WALRUS.ARL.MIL id aa23079; 2 Jun 98 17:54 EDT Received: from cad.arl.mil by CAD.ARL.MIL id aa25168; 2 Jun 98 17:17 EDT Date: Tue, 2 Jun 1998 17:17:29 -0400 (EDT) From: "Lee A. Butler" <butler@ARL.MIL> To: Mark Becker <mbecker@sunmil2.uml.edu> cc: CAD@ARL.MIL Subject: Re: AutoCAD and BRL-CAD In-Reply-To: <199805211929.PAA13296@sunmil2.uml.edu> Message-ID: <Pine.SGI.3.95.980602164732.19570C-100000@cad.arl.mil> X-URL: http://ftp.arl.mil/~butler/ MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 21 May 1998, Mark Becker wrote: > For the past couple of weeks I've been trying to find a combination of > AutoCAD and BRL-CAD tools to permit the exchange of images between the > two systems. > > My test drawing (in the AutoCAD world) is of a cube with a small > rectangular cavity in one side. My most recent success has been in > setting AutoCAD to output the drawing in "B-REP solid with analytical > surfaces" and using iges-g to translate to BRL-CAD g-format. > > This works.. partway. In an attempt to raytrace the object, 'rt' runs > for a while, emits a message "This better be a 2-manifold surface" and > dumps core (Platform: UltraSparc 2 with Solaris 2.5.1, running BRLCAD > 4.5).

This implies that you are creating a B-REP NMG solid in BRL-CAD for your object. The NMG code in release 4.x is what I would call "experimental" in quality. However, for some database formats, it is the only way to achieve a conversion.

In your case, it seems that you are not creating a closed solid, but rather a collection of planar surfaces which touch but are not topologically connected. You may wish to investigate the "asc-nmg" program.

In some cases, there are large performance improvements which can be achieved by re-modeling the object (or parts of it) in BRL-CAD. For example, ray-tracing a BRL-CAD object consisting of an arb8 with a subtracted arb8 will be much faster than ray-tracing the equivalent NMG planar suface representation.

For large models the effort to re-model may not be practical. In these cases I suggest investigating conversion of certain key sections for performance.

Lee

Received: from wolf.arl.mil by CAD.ARL.MIL id aa02432; 8 Jun 98 16:03 EDT Date: Mon, 8 Jun 98 16:02:58 EDT From: Paul Tanenbaum <pjt@arl.mil> To: cmoore@arl.mil cc: acst@arl.mil Subject: Re: cell-fb use of -k at same time as -d Message-ID: <9806081602.aa08851@wolf.arl.mil>

Carl, You wrote...

> If I use -k argument and ALSO use -d "0. 3" argument, the color key > comes out the same LENGTH as above, with the white (zero) value in > the same place (far left) as before. *But* the right end of the color > key becomes a blue shade (apparently the equivalent of 0.3333333 value), > and in-between parts of the color key are interpolated between this > value and the left endpoint's zero.

> The intent of the normalization is to get data into the "0 to 1" range, > so I would expect the color key to show the 0 to 1 range. Why is the > color key altered when I do said normalization?

The color key is altered because of a bug. Your hunch about the program's behavior was correct, and I've fixed it in the developmental sources. By the way, in tracking your bug, I discovered another one, too, which I've also fixed.

And I've implemented a new option, '-M r1 g1 b1 r2 g2 b2', which specifies that the color scale should be--instead of the standard blue-to-red w/ 0=white--interpolated between r1/g1/b1 and r2/g2/b2. With the -M option it's now easier to be less wasteful of the colors at one's disposal. For instance, ramping the cell data, say, from white to red leaves all the other colors (greens, blues, yellows, etc.) available to encode additional information in the image (e.g., text, aimpoints, delivery accuracy, etc.)

Thanks for your bug report, Paul

Received: from cad.arl.mil by CAD.ARL.MIL id aa24639; 22 Jun 98 16:23 EDT Date: Mon, 22 Jun 1998 16:23:22 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: acst@arl.mil Subject: Changes to db_comb.c and db_tree.c Message-ID: <Pine.SGI.3.95.980622161255.24383A-100000@cad.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

Mike asked me to notify when I changed the combination import/export routines. I have done that. They now convert the shader info to/from the TCL format. I also modified db_apply_state_from_comb() to convert from TCL format back to the "keyword=value" format, so that rt will still work. Note that when you supply shader info to the "mater" command in MGED, it must now be in TCL format. The format is a list where the first member is the shader name and the second member is a list of (white space separated) shader keywords/values. For example,

plastic sh=5 is now: plastic {sh 5}, and, stack camo c3="255 255 255";plastic is now: stack { {camo {c3 {255 255 255}}} {plastic {}}}

each member of the stack shaders parameter list is a shader list itself.

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by CAD.ARL.MIL id aa07886; 7 Jul 98 9:18 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa15562; 7 Jul 98 8:39 EDT Received: from cad.arl.mil by WALRUS.ARL.MIL id aa15528; 7 Jul 98 8:31 EDT Received: from cad.arl.mil by CAD.ARL.MIL id aa07463; 7 Jul 98 8:27 EDT Date: Tue, 7 Jul 1998 08:27:41 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> To: Marcel RICARD <ricard@igr.fr> cc: cad@ARL.MIL Subject: Re: Use rt command In-Reply-To: <3.0.1.32.19980706184830.00958dc0@igr.fr> Message-ID: <Pine.SGI.3.95.980707082339.7446B-100000@cad.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 6 Jul 1998, Marcel RICARD wrote:

> Dear BRL-CAD users, > > We are just trying to use the BRL-CAD package in the field of Medical > Physics concerning internal dosimetry. We use a SUN SPARCKstation 20 under > Solaris 2.4 and the software seems to be well installed on our computer. We > are able to build and edit objets but the rt command (do raytrace of view) > doesn't work. As we didn't find any information to view the result of rt > command, we want to know if anybody knows how to fix this problem. > > Thank you very much in advance for your help. > > Best regards, > > Marcel.

The "rt" code will try to send its output to a framebuffer, so you may need to tell it which framebuffer to use. You can use the "-F" option or set the "FB_FILE" environment variable. A pretty safe choice for framebuffer on a SUN is "/dev/Xl". Try the "fbhelp" command to see the available framebuffers.

-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

AMC says that my views do not represent an official Government position.

Received: from walrus.arl.mil by CAD.ARL.MIL id aa14702; 7 Jul 98 11:28 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa17085; 7 Jul 98 11:20 EDT Received: from admii.arl.mil by WALRUS.ARL.MIL id aa17081; 7 Jul 98 11:18 EDT Received: from gsi-1.geosol.com by ADMII.ARL.MIL id aa03712; 7 Jul 98 10:54 EDT Received: from localhost by gsi-1.GeoSol.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) id KAA16094; Tue, 7 Jul 1998 10:54:38 -0400 Date: Tue, 7 Jul 1998 10:54:35 -0400 (EDT) From: "Harry J. Reed" <reed@geosol.com> To: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.MIL> cc: Marcel RICARD <ricard@igr.fr>, cad@ARL.MIL Subject: Re: Use rt command In-Reply-To: <Pine.SGI.3.95.980707082339.7446B-100000@cad.arl.mil> Message-ID: <Pine.SGI.3.96.980707103958.15957A-100000@gsi-1.GeoSol.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

> On Mon, 6 Jul 1998, Marcel RICARD wrote: > > > Solaris 2.4 and the software seems to be well installed on our computer. We > > are able to build and edit objets but the rt command (do raytrace of view) > > doesn't work. As we didn't find any information to view the result of rt > > command, we want to know if anybody knows how to fix this problem.

Marcel,

Sometimes our students have trouble getting RT to work and the cause of this problem is usually easy to correct.

First: Make sure that "/usr/brlcad/bin" is in your PATH. The PATH is a UNIX environment variable that tells what directories are to be searched to find commands. Even though you are in MGED, the RT command invokes an outside code known as RT. If your PATH is not set up correctly, then RT is not found and therefore does not run.

To determine whether this is your problem, try running RT outside of MGED. If the RT command is not found when it is run outside of MGED, then it also will not be found if invoked inside of MGED.

SECOND: As John pointed out, perhaps your frame buffer variables are not set up correctly. I do not suspect this in your case since the MGED screen appears correctly.

To determine whether this is the case, try invoking RT INSIDE MGED with "rt -o junk.pix -s 512". This will attempt, if everything else is working correctly, a file named "junk.pix" in your current directory that contains the image of whatever was on the MGED editor screen. If the file was created correctly and is somewhere around .75 MB in size, then your problem is with the frame buffer. Otherwise, perhaps the FIRST problem or some other RT compilation problem may have occurred.

Hope this helps, Viva La France!

Harry Reed Geometric Solutions, INC +1 410 273 7058 Office Hours: Monday - Thursday 0930-1530, U.S. Eastern Standard Time

Received: from walrus.arl.mil by CAD.ARL.MIL id aa04086; 28 Aug 98 18:01 EDT Received: from walrus.arl.mil by WALRUS.ARL.MIL id aa24793; 28 Aug 98 17:31 EDT Received: from admii.arl.mil by WALRUS.ARL.MIL id aa24787; 28 Aug 98 17:23 EDT Received: from postal.clark.net by ADMII.ARL.MIL id aa29687; 28 Aug 98 17:09 EDT Received: from loas.clark.net (loas.clark.net [168.143.0.13]) by postal.clark.net (8.9.1/8.9.1) with ESMTP id RAA01691; Fri, 28 Aug 1998 17:10:17 -0400 (EDT) Received: from shell.clark.net (klaatu@clark.net [168.143.0.8]) by loas.clark.net (8.8.8/8.8.8) with SMTP id RAA17160; Fri, 28 Aug 1998 17:10:12 -0400 (EDT) Date: Fri, 28 Aug 1998 17:09:05 -0400 (EDT) From: klaatu <klaatu@clark.net> To: "Karen A. Swartz" <swartzk@email.uah.edu> cc: cad@ARL.MIL Subject: Re: Linux In-Reply-To: <Pine.GSO.4.02.9808281613510.25607-100000@shell.clark.net> Message-ID: <Pine.GSO.4.02.9808281705550.25607-100000@shell.clark.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

Correction, if you're running 8-bit X, you might want to do this under 'bash' which is probably your default Linux shell (otherwise use 'setenv' instead of 'export'

export FB_FILE="/dev/XsPl"

You might or might not want to use the 's' option depending on how much memory you've got.

On Fri, 28 Aug 1998, klaatu wrote:

> On Fri, 28 Aug 1998, Karen A. Swartz wrote: > > > I installed BRL-CAD and I worked through the tutorials for Mged. However, > > when I got to the ray tracing it didn't work like the tutorials said. In > > fact nothing really happened at all with the display. Is there any major > > differences when running in linux or Xwindows? Is there some way of > > checking if everything was installed correctly? > > Um, lessee - if I recall correctly, this is probably because you haven't > got your FB-FILE environment variable set right. There's more to it than > this, but I know that it must be set. > > In my /etc/profile (possibly you'd rather have this in your own 'bash' > ~/.profile file) add a line > > export FB_FILE="/dev/XsTl" > > Definitely read your 'man libfb' and related files, probably you've got a > different device from the XsTl device. But this works for me in 8-bit > SVGA under X. > > > > > > > Any input would be great. > > I appreciate all your help. > > > > > > Karen Swartz > > Teledyne Brown Engineering > > swartzk@email.uah.edu > > > > > > > > > > Be kind to your neighbors, | "When the going gets weird the weird turn pro." > even though they be | http://www.clark.net/pub/klaatu/home.html > transgenic chimerae. | Now. Chock full of uninteresting links. > --------- Whom thou'st vex'd waxeth wroth ---------------- > Re-transmission of this e-mail is a violation of Federal Copyright Law and > subject to a per-instance violation damages charge of $250,000.00 >

Be kind to your neighbors, | "When the going gets weird the weird turn pro." even though they be | http://www.clark.net/pub/klaatu/home.html transgenic chimerae. | Now. Chock full of uninteresting links. --------- Whom thou'st vex'd waxeth wroth ---------------- Re-transmission of this e-mail is a violation of Federal Copyright Law and subject to a per-instance violation damages charge of $250,000.00

Date: Fri, 28 Aug 98 23:13:44 EDT From: Mike Muuss <mike@arl.mil> To: BND@ARL.MIL cc: Jcst@ARL.MIL, CAD@ARL.MIL Subject: BRL-CAD Support for PNG Message-ID: <9808282313.aa09058@CAD.ARL.MIL>

Of all the image file formats supported by Microsoft PowerPoint(tm), Adobe PhotoShop (tm), Web browsers, and BRL-CAD(tm), the new PNG format (Portable Network Graphics) is the best choice for the two-way exchange of images.

PNG offers a typical compression ratio of 10:1, and uses a lossless algorithm, so that there is no degradation of quality in the decompressed image.

As you probably know, Jill has directed that all developmental BRL-CAD and MUVES software is to be carefully protected. With Jill's express permission, executable copies of these new PNG tools from the developmental ("5.0") version of BRL-CAD have been added to the "Production" BRL-CAD 4.4 executable tree stored in /usr/brlcad/ on the IRIX 5.3 (wilson.arl.mil) and IRIX 6 (raven.arl.mil) RDIST master machines. These binaries will be available to every machine that subscribes to the ARL rdist service, including machines at ARDEC, TECOM, CECOM, and elsewhere.

The programs png-fb, fb-png, and any-png.sh have been added, and the programs pixinfo.sh and show.sh have been upgraded to support PNG. Manual pages for png-fb and fb-png have also been installed. These files should go out on the Friday night RDIST.

The any-png.sh script is a convenient tool which can convert one image in any of our common formats (pix, bw, rle, yuv, jpeg, and gif) into PNG. To convert an entire directory of images into PNG format, just run:

for i in * do any-png.sh $i done

The PNG files are written in the current directory even if the input file is taken from another directory. So to get your own PNG version of the radar teapot, you can just run:

any-png.sh /n/wolf/demo/rt/radar-teapot.rle

You can then view the resulting image by running either:

png-fb radar-teapot.png or show.sh radar-teapot.png

(The show.sh program can display most image formats on your BRL-CAD framebuffer.)

This is a great way to zap your V/L analysis results painlessly into PowerPoint or PhotoShop!

Credit: As an interesting historical note, the PNG format was developed by a large group of people, including Glenn Randers-Pehrson, a long-time Army employee (ARDEC, BRL-TBD, ARL-WMRD), now retired. John Anderson ported the PNG library into the BRL-CAD source tree, and he and I wrote these new converter tools.

Enjoy! -Mike

Date: Wed, 30 Dec 1998 22:29:38 EST From: Mike Muuss <mike@arl.mil> To: Lamas@ARL.MIL cc: Morrison@ARL.MIL Subject: brlcad-check.sh split out from setup.sh Message-ID: <199812302229.aa22878@CAD.ARL.MIL>

As an additional tool for us developers, I've broken out the parts of setup.sh that checked the settings of $PATH, cake, machinetype.sh and Cakefile.defs into a separate shell script named "brlcad-check.sh".

setup.sh runs brlcad-check.sh, but if you're unsure about whether your path is set right, you can run it directly.

Best of all, if you're struggling to get machinetype.sh and cake and Cakefile.defs to all agree, you don't have to re-run setup.sh (and be forced to recompile CAKE) each time you experiment.

Best, -Mike

Date: Thu, 31 Dec 1998 01:24:41 EST From: Mike Muuss <mike@arl.mil> To: Lamas@ARL.MIL cc: Jill@ARL.MIL, Wendy@ARL.MIL Subject: Release 5.0 on FreeBSD Message-ID: <199812310124.aa09935@CAD.ARL.MIL>

As a starting point today, I modified gen.sh and Cakefile.defs to support using the vendor-provided versions of the TCL and Tk libraries, when compatible versions are provided. In the case of both FreeBSD and Linux, libtcl8.0 and libtk8.0 are available. In those cases, one less thing we need to ship along.

This evening I succeeded in taking the final step in the FreeBSD port: getting the package to build using shared libraries and optimization. Now that I've figured out all the magical compiler options needed, it works just fine! The full install tree for FreeBSD is 13.7 Mbytes, just slightly larger than a full install for Linux (12.7 Mbytes).

This is an extremely small disk requirement for modern software; the full BRL-CAD package can fit nicely on any laptop computer running FreeBSD or Linux.

Best, -Mike

Received: from cad.arl.mil by CAD.ARL.MIL id aa24829; 25 Jan 1999 09:32 EST Date: Mon, 25 Jan 1999 09:32:45 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: acst@arl.mil Subject: "db adjust" command Message-ID: <Pine.SGI.3.95.990125092928.7787A-100000@cad.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

I have modified db_tcl_comb_adjust() in tcl.c such that a "db adjust any_comb_parameter none" will set that parameter to its "not used", or its default value.

-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

AMC says that my views do not represent an official Government position.

Date: Mon, 25 Jan 1999 13:38:18 EST From: "Lee A. Butler" <butler@arl.mil> To: acst@ARL.MIL Subject: New "stack" type shader X-URL: http://ftp.arl.mil/~butler/index.html Message-ID: <199901251338.aa00538@CAD.ARL.MIL>

A new shader called "extern" was born in about 40 lines of code today. It's just a version of the venerable "stack" shader that takes it's parameters from an external file. The only parameter is the name of the file containing the real parameters. Usage:

mged> mater foo.r "extern {shader.txt}" 255 255 255 1

Then you need to fill in the file "shader.txt" with the actual parameters you wanted on the command line.

mged> exec cat shader.txt camo s=200 t1=-.3 t2=.125;plastic di=.8

This lame little hack allows us to sneak around the buffer length limits in the v4 database format.

Lee

Received: from cad.arl.mil by CAD.ARL.MIL id aa05575; 17 Mar 1999 14:53 EST Received: from cad.arl.mil by CAD.ARL.MIL id aa04464; 17 Mar 1999 14:49 EST Date: Wed, 17 Mar 1999 14:49:55 -0500 (EST) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@arl.mil> To: Tom Browder <tom2@fwb.asi.srs.com> cc: cad@ARL.MIL Subject: Re: mged's Maximum Tree Depth In-Reply-To: <01be6ca9$51eb4ac0$cb01000a@tomtom2.asi-fwb.com> Message-ID: <Pine.SGI.3.95.990317144712.5803A-100000@cad.arl.mil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 12 Mar 1999, Tom Browder wrote:

> The stock mged has a useful tree depth of twelve levels. Is there a simple > constant change in the source code to increase that or is it more than a > trivial change? > > Thanks. > > Tom Browder > > >

Yes, in "h/solid.h", there is a line that defines MAX_PATH. You can adjust this, then recompile mged. Making this larger will increase the memory used for each solid in MGED's display.

-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

AMC says that my views do not represent an official Government position.

< mike@arl.mil >
Release notes for other versions of BRL-CAD