rel4.0

Date: Mon, 6 Nov 89 22:50:11 EST From: Mike Muuss <mike@BRL.MIL> Subject: Re: CAD interchange formats, BRL-CAD, IGES, MEDUSSA, ...

I found this message on COMP.GRAPHCIS. Attached is my reply, for those of you who don't read netnews. Best, -Mike

----- Forwarded message # 1:

From: Bill Kish <kish@porthos.rutgers.edu> Newsgroups: comp.graphics Subject: CAD interchange formats, BRL-CAD, IGES, MEDUSSA, ... Date: 3 Nov 89 14:36:18 GMT

I'm trying to take a CAD application which is currently maintained by the MEDUSSA CAD system and convert it into a format which the BRL-CAD system understands. I'm told that MEDUSSA knows how to translate from its own internal representation format into IGES, but apparently the BRL-CAD system does not know how to read in a file in IGES format. I'm new to the BRL-CAD system and to CAD systems in general, so I'm hoping that I'm just not looking in the right place. I also know people who wish to take PATRAN output and be able to take advantage of the rendering capabilities of the BRL-CAD system, but here again, it would seem that some sort of conversion utility either has to be written or acquired. I can't believe I'm the first person to be in this situation, so I thought posting to the net would be a good idea before I think in terms of developing my own utilities. Is there another newsgroup specifically for CAD related issues ? I rarely if ever see CAD related questions in comp.graphics.

Thanks, Bill Kish

kish@jove.rutgers.edu

----- Forwarded message # 2:

From: Mike@BRL.MIL Subject: Re: CAD interchange formats, BRL-CAD, IGES, MEDUSSA, ... Newsgroups: comp.graphics Keywords: cad, geometry, interchange, format

Bill Kish <kish@porthos.rutgers.edu> wrote:

There are several levels of answer to this question. First, questions about the BRL-CAD Package are generally best addressed to < CAD @ BRL.MIL >, which is the list were users and developers of this software interact.

There is a deeper issue here that I though would be worthwhile addressing for the whole group: the difference between systems designed primarily for drafting (most IGES-compatible systems), and systems designed for full 3-D analysis.

First disclaimer: I really don't know anything detailed about the internals of the MEDUSA system; it may or may not have full 3-D connectivity to connect all the surfaces into consistent solid objects. However, once the data has been converted to IGES format, the surface and connectivity data that is necessary to fully describe 3-D solid objects has been lost. (That is, unless the not-yet-standard IGES SOLIDS extensions are used.)

It is important to note here that the BRL-CAD Package is a 3-D solid modeling system. One significant aspect of this is that geometry is restricted to objects that have both an "inside" and an "outside". For example, a single polygon is not a solid, although 5 polygons might be cleverly positioned to form a solid pyramid, or 6 polygons could be arranged to form a cube.

The difference is somewhat akin to the difference between the movie lot at Universal Studios, where largely only the outsides of buildings have been built, and an actual city, where the complete buildings have been built.

If you don't need the power of a solid modeling system (for example, if your only interest is in rendering some externally-generated polygons), then you may be better off with a different software package. The message which I am responding to didn't really indicate the intended application.

Having said this, I can offer some practical assistance:

1) At BRL, there is an ongoing project to build a converter between the experimental IGES SOLIDS specification and the BRL-CAD format. If you are certain that your modeler can output your model in the IGES SOLIDS format, then this may be of help to you. (This project is currently hampered by not having any serious model in IGES SOLIDS format to test with, since BRL does not use IGES). Contact <sue@brl.mil> and <earl@brl.mil> for more information.

2) There is a powerful and easy to use interface for creating BRL-CAD geometry from within a program; we call it LIBWDB, the library for writing databases. It is this library that we use for all our current converter programs. Thus, if you wish to build a new converter (or to generate procedural geometry), you have only to worry about the input format (or generation algorithm), and then just call LIBWDB to output your shapes for later review, editing, and/or analysis.

A more detailed discussion, if required, should probably move to the <CAD@BRL.MIL> mailing list.

Best, -Mike Muuss BRL-CAD Architect

----- End of forwarded messages Date: Tue, 7 Nov 89 16:22:33 EST From: Keith Applin (VLD/VMB) <keith@BRL.MIL> Subject: DISUM and TAP for CAD Symposium - draft

.nf The Technical and Programmatic (TAP) Report

Provided by: Vulnerability Methodology Branch/VLD

Title: BRL-CAD Symposium '89 .fi

The US Army Ballistic Research Laboratory (BRL) sponsored the BRL-CAD Symposium '89 at the Aberdeen Proving Ground on October 24-25. This was the second of these annual events and was supported by the American Defense Preparedness Association. BRL-CAD is a software package consisting of a 3-D geometric modeling system, a ray-tracing interrogation library, a generic framebuffer imaging library, and numerous associated utility packages. This BRL developed and maintained package has been distributed on a conditional, non-redistribution basis, free-of-charge to over 500 sites worldwide. Such features as source code availability, modularity, adaptability, and a broad base of applications make BRL-CAD a very attractive package. This symposium was held to provide an opportunity for an exchange of information, experiences and ideas associated with the BRL-CAD package. A total of 23 papers were presented and approximately 100 people attended, including representatives from academia, DoD agencies, industry, and foreign governments. Topics presented covered current applications and work as well as future planned developments. BG Malcom O'Neill, commander of LABCOM, presented the keynote address. The symposium was closed with a panel question and answer session.

Date: Wed, 15 Nov 89 3:18:00 EST From: Mike Muuss <mike@BRL.MIL> Subject: remrt

I made a variety of improvements to LIBPKG (replacing pkg_get with a new pkg_process, plus calls to pkg_suckin). This addresses some of the performance buffering complications, which turned out to be more involved than I had first thought (because of all kinds of unexpected recursion).

pkg_get is only used by REMRT and RTSRV; they have been changed to also reflect the new usage. (The ADDCOMPE folks might benefit from this, too).

More on this in a few days, after Chris has had a chance to put it through the wringer. Best, -Mike Date: Thu, 16 Nov 89 1:31:20 EST From: Mike Muuss <mike@BRL.MIL> Subject: Re: fb-rle -F flag

Thanks for pointing that out. The string "F:" was missing from the getopt() arg list; all the supporting code was present. I have fixed the source code, and it seems to perform as expected now.

Best, -Mike From: GEORGE_A_MANEY@cup.portal.com Newsgroups: comp.graphics Subject: Re: Information on IGES files wanted...ok Date: 22 Nov 89 02:12:38 GMT

IGES is an NBS publication. I got IGES v3.0 (NBSIR-3359) from

US Department Of Commerce National Technical Information Service Springfield, Virginia 22161

The cost was about $40. I believe that version 4 is now available.

George Maney FMC Corporate Tecnology Center Date: Fri, 24 Nov 89 16:00:43 EST From: Mike Muuss <mike@brl.mil> Subject: Details on CAD distribution terms

This letter should answer your questions.

> What happens if someone of the students doesn't abide by the > disrtibution terms? I suspect that forwarding our request through the > embassy creates a law problem: which country's laws apply?

The way things like this were handled when I was a student was that each student who would be using the software was asked to sign a short agreement with the University. This creates a form of contract between the student and University which is valid under local law. Since all we really ask is that redistribution be handled by us, and that each commercialization effort be cleared with us, I suspect that such an agreement would be simple and inoffensive. If there was an infraction that came to light, and for whatever reason your University was not able to deal with it, then our legal and policy offices would have to consider the details.

If you require a more detailed response than this, I will have to ask for an official statement from the legal office, which might take quite some time.

> What about updates?

Each time we produce a new release, sites that wish to obtain it must again send us a blank tape. While we have a modest budget for postage, we are not funded to provide magnetic tapes. Until recently, foreign sites were asked to re-send through the embassy for each update. Recently our security office has indicated that updates can be handled directly. I don't know if we have processed any update tapes in this new manner yet, but I assume that it will work fine.

> I fear that the size of the package will make it unacceptably slow in > 4-MByte workstations. Is this true?

The package is highly modular; there are more than 100 different programs. The 150,000 lines of code figure is for the aggregate. The two largest single programs are MGED, the multi-device graphics editor, which has a base executable of about 1 Mbyte on most machines, and RT, the ray-traced lighting model, which has a base executable of about 0.6 Mbytes on most machines. Of course, dynamic memory is used to contain the data for the model being constructed. Without knowing what complexity of modeling you intend, I can't judge how much memory you might need. However, I often run MGED on a Sun-3/50 with 4 Mbytes to perform simple modeling operations and to inspect existing models, although larger models I work on using a Silicon Graphics workstation.

> Since the NTUA acquires continuously many different machines running > Unix, the equipment list will be necessarily inexact. In the case of > machines that are installed after the licence agreement is made, can we > install the package?

While we don't state it precisely in the letter, all we desire is a list of machine TYPES (eg, Sun-3, Sun-4, Mac II, etc) that you intend to use the software on. This is largely so that if you state that you intend to use the software on a machine that we don't presently support, we can either (a) warn you of that, (b) try to persuade you to develop that new support and share the modification necessary to support that new machine, or (c) put other users who also have those machines in touch with you.

Our distribution tape contains only source code, no compiled binary code. Therefore, the one tape contains support for all systems. Thus, you must have a C compiler for each kind of system that you wish to use.

You are free to use the software on any and all computers that are owned or operated by your institution.

Of course, if our software proves helpful in your research, I always enjoy receiving a copy of any papers that might be produced. It is a continuing pleasure to observe the many and varied uses that our software has been put to.

Best, -Mike Date: Fri, 8 Dec 89 19:07:53 EST From: Mike Muuss <mike@brl.mil> Subject: Re: Some Thoughts....

In my mind there are two parts to the issue:

1) Is it honestly the case that TACOM would consider BRL-CAD, or are the technical issues just the first in a set of "excuses" to justify their doing what they want to do?

2) If it seems that TACOM will seriously consider BRL-CAD, if only certain technical issues can be addressed, then we need to rapidly produce a written list of what those issues are. Within a day or two of having the list, I should be able to predict roughly how much work it would entail. Then we can decide if there is any hope, or not.

As you hinted at in your message, I suspect that the issue of drawings will head the list of technical issues. What I still don't understand well yet is the role that the drawings are expected to play in the vehicle development process. Allow me to elaborate:

Producing engineering drawings that are ANSI or ISO compliant, suitable for use on the manufacturing floor, is not difficult, but entails addressing literally thousands of little details, each of which will require some special programming. Thus, setting out to build software that will product such a drawing would be a large undertaking.

On the other hand, drawings are entirely unsuitable for computer simulations. The only audience of a drawing is a human being.

I believe that it is quite possible to produce a wide variety of drawings, illustrations, and renderings of 3-D solid models, such that the drawing would convey the full details of the model to a human being. However, these drawings, illustrations, and renderings would NOT be standards- compliant drawings. They might or might not contain enough information to be useful on the manufacturing floor.

So, the question is, what happens in the prototype design stage? For models/drawings, what is the relative emphasis between these three areas:

1) computer simulation 2) human understanding 3) specifications for use in manufacturing

If #3 dominates, then BRL-CAD is not the answer. If #1 and/or #2 dominates, then BRL-CAD, perhaps with embellishments, should be a fine solution.

Can somebody who knows TACOM better than I do please comment? Best, -Mike Date: Sat, 9 Dec 89 2:22:57 EST From: Mike Muuss <mike@BRL.MIL> Subject: ARBN Progress

I am happy to report that this evening culminated a rather successful few weeks of code housekeeping.

I now have a new version of the COMGEOM to BRL-CAD geometry database converter. Formerly known as CVT4 and CVT5, this program is now known as COMGEOM-G, and can handle both versions of the input "deck".

Furthermore, this new program also properly converts the halfspace (HAF) and ARBN solids as well.

Libwdb has been expanded with routines mk_arbn() and mk_ars().

And, LIBRT now knows how to ray-trace an ARBN.

MGED can draw an ARBN, but does not yet have any ARBN editing capability.

So far, for my ARBN test case, I have been using the AH64 Apache heliocopter. In a few weeks, I will start soliciting for other folks to help test the ARBNs.

Hopefully, in my spare moments in the next few months, I hope to look at implementing the few remaining "missing" solids (LOF, WIR, and the ERIM solids). Does anyone have a COMGEOM model containing such solids that they would be willing to share with me for testing purposes?

In the meantime, *polygons*!

Best, -Mike Date: Tue, 12 Dec 89 17:05:39 EST From: Mike Muuss <mike@brl.mil> Subject: Re: BRL Program

Hi. I got your phone message. I'll be away on travel for the rest of the week, so I'll try to give you some answers here.

1) The space subdivision strategy is a non-uniform bin tree. Space is divided into a collection of "cells", each of which is a right rectangular parallelpiped. All intersections are found with the objects that occupy that cell, before moving on to the next cell. A bitmap is kept of which solids have already been intersected, so that solids which occupy multiple cells are not intersected more than once. Depending on the setting of a_onehit, raytracing either stops on the first hit that passes the boolean equations (gets a TRUE result), or continues until the end of the ray.

The existing boolean operation tree (which is separate from the space partitioning tree) is established in librt/tree.c, largely in the routine rt_drawobj(). Look for the section with the comment /* Store operation on subtree */

The boolean tree is applied to the segment list in librt/bool.c, in the routine rt_boolfinal(), using rt_booleval().

The space partitioning tree is established entirely in librt/cut.c; the strategy is to establish a single leaf "node" which contains everything in the entire model first, and then subdivide it until certain criteria (not the best criteria, I might add) are met. This subdivision is used in librt/shoot.c to quickly find the proper leaf node to consider. This is the only place the space subdivision tree is used. Look for this section of code: while( cutp->cut_type == CUT_CUTNODE ) { if( newray.r_pt[cutp->cn.cn_axis] >= cutp->cn.cn_point ) { cutp=cutp->cn.cn_r; } else { cutp=cutp->cn.cn_l; } } if(cutp==CUTTER_NULL || cutp->cut_type != CUT_BOXNODE) rt_bomb("leaf not boxnode");

2) Boolean tree is entered in MGED using "r" (region) command or the "comb" (combine) command. Example:

r fender.r u tire1 - rod1 - rod2 comb all u fender.r u hood.r u windshield.r - antenna.r

u=union, -=subtraction, +=intersection.

3) I think you are referring to this block of code?

int colorview( ap, PartHeadp ) register struct application *ap; struct partition *PartHeadp; { register struct partition *pp; register struct hit *hitp; register struct mfuncs *mfp; struct shadework sw;

for( pp=PartHeadp->pt_forw; pp != PartHeadp; pp = pp->pt_forw ) if( pp->pt_outhit->hit_dist >= 0.0 ) break; if( pp == PartHeadp ) { rt_log("colorview: no hit out front?\n"); return(0); }

The way the routine was set up, with a_hit = &colorview, the routine colorview() should only be called if the ray hit some geometry. When the ray is fired from the surface of an object (such as a light visibility ray or reflection ray), there are occasions where floating point error will place the exit point of they ray at a slightly negative distance (typ. -1.0e-10); in this case, that solid needs to be ignored. If no other solid is found, then that is a problem. Thus the error message.

Does this help?

Best, -Mike Date: Mon, 18 Dec 89 9:31:29 EST From: Paul Tanenbaum <pjt@BRL.MIL> Subject: RTG3 Paper

I have a comment about the method you give on page 10 to obtain azimuth and elevation from a direction vector. Does LIBRT normalize the v? If so, you can save yourself the call to

hypot(v[X], v[Y])

by computing elevation as

elev = asin(v[Z]).

Certainly MGED uses unit vectors? I should think that continual updating of the faceplate in response to knob twists might call for the simpler form.

+++paul

Date: Mon, 18 Dec 89 15:59:30 EST From: Mike Muuss <mike@BRL.MIL> Subject: Re: RTG3 Paper

Paul -

There are good reasons for RT applications using atan2() over acos().

The problem is that asin() is undefined outside the range of -1.0 .. +1.0, yet sometimes one of the elements of a vector that has "unit" length may be a few bits larger in magnitude than 1.0 (for example, 1.0000000000001). On machines like the Cray, the library routine asin() will abort with a core dump; in general, the desired behavior is not well defined.

By using atan2(), there is no opportunity for floating point error to cause trouble. The routine atan2(x,y) takes the length of both the "x" and "y" sides of the triangle for input. The routine is well defined for ALL values of "x" and "y". Small floating point errors in the input (for example, the hypotenuse having length slightly longer than one) will result in small changes in the output.

Thus, atan2() is robust in the face of numeric error, while acos() and asin() are not. It is to obtain this robust behavior that LIBRT and applications built upon it use only atan2().

I am indebted to Doug Gwyn for first calling this issue to my attention. Best, -Mike Date: Fri, 29 Dec 89 17:41:13 EST From: Mike Muuss <mike@BRL.MIL> Subject: LIBFB_LIBES

On Spark, I have changed all the Cakefiles so that LIBFB no longer contains "local vendor" type libraries. Instead, Cakefile.defs defines a new symbol, LIBFB_LIBES, that lists any and all loader options that have to be used when linking against LIBFB. Thus, all Cakefile rules should look like:

LIB_PRE''LIBFB LIBFB_LIBES

to refer to the framebuffer library.

This has the benefit of greatly reducing the size of LIBFB, and permits more flexibility in working around oddities (like BLD on the Crays).

Please note that this change applies only to the development version so far. Best, -Mike Date: Sat, 30 Dec 89 5:19:36 EST From: Mike Muuss <mike@BRL.MIL> Subject: raytrace.h BCC:

Gary -

This evening, I had to change LIBRT's free partition list from singly-linked to doubly-linked. (The active partition list was always doubly linked).

I recall your mentioning that you were freeing partition lists directly in some of your applications. If you were using the macros, this probably won't affect you at all.

Just didn't want you to be surprised. If something goes awry due to this change, I'd be interested in hearing about it.

Stay tuned for more librt work this week. Best, -Mike Date: Fri, 5 Jan 90 8:14:38 EST From: Paul Tanenbaum <pjt@BRL.MIL> Subject: [Doug Gwyn: Re: RTG3 Paper]

> One of "Gwyn's rules of numerical computation" (unpublished, alas) > is: "The only inverse trig function you should ever use is atan2()."

You once shared a weaker version of this rule with me, namely: "Don't use atan(), use atan2()." Your presentation was quite convincing, and I became a convert. But I had not heard the stronger form. A new decade begins...

+++paul

Date: Thu, 4 Jan 90 18:34:54 EST From: Doug Gwyn (VLD/VMB) <gwyn@BRL.MIL> Subject: Re: RTG3 Paper

Another advantage of atan2() in many applications is that it gets the quadrant right.

One of "Gwyn's rules of numerical computation" (unpublished, alas) is: "The only inverse trig function you should ever use is atan2()." Like most rules, there are valid exceptions, but they are quite rare and one should understand the reasons for the rule before deciding to violate it. Date: Thu, 11 Jan 90 0:23:19 EST From: Mike Muuss <mike@BRL.MIL> Subject: Interesting LIBRT details

Greetings -

Here are the answers to your questions:

1. In your space subdivision algorithm, can boxes overlap each other?

No, at no point in the tree will there be an overlap. The leaves (space partitioning "box nodes") will never overlap. A given "cut node" only ""overlaps"" with the children nodes below it.

Can solids be in more than one box?

Yes, absolutely. Each solid is listed in every box in which it appears.

Can a solid in one box overlap a solid in another box?

The relationship between two solids, inside a single box, can be determined simply by considering the solids listed in that box. For example, a 1-D example: |------ Box 1 ------|------- Box 2 -----| Solid A: AAAAAAAAAAAAAAAAAAAAAAA Solid B: BBBBBBBBBBB

While the ray is in Box 1, there is no overlap between A and B. Within Box 2, there is an overlap. What happens in Box 1 will depend on the boolean formula that defines the region. (See below for an example).

Are the boxes handled in any order (like along the ray) or are they handled arbitrarily?

The boxes are guaranteed to be traversed IN ORDER along the ray, starting from the ray origin to +infinity.

I don't quite understand what the following segment of code is doing (it is from the rt_boolfinal() function, about 15 lines into the function):

/* If partition begins beyond current box, stop */ if( pp->pt_inhit->hit_dist > enddist ) return;

In the current version of the code (I did some work on this stuff last week), the whole block of code now reads like this:

/* * If partition ends before current box starts, * discard it immediately. * If all the solids are properly located in the space * partitioning tree's cells, no intersection calculations * further forward on the ray should ever produce valid * segments or partitions earlier in the ray. * * If partition is behind ray start point, also * discard it. */ if( pp->pt_outhit->hit_dist < startdist || pp->pt_outhit->hit_dist <= 0.001 /* milimeters */ ) { register struct partition *zap_pp; if(rt_g.debug&DEBUG_PARTITION)rt_log( "discarding early part x%x, out dist=%g\n", pp, pp->pt_outhit->hit_dist); zap_pp = pp; pp = pp->pt_forw; DEQUEUE_PT(zap_pp); FREE_PT(zap_pp, ap->a_resource); continue; }

/* * If partition begins beyond current box end, * the state of the partition is not fully known yet, * so stop now. */ if( pp->pt_inhit->hit_dist > enddist ) return(0);

/* * If partition ends somewhere beyond the end of the current * box, the condition of the outhit information is not fully * known yet. */ if( pp->pt_outhit->hit_dist > enddist ) { if( ap->a_onehit <= 0 ) return(0); if( HITS_TODO > 1 ) return(0); /* In this case, proceed as if pt_outhit was correct, * even though it probably is not. * Application asked for this behavior, and it * saves having to do more ray-tracing. */ }

How do you find only the first hit when a_one_hit is true? Is this done by sorting the boxes in order along the ray?

The "enddist" stuff only comes into play when a_onehit is on. The idea is to trace through the minimum number of boxes, stopping as soon as something is hit. Then the boolean formulas are evaluated, to see if that produces a true result. Note that in the case where a_onehit=1, only the IN hit point is valid; the OUT hit point may wind up being incorrectly computed. Consider another 1-D example, with the formula being "A - B":

|----- Box 1 -----|----- Box 2 -----| Solid A: AAAAAAAAAAAAAAAAAAAAAAAAA Solid B: BBBBBBBBBBBBB

Output partitions: a_onehit=0 AAAAAAAAAAAAAAA a_onehit=1 AAAAAAAAAAAAAAAAAAAAAAAAA ^^^wrong^^

In the a_onehit=1 case, ray/solid intersection halts in Box 1, and the formula A-B is evaluated, giving a TRUE result. However, the out point of the partition seems to be at the out point of A, since solid B has no presence in Box 1. In reality, the out point of the partition is coincident with the IN point of B. However, the definition of a_onehit=1 is that only the FIRST hit (the IN hit) is valid in the partition returned, so this error in the OUT hit is acceptable, and saves having to intersect the ray with B. Since the application set a_onehit=1, it "promised" never to use the out hit, and so this efficiency measure can be employed.

The assumption is that a_onehit=1 mode is used primarily for lighting models, where ordinarily the surface is opaque. For those rare surfaces where there is transmission or reflection, another ray needs to be fired anyways, to take into account bending due to changes in the refractive index (for the transmission case) or the Snell's law reflection.

Also note that in the new version of the code, a_onehit is now a COUNT of the number of accurate hits to be provided by the library in the result partition. This has an upwards compatible interpretation with the previous meaning, and allows certain calculations (pertaining to internal reflection inside glass, and refractive index tracking) to be computed much more efficiently, using a_onehit=3 (IN, OUT, IN hits).

2. What are the inflip and outflip variables in the partition structure used for?

Let me refer to my 1-D subtraction example again, "A - B":

|----- Box 1 -----|----- Box 2 -----| Solid A: AAAAAAAAAAAAAAAAAAAAAAAAA Solid B: BBBBBBBBBBBBB

result AAAAAAAAAAAAAAA

Understand that the surface normals of each solid always point OUT. So, you could think of these ray segments having normals like this:

|----- Box 1 -----|----- Box 2 -----| Solid A: <--AAAAAAAAAAAAAAAAAAAAAAAAA--> Solid B: <--BBBBBBBBBBBBB-->

result <--AAAAAAAAAAAAAAA--> ^_____ note direction here!

The normal on the IN hit is just the surface normal of the entry into A. However, the normal on the OUT hit occurs at the point of entry into B, and has a normal which is the reverse of B's entry normal. This is a natural consequence of subtraction. Rather than reversing the normal values in the partition structure, potentially several times, the pt_inflip and pt_outflip bits are inverted as necessary. (This saved some storage in the partition structure, because pt_inhit and pt_outhit are actually pointers into to the ray segment structure; the normal itself is thus shared, and not amenable to modification, without smashing the interpretation for other partitions).

As a consequence, application program a_hit() routines all need to have a scrap of code to take this into account, before using a partition's normal vector, like this:

if( pp->pt_inflip ) { VREVERSE( hitp->hit_normal, hitp->hit_normal ); }

(Note that the extra {} brackets are needed because VREVERSE is a multi-line C macro.)

Also, is the solhit array in that structure used to indicate which solids are intersected by that partition?

The pt_solhit[] array is a bit vector, indexed by solid number (st_bit). If a partition is interior to a solid, then that is indicated by setting the bit, eg, BITSET( pp->pt_solhit, stp->st_bit ). After the partition "weaving" is finished (by rt_boolweave(), called before rt_boolfinal()), every partition is either entirely inside a solid, or entirely outside; all partition/solid crossings have been resolved by splitting the partition into two at the crossing point.

3. I don't quite understand your overlap handler. Does this refer to a partition that lies in two or more regions? Why would you want to eliminate such a partition?

The definition of a region is that it is a solid object which occupies physical space. It is not possible for two solid objects to occupy the same space; when this condition is detected in the model, it represents a modeling error. The details of the code are somewhat complicated by the fact that it can automaticly resolve overlaps between an (optional) explicitly modeled "air" solid and a non-air solid, in favor of the non-air solid.

Given than an overlap has been detected, this presents a problem for the analysis code. Which region gets to claim the ray (partition)? The overlap handler can make two choices: (a) randomly select one of the regions, or (b) act as if the partition was not present at all. Which one makes more sense depends on the particular application; the default overlap handler uses (a).

Hope this helps, -Mike Date: Tue, 17 Oct 89 15:17:45 EDT From: Mike Muuss <mike@BRL.MIL> Subject: cakeinclude.sh replaced

This afternoon, I have replaced "cakeinclude.sh" with the C program "cakeinclude" that Lee Butler recently wrote. It is compiled and installed automaticly by "setup.sh".

This provides a significant speedup when CAKE builds it's dependency lists.

Here are some timings for running on a full directory of source. The speedup factors are computed from the decrease in elapsed time. (SWM is Sun-3/50 diskless, SPARK is Gould PN9080, VOYAGE is SGI 4D/240. The files were accessed via NFS from SPARK).

Machine Dir Script Program Speedup

swm rt 4.7u 7.0s 1:00 19% 2.1u 2.7s 0:11 43% 5.5X swm util 12.2u 22.5s 2:48 20% 5.1u 8.8s 0:24 58% 7.0X

spark rt 2.9u 7.2s 0:17 59% 1.2u 2.5s 0:05 65% 3.4X spark util 7.8u 23.4s 1:00 51% 3.5u 9.1s 0:21 58% 2.9X

voyage rt 1.2u 3.0s 0:05 66% 0.2u 1.0s 0:02 37% 2.5X voyage util 3.2u 11.0s 0:20 68% 1.2u 4.0s 0:10 48% 2.0X

My thanks to Lee for this important development-performance boost! Best, -Mike From: "Phil Dykstra <phil>" <phil@sem.brl.mil> Newsgroups: comp.graphics Subject: Re: Raytracer performance on machines? Date: 26 Sep 89 03:20:19 GMT

> The whole BRL-CAD package is public domain, ...

The BRL-CAD package is *not* public domain. It is Copyright by the U.S.Army in order to control commercialization of it. We do distribute the source code at no charge however as long as the recipient agrees, in writing, to the conditions.

> but big, crufty, and pretty ancient as ray-tracing packages go.

Being one of the authors, I had to put in at least two cents worth of defense. Big - yes. Crufty - parts of it. Pretty ancient - some of it. But I wouldn't call things like CSG NURBs, arbitrary bounding planes, non-uniform space partitioning, parallel *and* network distributed capability very ancient.

- Phil Date: Sat, 12 Aug 89 7:36:06 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Quaternions added

I have taken Phil's Quaternion math package, and added many of the remaining features from Ken Shoemake's May '89 paper (ln, exp, stable slerp, etc). The macros have been added to h/vmath.h, and the subroutines now live in librt/qmath.c.

Perhaps this comming week I'll have a chance to actually USE them for something, thus testing them.

Best, -Mike Date: Wed, 23 Aug 89 14:44:25 EDT From: Phil Dykstra <phil@BRL.MIL> Subject: UnixPlot utilities in BRL-CAD

This note is to address a couple of the questions/problems posted recently about UnixPlot (plot(5)) utilities.

pl-X, pl-X10:

The reason that these were not included in the standard set of compiled software is because they are so minimally useful as they now stand. pl-X has a long way to go before it has any of the power of pl-sgi (the SGI IRIS specific plot display program). Someday there will be a much better version of pl-X.

pl-ps:

Many UnixPlot files (e.g. ones generated from Tek'ish programs) begin with an extra "erase" command. pl-ps in release 3.7 would (incorrectly) output an extra scale command (NEWPG macro) if it sees one of these. I have a much improved pl-ps that fixes this, along with output sizing/centering options similar to bw-ps, if anyone is desperate to print PostScript plot files.

Also, note that you can view plot files in MGED with the "overlay" command. This provides an alternative way to view them under X for the time being.

- Phil Date: Sat, 3 Mar 90 3:53:32 EST From: Mike Muuss <mike@BRL.MIL> Subject: MGED & lighting model

I have a very preliminary version of lighting model support in MGED, to help debug the NMG tessellation routines. It uses 4 infinite lights of dubious color and location, but it helps see the facets (eg, on the TGC) very clearly. As usual, getting the SGI to do anything useful has turned out to be a much bigger fight than I had expected.

A somewhat longer-term project will be to program the lighting model on the SGI with the same parameters that RT would use when rendering an object.

I have also started looking at the tessellation of the sphere, using Leech's algorithm that Paul Stay gave me a copy of.

Onwards! -Mike Date: Mon, 5 Mar 90 21:03:39 EST From: Mike Muuss <mike@brl.mil> Subject: comgeom-g

A new database converter program now exists, called COMGEOM-G. It replaces the old "Cvt4" and "Cvt5" converters.

COMGEOM-G will convert a GIFT-style COMGEOM file into a BRL-CAD binary database suitable for use with MGED, RT, etc. Automatic units conversion is built-in.

This new program, and it's manual page, are installed on BRL's Goulds for initial use. Please try this program on some of your old COMGEOM models, and let me know how it goes!

Note that this converter will convert ARBN solids, but most machines do not have a copy of MGED et.al. that is recent enough to include the ARBN support. However, the latest version of LIBRT raytraces ARBNs just fine. Best, -Mike Date: Thu, 22 Mar 90 17:39:05 EST From: Phil Dykstra <phil@BRL.MIL> Subject: Re: Irksome warning

Paul,

If you are using some of our old "pre release" software (e.g. 3.5) you will see the:

rt_shootray: defaulting a_resource to &rt_uniresource

message all of the time. As of release 3.7 however it should only come out if you have a librt debugging bit set. So your best bet is probably to get some up to date software (and ignore the message until then). But FYI...

The resource structure is used to handle parallel processing. If you are running on N CPU's, you need N resource structs. Thus a single CPU librt process may optionally allocate a resource struct, while a muti CPU job is required to.

To use rt_uniresource yourself you unfortunately need to:

extern struct resource rt_uniresource;

ap.a_resource = &rt_uniresource; rt_uniresource.re_magic = RESOURCE_MAGIC;

At that point it would be best to make your own resource struct. [The RESOURCE_MAGIC deal is an unfortunate technical detail.]

- Phil Date: Fri, 23 Mar 90 08:12:01 PST From: Vince Skahan <vince@atc.boeing.com> Message-Id: <9003231612.AA11158@atc.boeing.com> Subject: ray tracing

When we use rt in mged or pix-fb the ray tracing is done but the image disappears has soon as it finishes. This is on and SGI personal IRIS. If anyone there knows why this I happens I would be very thankful for a response.

Plese rely to vince@atc.boeing.com

Thanks, Steve Pirollo Boeing Helicopters Date: Fri, 23 Mar 90 14:45:30 EST From: "Lee A. Butler" <butler@brl.mil> Subject: Re: ray tracing

The key is to set your environment variable FB_FILE to something like "/dev/sgil" before you run mged, OR when you run rt, specify the option: "-F /dev/sgil". This tells rt that you want a LINGERING framebuffer. You will have to close the framebuffer window yourself using the mouse as a result. For more information about the options available with your framebuffer, try the command "fbhelp".

Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-8740 Aberdeen Proving Grounds, MD 21005-5066

Date: Fri, 23 Mar 90 18:49:44 EST From: Phil Dykstra <phil@BRL.MIL> Subject: Re: ray tracing

In brief, here is why the window goes away:

An application (e.g. rt) creates a frame buffer window. When an application goes away, so do all of its windows (this is simply part of the SGI window system, indeed almost all window systems). The "l" or linger option causes the application to "fork", i.e. make a copy of itself to hold the window open, while the parent exits.

An alternate solution is to have some process *other* than the application actually own the window, and allow an application to use that window via this other process. Code to support this will be in our next release, where that other process is called "fbserv" (a "frame buffer server", which is a generalization of the "remote frame buffer daemon" currently called "rfbd").

- Phil

ps: If you use the "l" option I would also suggest the "p" or private memory option as well (-F /dev/sgipl). (5.61+/IDA-1.2.8) id AA16584; Sun, 25 Mar 90 21:43:57 -0600 id AA04154; Sun, 25 Mar 90 21:41:13 CST Date: Sun, 25 Mar 90 21:41:13 CST From: Luke Lin <lukelin@uxh.cso.uiuc.edu> Subject: BRL-CAD on a Mac II

I was looking through Cakefile.defs when I noticed that it supported a Mac II running AUX. I would like to know whether mged runs well in this environment.

Also, what hardware is required and/or supported.

Will a Mac II with an Apple color screen handle the colors of a rendered image? Does BRL-CAD support 24 or 32 bit color boards available for the Mac? If I add a huge hard disk and a 19 inch color monitor to a Mac II, can I get something close to the modelling capabilities of an Iris?

Luke Lin Electomagnetics Lab University of Illinois Urbana Date: Mon, 26 Mar 90 13:21:44 EST From: "Lee A. Butler" <butler@brl.mil> Subject: Re: BRL-CAD on a Mac II

The only person I personally know with any experience running BRLCAD on a Mac II under AUX is on vacation right now, so I can't refer him to you, or you to him. My understanding is that it runs under X windows and is "appropriately slow." When you realize that the Mac is approximately equal to a Sun 3/[56]0, you understand the situation. The Mac, running a 68020 just doesn't have the horsepower of the Iris running a MIPS R3000 and a hardware graphics pipeline. The display on the Mac supports only 8-bit "color-mapped" mode (to my knowledge) so you begin to see the limitations. In all, I would recommend the Iris over the Mac for any serious modelling, unless you have no budget and already have a (well configured) Mac.

Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-6674 Aberdeen Proving Grounds, MD 21005-5066 Date: Mon, 26 Mar 90 13:22:28 EST From: "Christopher T. Johnson" <cjohnson@BRL.MIL> Subject: Re: BRL-CAD on a Mac II

Luke, I ported BRLCAD 3.x to a MacII running AUX 1.0. The rt parts and the utilities worked well. MGED worked poorly and required a good understanding of BRLCAD and AUX and MacOS.

Also under A/UX 1.0 there was no color support and no gray level support. BW only.

I have sinse ported BRLCAD 3.7 + to A/UX 1.1 running X windows (Apple offering) Color is not supported in 3.7 for X on A/UX but a slight hack will allow 254 color support. I expect that 24 bit color support will be availaibe as soon as we can access a 24 bit card and have A/UX 2.0.

If you have any questions please feel free to send e-mail and I will try to help.

Chris Johnson

Date: Mon, 26 Mar 90 12:50:03 CST From: Luke Lin <lukelin@uxh.cso.uiuc.edu> Subject: Re: BRL-CAD on a Mac II

Will the next release of BRL-CAD have better support for the Mac II? I guess the bottom line is: will the Mac II version of BRL-CAD be anywhere near the Iris version in usability? We have a ton of Mac II's in our lab, but we do not have A/UX. We've been thinking about purchasing A/UX along with a large hard disk so that we can have everything on a Mac, but if it is not as usable an Iris 4D, then we won't waste out efforts.

Also, any idea when the next release will be coming out? I've had problems compiling 3.7 on a personal iris running IRIX 3.2.1. I circumvented the problem by compiling everything on an Iris 4D with an older operating system and copying the binaries to the Personal Iris.

Thanks.

Luke Lin Electromagnetics Lab University of Illinois Date: Tue, 27 Mar 90 10:05:35 EST From: Bill Mermagen Jr. (VLD/VMB) <wm@BRL.MIL> Subject: Re: BRL-CAD on a Mac II

Luke,

I have been working somewhat with BRL-CAD on the Mac II running AUX. I recently got a chance to experiment with AUX 2.0, which runs the finder or MACOS system under Unix. It looks very promising. I plan to port BRL-CAD 3.7 on AUX 2.0 within the next month (as soon as I get a copy). Currently, my hardware configuration is a Mac cx with 8M, 8 bit color board with Apple rgb monitor and AUX 1.1.

The higher horsepower Mac fx, with high performance 24 bit video card, AUX 2.0, ethernet board, and jammed with memory could be a decent BRL-CAD platform. However, it will not beat a SGI 4D based system.

Bill Date: Tue, 27 Mar 90 18:32:47 EST From: "Christopher T. Johnson" <cjohnson@BRL.MIL> Subject: Re: BRL-CAD on a Mac II

Luke, I expect that future versions of BRLCAD will have better support for A/UX. At this time there are a few problems with a BRLCAD on a Mac. 1) Mac II is about 1.05 vgr's (see bench marking comments) With the newer versions of MacIIs I believe that this might be much improved. I also hope to have gcc running for the next test run. (gcc failed bencmarks the last time I tried. Port problem not gcc). 2) Most of the current Macs are using 8bit boards. This gives only 256 colors. Under A/UX, X windoes only allows 254 colors (two reserved for the cursor.) When X supports 24 bits, the color support will be available. (X for A/UX 2.0). At this time I am working on dithers for color under X and in Color Cut algorthems to get the best color possable with only n colors. 3) Mac Color cards are small. 640-480. The newest cards released by Apple support 24bit color in 640-480 but only 8 bits of color in the "Two Page Display" 1024-1024 plus. 4) Mged on a small display is painfull. It is also the case that each change of the model (or view point) requires that the display be repaointed This can take a LONG time with a large data base. This should be improved after I finish color support as I hope to add some clipping to reduce the number of lines drawn. 5) the rt and rrt commands under mged depend on IPC as due a number of utilites (pipes). MacOS programs under A/UX has some interprocess communication problems. (You can end up blocking on a pipe full because the MacOS program is not checking input as it is waiting on a child).

Chris Johnson Date: Thu, 26 Apr 90 1:55:03 EDT From: Mike Muuss <mike@brl.mil> Subject: Re: Help needed

Since the message was

contributed/toolkit-2.0 Help Extract write error

that suggests that TAR was unable to write on your local disk. Check to make sure that you did not run out of disk space.

You can verify that your tape is completely readable by running

tar t

(perhaps with the "f" option and the device name). The last file on the tape is named "zzzEND". If TAR can read through all the directory information on the tape as it goes, then you have a good tape. Best, -Mike Date: Thu, 26 Apr 90 2:23:36 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Tolerance-based drawing

Over the past two days, I have added support to MGED to permit the resolution of the display wireframes and NMG tessellated solids to be variable, controlled by specifying a tolerance.

In MGED, the command "tol abs 3.5" specifies an absolute tolerance of 3.5 current units. This means that objects will be drawn and tessellated so that no line segment or polygonal facet will be more than 3.5 units distant from the correct location of the surface, at the worst case part of the surface. (Which unit is the current unit is controlled by the "units" command).

The command "tol rel 0.01" specifies that a relative tolerance of 0.01 ie, 1%, is to be used. This means that objects will be drawn and tessellated so that no line segment or polygonal facet will be in error by more than 1% of the size of that particular solid.

The command "tol" will show the current setting. MGED presently defaults to no absolute tolerance, and a 1% relative tolerance.

Either or both relative and absolute tolerances may be specified. If both are given, the tighter tolerance on a solid by solid basis will be used. (The relative tolerance is always relative to the size of each solid).

Note that this tolerance only affects the quality of the MGED display; it has no effect on the geometry that is stored in the database. Also note that this feature only exists on the development copy of the software, expect it in "The Next Release". Best, -Mike Date: Thu, 26 Apr 90 11:01:27 EDT From: Mike Muuss <mike@brl.mil> Subject: Re: Help needed

On every System V UNIX that has the 14 character filename limit that I have encountered, the system just silently truncates the file name to 14 chars. Has this behavior been "standardized" away? If so, I'll change the names on the tape, otherwise, all that matters is uniqueness in the first 14 characters, which *is* checked for. -Mike Date: Wed, 25 Apr 90 3:30:19 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Parallel "prepping"

This evening I got "parallel prepping" to work, although more properly, it is "parallel gettree'ing" -- the part marked these days as "PREP" is for space partitioning, not database prepping.

Not a full 100% speedup, but by no means shabby! Here are the raw numbers, there is a summary table at the end. Best, -Mike

------ M35 truck

Vax reference:

GETTREE: 65.8user 13.8sys 1:27real 91% 134i+3424d 2335maxrss 3+51pf 3+13940csw

Voyage, 1 processor:

GETTREE: 4.86 user + 0.26 sys in 7 elapsed secs (69.4286%)

Voyage, 4 processors:

GETTREE: 8.19 user + 1.62 sys in 4 elapsed secs (204.75%)

------- Mountain Fortress

Voyage, 1 processor:

GETTREE: 348.28 user + 34.12 sys in 392 elapsed secs (88.8469%)

Whiz, 3 processors (should have been 4):

GETTREE: 437.04 user + 66.49 sys in 182 elapsed secs (240.132%)

Whiz, finally 4 processors:

GETTREE: 489.92 user + 87.94 sys in 156 elapsed secs (314.051%)

Voyage with 4 processors:

GETTREE: 493.08 user + 89.99 sys in 159 elapsed secs (310.113%) GETTREE: 491.65 user + 94.27 sys in 161 elapsed secs (305.373%) GETTREE: 501.71 user + 94.96 sys in 163 elapsed secs (307.798%)

# CPU speedup Elapsed Time ----- ------- ------------ 1 1 392 3 2.15 182 4 2.45 156, 159, 161, 163 (avg=159.75)

Notes: 1) Only a portion of rt_gettree() runs in parallel, so 100% speedup should not be expected.

2) I/O is involved, giving about 20% system time overhead (red bar in GR_OSVIEW) pre processor.

3) More optimization is possible. Date: Fri, 27 Apr 90 3:47:29 EDT From: Mike Muuss <mike@BRL.MIL> Subject: New Tree Walker

On and off for the past two weeks, one of my projects has been the implementation of a new, general purpose "tree walker" for BRL-CAD model databases. The motivation for writing a new tree walker was to support the NMG work (Non-Manifold Geometry, more on this in some other note), which needed a tree walker a little different from the existing ones. Since yet another tree walker was required, I decided to invest a bit of extra effort and make the new one a fully general tree walker, capable of replacing all of the half-dozen existing ones. And, at the same time, I had a "laundry list" of projects waiting to be done, all of which in some way affected parts of the tree walker.

Fortunately, I was able to clean all the laundry :-) . Here is the list:

1) Make this new tree walker be one general routine, suitable for replacing the existing half-dozen. As a result of this, all the other features described below should apply uniformly to RT, LGT, etc, as well as in the viewing commands in MGED ("e", "E", etc).

2) Support of non-union operations in combination nodes above regions. For example, you can create a group which is "vehicle minus cutout" for a cutaway view, and you get desired effect. No longer is it necessary to remove the cutout from each and every region. This has been a personal desire of mine for years.

3) Allow using partial (or full) path specifications, accumulating transformations along the way. For example, it is now possible to do e vehicle.g/suspension/l-track/idler vehicle.g/engine/drive-train

and see the "idler" and "drive-train" assemblies drawn in their final locations, relative to the common combination "vehicle.g". This satisfies the suggestion made by Paul Tanenbaum some time ago.

4) Allow the model tree to be walked and "prepped" in parallel. For large models, this can take a significant amount of time; why not use multiple processors when they are available? This feature applies to MGED viewing commands (like "e", "E", etc), as well as to callers of the LIBRT routine rt_gettrees(). This suggestion was first put forth by Doug Gwyn at the last CAD Symposium.

Note that rt_gettrees() is a new interface, mandated by the need to (a) aggregate as many tree tops as possible, and (b) provide controls for the amount of parallelism (ncpus) to actually be employed. rt_gettrees() replaces rt_gettree() as the preferred way of loading trees into LIBRT; of course, rt_gettree() still exists for code compatibility.

5) Better bounding RPP support. When a region contains non-union operations between solids, sometimes better model (and region) bounds could be found than the previous algorithm. I am grateful to Ed Davisson for suggesting the improved algorithm which is now used. Most noticably, this should give much better "view auto-sizing" in RT.

6) Uniform support of articulation style animation. Animation directives are now handled automaticly by the tree walker, so any programs that use the new tree walker and desire animation capability can now easily obtain it. In particular, this will make it easy for MGED to preview the articulation scripts that RT has been able to render for some time now.

All of these features seem to be working, and MGED has been largely converted to use the new tree walker. Parallel tree walking works and provides a significant speedup on parallel systems, as outlined below for a (large) sample database (the Mountain Fortress) on an SGI-4D/240:

# CPU speedup Elapsed Time (sec) ----- ------- ------------ 1 1 392 3 2.15 182 4 2.45 156, 159, 161, 163 (avg=159.75)

Notes on parallel tree walking:

1) Only a portion of rt_gettrees() runs in parallel, so 100% speedup can *not* be expected.

2) I/O is involved, giving about 20% system time overhead (red bar in GR_OSVIEW) pre processor.

3) Quite a bit more optimization is possible, facilitated by the new framework.

SUMMARY

I believe that the new tree walker addresses all the outstanding issues in the tree walking area. It provides new features, improved performance, and is generally useful, eliminating many different versions of essentially the same algorithm.

The new software is now part of the current "development" sources on SPARK. It will be part of "The Next Release".

Best, -Mike Date: Fri, 27 Apr 90 4:37:30 EDT From: Doug Gwyn (VLD/VMB) <gwyn@BRL.MIL> Subject: potential portability problem in librt

I notice you're using rt_calloc() to obtain a vector of elements of various types, initialized to "zero". Unfortunately, bzero() does not always work for non-integral types. For example, some Data General C implementations do not use an all-zeros bit pattern to represent a null pointer, so when you use rt_calloc() to set up a pointer array it is not necessarily full of values that compare equal to null pointer constants.

There is no simple solution to this (assuming that it is undesirable to restrict portability to implementations for which this bzero() trick works). The obvious two are to just malloc() the array then use an explicit element initialization loop, or to use memcpy() to blit a statically initialized object onto the freshly malloc()ed one. (It is guaranteed that an object of static storage duration that has no explicit initializer is preinitizalized to zero values of the appropriate types, which takes into account architectures that have unusual null pointer, floating-point zero, etc. representations.)

I notice also that you're relying on C compiler supporting "flexnames" (long identifiers). Since the ANSI C standard guarantees at least 31 characters of significance (except for external linkage), this should not cause long-term problems, although I bet there are still some C compilers on commercial systems that don't support flexnames. Date: Fri, 27 Apr 90 3:47:29 EDT From: Mike Muuss <mike@BRL.MIL> Subject: New Tree Walker

Fortunately, I was able to clean all the laundry :-) . Here is the list:

and see the "idler" and "drive-train" assemblies drawn in their final locations, relative to the common combination "vehicle.g". This satisfies the suggestion made by Paul Tanenbaum some time ago.

# CPU speedup Elapsed Time (sec) ----- ------- ------------ 1 1 392 3 2.15 182 4 2.45 156, 159, 161, 163 (avg=159.75)

Notes on parallel tree walking:

1) Only a portion of rt_gettrees() runs in parallel, so 100% speedup can *not* be expected.

2) I/O is involved, giving about 20% system time overhead (red bar in GR_OSVIEW) pre processor.

3) Quite a bit more optimization is possible, facilitated by the new framework.

SUMMARY

The new software is now part of the current "development" sources on SPARK. It will be part of "The Next Release".

Best, -Mike Date: Sat, 28 Apr 90 3:43:42 EDT From: Mike Muuss <mike@BRL.MIL> Subject: PolySolid Tessellator

This evening, with a little help from Lee, I wrote the first draft of the PolySolid "tessellator". The challenge for this one was not producing the geometry, but instead, re-derriving the topology of a set of randomly presented facets. With the creation of two new NMG library subroutines, I was able to implement a workable first version. Performance is O(n**2) or worse, but at least it works. I'll see about speeding it up in a few days -- I have some ideas on how to tackle it.

The fun part of this is that I was able to convert an 8396 polygon fractal mountain that Chris had created into an NMG on the first try. The viewing of it ran in real time on the SGI at about 5fps.

Neat stuff! -Mike Date: Tue, 1 May 90 3:12:35 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Tolerance on Normals

A few days ago, I reported that MGED had gained a "tol" command to specify relative and/or absolute tolerances for use when plotting and tessellating the primitives. Paul Deitz suggested that for some of the signature work, it could also be useful to specify *surface normal* tolerances when facetizing, so that an application program could specify an upper bound on the angular error in surface normals.

I have added "normal" tolerances to MGED's "tol" command, and implemented it in the torus tessellator. The other tessellators will pick it up next time they are worked on.

Just for amusement, to satisfy a normal tolerance of 1 degree on the torus, the tessellator has to generate a 180 * 180 (32,400) polygon surface! In a large model, this could get to be a lot of polygons.

Best, -Mike Date: Tue, 1 May 90 1:48:49 EDT From: Mike Muuss <mike@brl.mil> Subject: Re: RT error message

The message you got:

tcg(solidname): only 1 intersect

usually means that one ray was exactly tangent to the surface of the TGC when it struck. If you only got one (or a few) of such messages, then there is nothing to worry about. If you got a lot of them, then I would be interested in seeing a test case that exhibits the problem.

Best, -Mike Date: Mon, 7 May 90 19:00:54 EDT From: Mike Muuss <mike@brl.mil> Subject: Re: BRLCAD available on Power Series?

Let me add to Phils remarks. First, BRL-CAD works fine on the SGI Power Series. The machine on my desk is a Power Series 4D/240.

You may have heard of several current issues between BRL-CAD Release 3.7 and SGI's IRIX Release 3.2 (and 3.2.1 and 3.2.2):

*) It is necessary to modify a few files in the BRL-CAD Release 3.7 software before beginning compilation. These changes are listed on the erratta sheet that is shipped with every tape. These changes are necessitated by the fact that SGI IRIX Release 3.2 was not made available until after BRL-CAD Release 3.7, so there was no way the BRL-CAD software could have been tested in advance.

*) When running a parallel application that produces images on the framebuffer, it is necessary to bounce the image through RFBD, because SGI has a bug in their graphics library that makes it impossible for a parallel-processing application to produce graphics output (ugh!). This is easily accomplished by adding the flag -F127.0.0.1: to such applications, or setting FB_FILE=127.0.0.1: in advance. I knew of this problem before the BRL-CAD Release was finalized, and spent several days trying to develop an internal "fix", but nothing worked. When SGI promised me that this difficulty would be fixed in IRIX Release 3.2, I gave up. However, it was *not* fixed in 3.2, so the problem lingers on. SGI now claims that IRIX Release 3.3 will have this fixed. Note again that this is an SGI libgl bug, not a BRL-CAD bug, not that you as the user care about the distinction.

Other than these two issues, I believe that BRL-CAD Release 3.7 is a good, solid release, and should give you no trouble.

Please pass this information on to your "sources". If you have any questions, please feel free to drop me a line.

Best, -Mike

- - - - -

For those wondering what BRL-CAD is, here is a quick summary.

The BRL-CAD Package includes a powerful solid modeling capability and a network-distributed image-processing capability. This software is now running at over 600 sites. BRL-CAD started in 1979 as a task to provide an interactive graphics editor for the BRL vehicle-description data base. Today the package totals more than 150,00 lines of "C" source code. It runs under UNIX and is supported over more than a dozen product lines from Sun Workstations to the Cray 2. The package includes:

A Solid geometric editor The Ray tracing library Two Lighting models Many image-handling, data-comparison, and other supporting utilities

In terms of geometrical representation of data, BRL-CAD supports:

The original Constructive Solid Geometry (CSG) BRL database.

Extensions to include solids made from collections of Uniform B-Spline Surfaces as well as Non-Uniform Rational B-Spline [NURB] Surfaces.

A facetted data representation.

It supports association of material (and other attribute properties) with geometry which is critical to subsequent applications codes. It supports a set of extensible interfaces by means of which geometry (and attribute data) are passed to applications.

Applications linked to BRL-CAD:

o Weights and Moments-of-Inertia o Optical Image Generation (including specular/diffuse reflection, refraction, and multiple light sources, animation, interference) o Bistatic laser analysis o A number of Synthetic Aperture Radar Codes (including codes due to ERIM) o Acoustic model predictions o High-Energy Laser Damage o High-Power Microwave Damage o An array of V/L Codes o Neutron Transport Code o Link to PATRAN [TM] and hence to ADINA, EPIC-2, NASTRAN, etc. for structural/stress analysis o X-Ray calculation Date: Wed, 9 May 90 20:01:59 EDT From: Mike Muuss <mike@BRL.MIL> Subject: enmg -> ev

In the most recent copy of MGED, I have renamed the "enmg" command to be "ev". This stands for EValuate. Few mged users will be likely to remember what NMGs are, and "enmg" is hard to type. -M Date: Tue, 15 May 90 22:32:43 EDT From: Mike Muuss <mike@brl.mil> Subject: Re: Bug in MGED

The big-E command is notorious for having difficulties. It is often handy for a "quick look", but does not handle quite a few cases. The big-E command operates by approximating everything as an ARBN, and then ray-tracing the edges to see what is left.

This does not work for concave objects, like the torus.

There is also difficulty with the big-E implementation of UNION -- it does not eliminate common area. Recall that (A union B) is done by joining all the parts of (A - B) with all the parts of (B - A). The big-E command simply joins all the parts of A with all the parts of B. Greatly simplifies the code, but produces displays with extra lines.

For the future, the big-E command will be entirely replaced with the NMG support (non-manifold geometry), which is capable of providing the correct boolean operations on any combination of primitives. The NMG support isn't done yet. Look for it in the next release.

The big-E command has been a handy visualization tool. But, please don't use it's output as a definitive representation of the shape.

Thanks for the bug report! Best, -Mike Date: Tue, 15 May 90 18:59:12 EDT From: Doug Gwyn (VLD/VMB) <gwyn@BRL.MIL> Subject: problem with /usr/brlcad/lib/libplot3.a on WAFFLE

This library doesn't seem to provide space3(), line3(), color(), etc. I thought it was supposed to be a superset of /usr/5lib/libplot.a? Date: Tue, 15 May 90 23:37:46 EDT From: Phil Dykstra <phil@BRL.MIL> Subject: Re: problem with /usr/brlcad/lib/libplot3.a on WAFFLE

This library doesn't seem to provide space3(), line3(), color(), etc. I thought it was supposed to be a superset of /usr/5lib/libplot.a?

No. From the source code (note numbers 1 & 4):

* These routines generate "UNIX plot" output (with the addition * of 3-D commands). They behave almost exactly like the regular * libplot routines, except: * * (1) These all take a stdio file pointer, and can thus be used to * create multiple plot files simultaneously. * (2) There are 3-D versions of most commands. * (3) There are IEEE floating point versions of the commands. * (4) The names have been changed.

To support the traditional unix plot commands what you could use is a simple set of #define's to map xxx(...) into pl_xxx(stdout,...). [I used to have one of these but a quick search didn't turn it up.]

- Phil Date: Mon, 21 May 90 16:12:53 EDT From: Gary S. Moss (VLD/VMB) <moss@BRL.MIL> Subject: Demoing BRLCAD images on a IRIS 4D.

Hi, John Anderson just asked me a question that probably has been asked many times before: "How do you display your RLE or PIX files in a loop under the IRIS window manager without the window going away *and* not end up with a million lingering windows on the screen that you have to kill manually?". Well I thought of something that works real well, I wouldn't be surprised if many of you already discovered this, but just in case, here goes...

1) Open a lingering, shared high resolution (1024x1024) window as follows (the '$' is the shell prompt [;-b yuh-hilk]):

$ FB_FILE=/dev/sgil fbclear -h.

2) Send the images with FB_FILE set to the default (/dev/sgi):

$ FB_FILE=/dev/sgi rle-fb foo.rle

This will put up foo.rle, then when that window vanishes, the lingering window underneath it will get an expose event and redisplay foo.rle because it is a window into shared memory. This typically happens so fast that it doesn't look like second the window vanished at all.

Note: If more than 1 image is to be displayed, substitute step 2) with a shell loop which prompts you for a Return between images.

Note: If you are mixing high and low res. images, portions of previous high res. images will still be visable behind low res. ones. If all images are low res, change step 1) to use low res.

Note also: this works well remotely.

3) Click the mouse on the window to kill it when you are done.

NOTICE: If you don't understand this DON'T CALL ME, just send me a note.

-Gary

Date: Tue, 22 May 90 14:53:53 EDT From: Mike Muuss <mike@BRL.MIL> Subject: mged color plot overlays

I have just revised the development version of MGED so that when the "overlay" command is used to overlay a UNIX-plot file on top of the current display, the color information found in the plot file is retained in the MGED display.

This has proved helpful for examining some of the NMG debugging.

Best, -Mike From: Phil Dykstra <phil@BRL.MIL> Newsgroups: brl.support Subject: Re: /usr/include/brlcad vs. /usr/brlcad/include Date: 23 May 90 19:10:41 GMT Sender: news@adm.brl.mil

Why don't you check with the BRL-CAD folks instead of guessing. They finally were convinced that putting local headers in /usr/include was poor practice and have changed BRL-CAD to have them where I said. To support (for a transition period) existing applications that were looking in /usr/include/brlcad, a symbolic link is appropriate, with the expectation that it will be removed eventually.

Ok, from a BRL-CAD folk:

No I am not conviced that putting things in /usr/include is a bad practice. That is part of a programmers interface to UNIX. You should not have to go hunting everywhere for include files and libraries.

We have decided to start putting all binaries/libraries/include files etc. for a package xxx (such as brlcad) under /usr/xxx/* for ease of system maintenance, and "linking it into the system" via a symlink in /usr/include/xxx to /usr/xxx/include, and by teaching ld (where possible) about /usr/xxx/lib, and man about /usr/xxx/man.

The last release of BRL-CAD was not configured this way. The next one will be. But the symlink will stay.

- Phil 29 May 90 17:37 EDT Date: Tue, 29 May 90 16:25:59 CDT From: Mbowden@redstone-emh2.army.mil Subject: Monotonic Non-decreasing Database Sizes

Apparently, deleting objects within mged does not actually remove data from the model database. If this is indeed the case, is there a good way to compact the mged databases?

Mark Huston Bowden <Mbowden.ssdd@REDSTONE-EMH2.ARMY.MIL> Date: Tue, 29 May 90 22:09:32 EDT From: Phil Dykstra <phil@BRL.MIL> Subject: Re: Monotonic Non-decreasing Database Sizes

You are correct that the on disk database is not compacted when objects are deleted. The empty slots will be used however by any newly created objects.

If you do wish to compact it one way that comes to mind would be:

g2asc < orig.g | asc2g > compacted.g

- Phil Date: Mon, 4 Jun 90 10:35:28 EDT From: Paul Tanenbaum <pjt@BRL.MIL> Subject: Compiling on victor.brl.mil

Tried to compile a fairly simple program on a 4D running BRLCAD 3.2, and got hollered at about a function I'm not explicitly calling. According to the man page, USINIT(3P) is a semaphore and lock initializer. If it's being used within LIBRT, how come the loose end? +++paul

Script started on Fri Jun 1 15:03:33 1990 $ make /usr/bin/cc -I/usr/include/brlcad -c opfile.c /usr/bin/cc -I/usr/include/brlcad -c sigma.c /usr/bin/cc opfile.o sigma.o /usr/brlcad/lib/librt.a -o opfile -lm /usr/bin/ld: Undefined: usinit *** Error code 1

Stop. $ grep usinit * $ exit

script done on Fri Jun 1 15:04:23 1990

Date: Mon, 4 Jun 90 21:55:03 EDT From: Mike Muuss <mike@brl.mil> Subject: final word: brlcad includes

I determine the tree structure.

In this discussion, all parties were "mostly right". The scoop is:

Release 3.7 uses /usr/include/brlcad Release 4.0 (not yet out) will use /usr/brlcad/include, with a symlink from /usr/include/brlcad.

The development system operates in the new style (brlcad/include), but all the production systems operate in the old style (include/brlcad).

Everything should become consistent with the next release. I think Doug was just caught off guard by the (admittedly lengthy) transition period (ie, both arrangements can currently be found).

Best, -Mike Date: Mon, 4 Jun 90 22:09:39 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Re: Compiling on victor.brl.mil

When building an application that uses LIBRT, you must also link against the library listed as LIBRT_LIBES in Cakefile.defs. Here is the comment in Cakefile.defs:

* * * Note that when applications link with certain BRL-CAD * * libraries, they must also link with some related libraries. * * This relationship is listed in this table: * * * * LIBRT LIBRT_LIBES (formerly RT_LIBES) * * LIBFB LIBFB_LIBES * * *

If you are using MAKE rather than CAKE for your application, then you will need to dig out the particular vendor-specific settings for these libraries and add them to your Makefile. In particular, you should note that on the SGI 4D machines:

# define STANDARD_LIBES -lm -lc # define LIBRT_LIBES -lmpc # define MGED_LIBES -lbsd -lgl # define LIBFB_LIBES LIBPKG -lbsd -lgl

The settings for these defines will be quite different on other brands of computer. Having CAKE automaticly select the right settings is one of the reasons that we switched from MAKE to CAKE.

Best, -Mike

PS: Note that for compatability with older Cakefiles, :

#define RT_LIBES LIBRT_LIBES /* compat w/old Cakefiles */ Date: Tue, 10 Jul 90 16:16 PDT From: LAGUNA@icdc.llnl.gov Subject: Choosing Workstations for Use with BRL-CAD

We are considering the purchase of several workstations for use by individual engineers. One of the uses of these workstations will be modeling with the BRL-CAD package. Since we want to keep costs low (under $25K each) and performance good, the workstations which we are currently considering are

Personal Iris Sparcstation Decstation We would be interested in hearing any comments about the above machines as they relate to the BRL-CAD package (or general performance) and any other machines which the BRL-CAD community deems worthy of examination. Also, since X is available on all of these machines, we are interested in whether or not color for X-windows will be available in the next release of the CAD Package and when that release might be expected. Thanks.

Gary Laguna Lawrence Livermore National Laboratory laguna@icdc.llnl.gov

Message-Id: <9007101128.AA07850@decpa.pa.dec.com> Date: Tue, 10 Jul 90 04:29:00 PDT From: "Mgr. Open System Migration Program, LSE, PDF, SCA 10-Jul-1990 0707" <ellenberger@tle.enet.dec.com> Subject: Rookie Questions

I haven't seen any "READ THIS BEFORE POSTING" mail in this group, so I'll go ahead and ask about some of the things I've run into after spending an hour or two with the package:

1) Has anyone done the Cakefile.defs and other changes necessary to install brl on a DECstation rather than a VAX? If so, I'd appreciate mail on the subject.

2) What macro packages do I use to format the docs? -ms does most of it, but I'm left with all the tables unformatted and this makes install.tr pretty hard to read.

3) Has anyone compiled this stuff on a VAX lately? I tried to build it on our 60xx file server running Ultrix 3.1 and I came-up with some illegal typedef errors that caused the mged build to abort. I haven't tracked them down yet, but it looks like u_char might have conflicting definitions between some header file and the typedef declarations in dm-xxx.c programs.

Also, I scanned the Cakefile and it looks like (although I'm brand new to all of this) it doesn't even build the X11 interface. This seemed a little strange since that's pretty standard on Ultrix (or even vanilla BSD) these days.

Sorry if these are too naive, but I'm taking advantage of the "I'm just a rookie" excuse while I still can... Date: Tue, 10 Jul 90 21:54:00 EDT From: Phil Dykstra <phil@BRL.MIL> Subject: Re: Rookie Questions

1) Has anyone done the Cakefile.defs and other changes necessary to install brl on a DECstation rather than a VAX?

Sorry. I don't have any.

2) What macro packages do I use to format the docs? -ms does most of it, but I'm left with all the tables unformatted ....

Use "tbl" first. Most of the documents will have a comment string at the top with a sample formatting line. E.g. from install.tr: .\" tbl install.tr | troff -t -ms | ... For the papers, there is a Makefile you can look at.

3) Has anyone compiled this stuff on a VAX lately? I tried to build it on our 60xx file server running Ultrix 3.1 ...

Sorry, "VAX" to me still means a 7xx running BSD. We have some 60xx's here running Ultrix. I will try to make a note to test the next release on them. The only Ultrix caveat that I remember is that the C compiler needed "#define CC_DEFS -Dvoid=int". That was quite some time ago though.

I scanned the Cakefile and it looks like it doesn't even build the X11 interface. This seemed a little strange since that's pretty standard on Ultrix (or even vanilla BSD) these days.

Since BRL-CAD is not using "Imakefiles" like X, linking to X can be a very machine type specific, and even site specific thing. As it becomes standard on more and more machines, it will probably get used by default in Cakefile.defs. For now, look at the couple of places it is used in Cakefile.defs for an example of how to add it to your configuration.

- Phil Message-Id: <9007191013.AA24250@decpa.pa.dec.com> Date: Thu, 19 Jul 90 03:13:10 PDT From: "Mgr. Open System Migration Program, LSE, PDF, SCA 19-Jul-1990 0556" <ellenberger@tle.enet.dec.com> Subject: More Rookie Questions

1) I gather from reading one of the documents that there is X support for rt, but I can't figure out from reading docs and header files how to set FB_FILE or (-F) to drive X.

2) Since I see the NFF document sitting around, I'm curious whether you have any intention of supporting NFF format (i.e. exporting geometry).

3) If I'm modeling away on X and I want to generate a postscript plot of a particular view (and return to modeling), what commands do I issue?

4) Is there a document that I missed that provides up-to-date information such as 1)? I think I read or at least scanned most of the documents and I didn't find the data. Date: Thu, 26 Jul 90 4:36:52 EDT From: Phil Dykstra <phil@BRL.MIL> Subject: Re: More Rookie Questions

> 1) I gather from reading one of the documents that there is X support for > rt, but I can't figure out from reading docs and header files how to > set FB_FILE or (-F) to drive X.

See "fbhelp" to find out what frame buffers are supported on your system. If X is compiled in it will be "/dev/X".

> 2) Since I see the NFF document sitting around, I'm curious whether you > have any intention of supporting NFF format (i.e. exporting geometry).

I wrote a partial NFF -> g translator a year or two ago. Exporting g to NFF would be very hard (missing primitives, no booleans, etc.).

> 3) If I'm modeling away on X and I want to generate a postscript plot of > a particular view (and return to modeling), what commands do I issue?

You could either (1) "xwd" dump the X window and print it, (2) "release" the MGED window and "attach" to the "ps" device (which will write a postscript file for you), or (3) unix plot it with the "plot" command and convert that to postscript with "pl-ps".

> 4) Is there a document that I missed that provides up-to-date information > such as 1)?

Libfb(3) has some, and brlcad(1) has some, but "fbhelp" is the best place to start.

- Phil Date: Tue, 10 Jul 90 16:16 PDT From: LAGUNA@icdc.llnl.gov Subject: Choosing Workstations for Use with BRL-CAD

Gary Laguna Lawrence Livermore National Laboratory laguna@icdc.llnl.gov

Date: Tue, 10 Jul 90 22:19:07 EDT From: Phil Dykstra <phil@BRL.MIL> Subject: Re: Choosing Workstations for Use with BRL-CAD

I think it will be a long time (if ever) until an X interface to BRL-CAD will have as high of performance as a platform specific one (e.g. GL, SunView, StarBase). On wire-frame displays (MGED), the Sparcstation under SunView didn't do as bad as I would have thought compared to a Personal Iris (PI). Models would "vectorize" at approx the same speed. The PI did the resulting wire frame ~4x faster. I have not benchmarked the Decstation under X.

Other non-X factors are that the next release will include support (in the SGI GL interface) to do hardware lighting of polygonal surfaces (and some code to generate those surfaces!, but I'm letting the cat out of the bag). 24-bit color is also worth considering.

we are interested in whether or not color for X-windows will be available in the next release of the CAD Package and when that release might be expected.

Color X support, yes. Also "frame buffer servers" which will help all window system machines. When? My unofficial answer is that I can't see it comming out sooner than September, which may mean Thanksgiving, but I hope it's before then.

- Phil Date: Thu, 26 Jul 90 21:27:22 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Re: rt_shootray()

You can see if the start point lies within the model RPP with this bit of code:

(where "rtip" is the return from rt_dirbuild(), and pt[] is the point to test).

if( (pt[X] >= rtip->mdl_min[X] && pt[X] <= rtip->mdl_max[X]) & (pt[Y] >= rtip->mdl_min[Y] && pt[Y] <= rtip->mdl_max[Y]) & (pt[Z] >= rtip->mdl_min[Z] && pt[Z] <= rtip->mdl_max[Z]) ) { /* The point is inside the model RPP */ }

Best, -Mike Date: Sat, 25 Aug 90 11:35:20 EDT From: Mike Muuss <mike@brl.mil> Subject: Re: Various (repost, with additions)

Greetings!

Sorry about the long delay in responding, I have been swampped with my preparations for two big conferences (just back from Scotland, leave in 2 weeks to teach a tutorial, give a paper, and teach a class at Ausgraph in Australia). These trips have overwhelmed me with work!

I forwarded your message to Bill Mermagen. He returned just in time to dart off to SIGGRAPH. His E-mail address is <wm @ brl.mil>.

To answer your questions:

a) I am unaware of anyone having modified the Cakefiles to create shared libraries on the Sun. We now have SunOS 4.0.3, so this is a good thing to put on the "to do" list.

b) We have plans to use the GNU command-line editor library for MGED. We miss this too, using TCSH as our Shell all the time.

c) Since we write the documentation ourselves (no paid technical writers here), there isn't as much as I might like. On the other hand, I think that we have done astonishingly well. Terseness is still our biggest problem, yet more and more users fail to read the manuals due to their rather large size. I don't know how to win on this one. The next set of manuals will be much thicker; I don't know if that will help.

For your specific question, it is true that the LGT man page was omitted from the manual. However, there is a full paper on it, so that should help. It can also be found on the "Road Map" diagram, which shows that RT and LGT are the two programs to make color shaded images from a .g geometry database. RT is a traditional UNIX-tool, which uses command line options and/or a command script on stdin to tell it how to render things. RT can also be invoked from within MGED, to render the current view. LGT is a "user friendly" program to allow a user without a workstation to change viewpoints, change material properties, lights, etc. I prefer to use MGED to do that sort of thing, getting instant feedback via the wireframe display, but then I wrote RT, so you might expect that... Unfortunately, both RT and LGT have one or two capabilities that the other does not. Competition keeps things interesting.

d) The next version of the manual will almost certainly require three volumes. Man pages for all the URT stuff that we install by default is included in the printed manual, including the libraries. (At least, that is my impression). If you go after parts of URT that came from the "contributed" directory, then you need to print the extra man pages there, yourself. (Mostly device specific stuff there).

The style of the footers was agrivating, but so minor that we didn't have any interest in re-printing just for that. Sorry if it bothers you. Perhaps you don't understand just how small my group is: right now, we are three fulltime, with a few occasional helpers (like Gary Moss, the author of LGT).

e) We have quite a variety of database IMPORTERs already. Not all of them made it into the 3.7 release. More is planned in this area. We have almost no interest in more EXPORTERs, except for PDES. However, we are just finishing a substantial project to permit approximate polygonal tessellations of the final "developed" shapes to be exported. Useful for hardware rendering, thermal analysis, radar codes, and the like. This will be the MAJOR new feature in Release 4.0, and is also the pacing item for the release date (currently projected for November, sigh).

There is also a big push in Trimmed NURBS and a new Graphical User Interface Management System (G-UIMS), for Release 4.n where n>0.

Best, -Mike

Date: Mon, 27 Aug 90 11:55:07 EDT From: "Christopher T. Johnson" <cjohnson@BRL.MIL> Subject: Re: [Keith Goldfarb: Re: GIFs]

Hello Keith,

I'm the person at BRL that is (currently) working with reducing the amount of information in a picture and still having good resulation.

The problem of reducing 24 bits of data to 8 bits of bw or 8 bits with CLUT (gif format) is not at all simple. Paul Heckbert (sp) wrote the definitive paper on 24 to 8CLUT. His method produces some very nice output. 1) Cut from 24 to 15bits by chopping the low 3 bits of each color. 2) With the reduced color space, count the number of hits for each color. (Generate a histogram) 3) In color space, a) cut at median point along the longest axis of largest box. b) repeat until you have 256 boxes. 4) For each of the 256 boxes, pick the center as a color to put in your CLUT. (Color Look Up Table)

Once you have a CLUT the next step would be to translate your original 24 bit image into an 8bit image of CLUT look ups.

I have not (yet) implimented a color dither program but the theary is the same as for doing black and white dithering. I will try and describe a Floyd-Steinburg color dither.

1) zero error line (RGB * length of scanline) 2) read line from file 3) going from left to right do: Pix += thisline[X]; thisline[X] = 0;

value = closest(Pix); diff = Pix - value;

if (X+Dir < width && X+Dir >= 0) { thisline[X+Dir] += diff*7/16; error[X+Dir] += diff*1/16; } error[X] += diff*5/16; if (X-Dir < width && X-Dir >= 0) { error[X-Dir] += diff*3/16; } return(value) 4) swap thisline and error; 5) repeat step 3 going from right to left 6) repeat until end of file.

The code chunk comes from my black and white version with a few simple modifications to handle color. I hope this helps to some extent and I aplogize for getting long winded. One of the reasons for babeling on is that I hope to write a color dither program RSN.

This is the method that I have been told will generate the best looking color pictures with a reduced color set. Things to be careful of are: Finding the closest color. Lossing an important color. Computing the diffrence between the Pixel read and the Pixel used. Adding the Error to the Pixel read.

The other method that I have used with fair results to view 24bit pictures with 8 bits or less is to split the 24 bit image into three 8bit images of the red, green and blue channels.

Dither each channel as a simple gray scale image down to 6 levels. Set your CLUT so that CLUT[r*6*6+g*6+b].red=r*255/6; .green=g*255/6; .blue=b*255/6;

Your final CLUT indexs would be red channel *36 + green channel*6 + blue channel.

This uses only 216 colors but should give you a "reasonable" picture.

Good luck and if you have any questions feel free to e-mail them to me and or mike.

Chris Johnson <cjohnson@brl.mil> Date: Thu, 27 Sep 90 10:16:15 EDT From: Paul Stay <stay@brl.mil> Subject: re:Spline Solids

The teapot program is good example for creating a b-spline solid using the libspl library, the fact that its from IEEE CG&A, is just a side light. Other splines solids and surfaces should be created in a similar manner. But to answer your questions.

1. What determines the # granules of knots? 2. What determines the # granules of ctls?

A granule is the size of a database record as defined in h/db.h and usually is a solid description. In a few instances such as ARS solids and Spline solids a granule can contain floating point values of either knots or control points.

Let say you have a spline surface which has 30 knots. then the number of granules is

gran = (number of floats) + (sizeof( union record)-1) / sizeof(float)); gran = (gran * sizeof(float)) / sizeof(union record);

Thus a spline solid database record consists B-spline solid header record b-spline surface record n granules (records) of floats (knots values) n granules (records) of floats (control point values)

3. What is the difference between geom type 3 and 4.

The geom type is whether the b-spline surface control points consist of Rational 3 space points (X,Y,Z,W) or Non Rational 3 Space points (X,y,Z).

-Paul Date: Tue, 18 Sep 90 9:28:55 EDT From: Robert Shnidman (VLD/VMB) <robert@BRL.MIL> Subject: Re: [J. Terrence Klopcic: [J. Terrence Klopcic: Ullyatt]]

Paul, Correct answers ought to be at least as important an issue as user-friendliness when it come to compare BRL-CAD with FASTGEN. Let me related a piece of my limited experience with FASTGEN. I had John Anderson run FASTGEN on a PATCH description I obtained from DRI. As is evident from the shotline file, overlaps were not resolved at all! That is, volume of the overlap was assigned to BOTH of the overlapping regions. If only real armor were that good.

Bob Date: Wed, 24 Oct 90 8:16:31 EDT From: "John R. Anderson" (VLD/ASB) <jra@BRL.MIL> Subject: BRLCAD on a Sparcstation 1+

Out of curiosity I installed BRLCAD on my new SParcstation 1+. I have included the bechmark results below. Everything compiled fine with the exceptions of LGT and FBED. MGED seems to work nicely under SUNVIEW. The operating system is SunOS 4.1.

Abs whisper.brl.mil 1118.35 561.81 473.52 439.76 509.26 620.54 Tue Oct 23 18:18:24 EDT 1990 *vgr whisper.brl.mil 8.69 10.31 10.48 10.89 10.38 10.15 Date: Sat, 3 Nov 90 16:13:48 EST From: Mike Muuss <mike@BRL.MIL> Subject: Minor additions

This afternoon, pix-fb, bw-fb, and pixhalve all got a "-a" flag, which invokes an AUTOSIZE option. A table of common image sizes is consulted, and if the input file size matches the size found in the table, then those values for width & height are used. This goes a long way to keeping the "headerless" image file formats convenient to use (given that we often work with images other than the default 512x512 now).

I imagine that many of the other programs that deal with images will also acquire this flag.

pixhalve is a program to downsample an image to one-half it's original size. It does so using a 5x5 filter kernel to obtain each pixel in the output file. The intent was that a single-pixel wide feature in an input image will be guaranteed to influence at least two pixels in the output file. This becomes quite significant when producing images for NTSC video. When pixhalve takes a 1280x960 image and makes a 640x480 result which is displayed on a composite NTSC monitor, the results are really terrific looking images. It may be possible to do better, but this defines a new high point in our ability to prepare images for NTSC video display.

Along the way, I added a few lines to libfb/if_disk.c, so that the framebuffer named "-" is now a synonym for standard output. If a program that writes to a framebuffer is "well-behaved" and writes scanlines in ascending order, then that program can be used in a pipeline for further processing. As a silly but potent example,

fbclear -F- 100 200 100 | pixmatte ....

is a way of creating a file of a given color of exactly the right size. (The other, better, way of actually doing this is with GENCOLOR).

For program that are not well-behaved in writing to the framebuffer, this can be stacked with the /dev/mem interface, so that things like

fbgrid -F "/dev/mem -" | pixmatte ....

can be done.

Best, -Mike Date: Thu, 22 Nov 90 3:37:41 EST From: Mike Muuss <mike@brl.mil> Subject: rtsrv looping on exit: fixed

This evening I discovered why RTSRV, when aborted, often seems to leave one CPU spinning: while trying to send a last message via rt_log(), it called pkg_suckin(), which noticed that the TCP connection had gone away, so it went to the user-provided error logger (rt_log, in this case), which is semaphore protected, and deadlocked in RES_ACQUIRE. I just changed it to use pkg_errlog() instead (the default), so that libpkg errors detected by the worker don't result in more libpkg messages being sent. (Generally pointless, anyways).

Best, -Mike From: "Michael John Muuss <mike>" <mike@BRL.MIL> Newsgroups: comp.graphics Subject: 3/4" -vs- S-VHS, etc. Date: 22 Nov 90 03:55:05 GMT

(I wrote this rather lengthy response, to INFO-IRIS. It seemed worthwhile to share it with this somewhat larger community as well. Please note that many of my assessments are subjective; if you have achieved different results, by all means report them. Mileage varries. -Mike)

In a recent note to INFO-IRIS, Stuart Levy wrote:

>> From what I hear, super-VHS is supplanting 3/4" tape. (In fact, JVC and >> Panasonic are discontinuing their 3/4" lines.) SVHS uses Y/C component video, >> with two channels on the (1/2") tape, one each for luminance (Y) and chroma (C) >> plus the usual audio stuff. SVHS is supposedly higher resolution than 3/4" >> but somewhat worse noise. The difference is apparently not large, but >> SVHS equipment is decidedly cheaper. ...

This is somewhat misleading. 3/4" U-matic tape is also recorded as separate luminance (Y) and chroma (C), as is regular VHS, Super-VHS, and many other formats. The differences between these formats are in terms of bandwidth available for each signal, and signal/noise ratio.

While some very low-budget operations have begun mastering on S-VHS, there is no question that S-VHS is a lower quality format than 3/4". A 5th or 6th generation dub on 3/4" is still of acceptable quality (although not prizewinning), while the same can not be said of even a 3rd generation S-VHS dub. Certainly not with any S-VHS equipment that I have worked with.

It is important to note that the Y/C bandwidths on 3/4" come in two flavors as well. Regular 3/4" has about 260 lines of resolution (e.g. about 520 pixels/scanline), while SP-format 3/4" has about 360 lines, or about 720 pixels/scanline. The NTSC format is bandwidth limited by law to have no more than 720 pixels/scanline, so this is as good as it gets in real NTSC. Wider bandwidth signals can be easily created in your studio (the "multiburst" signal from most test sets is an example), but it isn't real NTSC. Thus, the SP version of 3/4" fills roughly the same need for 3/4" users that S-VHS serves for VHS users, but with the 50 dB video S/N and tape speed stability of the 3/4" format.

A QUALITY COMPARISON: Subjective, and Measured.

Just last week, I had the opportunity to make several dubs of my recent video, and used this chance to compare S-VHS to regular (not SP) 3/4". I tried to give the S-VHS dub every advantage. I used my NEC 1000 S-VHS machine ($1000), which I have measured as having about 375 lines of resolution in S-VHS mode (i.e., full NTSC bandwidth) on the composite NTSC input. Note that the manufacturer claims this machine to have "425 lines of resolution" when fed a non-band-limited S-Video (Y/C) input signal (which is hard to come by).

I connected the output of the 1" mastering machine directly to the composite NTSC input of my S-VHS deck, and used TDK's best S-VHS tape. Hi-Fi sound was also taken straight from the 1" machine. (BTW, 1" machines have rather mediocre sound, ~45 dB S/N, compared to better than 80 dB S/N on a Hi-Fi VHS or S-VHS deck). Next, I also made a copy on 3/4", through the regular distribution amps, i.e. I had additional gunky circuitry in the signal path over the S-VHS dub.

Comparing my S-VHS dub to the 3/4" dub requires no special talent. The S-VHS copy is *much* noisier than the 3/4" copy. And recall, this is conventional 3/4", *not* the wider bandwidth SP format. The S-VHS is still quite good to look at, but not nearly as nice as the 3/4". If you are accustomed to viewing NTSC only on VHS tape, you would not be upset, but if you are accustomed to viewing NTSC as it exists in the mastering process, you would mourn the loss.

However, it is true that 3/4" is no longer the best way to capture video. In order of increasing quality, the competition comes from Hi-8, Betacam SP, D-2 digital, and D-1 digital. Betacam SP is a "component" video system, recording Y, R-Y, and B-Y signals, rather than Y and C. D-2 is a "composite" (Y/C) digital format, and D-1 is the "component" (Y, R-Y, B-Y) digital format. D-2 decks are now available for less than $50k, and the prices are comming down. Since a good 3/4" machine costs from $10k to $30k, this isn't such a large price difference (reference: the Sony BVU-850 and BVU-870). Note, however, that while the digital formats offer zero generation loss, the digital format has inherrent quantization, which can be quite noticable in the D-2 format. 8 bit samples are just not wide enough; we need 10 or 12 bits to satisfy the discerning eye, even with dither used to prepare the original signal.

Mind you, I'm no big fan of NTSC -- it is a very limiting, low quality video format. But, it has supplanted 16mm film (a superior quality format) as the standard way of communicating scientific results, so one might as well understand it, and master it. NTSC, when done well, can be a very striking and effective way of communicating.

AN EXAMPLE OF MAKING A VIDEO

Just to give you a quick idea of how I created my recent video:

Images were created in RGB at 1280x960, and decimated using a 5x5 filter kernel down to 640x480. These RGB images were converted to Y/U/V format, the U and V data was low-pass filtered to meet NTSC bandwidth limitations, and the YUV data was transmitted over Ethernet to an Abekas A60 digital video disk ($60k), where they were stored in D-1 digital video format.

When an entire segment of video had been loaded onto the Abekas, it was played back in real time, under control of an FCC-approved broadcast quality sync generator. The RGB outputs of the Abekas were sent to a Faroudja CTE-1 RGB->NTSC encoder ($7k), and the composite NTSC was recorded on a Sony BVU-870 3/4" VTR ($30k) with SMPTE time code generator.

Real-time sequences were captured from an SGI-4D/240 GTX ($100k) with CG3 board ($7k?). The sync pulses were fed into the CG3. With the SGI in NTSC mode, genlocked to "house sync", it provided RS-170 RGB, which was fed into the Faroudja encoder, and the composite NTSC was recorded on the BVU-870. I note in passing that the CG3 still does not succeed in producing broadcast quality video, although it is far better than earlier attempts. Unlike earlier SGI CG boards, the output of the CG3 is sufficiently good that it can actually be used, if you don't mind "tweeking" the Faroudja into forgiving SGI's sins.

Each segment went onto a separate 3/4" cartridge, and all were indexed event-by-event according to the time codes. This allowed the script to call for segments to be assembled with individual frame accuracy. (Allow me to make a BIG PLUG for the use of SMPTE time code on your video tapes. It makes the editing process vastly easier, and more accurate).

All the 3/4" original tapes went into a big box, and I took it all to our 1" edit suite. The original tapes were read on a pair of Sony 3/4" machines (VO series), stablized by a time base corrector (TBC), routed through an edit controller with Ampex effects box (for fades and wipes) and Ampex ADO (for inset screens, flip-away effects, and "MTV" style rotating and tumbling images), after which each finished sequence was recorded on an Ampex 1" machine ($50k).

After the video was complete, I added the music to Channel 1, going from Compact Disc to the 1" machine via a sound board, where the mix to mono was accomplished. Then, I recorded the narration in a sound booth, onto a 3/4" tape. Using the same edit system, the narration track was copied onto the 1" machine (although I'm proud to say that in 8.5 minutes of narration, I only made one "flub" that we had to splice in a replacement for. This was done using the edit system, just like editing video). At this point, the master tape was finished.

Dubs for the final distribution were made from the 1" master onto 3/4" and VHS, through a 1->12 video and audio distribution amplifiers. Thus, the distribution copies delivered to the clients are only 3rd generation. Since the trip from 3/4" to 1" is "nearly lossless", the distribution copies have excellent quality. Given that, in my instance, distribution is done on 3/4" and VHS, increasing the quality of the intermediate steps is not likely to make a noticable improvement in the quality of the product. The 1" master would be completely suitable for broadcast.

Even if you don't have the financial resources to engage the services of a 1" edit suite for your video productions (not that it is very expensive), and you do all your production and editing in 3/4", you will get a high quality result. Certainly better than anything you could produce on Super-VHS.

FRAME AT A TIME

In the past, I have also done quite a bit of frame-at-a-time recording of video, using the Sony 3/4" machines and a Lyon-Lamb VAS-4 VTR controller. This produces results of equal quality (all other elements being equal), but takes longer. It is also more of a bother to find and fix botched frames when recording this way. It also requires a much smaller investment in equipment! ($5k for Lyon-Lamb Mini-VAS, plus a VTR).

LASER DISCS

On a related topic that I won't bore you with this evening, I recently investigated the quality of LaserDisc players. They are much better than consumer videotape (even Beta), but 3/4" tape does even better. The machines evaluated were the Pioneer CLD-91 ($2000) and Pioneer CLS-S2 ($3500) [the worlds finest Laser Disc player at the moment].

SUMMARY

*) 3/4" videotape is no longer the best thing around. *) 3/4" can be used to produce excellent results. *) 3/4" beats S-VHS every time (video, not audio). *) 3/4" is mature, and not too expensive.

Many alternatives exist, and lots of good stuff is happening. Keep your eyes on Betacam SP and D-2. If you have (or are) a good video engineer, there are lots of alternatives. If you don't have access to a good video engineer, the business of video recording still has a lot of pitfalls, and it will pay to be very conservative. Be suspicious.

Also, most large universities and companies have a TV studio, and there are many commercial firms in the business. Strongly consider using them to assist with your post-production needs. The aid of a professional video editor (person) can greatly increase the quality of your result; knowing when and how to use fades, wipes, etc, is more of an art than a science. Rates are generally in the $100/hour to $200/hour range, and often less.

Best, -Mike Muuss

PS: In case you are interested, all the image generation software, image filtering software, Lyon-Lamb controller software, etc are all included as a small, but significant, part of the BRL-CAD Package, which we make available for free. See SGI's software partners catalog for details, or send E-mail. From: Dave Martindale <dave@imax.com> Newsgroups: comp.graphics Subject: Re: 3/4" -vs- S-VHS, etc. Keywords: NTSC, video, videotape, recording Date: 23 Nov 90 05:20:59 GMT

In article <14556@smoke.brl.mil> mike@brl.mil writes:

[ lots of useful and interesting stuff about video recording. However, there were a few errors I'd like to correct.]

>Regular 3/4" has about 260 lines of resolution >(e.g. about 520 pixels/scanline), while SP-format 3/4" has about >360 lines, or about 720 pixels/scanline.

Video resolution is given in lines, not line pairs. 2 lines == 1 line pair == 2 pixels. So a vertical resolution of 485 lines is really just 485 pixels. Horizontal resolution is a bit odd, since it is usually specified as "lines per picture height" rather than "lines per picture width". Because of the 4:3 aspect ratio, a horizontal resolution figure of "330 lines per picture height" is really "440 lines per picture width", or 440 pixels, or 220 line pairs.

Even when you see resolution quoted as "330 lines" with no other qualifiers, they really mean 440 pixels H resolution. This is because vertical resolution should always be the same with a properly-interlaced TV, so nobody quotes it, while horizontal resolution depends on bandwidth which does vary. And because H resolution is quoted in terms of picture height, not picture width, even when only H resolution is being given.

This is all a bit weird for those of us used to thinking in pixels.

>The NTSC format is >bandwidth limited by law to have no more than 720 pixels/scanline, >so this is as good as it gets in real NTSC.

An NTSC signal is limited to 4.2 MHz bandwidth when broadcast. This is equivalent to just about "330 lines" or 440 pixels (horizontal). More pixels than that doesn't gain you any resolution if it's going to be broadcast. Some frame buffers have 512 because it's a convenient number (power of 2), some use 640-650 because it's a convenient number (square pixels), but they won't give any more resolution when broadcast.

720 pixels is what is used by D-1 digital recorders; that's just what the width comes out to with a 13.5 MHz sampling rate. This probably allows them to have about a 6 MHz bandwidth, but anything beyond 4.2 will be lost on broadcast (but is useful for multi-generation processing).

All of the above figures are for luminance bandwidth only. Colour bandwidth is always less. D-1 digital recorders give half as much bandwidth for the two colour components as the luminance gets, and everything else is worse. The NTSC standard itself specifies about 500 kHz bandwidth for the Q colour channel, which is equivalent to about 53 pixels horizontally. Yes, yechh. That's why colours smear well beyond the boundaries of the pixels that are supposed to be coloured. The I channel gets somewhat more than twice that, but most (or all) consumer TV sets discard it, limiting both I and Q to 500 kHz.

Dave Martindale Date: Mon, 26 Nov 90 13:26:49 EST From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> Subject: Re: lgt on Sun3

Mike, I fixed the warnings generated on vision (under SunOS 4 Sun fixed the signal() declaration). Since there is no preprocessor define specific to SunOS 4, warnings will now occur under older releases unless the user compiles with -DSunOS4=0. Correct code will be produced either way, but perhaps we should document this somewhere, besides in the source code.

There is a good chance that similar warnings will appear on other machine types; It's hard to predict when various vendors will fix this.

Thanks for the bug report, -Gary

Date: Thu, 29 Nov 90 21:48:44 EST From: Phil Dykstra <phil@BRL.MIL> Subject: Re: a troff link with CAD?

I use a package called "psfig" under Latex (or TeX) for including postscript figures in reports. BW and PIX files, as well as MGED displays, can be converted to postscript and included that way. If you are running under X, the program xdvi can be used to preview the TeX output (with blank spaces where the figures go) or "gs", the GNU postscript interpreter, can show you the final postscript output (from dvips) figures and all, although this is pretty slow.

There is a TROFF version of psfig, though I have not tried it. I believe that Mike Muuss <mike> and Lee Butler <butler> have used it before so you may want to ask them for details.

- Phil Date: Fri, 30 Nov 90 0:57:15 EST From: Phil Dykstra <phil@BRL.MIL> Subject: Re: sun 386i

While none of us at BRL has tried it, I know a couple of people that seem to have compiled BRL-CAD successfully on PC/AT's running Interactive Systems Unix. It apparently only takes a few minor changes. I can send you the changes I got thanks to Garry Paxinos. [In fact I just added them to our own sources since you reminded me about it.]

- Phil Date: Wed, 5 Dec 90 5:51:46 EST From: Mike Muuss <mike@BRL.MIL> Subject: new g2asc, asc2g

This evening, I spent several hours testing new versions of g2asc and asc2g that were provided by Sue. These new versions have two major areas of enhancement:

1) They support particle and pipe solids (similar to GIFT WIR solids). (Some of the code was temporarily grafted out of LIBRT until the import/export interface exists).

2) The new asc2g uses LIBWDB for most of it's output operations, making it easier to understand and maintain. This is also an important precursor to the (post-Release-4.0) database format change.

This is a nice piece of work.

Because these converters are central to database integrity, and are critical in the moving of databases from one architecture to another, they got rather extensive testing. I solicit other BRL-CAD developers to experiment with them for a few minutes, when convenient, as an extra double-check of my testing.

The new software correctly converts all the databases in wolf:/m/cad/db back and forth, with these caveats:

1) LIBWDB has the axis of the torus rotated 45 degrees from the way that ASC2G did it. This results in the same torus, but the numbers in the file are different. This kicks out a handful of non-harmful differences when comparing solid type 16 records (TOR).

2) Unused entries for the sphere, polygon, etc, are zeroed now; they used to have garbage in them, which was carried around in the .asc file.

3) The c_num and m_num fields are forced to zero, and do not propagate. (These were GIFT solid numbers once upon a time, and are no longer relevant.)

4) The current working units from the last MGED session (kept in the ID record) are not brought along, because the mk_id() routine does not allow this field to be set.

With these caveats, the new converters produce the "same" results as the old converters. Please speak up if you can break them.

Best, -Mike Date: Mon, 25 Jun 90 13:42:56 EDT From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> Subject: MGED not giving some READ-ONLY messages?

Someone just got confused when edcodes failed to update the desired region characteristics; it turns out that the file was read-only and that MGED did NOT complain about it being read-only! Other things I found that weren't quite right: units command gave no complaint, title command gave only "error", and notice what happened in my attempted use of "killall r1" in this script on vmb.brl.mil host:

Script started on Mon Jun 25 13:40:53 1990 [env]$ mged test.g BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 88 Fri May 19 23:12:38 EDT 1989 mike@spark.brl.mil:/m/cad/.mged.sel

test.g: READ ONLY attach (nu|tek|tek4109|ps|plot|X)[nu]? ATTACHING nu (Null Display) Untitled MGED Database (units=mm) mged> tops r1/R mged> killall r1 mged> tops a b mged> q $ mged test.g BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 88 Fri May 19 23:12:38 EDT 1989 mike@spark.brl.mil:/m/cad/.mged.sel

test.g: READ ONLY attach (nu|tek|tek4109|ps|plot|X)[nu]? ATTACHING nu (Null Display) Untitled MGED Database (units=mm) mged> tops r1/R mged> Date: Fri, 7 Dec 90 23:17:07 EST From: Mike Muuss <mike@BRL.MIL> Subject: Re: MGED not giving some READ-ONLY messages?

Carl -

This week I have been working on patching up bugs and deficiencies in MGED and related geometry database tools. In reference to the note you sent this summer (see below) I can report the following progress:

*) The MGED command EDCODES has been fixed to give error messages on read-only databases. The problem was that EDCODES didn't use the library routine db_put(), but instead had a (void)write() call.

*) The UNITS command was not checking an error return. It now prints a warning message if appropriate.

*) The TITLE command message "error" has been made more descriptive.

*) The KILL and KILLALL commands have been changed to check error returns, and make appropriate remarks. In general, all uses of the db_*() I/O routines have had their error return codes checked. Here is a sampling of the error messages that might result:

/* For errors from db_get() or db_getmrec() */

Database read error, aborting

/* For errors from db_put() */

Database write error, aborting. The in-memory table of contents may not match the status of the on-disk database. The on-disk database should still be intact. For safety, you should exit MGED now, and resolve the I/O problem, before continuing.

/* For errors from db_diradd() or db_alloc() */

An error has occured while adding a new object to the database. The in-memory table of contents may not match the status of the on-disk database. The on-disk database should still be intact. For safety, you should exit MGED now, and resolve the I/O problem, before continuing.

/* For errors from db_delete() or db_dirdelete() */

An error has occured while deleting '%s' from the database.\n", _name); \ The in-memory table of contents may not match the status of the on-disk database. The on-disk database should still be intact. For safety, you should exit MGED now, and resolve the I/O problem, before continuing.

Overall, this should make MGED more informative about errors. Hopefully, the only common error encountered will be users trying to modify READ-ONLY databases. :-)

(Of course, these modifications are only in the experimental versions of the software. At BRL, the latest versions should be available for internal testing in a few weeks. Just in time for Christmas!)

Best, -Mike

------------------------------------------------------------ Date: Mon, 25 Jun 90 13:42:56 EDT From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> Subject: MGED not giving some READ-ONLY messages?

Someone just got confused when edcodes failed to update the desired region characteristics; it turns out that the file was read-only and that MGED did NOT complain about it being read-only!

Other things I found that weren't quite right: units command gave no complaint, title command gave only "error", and notice what happened in my attempted use of "killall r1" in this script on vmb.brl.mil host:

Script started on Mon Jun 25 13:40:53 1990 [env]$ mged test.g BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 88 Fri May 19 23:12:38 EDT 1989 mike@spark.brl.mil:/m/cad/.mged.sel

test.g: READ ONLY attach (nu|tek|tek4109|ps|plot|X)[nu]? ATTACHING nu (Null Display) Untitled MGED Database (units=mm) mged> tops r1/R mged> Date: Fri, 7 Dec 90 23:23:45 EST From: Mike Muuss <mike@BRL.MIL> Subject: [Carl Moore: error message in mged] [Daniel C. Dender: Re: error message in mged]

This message addresses the issues raised by Carl and Dan, below.

A new version of db_addrec() exists, which will try hard to create temporary names for duplicates. As an example:

foo.g: READ ONLY attach (nu|tek|tek4109|ps|plot|sgi)[nu]? ATTACHING nu (Null Display) db_diradd: Duplicate of 'tor', given temporary name 'A_tor' db_diradd: Duplicate of 'platform.s', given temporary name 'A_platform.s'

Thus, the second instance of the duplicated object can be referred to by it's temporary name, and perhaps given a better name. E.g.:

mv A_tor torus3

Best, -Mike

----- Forwarded message # 1:

Date: Thu, 1 Nov 90 12:11:55 EST From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> Subject: error message in mged

I made 2 ".g" files via the converting of old ".vg" files. Now I am getting messages like this which do not go away even if I keep group "hepro" in a separate file, kill "hepro", and then concat it back in. What is the meaning of this message?

db_diradd( x10039ef0, hepro, addr=x8480, len=5, flags=x2) duplicates entry x1008a300 d_addr=x7e00

----- Forwarded message # 2:

Date: Fri, 2 Nov 90 23:32:38 EST From: "Daniel C. Dender" (SE|andr) <dender@BRL.MIL> Subject: Re: error message in mged

> What is the meaning >of this message? >db_diradd( x10039ef0, hepro, addr=x8480, len=5, flags=x2) duplicates entry x1008a300 d_addr=x7e00

Carl,

This message is a diagnostic printed at the beginning of an mged session when mged is building up an internal directory of all the object names defined in the database. It means that the name mentioned has already been defined once in the database, and that this second definition for the name is being ignored as if it did not exist *during this mged session*.

Try this procedure to see what you actually have. 1) Run the conversion from .vg to .g again (might as well start with a clean slate). 2) Keep the group "hepro" into a separate file, and kill it in this database. 3) Exit mged, and then start it up again. This allows mged to build its directory anew and thus pick up the directory entry it ignored previously. 4) You should see a group called "hepro" still in your database. If so, then somehow there were two objects in the old .vg database called "hepro". I don't really know how that would have happened, but there was a lot less error checking back then. 5) Assuming you find that you still have an object "hepro", compare it to the one in the separate file. (You can bring the other file into the database with some prefix just for comparison.) 6) If, by chance, you still receive the same error message, then you will have to repeat this procedure until everthing in your database is singly defined.

One duplicate entry message is printed for each object name found duplicated. If you see the same object name appearing multiple times then you have some serious work cut out for you.

You get rid of the extra definitions by 'keep'ing the duplicated object into a separate file. Then you kill the object in your database, and exit mged. Now start mged up again, kill the object again (to get rid of the entry that was being ignored), and 'concat' the object back in from your separate file.

Good luck.

Dan Dender

----- End of forwarded messages Date: Fri, 7 Dec 90 13:41:32 EST From: Natalie Eberius <barker@BRL.MIL> Subject: Multiple Processors

I have written an application that uses raytracing and I am interested in utilizing multiple processors. What do I need to do to implement something similar to the -P option on rt?

Thanks, Natalie Eberius <barker@brl> 6980 Date: Thu, 13 Dec 90 6:13:32 EST From: "Lee A. Butler" <butler@BRL.MIL> Subject: Changes to MGED for blit

This morning I've made some modifications to mged's tek4014 display manager that allow it to be more conveniently used with the ATT 5620 terminals (for those of us still trying to use this device for mged ;-). Now, When you are prompted for the tty device for the tek display, give the name of the terminal pseudo-device for the window running the "tek4014" emulator on the blit, followed by a space and "-b". This can be thought of as the "blit" flag to the tty device. You should be able to use the mouse to position the tektronix cross-hair cursor, and typing a return will send the cursor position to mged.

The tek4014 emulator should be started with the "-e" option.

Lee Path: adm!smoke!gwyn From: Doug Gwyn <gwyn@smoke.brl.mil> Newsgroups: comp.bugs.4bsd Subject: SunOS 4.0 frexp() bug Date: 6 Dec 90 21:34:06 GMT

We recently tried using a Sun-4 for the first time and immediately discovered that frexp(0.0,...) goes into an infinite loop. The only SunOS source code I could find around here seems to indicate that the frexp.c that I assume was used for the SPARC machine was obtained via BSD, which is why I'm posting this here.

One wonders how frexp() could possibly have passed its pre-release tests.. Date: Thu, 6 Dec 90 20:08:44 EST From: Mike Muuss <mike@brl.mil> Subject: mged big-E working (again)

I'm pleased to be able to report that MGED's big-E command in the current development MGED is working again.

You may recall that when I added the NMG support ("ev" command) to MGED, using the new tree-walker, I broke the big-E command.

What I have done is to place a private copy of the old tree walker into the big-E module (proc_reg.c), and given it some private new subroutine names, so that the big-E command can continue to operate exactly as it had done in the past, while the remainder of the software can remain switched over to the new tree walker. Not the prettiest solution, but pragmatic.

Now I don't have to worry about whether the NMG support will provide the big-E capability immediately, or not. This also means that when the handful of known MGED bugs have all been addressed, this new MGED can be put in the hands of the user community for testing (breaking), well before the release cycle gets really underway.

Onwards! -Mike Date: Thu, 13 Dec 90 16:04:45 EST From: Mike Muuss <mike@BRL.MIL> Subject: Re: Multiple Processors

> I have written an application that uses raytracing and I > am interested in utilizing multiple processors. What do > I need to do to implement something similar to the -P > option on rt?

There is only a little bit extra that you will have to add to your main program, in order to cooperate with the multi-processor support already provided in LIBRT. The global RT resource structures will need initialized, as seen in this excerpt from rt/rt.c:

/* * Handle parallel initialization, if applicable. */ if( npsw > 1 ) { rt_g.rtg_parallel = 1; fprintf(stderr,"rt: running with %d processors\n", npsw ); } else rt_g.rtg_parallel = 0; RES_INIT( &rt_g.res_syscall ); RES_INIT( &rt_g.res_worker ); RES_INIT( &rt_g.res_stats ); RES_INIT( &rt_g.res_results ); RES_INIT( &rt_g.res_model ); /* * Do not use rt_log() or rt_malloc() before this point! */

However, there remains the issue of handling the dispatching of work, and the accumulation of results, within your program. The program RT uses a "self-dispatcher" algorithm, centered on the semaphored variable "cur_pixel", to manage sharing the work between the processors. Here, whenever a processor is ready for more work, it takes the next pixel in the sceen. Thus, the granularity of the parallelism is at the pixel leve. This can be seen in this excerpt from rt/worker.c:

/* * Compute a run of pixels, in parallel if the hardware permits it. * */ void do_run( a, b ) { cur_pixel = a; last_pixel = b;

if( !rt_g.rtg_parallel ) { /* * SERIAL case -- one CPU does all the work. */ worker(); return; }

/* * Parallel case. */ nworkers = 0; rt_parallel( worker, npsw ); }

/* * Compute one pixel, and store it. */ void worker() { LOCAL struct application a; LOCAL vect_t point; /* Ref point on eye or view plane */ LOCAL vect_t colorsum; register int com; int cpu; /* our CPU (PSW) number */

RES_ACQUIRE( &rt_g.res_worker ); cpu = nworkers++; RES_RELEASE( &rt_g.res_worker );

resource[cpu].re_cpu = cpu; resource[cpu].re_magic = RESOURCE_MAGIC; rand_init( resource[cpu].re_randptr, cpu );

while(1) { RES_ACQUIRE( &rt_g.res_worker ); com = cur_pixel++; RES_RELEASE( &rt_g.res_worker );

if( com > last_pixel ) break;

/* Note: ap.... may not be valid until first time here */ a = ap; /* struct copy */ a.a_resource = &resource[cpu];

.... a.a_level = 0; /* recursion level */ a.a_purpose = "main ray"; rt_shootray( &a ); .... view_pixel( &a ); if( a.a_x == width-1 ) view_eol( &a ); /* End of scan line */ } RES_ACQUIRE( &rt_g.res_worker ); nworkers--; RES_RELEASE( &rt_g.res_worker ); }

The code above handles the dispatching of the work. This leaves the issue of disposing of the results. When RT sends it's results (unbuffered) to a framebuffer, this fragment of code from rt/view.c is used:

/* * Arrange to have the pixel output. */ void view_pixel(ap) register struct application *ap; { .... if( fbp != FBIO_NULL ) { /* Framebuffer output */ RES_ACQUIRE( &rt_g.res_syscall ); fb_write( fbp, ap->a_x, ap->a_y, (char *)p, 1 ); RES_RELEASE( &rt_g.res_syscall ); }

If the results are buffered (either for framebuffer or file output) the results are accumulated in a pixel array called "scanbuf". The access to scanbuf needs to be single-threaded, because most RISC machines do not have hardware byte-splice capability:

/* * Store results into pixel buffer. * Don't depend on interlocked hardware byte-splice. * Need to protect scanline[].sl_left when in parallel mode. */

case BUFMODE_DYNAMIC: slp = &scanline[ap->a_y]; RES_ACQUIRE( &rt_g.res_results ); if( slp->sl_buf == (char *)0 ) { slp->sl_buf = rt_calloc( width, 3, "sl_buf" ); } pixelp = slp->sl_buf+(ap->a_x*3); *pixelp++ = r ; *pixelp++ = g ; *pixelp++ = b ; if( --(slp->sl_left) <= 0 ) do_eol = 1; RES_RELEASE( &rt_g.res_results ); break;

followed a little later by the actual output section:

case BUFMODE_DYNAMIC: if( fbp != FBIO_NULL ) { RES_ACQUIRE( &rt_g.res_syscall ); fb_write( fbp, 0, ap->a_y, scanline[ap->a_y].sl_buf, width ); RES_RELEASE( &rt_g.res_syscall ); } if( outfp != NULL ) { int count;

RES_ACQUIRE( &rt_g.res_syscall ); fseek( outfp, ap->a_y*width*3L, 0 ); count = fwrite( scanline[ap->a_y].sl_buf, sizeof(char), width*3, outfp ); RES_RELEASE( &rt_g.res_syscall ); if( count != width*3 ) rt_bomb("view_pixel: fwrite failure\n"); }

Thus, you can see that the RT application makes use of these semaphore variables:

res_worker to protect work-dispatcher variables res_results to protect scanline[] and scanbuf[] res_syscall to protect system calls (mainly I/O)

(The LIBRT library internally makes use of res_syscall and res_model).

The RES_ASCUIRE() macro begins a critical section, and the RES_RELEASE() macro ends the critical section.

If you are generally familiar with parallel programming, this should be enough information to get you going. If you would like some additional background on parallel programming, Cray has a small, excellent publication (number SR-222) that I highly recommend as introductory reading. To relate the terminology used, this chart should help:

BRL-CAD Routine Cray Routine =============== ============ RES_INIT LOCKASGN RES_ACQUIRE LOCKON RES_RELEASE LOCKOFF rt_parallel TSKSTART plus TSKWAIT

I feel compelled to caution at this point that some algorithms lend themselves to parallelism much more readily than others do, so the amount of effort required to parallelize your application may vary. If, after reading the Cray manual, you feel that you need some additional guidance, I'd be willing to get together with you and go over your application.

Best, -Mike Date: Wed, 26 Dec 90 19:54:42 EST From: Mike Muuss <mike@BRL.MIL> Subject: cad/Cakefile.lib fix

Dear John -

Thanks for your bug report about installing BRL-CAD Release 3.7 on your SGI 4D/210VGX.

In SGI's IRIX 3.3.1, the object-file archiver was modified, necessitating this matching change to the file cad/Cakefile.lib. This information should be added to the errata sheet for Release 3.7; it has already been incorporated in the sources for Release 4.0.

My notes regarding this change were: "According to the documentation, the "u" option to AR is a modifier to be applied to the "r" command, rather than a real command in it's own right. While this has worked fine for a decade or more, it broke with SGI Release 3.3.1, sigh. Might as well be standard."

The fix is to change line 41, e.g.:

41c41 < AR u PRODUCTS OBJ EXTRA_OBJ --- > AR r PRODUCTS OBJ EXTRA_OBJ

Here is the context diff:

*** 38,44 ****

PRODUCTS:: EXTRA_OBJ OBJ rm -f PRODUCTS; EXTRA_SETUP ! AR u PRODUCTS OBJ EXTRA_OBJ RANLIB PRODUCTS

--- 38,44 ----

PRODUCTS:: EXTRA_OBJ OBJ rm -f PRODUCTS; EXTRA_SETUP ! AR r PRODUCTS OBJ EXTRA_OBJ RANLIB PRODUCTS

Best, -Mike Date: Wed, 19 Dec 90 6:37:18 EST From: Mike Muuss <mike@BRL.MIL> Subject: New SGI 4D libfb: parallel!

This evening I removed the bug-check code in libfb/if_4d.c which checked to make sure that only single-thread (uniprocessor) programs would write graphics directly to the SGI screen. This had been necessary because of a long-standing problem in libgl.

In IRIX 3.3.1, the libgl bug no longer exists, and now parallel libfb programs are free to write to the framebuffer in parallel, provided of course that framebuffer operations are performed in a critical section (i.e. bracked by RES_ACQUIRE(syscall) and RES_RELEASE(syscall) operations).

I have also modified the defaults so that the RT program on the SGI now defaults to using all the CPUs, rather than just one, since it will now work.

Considering that SGI makes multi-processor graphics systems, I shudder to think how many years it has taken to get multi-processor graphics capability working! But, at least it is here now.

...Working hard on BRL-CAD Release 4.0... Best, -Mike Date: Wed, 26 Dec 90 19:54:42 EST From: Mike Muuss <mike@BRL.MIL> Subject: cad/Cakefile.lib fix

Dear John -

Thanks for your bug report about installing BRL-CAD Release 3.7 on your SGI 4D/210VGX.

The fix is to change line 41, e.g.:

41c41 < AR u PRODUCTS OBJ EXTRA_OBJ --- > AR r PRODUCTS OBJ EXTRA_OBJ

Here is the context diff:

*** 38,44 ****

PRODUCTS:: EXTRA_OBJ OBJ rm -f PRODUCTS; EXTRA_SETUP ! AR u PRODUCTS OBJ EXTRA_OBJ RANLIB PRODUCTS

--- 38,44 ----

PRODUCTS:: EXTRA_OBJ OBJ rm -f PRODUCTS; EXTRA_SETUP ! AR r PRODUCTS OBJ EXTRA_OBJ RANLIB PRODUCTS

Best, -Mike Date: Thu, 10 Jan 91 22:27:24 EST From: Mike Muuss <mike@brl.mil> Subject: fbclear -c

I have thought about this a lot, (and I've been burned by it a lot lately), so I have reversed the sense of the -c flag on fbclear. By default, only the color is sent. If -c is given, then cmap and zoom/pan are reset as well.

To prevent novices from getting surprised by this change in behavior, in default mode, if the colormap or zoom are not normal, a message is printed.

Not clearing the cmap (especially) is much more consistent with the growing trend to use gamma correction in the colormaps. My SGI monitor certainly needs it, and it is tiresome to have to keep putting the gamma ramp back in.

Comments? -Mike Date: Fri, 11 Jan 91 9:48:21 EST From: Patrick Jonke <jonke@BRL.MIL> Subject: MGED Question

Is it possible for two people working on different terminals to edit the same mged file simultaneously? The mged file in question is located on a file server, and each of the terminals is a Personal Iris. Date: Fri, 11 Jan 91 11:12:46 EST From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> Subject: Re: MGED Question

Patrick Jonke asks what if 2 people on different terminals are editing the same mged file. It appears to me that you might end up with some of the changes made by each! (This would be different from writing out a new file with the editors "e", "jove", etc., where the version which is saved last blows away all changes made in the version saved earlier.)

I tested by editing the same mged file in

1. Two windows on a Silicon Graphics terminal (file was on a server) 2. Two MPX windows on vmb.brl.mil . Here, I then tried editing a file consisting only of 2 solids (call them "original" and "original2"). In the first window, I said "mv original first", and in the second window I said "mv original2 second". When I have done this, I have solids called "first" and "original2" in the first window, and solids called "original" and "second" in the bottom window. Then when I exited both MGED runs, and then came back into MGED, I found that the solids were called "first" and "second"! In other words, when I run MGED, I seem to have a working version of the file AND a saved version which gets updated immediately; and these versions should be the same if only one person is running MGED on that file. Date: Fri, 11 Jan 91 14:01:47 EST From: "Daniel C. Dender" (SE|andr) <dender@BRL.MIL> Subject: Re: MGED Question

Carl Moore writes:

> Patrick Jonke asks what if 2 people on different terminals are editing > the same mged file. It appears to me that you might end up with some > of the changes made by each! (This would be different from writing > out a new file with the editors "e", "jove", etc., where the version > which is saved last blows away all changes made in the version saved > earlier.)

[ and then details his experiment. ]

Carl and Patrick,

Unfortuneately, it is possible to have two people work on an MGED file at the same time. The reason it is unfortunate is that the two sessions both write into the same database, unaware of the changes made by the other. There is no file locking done by MGED to ensure that only one person works on a database at one time, and all changes are made directly in the binary database according to what each MGED session thinks the database looks like. So Carl is right, some of the changes made by each can be reflected in the new database, but not all and not in any reliable fashion.

The important point is that the two sessions are unaware of the state of the database after changes made by the other. Carl's example is misleading in that it seems that both sets of changes are retained. This is due to the simple nature of his experiment, in that the quantity changed was simply the name field in two objects that already existed in both databases. If instead the example had looked at the two sessions each adding new objects to the database then the same results would not have been seen. Only one set of changes, or one set plus the fragmented end of the second set (which would probably show up as an error), would be seen then.

So the rule (at least for now) is don't let it happen!

Dan Dender

Date: Fri, 11 Jan 91 14:33:15 EST From: Carl Moore (VLD/VMB) <cmoore@BRL.MIL> Subject: Re: MGED Question

Yes, I see the item about my experiment changing only the name fields of existing solids. But, to respond to Dan Dender, I did not intend to point out that both sets of changes are retained. It so happened that no change I made in my test cancelled another change, but the saved file still was not the same as either working file at the end of the respective, simultaneous MGED sessions.

Therefore, I tried an even simpler experiment. I made a file with just one solid, called "original", then I ran MGED in 2 windows. In the first window, I said "mv original first", and in the second window, I then said "mv original second". At this point "tab *" showed the solid to be called "second" because that was the last name change for that solid in the saved file (database), but the working files still had "first" and "second" as the respective names for that solid. When I left these MGED sessions and then re-entered MGED, the solid was called "second".

So as you have already heard: Know what you are doing if you want to run more than one MGED at the same time on the same file, or don't do it! Date: Fri, 11 Jan 91 16:21:09 EST From: Phil Dykstra <phil@BRL.MIL> Subject: Re: MGED Question

Knowing what MGED is doing inside, the answer is pretty clearly no, i.e. only one MGED can edit a single database at a time.

While you can get away with some things using multiple MGEDs, the problems will only get worse in the next release where more info is cached in memory. Dan brings up an important point though, perhaps file locking should be used so that any additional MGEDs come up in Read-Only mode.

Alternately, if people thought that multiple simultaneous edits was a really important thing, we might be able to construct a scheme with locking and file stat'ing that would allow this. However, there would still be cases which would be hard, if not impossible, to handle (e.g. in the middle of a solid or object edit, someone else modifies that same object).

In general, I would suggest that you copy some or all of the database, work seperately on those copies, and then merge the results back together.

- Phil Date: Thu, 17 Jan 91 17:57:09 EST From: Phil Dykstra <phil@BRL.MIL> Subject: Re: brl on rs/6000

A couple of us independently tried to put BRL-CAD on the R6000 several months ago. At that time the process was very difficult due to numerous bugs in the C compiler and/or OS. I don't remember the AIX revision number back then. It is likely to have gotten better, but no one here has tried again recently. I will take a shot at testing our next release against it.

- Phil Date: Sat, 26 Jan 91 5:12:42 EST From: Mike Muuss <mike@brl.mil> Subject: librt import/export

This evening I converted all the geometry modules over to the new import/export interface. This is already starting to have a simplifying effect on some of the more difficult code elsewhere. -M Date: Tue, 29 Jan 91 0:33:07 EST From: Mike Muuss <mike@brl.mil> Subject: new vlist structure

This evening, I instituted the new "chunky" vlist structures. LIBRT and RT directories have been converted over, but MGED will need some work. Lee and I will continue on this Tuesday. Best, -Mike id AA13004; Sun, 27 Jan 91 12:54:26 EST Date: Sun, 27 Jan 91 12:54:26 EST From: "Christopher T. Johnson" <cjohnson@slc1.brl.mil> Message-Id: <9101271754.AA13004@slc1.brl.mil> Subject: Mged projective mode, sgi-4d

Hello,

This weekend the development version of dm-4d (device manager for sgi 4ds) was modified so that the perspective mode key (F3) toggled through verious prospectives.

Originally the perspective key toggled between 90% perspective and orthagonal. This would simulate the -p90 and -p0 (or nothing) option to rt.

I've changed the perspective key to toggle through 90,60,45,30 and orthagonal projections. On keyboards that have led indicators the perspective light is lit in 90,60,45 and 30 degree modes.

This was done to allow for the previewing of rt anim scripts at different prospectives.

Chris id AA13012; Sun, 27 Jan 91 13:05:37 EST Date: Sun, 27 Jan 91 13:05:37 EST From: "Christopher T. Johnson" <cjohnson@slc1.brl.mil> Subject: rtsrv et al

Mike, Paul,

After getting Paul's e-mail yesterday explaining how he had changed my id on wizard and killed off the rtsrv to allow him to get work done on wizard I started thinking about ways to allow users to keep remrt from using a machine.

To this end I added to new commands to remrt hold host Drop a host and hold from adding. resume host Add a host and release any holds.

To stop an obnoxious rtsrv, do a ps -ef |grep rtsrv. This will tell where the remrt is coming from.

rtsrv whale 4446 'hold wizard.brl.mil'

This command will cause the remrt on whale to drop wizard and to ignore wizard until further notice.

rtsrv whale 4446 'resume wizard.brl.mil'

This command will cause the remrt on whale to clear the hold on using wizard and will start processing on wizard. If the time is not correct remrt will drop wizard at the next time check.

Thanks, Chris Date: Wed, 6 Feb 91 15:41:59 EST From: Mike Muuss <mike@BRL.MIL> Subject: remrt: /tmp/public_cpus

REMRT's distributed raytracing server, named RTSRV, has gained a new feature. When starting up, it reads the file /tmp/public_cpus to find out how many cpus on that system it may use. The file contains a single number, in ASCII, on a line by itself.

If the number of public cpus is zero, RTSRV will not continue to run on that machine. If the number of public cpus is positive, RTSRV will use that many cpus (not to exceed the number of physical cpus actually operating at that time). If the number of public cpus is negative, RTSRV will use "all but" that many cpus. For example, if public_cpus = -2 and the system has 8 cpus, RTSRV will use 6 ("all but 2"). These semantics follow RT's -P (number of processors) option.

This makes it possible to use some, but not all, the resources of a given machine for RTSRV. Best, -Mike

Date: Wed, 6 Feb 91 16:07:34 EST From: Mike Muuss <mike@BRL.MIL> Subject: correction: /usr/tmp/public_cpus

Oops, wrong path name. The public_cpus file actually lives in /usr/tmp, so that it persists across reboots. Best, -Mike Date: Thu, 7 Feb 91 0:51:58 EST From: "Lee A. Butler" <butler@BRL.MIL> Subject: ERIM solids

The first of the ERIM solids has been implemented. More to come.

Lee Date: Mon, 11 Feb 91 17:13:30 EST From: "Robert J. Reschly Jr." <reschly@BRL.MIL> Subject: Re: correction: /usr/tmp/public_cpus

Mike,

It strikes me that this is something of a system configuration file and should therefore live in {/, /usr/local/, ...}etc, especially if this is something you envision having long term life (i.e. there for months at a time). If you don't want to clutter the main file systems with this file, I hesitantly suggest /usr/brlcad/lib, though I have never completely forgiven the folks who brought us /usr/lib/crontab.... This also protects it from those nice little housecleaning scripts.

If you feel there must be a "public" version of this file, then I still argue for the above, with rtserv using the more restrictive of the two.

Later, Bob

Date: Mon, 11 Feb 91 20:34:35 EST From: Mike Muuss <mike@brl.mil> Subject: Re: correction: /usr/tmp/public_cpus

A couple of items:

If the file does not exist, RTSRV will re-create it.

I think that it is important that this file be writable to all users, and I expect that it might be updated pretty much at any time.

There really isn't any parallel for this kind of "configuration" file in UNIX, and we needed something right away, so I just SWAGed it and threw the file in /usr/tmp.

So far, we have managed to avoid having any system-specific configuration files in /usr/brlcad, but I could live having them, if necessary. I'm not sure what the "right" long term implementation should be.

Thoughts? -Mike Date: Tue, 12 Feb 91 9:39:30 EST From: Sue Muuss (VLD/ASB) <sue@BRL.MIL> Subject: Arbns

This morning I checked in a new set of asc2g and g2asc: this version supports arbns.

Cheers,

Sue Date: Wed, 20 Feb 91 0:25:45 EST From: Mike Muuss <mike@BRL.MIL> Subject: SGI 4d improvements

These new features have been added to the experimental MGED's SGI 4D software:

*) Can now move and resize MGED window.

*) Note account for 5:4 aspect in NTSC mode, so that circles are round on TV.

*) Clear full viewport in NTSC mode, to clean out other window stuff that may have popped up in the interim (like libfb).

These may seem like minor nits, but resizing the window had never worked. It seems that the SGI writeprotects all new bits added to your window on resize or move until you make them writable with scrmask(). Until now, a bit of trivia that had escaped me.

Best, -Mike (for cad@brl.mil) id AA01186; Wed, 20 Feb 91 23:41:23 +0100 From: Valter Cavecchia <root@itnsg1.cineca.it> Subject: Some problems Date: Wed, 20 Feb 91 23:41:21 MET Organization: Laboratorio di Fisica Computazionale I.N.F.M.

I'm a novice user of brl-cad so please apologize... I have compiled the package on a Silicon Graphics Personal Iris, it follows the output of "hinv":

1 12 MHZ IP6 Processor FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 1.5 CPU: MIPS R2000A/R3000 Processor Chip Revision: 1.6 Data cache size: 8 Kbytes Instruction cache size: 16 Kbytes Main memory size: 12 Mbytes Integral Ethernet controller: Version 0 Graphics board: GR1.1 Bit-plane, Z-buffer options installed Integral SCSI controller 0: Version WD33C93 Tape drive: unit 2 on SCSI controller 0: QIC 150 Disk drive: unit 3 on SCSI controller 0 Disk drive: unit 1 on SCSI controller 0

and "uname -a": itnsg1 itnsg1 3.3.1 08201206 IP6

I found a problem compiling the sources, a lot of programs were linked (using the default Cakefile) without the lgl_s library...

Now the REAL problems: First, when I invoke mged I found the following errors regarding DIALDAEMON, it is important? Is there any way to bypass this?

BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 1 Mon Feb 18 22:10:03 MET 1991 root@itnsg1:/home/brl/mged attach (nu|tek|tek4109|ps|plot|sgi)[nu]? sgi ERROR #104 dbtext: ERR_NODIALDAEMON ATTACHING sgi (SGI 4d) The Enterprise and Shuttlecraft (units=meters) ERROR #104 setdblights: ERR_NODIALDAEMON

But the major problem is that "fbed" core dumps with: Segmentation fault (core dumped)

And this seems a big problem to solve, any experience?

Thanks a lot in advance, valter

p.s.: I made the kernel mods that you suggested.

--------------------------------------------------------------------------- | Valter V. Cavecchia | Bitnet: cavecchi@itncisca | | Centro di Fisica del C.N.R. | Internet: root@itnsg1.cineca.it | | I-38050 Povo (TN) - Italy | Decnet: itnvax::cavecchia (37.65) | ---------------------------------------------------------------------------

Date: Wed, 20 Feb 91 21:57:16 EST From: Mike Muuss <mike@BRL.MIL> Subject: Re: Some problems

Valter -

Thank-you for the detailed bug report. If your SGI machine does not have the dial and button box, you can disable support for it by editing the file Cakefile.defs, and changing the line that now reads:

# define MGED_CONFIG GFLAG -DIR_KNOBS=8 -DIR_BUTTONS=32 -DDM_4D

# define MGED_CONFIG GFLAG -DDM_4D

e.g., remove the definitions of IR_KNOBS and IR_BUTTONS. Then: cd mged cake clobber cake

and you should have a working MGED that won't complain about ERROR #104.

I am not certain why FBED might dump core. Several suggestions:

First, set your environment variable FB_FILE=/dev/debug and try again. If that seems OK, then try FB_FILE=/dev/sgi and try again. If you get a core dump again, please run SCRIPT, then inside the script session, run "dbx fbed" (if FBED comes from another directory, please use the full path to get to FBED, e.g., "dbx /usr/brlcad/bin/fbed"). Then, inside DBX, give the "where", "dump", and "quit" commands, exit the script, and E-mail it to me. That way I'll have some idea how to advise you.

Do other framebuffer programs operate correctly, like "fbclear 200 0 200" ?

Best, -Mike Date: Sat, 23 Feb 91 5:27:04 EST From: Mike Muuss <mike@brl.mil> Subject: Re: BRL-CAD

OK, I've been prodded. Here are the answers to your questions.

1) There is some work in progress to read the solid modeling part of IGES v.4 files. In general, IGES files contain *drawings*, not solid models. BRL-CAD is a solid modeling system, and not a drafting system. We do read quite a number of other solid modeling formats. (Air Force "PATCH" format, Navy "BSSD" format, etc), and a number of commercial system interfaces are underway.

2) What is included? 17 Mbytes of source code and reference material. See below for a hint.

3) We only send source, and that one set of source runs on all the supported platforms. Suns and SGIs are supported. One tape is all you have to send.

4) Basicly, we want you to say "we agree to the terms", and give us a hint of (a..d). One sentence each. For our "brag sheet" to HQ, never sent to non-Gov't people.

5) There are copies at Langley, but we'd like to put you on our mailing list anyway.

6) We are getting ready to have another BRL-CAD Symposium. Contact <keith@brl.mil> for info.

Best, -Mike

-------------- Attachment 1, Langley sites:

--- 83 --- NASA Langley Research Center Space Systems Division Mail Stop 365 Hampton, VA 23665-5225 ATTN: John Rehder

SGI cartridge

-------------- Attachment 2, "the blurb":

The BRL-CAD Package includes a powerful solid modeling capability and a network-distributed image-processing capability. This software is now running at over 400 sites. It has been distributed to 42 acedemic institutions in twenty states and four contries. 75 different businesses have requested and received the software including 23 Fortune 500 companies. 16 government organizations representing all three services, NSA, NASA, NBS and the Veterns Administration are running the code. Three of the four national laboratories have copies of the BRL CAD package.

BRL-CAD started in 1979 as a task to provide an interactive graphics editor for the BRL vehicle-description data base. Today the package totals more than 150,00 lines of "C" source code. It runs under UNIX and is supported over more than a dozen product lines from Sun Workstations to the Cray 2. The package includes:

A Solid geometric editor The Ray tracing library Two Lighting models Many image-handling, data-comparison, and other supporting utilities

In terms of geometrical representation of data, BRL-CAD supports:

The original Constructive Solid Geometry (CSG) BRL database.

Extensions to include solids made from collections of Uniform B-Spline Surfaces as well as Non-Uniform Rational B-Spline [NURB] Surfaces.

A facetted data representation.

Applications linked to BRL-CAD:

For more details about what geometric models are useful for, see M. Muuss, ``Understanding the Preparation and Analysis of Solid Models'', in ``Techniques for Computer Graphics'', ed: Rogers & Earnshaw, Springer Verlag, 1987.

To obtain a copy of the BRL CAD Package distribution, you must send enough magnetic tape for 20 Mbytes of data. Standard nine-track half-inch magtape is the strongly preferred format, and can be written at either 1600 or 6250 bpi, in TAR format with 10k byte records. For sites with no half-inch tape drives, Silicon Graphics and SUN tape cartridges can also be accommodated. With your tape, you must also enclose a letter indicating

(a) who you are, (b) what the BRL CAD package is to be used for, (c) the equipment and operating system(s) you plan on using, (d) that you agree to the conditions listed below.

This software is an unpublished work that is not generally available to the public, except through the terms of this limited distribution. The United States Department of the Army grants a royalty-free, nonexclusive, nontransferable license and right to use, free of charge, with the following terms and conditions:

1. The BRL CAD package source files will not be disclosed to third parties. BRL needs to know who has what, and what it is being used for.

2. BRL will be credited should the software be used in a product or written about in any publication. BRL will be referenced as the original source in any advertisements.

3. The software is provided "as is", without warranty by BRL. In no event shall BRL be liable for any loss or for any indirect, special, punitive, exemplary, incidental, or consequential damages arising from use, possession, or performance of the software.

4. When bugs or problems are found, you will make a reasonable effort to report them to BRL.

5. Before using the software at additional sites, or for permission to use this work as part of a commercial package, you agree to first obtain authorization from BRL.

6. You will own full rights to any databases or images you create with this package.

All requests should be sent to:

Keith Applin Ballistic Research Lab APG, MD 21005-5066

Best Wishes, -Mike Muuss

Advanced Computer Systems ArpaNet: <Mike @ BRL.ARPA> Date: Thu, 28 Feb 91 15:58:07 EST From: Mike Muuss <mike@BRL.MIL> Subject: RT options

This afternoon, I added a few new options to RT, at the request of several users. First, the "-c" option, which allows any RT animation script command to be given on the command line. For example,

rt -s64 -c "set bounces=7" -c "set" moss.g all.g

allows the maximum number of ray bounces to be changed (first -c option), and the current viewing-model variables to be displayed (using the -c "set" command). Another example is:

rt -s64 -c "set background=.25,0,.5" moss.g all.g

which sets the background to the current default purple background, using normalized intensities in the range 0 to 1. This can also be accomplished with a shorthand option, using RGB values in the range (0..255):

rt -s64 -C 63/0/127 moss.g all.g

Note that any non-numeric characters can be used as value separators. The comma and slash are the two I find myself using most often.

The -c option will be especially useful for the radar codes built as RT view modules, as it will now allow access to all the application-specific variables from the command line. Traditionally, they could only be set in an animation script, which was not always convenient.

On a related subject, I am considering changing the default background color in RT from purple to black (0/0/1). If you have an objection to this, please send me E-mail by 6-March.

Best, -Mike Date: Mon, 4 Mar 91 21:35:16 EST From: Mike Muuss <mike@BRL.MIL> Subject: Re: RT options

The 0/0/1 choice is so that the checkpoint/restart code can tell the difference between unwritten pixels in the middle of the image (UNIX zero-fills unwritten sections of a disk file), and background pixels. This prevents having to recompute all black background pixels on a restart.

The choice of 0/0/1 is because the eye is less sensitive to blue, so that keen-eyed watchers would be less likely to see it than, say, 0/1/0.

Best, -Mike Date: Tue, 5 Mar 91 3:11:36 EST From: Mike Muuss <mike@BRL.MIL> Subject: Re: RT options

I'm not sure I understand yet. Yes, REMRT (in particular) does seek around in the file, and gets big black gaps where CPUs have not yet answered.

RT, when running in parallel (BUFMODE_DYNAMIC) also seeks around in the file, as each scanline is completed.

I don't see any difference for compositing, as you would just pixmatte foo.pix -C0/0/1 stuff rather than pixmatte foo.pix -C0/0/0 stuff It would just be a different number to type.

Visually, 0/0/1 is indistinguishable from black 0,0,0 -vs- 0,0,0.0039 in floating point format. (I've been using slashes for RGB values, and commas for 0-1 normalized intensities, although the number parser does not care).

So, please help me understand why 0/0/0 would be better than 0/0/1, and how I should deal with the checkpoint restart issue then. I'm genuinely concerned that I've missed some important point! Best, -Mike Date: Wed, 6 Mar 91 13:17:37 EST From: Paul Tanenbaum <pjt@BRL.MIL> Subject: Re: FBZOOM(1) bug

Mike, I've fixed the VI/JOVE commands, the help menu, and the man page. I also took you up on your suggestion, and added the -T option and the 'T' command, which toggle the sense of the pan commands. The output line now displays an indication whether you are moving the window or the image. As for the choice of option flags... because you said that there are two camps as far as this panning thing, I thought that eventually several of the BRL-CAD utilities etc. might support the same kind of user-selectable behavior. To facilitate potential standardization, I found a flag (viz. -T) which does not show up in util/*.1 so that any other routines that acquire this functionality might use the same flag. If this ever came to pass, I guess it would end up in brlcad.1 as well. +++paul

Date: Wed, 6 Mar 91 21:02:35 EST From: Mike Muuss <mike@BRL.MIL> Subject: IGES opinion from net

FYI, a good terse summary of IGES. Not entirely accurate, but close. -M

----- Forwarded message # 1:

From: Bret Strain <brets@hpnmdla.hp.com> Newsgroups: comp.graphics Subject: Re: IGES Date: 6 Mar 91 16:09:55 GMT

>In comp.graphics, pdbourke@ccu1.aukuni.ac.nz (Bourke) writes: > > Could someone please supply me with information on the IGES graphics > file format. Like, who developed it, what are its strong points, > what are its problems. How successful is it...etc...

IGES (Initial Graphics Exchange Specification) Current revision 5.0.

Developed by a committee of representitives of the CAE/CAD/CAM industry.

Published by the National Institute of Standards and Technology, U.S. Department of Commerce.

Contact: Nancy Flower (703) 698-9600 extension 325 to order a spec.

Its primary use is to interchange design data and annotation for (primarily) mechnical 2D and some 3D databases.

It is a well documented standard, and it is in common use with mechanical CAD/CAM systems as well as some FE analysis packages.

The standard is not perfect. It does not transfer 3D solid geometry. It has a reasonbly rich specification in which many CAD/CAM systems only implement a subset of its definition.

Strong points:

Documented standard. Well accepted.

Weak points:

Like all standards, the semantics (based on implementations I've seen) are not absolutely robust. Does not handle 3D solid geometry. The standard is "rich" (i.e. complex in many ways).

----- End of forwarded messages Date: Fri, 8 Mar 91 10:45:14 EST From: Earl Weaver (VLD/ASB) <earl@BRL.MIL> Subject: Re: IGES opinion from net

Perhaps a little more details on the "inaccuracies" is in order.

IGES 5.0 addresses other applications as well as mechanical (electrical, architectural, piping...)

It DOES handle 3D solid geometry, but not all 3D solid geometry. For CSG geometry, it handles only a subset of all primitives and booleans used in solid modeling packages. It handles the "block", "right angular wedge", "right circular cylinder", "right circular cone frustum", "sphere", "torus" (only circular cross-sectioned torus), "ellipsoid", "solid of revolution", "solid of linear extrusion", boolean tree (union, intersection, subtraction), solid assembly, and solid instance. For B-rep, it should handle most models (as long as there are IGES entities for the surface types; IGES addresses most of those, I believe).

We are planning on working with IGES to implement extentions to the primitive set such that the cones and cylinders would be more general (corresponding to the BRLCAD TGC), and adding a general polyhedron, and an ARB8. Date: Fri, 8 Mar 91 15:04:34 EST From: Phil Dykstra <phil@BRL.MIL> Subject: Re: plot-fb

It is called "pl-fb" now (since Jan '88) and it does work into any frame buffer - including the SGI. On the SGI though, there is also "pl-sgi" which allows you to rotate plot files around and such. See also: plrot, pl-pl, pl-ps, pldebug.

- Phil Date: Fri, 8 Mar 91 20:13:12 EST From: Mike Muuss <mike@brl> Subject: Re: IGES solids

I have no information on the ACAD converter. I know they were working on it. It is unclear how they convert their Bezier patches into solids, since one patch is unlikely to enclose a volume.

Intergraph is working on a converter, under contract to US Army TACOM. Progress is slow, but they should have something by next year.

I don't see how the IGES support would help. Both of these activities have copies of LIBWDB, which gives them the ability to create any kind of geometry that BRL-CAD supports. The main difficulties have been in (a) arranging approximations for solids they may have that BRL-CAD does not have [a minor problem], and (b) determining how to infer topological data from DRAWINGS which are *not* solid models, in order to create a set of solids suitable for use in BRL-CAD.

There are a number of major extensions to the NMG work, to permit NMG objects to have trimmed-NURBS faces, currently in progress. This will eliminate all further problems of type (a) above. The problem in (b) is hard, and in general, can't be solved. As more people start building true solid models, this will fade in importance.

Does this explanation help? If there is some specific conversion task that you face, perhaps I can suggest how you could do it using LIBWDB. Rest assured that we do have a serious long-term interest in being able to import models from commercial systems. Right now, given current priorities and funding, that won't be totally finished until FY93 or beyond. (My biggest problem at the moment is that DoD has been in a total hiring freeze condition for > 1.5 years now).

Best, -Mike From: "David R. Blythe" <drb@eecg.toronto.edu> Newsgroups: comp.graphics.visualization Subject: Re: apE and AVS pricing Date: 14 Mar 91 04:32:02 GMT

In article <38945@netnews.upenn.edu> joe@retina.anatomy.upenn.edu (Joseph Panico) writes: >in MOVIE.BYU format. Where can I get MOVIE.BYU and the data formats for >both MOVIE.BYU and Wavefront's personal visualizer? > > Joe Panico > joe@retina.anatomy.upenn.edu

The movie.byu geometry file format looks like this:

write(iunit,80) npn,njn,nptn,nedge write(iunit,80) ((npl(i,j),i=1,2),j=1,npn) write(iunit,100) ((x(i,j),i=1,3),j=1,njn) write(iunit,80) (jp(i),i=1,nedge) 80 format(10i8) 100 format(6e12.5)

where npn = number of parts (geometric objects) njn = number of nodes (total number of vertices) nptn = number of polygons (total over all parts) nedge = number of edges (total over all polygons in all parts) npl = array of pairs of indices into connectivity array for start polygon node and end polygon node for each part (if there is 1 part then it is a single line = 1 and nedge) x = array of 3D vertices jp = connectivity array - indices of vertices in x array making up a polygon with a negative index indicating the last vertex of a polygon (an n-sided polygon would have n entries in the connectivity array and the n-th entry would be negated).

I have seen a number of programs that understand this format so its probably worth knowing. So does anybody know the file formats for the personal visualizer? david blythe ontario centre for large scale computation drb@clsc.utoronto.ca From: Gautam Mehrotra <gautamm@ncsa.uiuc.edu> Newsgroups: comp.graphics.visualization Subject: Wavefront's File format( was Re: apE and AVS pricing ) Date: 14 Mar 91 06:11:23 GMT

In article <1991Mar13.233202.25268@jarvis.csri.toronto.edu> drb@eecg.toronto.edu (David R. Blythe) writes: >In article <38945@netnews.upenn.edu> joe@retina.anatomy.upenn.edu (Joseph Panico) writes: >>in MOVIE.BYU format. Where can I get MOVIE.BYU and the data formats for >>both MOVIE.BYU and Wavefront's personal visualizer? >> >> Joe Panico [ description of MOVIE>BYU's format deleted] >I have seen a number of programs that understand this format so its probably >worth knowing. So does anybody know the file formats for the personal >visualizer? > david blythe

Matthew Arrott posted a description of the format some time back. [ The Subject header on his article was mysteriously missing ..]. I am posting a copy for those who missed it .....

Matt's article follows ... -----------------------------------------------------------

If I am not mistaken one can call both institutions for this information.

The wavefront object format, if I remember correctly is the same as their advanced animation package. That is as follows:

# This is a comment line # # One moviable object per file. In other words, a file is the atomic # unit of a rigid body system # The UNIX directory structure is used as the database structure # # "\" The backlash character is used for line continuation # "!" is used as an end of line comment

o square ! object name : Not used in the advanced animation package [optional]

mtllib my.mtl your.mtl project.mtl ... ! material library search ! path [optional] maplib my.map your.map ... ! map library search path ![optional]

usemtl red ! current material : all subsequent geometry will be ! assigned this material [optional] usemap logo ! current map : all subsequent geometry will be assigned ! this map [optional] usemap off ! turn texture mapping off for subsequent geometry

# Maps are the definition of the application of textures to the material # properties of the object : # # the mapping of the texture to the materials of the object # # This definition of the material/texture relationship is not the # definition of the uvw space of the # texture to the xyz space of the geometry. That definition is # facilitated through texture verticies # which are dicussed shortly. # # Material and Map files have there own formats # Material files are discussed after the object file.

s 1 ! smoothing group : average vertex normals for shared verticies !of the same smoothing group s off ! turn smoothing off

v 0.0 0.0 0.0 ! vertex position v 1.0 0.0 0.0 v 1.0 1.0 0.0 v 0.0 1.0 0.0

vt 0.0 0.0 0.0 ! texture vertex position vt 0.0 1.0 0.0 vt 1.0 1.0 0.0 vt 1.0 0.0 0.0

vn -1.0 -1.0 1.0 ! vertex normal : may override the smoothing notion, !may need to be normalized vn 1.0 -1.0 1.0 vn 1.0 1.0 1.0 vn -1.0 1.0 1.0

p 1 2 3 4 ! a series of four points made up of four index ! references to verticies ( 1 base ) l 1 2 3 4 ! a line made up of four points with the !topology of vertex 1 to 2 to 3 to 4

f 1 2 3 4 ! a face (polygon) made up of four verticies. !Counter clockwise ordering

f 1/1 2/2 3/3 4/4 ! a face with index references to texture verticies

f 1/1/1 2/2/2 3/3/3 4/4/4 ! a face with index references to texture !verticies and vertex normals

f 1//1 2//2 3//3 4//4 ! a face with index references to ! vertex normals

f -4 -3 -2 -1 ! a face using relative vertex referencing. "-N" ! reads: use N vertex ago

# vertices, texture verticies, vertex normals, points, lines, and face # can be intermixed as long # as the referenced stuff is defined before it is referenced.

Material file

# special characters are the same.

newmtl red Ka 0.1 0.0 0.0 ! ambient color responce Kd 0.4 0.0 0.0 ! diffuse color responce Ks 0.4 0.0 0.0 ! spectular color Ns 20 ! spectular exponent d 1.0 ! dissolve 0.0 -- 1.0 transparent -- opaque illum 1 ! illumination model 0:color 1:diffuse ligthing ! 2:diffuse and spectular lighting

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

End of Matt's article ....

hope that helps

cheers, gautam

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

Gautam Mehrotra,

National Center for Supercomputing Applications, Univ of Illinois. e-mail: gautamm@ncsa.uiuc.edu

---------------------------------------------------------- Date: Mon, 15 Apr 91 9:01:31 EDT From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> Subject: Re: vdeck?

|> Just out of curiosity, what changed in VDECK? Nothing really. Vdeck statically allocates arrays to hold info about objects and solids; the length is configured with two #define constants NDIR and MAXSOL respectively. So, periodically as descriptions get larger, these limits have to be enlarged and vdeck recompiled. Since I always thought that people weren't supposed to use GIFT, I haven't bothered to fix vdeck to dynamically allocate the arrays. Besides upping the array sizes, I recently modified vdeck to allow configuration of these constants in the Cakefile.

-Gary

23 Apr 91 21:22 EDT id AA28296; Tue, 23 Apr 91 18:19:34 PDT Date: Tue, 23 Apr 91 18:19:34 PDT From: Roy Williams <roy@sampson.ccsf.caltech.edu> Subject: color in brlcad

Is it possible to have a boolean operation such as intersection between solids of different colors, with the ray tracer showing both colors?

Thanx

Roy Williams Caltech Concurrent Computation Project Date: Wed, 24 Apr 91 4:17:57 EDT From: Phil Dykstra <phil@BRL.MIL> Subject: Re: color in brlcad

Material properties, including color, are assigned to "regions" - combinations with a special bit set indicating that they, and everything below them in the model tree, make up one homogeneous piece of material (not necessarily continuous). Two regions should not overlap, since two pieces of material can not occupy the same physical space. As such, there should not be any booleans other than non-overlapping unions ("groups") above region nodes in the tree.

If you do have any such overlaps, or non-union booleans above the region nodes, the ray tracer will complain. Which "material" (e.g. color) you get in areas of conflict is somewhat non-deterministic. If you do want to see e.g. an intersection specifically colored, you should make a region node containing the intersection and assign it the desired color. [If the objects being intersected are themselves regions, the ray tracer will print a warning during the "prep" phase, and (by default) the material properties of the parent will "win" and become the properties of the intersection. Who wins is what the inheritance property is about.]

I hope that helps. In case you are just looking for overlaps, note that there is the rtoverlap utility.

- Phil Date: Wed, 29 May 91 0:09:54 EDT From: Susan Muuss (VLD) <sue@BRL.MIL> Subject: RTRANGE

This weekend, on my own time, I wrote RTRANGE. This program takes advantage of the RTUIF I reported on at the BRL-CAD Symposium and writes a UNIX-Plot file containing scanlines of range data. Model coordinates are preserved to permit overlays in MGED and to also permit registration of the plot with other data. This project was inspired by presentations given by Dr. Judy Temperly and Bruce Wallace during the SECAD Tutorial last week. I hope that this new BRL-CAD analysis tool will prove very useful to them in their work.

-Sue Date: Fri, 31 May 91 11:48:59 EDT From: Mike Muuss <mike@BRL.MIL> Subject: TIG-PACK and LIBPLOT3

While rolling things up for the release, I have moved all the TIG-PACK routines (from LIBTIG) into LIBPLOT3. -Mike Date: Mon, 10 Jun 91 10:09:44 EDT From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> Subject: Re: [Dick Wiley - System: CAD on SunOS v4.1.1]

Dick, I have already addressed these problems in the current sources (to be part of the next release of BRLCAD) though I haven't tested it yet under SunOS 4.1.1 or on a Sparc, just 4.0.3 on a 3/80 where it compiles cleanly.

|> I have run into a couple of problems installing BRL-CAD on out SPARCserver |> 490 under SunOS v4.1.1. |> |> The major one comes from the following definitions in the include file |> /usr/include/sys/sysmacros.h: |> |> * Major/minor device constructing/busting macros. |> /* minor part of a device */ |> #define minor(x) ((int)((x)&0377)) |> |> /* major part of a device */ |> #define major(x) ((int)(((unsigned)(x)>>8)&0377)) |> |> which conflict with the variables major and minor in fbed.c. We get them |> because fbed.c includes fcntl.h, which includes sys/fcntlcom.h, which |> includes sys/stat.h, which includes sys/sysmacros.h. I have changed the name of the variables "minor" and "major" in fbed.c to "mindelta" and "majdelta".

|> The other problem is that the following statements in fbed/std.h are |> causing the compiler to give 'illegal type combination' messages: |> |> typedef unsigned char u_char; /* unsigned integer types */ |> typedef unsigned short u_short; |> #ifdef pdp11 |> typedef long u_long; /* (not in Ritchie compiler) */ |> #else |> typedef unsigned long u_long; |> #endif |> |> These occur in fbed/fbed.c and fbed/execshell.c. The following is from the current std.h:

#if defined(mips) && ! defined(IRIX3_3) #define IRIX3_3 1 /* Assume running release 3.3 or later. */ #endif

#if ! IRIX3_3 || ! defined(__SYS_TYPES_H__) /* Defined in <sys/types.h> under IRIX3.3. */ typedef unsigned char u_char; /* unsigned integer types */ typedef unsigned short u_short;

#ifdef pdp11 typedef long u_long; /* (not in Ritchie compiler) */ #else typedef unsigned long u_long; #endif #endif

|> The compiler is also complaining about illegal pointer combinations on |> calls to the signal function in fbed/execshell.c, lgt/lgt.c, and |> lgt/execshell.c. This was resolved similarly in fbed and lgt as follows:

[in extern.h] /* Set pre-processor switch for getting signal() handler declarations right. */ #if defined(sun) && ! defined(SunOS4) /* For Suns running older releases, compile with -DSunOS4=0 to suppress bogus warning messages. */ #define SunOS4 1 #endif #if __STDC__ || (defined(SYSV) && ! defined(cray)) || SunOS4 #define STD_SIGNAL_DECLS 1 #else #define STD_SIGNAL_DECLS 0 #endif

[Then whenever signal handlers are declared:] #if STD_SIGNAL_DECLS STATIC void general_Handler(); #else STATIC int general_Handler(); #endif

[And, where they are defined:] #if STD_SIGNAL_DECLS STATIC void #else STATIC int #endif general_Handler( sig ) int sig;

[Finally, the return from each handler:]

#if STD_SIGNAL_DECLS return; #else return sig; #endif

|> Enjoy, |> |> Dick I already have. :-{ Thanks for the detailed bug reports.

-Gary Date: Wed, 12 Jun 91 7:04:23 EDT From: Mike Muuss <mike@BRL.MIL> Subject: CAKE Fixed

This evening, I fixed CAKE so that internally, a number of subroutines no longer return a union Wait, but instead return an integer.

It seems that /bin/cc on UNICOS 5.1 has some difficulty with this construct, and this is the reason that CAKE has not worked on Eglin's YMP. Best, -Mike Date: Thu, 13 Jun 91 8:03:58 EDT From: Mike Muuss <mike@BRL.MIL> Subject: VDECK & Geom Export

Over the last few evenings, I have modified the VDECK program to use the new LIBRT geometry import/export interface.

As a result, the new VDECK in Release 4.0 will be able to handle nearly all MGED models, except for those where non-GIFT primitives (like NURBS and NMGs) have been used. This includes booleans above the region combinations (like tank minus cutaway), groups within regions, regions subtracted from (or intersected with) other regions, etc., courtesy of using the new tree-walker. I have also extended it to be able to output HAF and ARBN solids. For builders of enormous models, all limits on number of solids have been removed. I'm certain these improvements will thrill the folks at ERIM, and others who may still use GIFT.

If you have a GIFT deck, you can use COMGEOM-G to convert it to a .g file, and then use VDECK to get back an equivalent GIFT deck. I have run several models back and forth. This was a good way to catch bugs in the libraries.

For me, the object of the exercise was to demonstrate that new subroutines for geometry export work, and are easy to use. VDECK is now a prime example of this. The new VDECK source code makes no reference to db.h (the on-disk format of geometry) at all, so it has no dependence on the peculiarities of how solids are stored on disk. This means that the import/export routines succeed at providing a loss-less interface to the full MGED database, with much less pain & effort than reading the database yourself. It also means that VDECK will be unaffected by database format changes.

This new version of VDECK could be easily modified, for example, to provide an IGES Solids file (for that set of solids that the systems have in common), or for other CSG-capable systems.

Onwards! -Mike Date: Fri, 14 Jun 91 2:03:58 EDT From: Mike Muuss <mike@brl> Subject: Release 4.0 schedule etc

Jim -

Thanks for the kind words. Here is the schedule of events leading up to Release 4.0:

Mon June 24 (Features Freeze for BRL-CAD Release) Mon July 1 (Begin VLD-only "alpha" test of Release 4) Tue July 9 (Begin "beta" tests of Release 4) Mon July 22 (Planned date to have finalized Release 4)

It is important to be very careful when mixing programs from the experimental Release 4.0 software and the current production Release 3.7 software. In particular, .g files created or edited with Release 4.0 software may not work with the old Release 3.7 software. There are lots of new goodies in the .g file that didn't exist in 3.7 days. So, there is "upwards compatability" (all 3.7 databases work on 4.0), but not "backwards compatability" (4.0 databases will NOT work on 3.7).

So, feel free to experiment, but please be careful, and do it on a copy of your precious files, rather than on your original!

Best, -Mike Date: Fri, 14 Jun 91 7:03:11 EDT From: Mike Muuss <mike@BRL.MIL> Subject: LIBRT identity matricies

My project for this evening was to act on a suggestion made by Harry Reed. As you may recall, Harry builds very large MGED databases, and he uses very few modeling transformations. (He prefers to simply transform the solids).

Harry noted one day that a 4x4 transformation matrix consumes 128 bytes of memory, and if he has 30,000 solids with identity transformations, that is 3.8 Mbytes of memory that could be saved.

I modified LIBRT's "struct soltab" so that mat_t st_pathmat has become matp_t st_matp. A null pointer denotes an identity matrix, and non- identities matricies are malloc()ed as required. As a byproduct, this change also makes the "prep" phase go a little faster, too.

Best, -Mike Date: Fri, 14 Jun 91 8:46:37 EDT From: Paul Tanenbaum <pjt@BRL.MIL> Subject: ADC Command added to MGED(1)

I've just installed a command which allows keyboard control of the angle/distance cursor. It has the following synopsis:

adc toggles display of angle/distance cursor adc a1 # sets angle1 (degrees) adc a2 # sets angle2 (degrees) adc x # sets horz. coord of cursor location (local units) adc y # sets vert. coord of cursor location (local units) adc dst # sets tick distance (local units) adc reset Resets angles, location, and tick distance.

You will see it in release 4.0. +++paul

Date: Fri, 14 Jun 91 13:33:32 EDT From: "John R. Anderson" (VLD/ASB) <jra@BRL.MIL> Subject: IGES-to-BRLCAD Translator

Thanks to some help from Mr. Muuss, the IGES-to-BRLCAD translator (iges-g) that I reported on at the last BRLCAD Symposium will be included in the upcoming release 4.0. Here is a brief description of its capabilities:

Iges-g converts IGES files (ASCII format) to BRL-CAD database format. The IGES file is expected to conform to the ANSI standard, ASME Y14.26M-1989, which is esentially IGES 4.0. All IGES CSG objects are converted to BRLCAD equivalents. Most conversions are exact, with the exceptions of the solid of revolution and the solid of linear extru- sion. These solids do not exist in BRL-CAD and are therefore approximated. The solid of revolution is built from a series of truncated right cones developed by approximating the curve to be revolved with a series of straight line sege- ments. The extrusion is similarly handled by approximating the curve to be extruded with straight line segments and using that to build a BRL-CAD polysolid.

IGES non-uniform rational B-spline surfaces (NURBS) are also converted, but this translator is not intended to be a BREP translator at this time. All NURBS are combined into a single BRLCAD spline solid named "nurb.s".

An all-encompassing group is created, with the name "all", that includes all the objects in the database not referenced by other objects.

I hope this proves useful to some of you.

-John

Date: Fri, 7 Jun 91 15:12:51 EDT From: "Jill H. Smith" <jill@BRL.MIL> Subject: TAP Report

BRL-CAD Release 4.0

BRL-CAD, Release 4.0, is in the final testing phase and will soon be available for distribution. BRL-CAD is a government developed and owned geometric modeling software package. This package uses the Constructive Solid Geometry (CSG) technique where desired volumes are created by combining basic primitive solids with boolean operations. This long awaited release will contain numerous improvements and new capabilities, the most significant being the addition of n-Manifold Geometry (NMG) support. NMG is a polygonal (faceted) geometric representation, but unlike other polygon based systems stores full topological as well as geometric information. This means that the relationships between all NMG elements are continuously available, making it possible to robustly apply booleans to the NMG polygons. With NMGs, BRL-CAD now has full polygonal support, allowing for the import of other polygon based geometries. Furthermore, through the tessellation and boolean routines, the current primitive based CSG geometry of BRL-CAD models can readily be converted for export to polygon based modelers. Finally, the NMG polygons will allow for full exploitation of the fast polygon fill available on modern workstations, giving real time shaded display capability for enhanced visualization. Other additions to Release 4.0 include a completely new spline library and new primitive solids(arbitrary convex faceted solid-ARBN, the halfspace-HAF, and wire solids-WIR). There also are improvements in other areas such as the data base converters, the network distributed ray-tracing software, and the frame buffer and ray-trace libraries. POC: Keith Applin, X6647

INPUT PREPARATION FOR PREDICTIVE THERMAL MODELING INCLUDED IN BRL-CAD

IRPREP is a collection of C-programs for extracting geometric and material properties from BRL-CAD MGED solids models for input into predictive thermal modeling codes. One can also generate a correctly formatted input file for PRISM ( Physically Reasonable Infrared Signature Model), a code from the Keweenaw Research Center. These programs, written by Susan Coates and developed through efforts of the VLD/ VMB/Signatures Team and the SECAD/WSTB/IR System Technology Team, determine region volumes, centroids, free and shared surface areas, adjacent region pairs, conduction factors, and shape factors.

Each region of an MGED description functions as a node in the lumped-parameter mesh for PRISM. Region volumes, used to determine thermal masses, and region centroids, used in calculation of conduction factors, are calculated from information gathered by dense parallel ray sampling of the geometry. The same ray-trace information is used in calculating the areas for surfaces that bound air (free) and that are shared by other regions. Conduction factors are determined from a user-selected conduction path length function in combination with shared surface area and adjacent region pair material properties.

The shape factor from region A to region B the fraction of all lines leaving the surface of region A that have line of sight to region B. IRPREP determines the shape factors for a set of regions by means of Monte Carlo sampling. The shape factors are currently used in modeling the radiative exchange taking place in an engine compartment.

IRPREP will be released in the upcoming 4.0 Release of the BRL-CAD package. POC: Edwin Davisson, Ext. 6711

Date: Sun, 23 Jun 91 1:53:33 EDT From: Mike Muuss <mike@brl> Subject: "brlman"

For those systems that install BRL-CAD and don't have NROFF or DWB, the "brlman" command should solve the problem. It is a simple shell script which uses Henry Spencer's AWF "nroff -man" formatter.

brlman honors the MANPATH, PAGER, and MANPAGER environment variables, using "more" by default.

This means that recipients of the CAD package will always be able to reference the on-line manual pages.

Best, -Mike Date: Mon, 1 Jul 91 14:08:19 EDT From: Susan Muuss (VLD/ASB) <sue@BRL.MIL> Subject: Cell Plot overlays

I am pleased to announce that BRL-CAD now has the ability to do quick cell-plot overlays. Cell-fb now has a logging option which prints out information which is used by rtregis (a program that constructs a registration matrix for use by plrot) to register an RT produced hidden line removed plot file with the cell-plot.

This is a major break-through since it permits a cell-plot and an rthide UnixPlot file to be registered and overlayed within seconds. All the programs necessary to achieve this will be in the next BRL-CAD release, so enjoy.

Cheers,

Sue Date: Tue, 2 Jul 91 14:16:55 EDT From: Susan Coates (VLD) <scoates@BRL.MIL> Subject: BRL-CAD 4.0 alpha test

I am running into a problem in compiling a program I am writing (stick.c). It is using libwdb. I have been compiling it using the following statement and it has worked fine.

cc stick.c /usr/brlcad/lib/libwdb.a -lm -o stick

This did not work after I started using the new cad distribution. When I used libwdb.a.bak it worked fine. See the script below. My file is on /n/walrus/s/scoates/IR.prep.stick.

$ cc stick.c /usr/brlcad/lib/libwdb.a -lm -o stick /usr/bin/ld: Undefined: mat_vec_ortho rt_functab rt_log db_free_external rt_bomb rt_identify_magic rt_units_conversion $ $ cc stick.c /usr/brlcad/lib/libwdb.a.bak -lm -o stick $

Why do I get all these things that are undefined?

If you need more information please let me know.

Sue

Date: Tue, 2 Jul 91 14:36:41 EDT From: Paul Stay <stay@BRL.MIL> Subject: Re: BRL-CAD 4.0 alpha test

Sue-

The problem is that you need to include two more libraries with the libwdb now. libwdb now depends on routines that are found in librt, another system library must also be included on the SGI machines -lmpc. The following command worked fine.

cc stick.c /usr/brlcad/lib/libwdb.a /usr/brlcad/lib/librt.a -lmpc -lm -o stick

-Paul

Date: Tue, 2 Jul 91 15:50:44 EDT From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> Subject: Lgt fixed for 3.10.

Mike, Lgt did not initialize the res_model semaphore, so it was dumping core in librt/tree.c:rt_find_identical_solid() where it calls RES_ACQUIRE on that semaphore. If you haven't already mentioned this new semaphore in the release notes, it would be a good idea. I updated lgt sources on wolf and the binary on walrus.

Interestingly, the RCS archive on wolf for lgt/do_options.c was corrupted; it yields a truncated file (with a couple of lines of garbage at the end), so I copied the archive to do_options.c,v.bad and made a new archive from a copy I had elsewhere.

Another change that I noticed in compiling a non-BRLCAD application with 3.10 was that the re_seg field of the resource struct was changed to a "struct seg" from a "struct seg *" and that the SEG_NULL macro was apparently renamed to RT_SEG_NULL. As it turns out that reference was part of a workaround that is no longer necessary, so I removed it, but it may also deserve mention in the release notes.

-Gary Date: Wed, 3 Jul 91 12:51:14 EDT From: William Potter (Summer|shenry) <wpotter@BRL.MIL> Subject: Window Size

Why is the new MGED window smaller than the earlier version's window? Date: Wed, 3 Jul 91 12:51:14 EDT From: William Potter (Summer|shenry) <wpotter@BRL.MIL> Subject: Window Size

Why is the new MGED window smaller than the earlier version's window? Date: Wed, 3 Jul 91 14:36:23 EDT From: Paul Stay <stay@BRL.MIL> Subject: Re: Window Size

One of the features of teh new mged is that the window can be resized. The smaller size is due to the fact that many individuals exressed a desire to have some space at the bottom of the screen for the shell window which is used for mged commands. If you want a larger window you should be able to resize it.

-Paul Date: Sat, 6 Jul 91 1:45:42 EDT From: Mike Muuss <mike@BRL.MIL> Subject: util & fb split

The "util" directory in the source tree of the CAD Package has begun to overflow with utilities. In order to get the directory size back down to just barely managable size, I have moved all the Framebuffer (fb) utilities into their own directory "fb". There are an appreciable number of them.

So, if you don't find the utility you are looking for in "util", try looking in "fb" as well.

Best, -Mike Date: Tue, 9 Jul 91 2:28:05 EDT From: Mike Muuss <mike@brl> Subject: Re: Alpha release comments

Thanks for the detailed comments!

1) I fixed the paths command in mged. utility2.c. I don't think this was a new problem, considering the "throw away any input" comment that had been in the source there.

2) I added a warning message to the "keep" command, so that it notifies you when you are appending to an existing keep file.

3) Still thinking about this one.

4) Lee has added the same warning message to the "facetize" command.

5) "ev" only works for simple cases.

6) Using "plot" on a polygon display created with the "ev" command, for now, gives you a plot of the outlines of the faces. (i.e., it draws the edges). When Phil has time to integrated in his polygon support in UNIX-plot (next release), then it will output that.

Best, -Mike Date: Tue, 9 Jul 91 2:30:57 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Re: Keyboard Lights

Thanks for the report on the alpha-test software. There are now 7 function buttons active on the SGI 4D, and only 4 lights. In addition, setting those lights represented a performance problem, as the path from the computer back to the keyboard (!) is not very fast. So, in the forthcomming release, the keyboard lights will not be used.

Best, -Mike Date: Tue, 9 Jul 91 22:02:27 EDT From: Mike Muuss <mike@brl> Subject: Re: Title in the MGED faceplate

The title has been removed, to increase drawing efficiency. Harry Reed correctly noted that all the text on the screen can noticably slow down the screen drawing rate. -Mike Date: Thu, 11 Jul 91 0:02:37 EDT From: Mike Muuss <mike@brl> Subject: Re: librt/qmath bug az=90!

The code in qmath.c for mat2quat was from Ken's 1985 paper. In his 1989 paper, he gives a different algorithm which looks to be stable even when w**2 is near zero (i.e., even at azimuth=90 degrees). I typed it in, as a replacement in librt/qmath.c

This seems to have solved the problem Sue reported; hopefully it won't produce any new problems... -Mike Date: Mon, 15 Jul 91 22:35:00 EDT From: Mike Muuss <mike@brl> Subject: [Sue Muuss: [Donald F. Haskell: [Abdul Kiwan: [Abdul Kiwan: TAP report]]]]

BRL DEVELOPS IGES-TO-BRLCAD TRANSLATOR

At the recent BRLCAD Symposium, John Anderson, Sue Muuss, and Earl Weaver presented their IGES-to-BRLCAD translator. This software, being distributed as part of the BRLCAD package, allows the user to convert files conforming to the Constructive Solid Geometry (CSG) portion of the Initial Graphics Exchange Specification (IGES) to the BRLCAD format. IGES/CSG was recently approved as an ANSI standard and was preceded by an earlier version that did not include CSG. The earlier version of the standard was embraced by commercial CAD vendors and widely implemented. This translator is the first step in a proposed effort to develop full IGES compatibility for BRLCAD which would include a BRLCAD-to-IGES translator and extension of the IGES-to-BRLCAD translator to include Boundary Representation (BREP) IGES files. The IGES/BREP specification is currently under development and is expected to become an ANSI standard in the near future. POC: Dr Donald Haskell Tel (301)-278-2032.

RAPID CREATION OF ANALYSIS CODES USING BRL-CAD/RT VIEW-MODULE INTERFACE

On May 7, 1991, Susanne Muuss, of the Air Systems Branch presented a paper on the 'Rapid Creation of Analysis Codes Using BRL-CAD The RT View-Module Interface', at the third annual BRL-CAD Symposium. This paper, which detailed the use and function of the RT view-module interface, was well received by the attendees and generated much interest among the audience. The impact of this software engineering tool has been significant. In the few short weeks since the BRL-CAD Symposium, this software engineering tool has been used by various software designers to complete three new RT applications: rtweight, rtrange, rtcell. Another application is currently under development. Sue Muuss's presentation is also the basis for an official view-module template to assist applications programmers with software design and implementation via the RT view-module interface. This reception demonstrates the far-reaching implications this paper has had on facilitating the design and implementation of RT-based software tools. POC: Dr Donald Haskell (301)-278-2032.

THE AIR SYSTEMS BRANCH TRAINS WEST POINT CADET IN RESEARCH

West Point Cadet Frank DeGeorge continued a tradition of association and exchange between West Point and the BRL - Air Systems Branch (ASB). A participant in the United States Military Academy Summer Research Program, from 3 to 28 June, 1991, Cadet DeGeorge assisted in development of Height-Velocity damage curves for the HIND-F helicopter following complete loss of power to one of two engines and two of two engines. Cadet DeGeorge was responsible for gathering helicopter configuration data, calculation of steady level flight trim states (from hover to maximum forward speed), and determination of optimal autorotation and landing "flare" states. In support of the vulnerability/lethality analysis for Live Fire Test of the M830E1 HEAT Multi-Purpose Cartridge, Cadet DeGeorge's assistance was essential to the timely completion of the analysis. For the past two years the ASB received West Point Cadets under The United States Military Academy Summer Research Program. The ASB will continue to participate in this important research program. POC: Dr Donald Haskell (301)-278-2032.

FEASIBILTY DEMONSTRATED FOR AUTOMATIC SOLID MODELING OF AIRCRAFT AIRFOILS

The Air Systems Branch has just completed a feasibility demonstration for automatically modeling aircraft airfoil shapes that use the NACA wing section designations. Heretofore, geometry modelers produced rough approximations of airfoil surfaces using constructive solid geometry techniques by combining shapes such as elliptical cylinders and wedges. Although these simple airfoil models were adequate for ballistic vulnerability analyses, they were deficient for more rigorous analyses such as signature studies. The automatic technique exploits the explicit parametric shape specification in the NACA numbering designations to produce an interpolating spline approximation that is extremely close to the actual wing shape; indeed the final spline shape probably more accurately approaches the theoretical NACA shape than can be effected in metal fabrication by airframe manufacturers. The spline shape is then cast into the BRL-CAD spline solid and thus is compatible with both current BRL-CAD models as well as new models. POC is Dr. Donald Haskell, (301) 278-2608. Date: Tue, 16 Jul 91 1:56:08 EDT From: Mike Muuss <mike@BRL.MIL> Subject: MGED window size

There seems to be quite a debate over the desired initial size of the MGED window. Some users want it small, some medium, and some full-screen.

In this release, it will default to nearly full-screen.

In the next release, this should be user settable with some sort of per-user configuration file, perhaps called .mgedrc ! Best, -Mike Date: Tue, 16 Jul 91 14:00:35 EDT From: Phil Dykstra <phil@BRL.MIL> Subject: Re: [Mike Muuss: Re: mged]

A thought: Why not make "title" print out the current title (rather than the help message) and "title This is a title" set it.

- Phil Date: Thu, 18 Jul 91 13:55:52 EDT From: Mike Muuss <mike@brl> Subject: Re: nirt & librt

There are two issues:

1) Applications that need dynamic memory should use rt_malloc et.al. everywhere. It isn't strictly necessary, but it will really foul up LIBRT's memory debugging, should you enable it with a -x option.

2) Applications that need to do I/O **in the parallel sections** should use rt_log(), or else be careful to protect all that I/O within critical sections (RES_ACQUIRE/RES_RELEASE). I/O in non-parallel sections can be done freely, as you wish.

I hope this removes some of your concerns, and clarifies the rules. Best, -Mike Date: Tue, 23 Jul 91 2:55:56 EDT From: Mike Muuss <mike@brl> Subject: pl-tek

This evening, I got tired of having to RSH to VMB to print unix-plot files, so I wrote pl-tek, and added it to the UTIL directory. It seems to work, and even has a man page. -Mike Date: Thu, 25 Jul 91 3:23:55 EDT From: Mike Muuss <mike@brl> Subject: cv

Using Chris' new data format converter routines, I have written a generalized file converter, "cv", and stuck it in the util/ directory. It promises to handle a lot of miscellaneous conversion chores for us.

-Mike Date: Fri, 16 Aug 91 15:38:21 EDT From: "Lee A. Butler" <butler@BRL.MIL> Subject: Re: cell-fb changes

Kathy,

There was a problem with the "-h" option to the cell-fb command in the brlcad/bin directory. I have fixed this, and the new version will go out with tonight's upgrade to the beta version of BRLCAD.

Please note that by default, cell-fb "autosizes" the framebuffer to the smallest framebuffer that will hold the image. This is why cell-fb prints the message about fb_size requested/obtained. This tells you the size (in framebuffer pixels) of the image being created. Most of the time, this will NOT be one of the standard image sizes. Because of this, the "-a" option on pix-fb will not be able to get the sizes right.

To generate a cell plot in one of the standard image sizes, you will have to specify "-h" or something like "-S 0" on the command line to cell-fb.

Lee Butler

Date: Sun, 25 Aug 91 3:29:27 EDT From: "Lee A. Butler" <butler@BRL.MIL> Subject: warning messages from fbclear

This evening, I changed the notices printed by fbclear:

fbclear: NOTE: non-linear colormap in effect. -c flag can correct this. fbclear: NOTE: framebuffer is zoomed. -c can correct this.

For the novice user the old messages appeared to be warnings about an UNDESIREABLE condition. In the case of the colormap, this is generally not the case. Non-linear colormaps are used to gamma-correct framebuffers. For each message, I have selected more "neutral" language:

fbclear: NOTE: non-linear colormap in effect. -c flag loads linear colormap. fbclear: NOTE: framebuffer is zoomed. -c will un-zoom.

Lee Date: Wed, 28 Aug 91 4:41:32 EDT From: Mike Muuss <mike@BRL.MIL> Subject: mged 4.0 feature

In response to some of the numerous suggestions from Ed Davission and his team, Lee and I have added a last-minute feature to mged: the .mgedrc file, which mged reads and processes before starting interactive editing sessions. .mgedrc files contain commands just like you would type at the keyboard.

We are presently experimenting with ways that this can become useful, most notably in the areas of the autosize feature, and (SGI-specific) variables to control size and placement of the window on the screen.

There isn't time to expand this into a rich facility, but this should address the most serious issues of mged mode setting, and provide a good mechanism for future additions.

Best, -Mike Date: Fri, 30 Aug 91 9:13:07 EDT From: Paul Tanenbaum <pjt@BRL.MIL> Subject: NIRT(1) enhancement

I added twelve new "output items" to NIRT. A highly placed ACST official stated (not for attribution) that it probably wouldn't break the 4.0-distribution process to do so. Anyway, NIRT can now tell you the components of the entry and exit normals both in model and view coordinates. The new item names are of the form:

nm_<var>_<loc>

where <var> is an element of

{"x", "y", "z", "d", "h", "v"}

and <loc> is in

{"in", "out"}.

Of course, nirt.1 has been updated accordingly. +++paul

Date: Sat, 31 Aug 91 3:43:41 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Stardent port

Thanks to Phil Dykstra and John Grosh kindly providing me with network access to a Stardent VISTRA 800 workstation, BRL-CAD has been ported to it. Both network and X11 framebuffers work, and MGED superficially seems to work via X11. Anyway, if someone gets serious about this machine, there probably isn't much work left to do.

This was a good effort, because the Stardent C compiler, when run in ANSI C mode, gave a lot of useful warnings. There was one mged file that caused an internal compiler error, but some code simplification fixed that.

In the process, I also ported JOVE to the Stardent and IBM RS/6000, which will be quite handy to have around. Best, -Mike Date: Sat, 31 Aug 91 7:13:25 EDT From: Mike Muuss <mike@brl> Subject: Re: BRLCAD 4.0beta librt bug.

Gary -

Thanks for once again providing an excellent test case. I really appreciate having a reproducable starting point to work from! I was able to duplicate the effects that you noted, and spent much of the evening trying to make sense of what was going on. A valuable byproduct was that DEBUG_PARTITION output of librt is now even better than before.

The differences between 3.7 and the beta version of 4.0 are due entirely to the fact that, in the absence of a user-provided overlap handler, librt simply makes a random choice as to which region will claim the region of space that has the overlap. For lots of reasons, the randomness in 3.7 and 4.0 is not the same, and that explains the different results. In the test case you provided, solid "s1" in region "hull.armor/r1.top" overlaps all the other regions involved. I have a sketch of the situation on my desk, if you would like to see it.

While studying the output, it struck me that it might be nice if the default overlap handler made more of an effort to provide some consistency in the face of overlaps. So, I extended the return codes from a_overlap(), to allow the overlap handler not only to indicate accept/reject as before, but also to indicate WHICH of the two regions to accept. This now nicely separates policy (provided by the user) from the mechanism (still implemented by librt) of handling overlaps. The default overlap handler has several new heuristics to try and make more consistent choices, which in at least some cases seems to be the right thing to do.

In the case of your example:

rtshot -x 2000 -p 4000 -36 0 -d -1 0 0 ktank.g component

release 3.7 broke the ray into 10 different partitions, while 4.0 of Friday morning broke the ray into 12. The latest version leaves the ray intact as a single partition:

--- Hit region /component/hull/hull.ext/hull.armor/r1.top (in s1, out s1) InHIT dist=1841 (surf 0) Point (2159, -36, 0) Normal (1, 0, 0) PDir (0, 0, -1) c1=0, c2=0 OutHIT dist=7175 (surf 1) Point (-3175, -36, 0) Normal (-1, 0, 0)

which in this case seems to be a reasonable thing to do, since "everything else" overlaps with r1.top.

RIP does not need to be changed to continue working. However, if RIP is to take advantage of the new heuristics, then RIP's f_Overlap() routine will need to be modified slightly, so as to express more of a choice than it's present return(1). Here is how librt's default handler works:

/* * Default handler for overlaps in rt_boolfinal(). * Returns - * 0 to eliminate partition with overlap entirely * 1 to retain partition in output list, claimed by reg1 * 2 to retain partition in output list, claimed by reg2 */ int rt_defoverlap( ap, pp, reg1, reg2, pheadp ) register struct application *ap; register struct partition *pp; struct region *reg1; struct region *reg2; struct partition *pheadp; { ....... /* * Apply heuristics as to which region should claim partition. */ if( reg1->reg_aircode != 0 ) { /* reg1 was air, replace with reg2 */ return 2; } if( pp->pt_back != pheadp ) { /* Repeat a prev region, if that is a choice */ if( pp->pt_back->pt_regionp == reg1 ) return 1; if( pp->pt_back->pt_regionp == reg2 ) return 2; } /* To provide some consistency from ray to ray, use lowest bit # */ if( reg1->reg_bit < reg2->reg_bit ) return 1; return 2; }

If you can suggest further refinements, I'd love to hear them!

I hope that this analysis puts your worries to rest about the differences between 3.7 and 4.0, and will leave you free to resume RIPing away.

Best, -Mike

Date: Tue, 17 Sep 91 18:51:27 EDT From: Mike Muuss <mike@brl> Subject: Re: Brlcad4.0

Dear Holly -

In your message, you indicated:

>> I have been informed by Sue Coates that there is >> some problem with the include file for this function. I >> statically declare the 'struct application ' variable I >> use and assign it specific values. >> >> Could someone please elaborate on the problems >> and provide me a list of possible solutions or at least >> some explainations??? >>

I am not aware of any problems with the header file raytrace.h, in which rt_shootray() and struct application are defined.

When you file a bug report, it would be most helpful if you would provide the name of the file that has the source code in it which is troubling you. Without more information to go on, I can't be certain what the issues might be.

If you are attempting to initialize the application structure at compile time, that won't work from version to version. Here is the comment in the header file:

/* * This structure is the only parameter to rt_shootray(). * The entire structure should be zeroed (e.g. by bzero() ) before it * is used the first time. ... * * Note that the organization of this structure, and the details of * the non-mandatory elements are subject to change in every release. * Therefore, rather than using compile-time structure initialization, * you should create a zeroed-out structure, and then assign the intended * values at runtime. A zeroed structure can be obtained at compile * time with "static const struct application zero_ap;", or at run time * by using "bzero( (char *)ap, sizeof(struct application) );" or * rt_calloc( 1, sizeof(struct application), "application" ); * While this practice may not work on machines where "all bits off" * does not signify a floating point zero, BRL-CAD does not support any * such machines, so this is a moot issue. */ struct application { /* THESE ELEMENTS ARE MANDATORY */ struct xray a_ray; /* Actual ray to be shot */ int (*a_hit)(); /* called when shot hits model */ int (*a_miss)(); /* called when shot misses */ int a_onehit; /* flag to stop on first hit */ struct rt_i *a_rt_i; /* this librt instance */ int a_zero1; /* must be zero (sanity check) */ /* THESE ELEMENTS ARE USED BY THE LIBRARY, BUT MAY BE LEFT ZERO */ .... /* THE FOLLOWING ELEMENTS ARE MAINLINE & APPLICATION SPECIFIC. */ /* THEY ARE NEVER EXAMINED BY THE LIBRARY. */ .... };

If this relates to your difficulty, I would be happy to provide you with copies of some E-mail traffic that discuss this programming strategy. Or, if you could provide me with a pointer to your source code and a test case, I'll make sure that your difficulty gets looked at and resolved.

Continued discussion of this should be directed just to <acst>, so that we are not cluttering the mailboxes of the whole Division, e.g. <vld>.

Best, -Mike

Date: Thu, 19 Sep 91 16:32:38 EDT From: Mike Muuss <mike@BRL.MIL> Subject: g2asc update

Thanks for your note a week or two ago, reporting that the TACOM "FRED" program was not able to read new format .asc file. I have modified the g2asc program to output a compatible value for the c_length field, so when the next CAD update goes out, things should work better.

This should also make it possible to move .asc files back to machines running Release 3.7, should that be necessary.

I would appreciate hearing about any other incompatibilties that you might encounter.

Best, -Mike Date: Fri, 20 Sep 91 16:13:05 EDT From: Mike Muuss <mike@BRL.MIL> Subject: Re: area command in MGED

Thanks for your bug report of 6-Aug. The problem you reported (boundp and parea not being included in the distribution) has been rectified in the 4.0 Release of BRL-CAD.

Thanks for pointing this out. Best, -Mike Date: Fri, 20 Sep 91 19:50:52 EDT From: "Lee A. Butler" <butler@BRL.MIL> Subject: Re: Angle Distance Cursor in MGED

Jim,

Thanks for the note. It is clear that different folks wanted different things from the ADC. In the next release (Beta/final?) the ADC ABSOLUTE position will be reported as "cent=(x, y)" and the RELATIVE position (which was what was previously reported as "cent=") will be reported as "delta=(x, y)".

Lee Butler Date: Mon, 15 Jul 91 17:48:48 EDT From: "Lee A. Butler" <butler@BRL.MIL> Subject: Size of BRLCAD 4.0

Many of us have noticed that BRLCAD 4.0beta requires substantially more disk space than 3.7. In some cases, utilities have more than doubled in size. I went looking for the reasons for this today. It would appear that the greatest difference comes from the fact that the SGI now links with the X11 libarary. This is somewhat compounded by the fact that we are not currently using a shared library for X11.

As an example, I compiled libfb(3) and fbcolor(1) with and without the X11 support. Here is the breakdown:

Size file coments ---------------------------------------- 293760 fbcolor* No X11 818432 fbcolor.X11* X11 support

Lee A. Butler SLCBR-VL-V Internet: butler@brl.mil Ballistic Research Laboratory Phone: (301) 278-9200 Aberdeen Proving Ground, MD 21005-5066 Date: Mon, 23 Sep 91 2:13:00 EDT From: Mike Muuss <mike@brl> Subject: Re: BRL-CAD Release

Dear Sue -

In your note of Mon, 29 Jul, you mentioned an interesting problem:

>> I have noticed that with the new release of mged there is no limit >> (or a much larger limit) on how many regions I can display by typing >> e r.b*. This is really nice. However, there is still a limit on >> the number of regions that rt can handle. The following lines show >> what I typed and the errors I got. >> >> e r.b* (This displays approximately 1610 regions.) >> rt -s 1024 -P 4 >> rt: Arg list too long Abnormal exit x 1000, return (exit) code=16 >> >> I got around this by grouping all my regions into one group (g cylinders >> r.b*).

I investigated this behavior this evening. The "rt" command in MGED currently has a limit of 2000 objects. However, the SGI operating system has a limit (called ARG_MAX) on the number of *characters* permitted when exec'ing a new program (the "command line" to the program). This limit is set by SGI at 5120 characters, and in this case, is the limit that you were running into. There isn't much that can be done about this, so your work-around is a good general practice.

Best, -Mike

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