The most recent version is Release 2.3, 2-November-1987. There is a Release 3.0 comming up, targeted for May/June timeframe. The new 3.0 release will include quite a variety of improvements, including better rendering in RT, MGED support for X11r2, much improved MGED support for SunView("suntools"), SGI 4D support, 3-D floating point UNIX Plot and related plotting tools, and much more.
Here is an example sequence of what you are trying to do:
make a sph r r1 u a r r2 u a g all.g r1 r2
Then use object editing to modify (rotate, translate, scale) the arc r1/a and the arc r2/a. Or, you could modify the arcs all.g/r1 and all.g/r2, depending on your intent.
The Release 2.3 and earlier suntools support is in a very early form. Quite honestly, if Bill Lindemann at Sun hadn't taken an evening and done it, you wouldn't have anything yet. BRL uses lots of Suns, but not for vector graphics -- we have other devices for that. We were hoping that one of the BRL CAD recipients that was more heavily involved with vector graphics on Suns might do some work to polish things up a bit.
However, I am pleased to note that Gary Moss has gotten excited about running MGED on the Suns, and he has already made major progress in improving the dm-sun.c support.
In a related area, Bill Mermagen has embarked on his first venture into MGED (a learning exercise leading to a much more ambitious project). For starters, he will be adding vendor-independent pop-up sliders, so that all displays without knob boxes will be able to use sliders on the screen under control of the mouse/pen. This will be a very significant addition.
Paul Stay is working on significant performance advances in handling splines. Phil and I have been working on at least a half a million various things. Last week Phil did the X11r2 support, which is pretty nice now. I have been preoccupied with videotape lately (not to mention being burried in paperwork). Phil and Terry and I will be making a "big push" in animation tools in the Spring.
There has also been significant work in the predictive signature area over the last year (sorry, not included in the normal distribution).
Lots of good stuff happening. You can expect some terrific papers at the BRL CAD Symposium this summer (plug, plug). Contact <Keith@BRL.ARPA> for details. Best, -Mike
This evening I made some worthwhile progress. The RTCHECK program now exists, and produces 3-D floating-point UNIX-plot pictures of overlapping regions within an MGED database. It can be used as a standalone tool (with plot viewers like pl-fb, pl-sgi, tplot, etc), or it can be run directly from within MGED.
From within MGED, the command "rtcheck" invokes the RTCHECK program on the model from the current view, and then displays any overlaps detected with yellow vectors added to the screen as "3-D overlays". When RTCHECK is finished, the view can be rotated, zoomed, etc, to more closely examine the overlaps.
As a by-product, MGED also got a new command called "overlay", which allows a UNIX-plot file to be read in as an (optionally named) overlay. This can be useful for studying a single ray-path in the context of the model geometry. (The RT program can give unix-plot dumps of ray paths as a debugging option). This could also be used to superimpose, for example, measured spall-cloud contours with model geometry, as a visualization aid. There are probably many other uses, too.
The RTCHECK program is installed on VGR only. Because I still have not finished fixing the ARB8-becomes-ARB6 bug in MGED, this new version of MGED is not yet installed. However, the bug hunt should not drag out more than a few more weeks.
Phil has been making good progress with pl-X, the UNIX-plot to X-windows display program, the precursor to having X-windows support for MGED.
Best, -Mike
Conversion of CSG solid models to bags of trimmed polygons is not an easy task. The "big-E" command does not do this, it outputs a list of trimmed EDGES, but has no notion of the polygons (although it could figure it out with some additional overhead and more code).
The strategy now being persued at BRL is to implement a several-stage tool, that will:
1) tessalate each leaf note as a single solid object, 2) Apply the SIGGRAPH 86 work from Brown to perform the boolean operations on the polygons, and 3) Output the result in a variety of useful forms.
Obviously part #2 is the hardest, and we have Jeff Schmitt from TSU working on this code now. Part #1 isn't trivial, but a first cut won't be too bad.
We too have SGI's, including the new 4D machines, and would like to be able to rotate trimmed wireframes and shaded polygons, for viewing. We plan on having this capability by springtime.
Sorry I sound like a vendor, but we have limited manpower, and have to schedule carefully. Would be wonderful to be able to do everything immediately. (I don't even get to do my own research immediately, so there).
If anybody would like to contribute help to this effort, especially in part #1, please contact <Schmitt@brl.arpa>, with a CC to me <Mike@BRL.ARPA>. Best, -Mike
It is necessary to define SOLIDS (leaf nodes in the DAG) which are composed of multiple polygons (typically triangular facets), the collection of which encloses a finite volume.
Raytracing of such a solid presently works by determining potential intersections for each facet, and weaving the result together into a segment chain for boolean processing. This is not unlike the ARB code. (Which is a modified Cyrus and Beck algorithm -- possible because ARBs are always convex, while the ARS may not be).
This code is being used at BRL now for the first time, and I expect it to continue to evolve (especially in the area of performance). However, there should be enough to start with. Best, -Mike
Right now, RT assumes square pixels in ordinary use.
If you are displaying on a non-square video system, eg, 768x512, for NTSC use, then RT can be run to produce the appropriate size images with -w768 -n512 options.
If you have a display that shows 512x512 images, such as an Ikonas, then ordinarily all the RGB monitors are set to display this as a square image (as you reported).
When such a framebuffer is used to create NTSC video, the pixel clock is usually altered to "fill the screen", which results in a non-square set of pixels, because the television image is not square.
In January, when we first started doing videotape work, Phil and I began discussing another set of options to RT to pre-distort the grid to compensate for what the NTSC encoding would do. The module rt/worker.c is where the changes would go. Unfortunately for you, we never implemented the change. For now, we put up with the distortion when creating videotape. My hope is that within the next few months, we will be switching to a 768x512 format for generating videotape (if SGI would ever deliver our GenLock board), and then this issue will be moot (for us).
The only short-term workaround I can suggest is to run RT at the 768x512 resolution, and then pixscale into 512x512. Then, when the lengthened pixel clock widens the pixels, the image should look about right. (If you feel like writing 20 lines of code, just changing RT would probably be simpler, and certainly take less CPU time).
Hope this helps some, Best, -Mike
Due to popular demand, I have made X Window System support for MGED available via anonymous ftp. WARNING: you may experience difficulty in that vector lists (struct vlist) have changed somewhat since the last BRL-CAD release. You are on your own there.
You can find it on VGR.BRL.MIL (a.k.a. BRL-VGR.ARPA, 192.5.23.6) in pub/mgedx.shar. The README file in that shar file follows: ------------------- 21 April 1988
This is a BRL-CAD "prerelease" of MGED support for the X Window System. Expect to find this in our next major release sometime this summer. Included is:
dm-X10.c An X10R4 display manager for MGED.
dm-X.c An X11R2 display manager for MGED (the prefered one).
attach.diff A patch file for mged/attach.c to include the X display manager as an option.
usepen.diff An optional patch file for mged/usepen.c which makes object selection nicer by only doing a redraw when the illuminated object changes.
To use, 1) add the apporiate file (dm-X10 or dm-X) to the mged directory. 2) Apply the patch(es). 3) Add the source file and object to mged/Makefile.loc 4) Define DM_X in Makefile.defs and include your X library, e.g.
MGED_CONFIG = -DDM_SUNPW -DDM_X MGED_LIBES = -lsuntool -lsunwindow -lpixrect /usr/local/lib/libX.a
I have used this code on both a Sun 3/50 and the Cray-2, with a server running on the Sun 3/50 only. There is no support for color at this time. If anyone has any difficulties or adds additional capabilities (e.g. color) please let me know.
- Phil Dykstra <phil@brl.arpa>
For those of you who still don't know:
Black-on-white line drawings which resemble the old GIFT CALCOMP hidden-line, plots can be generated from LGT, by setting the flag either by typing "k 1" to the prompt, supplying the -k1 option on the shell command line, or by selecting the "special applications" menu, followed by "hidden-line drawing". An intermediate image will be generated which is actually the result of stuffing the surface normals into the RGB components of the pixels in the image. Then, this image will be replaced by the final result. The computation of the second image may take a few minutes, depending on the horsepower, load and available memory of the host computer. Images of at least 512-by-512 pixels are usually necessary to produce an accurate result. HIRES (1024-by-1024) images require 1 meg. of short integers (2 to 8 Megs, depending on the machine) extra memory for the hidden-line computation, so be careful on smaller machines with HIRES, or you will send them off to swap city.
BW-IMPRESS may be used to plot these pictures on the IMAGEN laser printers as follows:
$ pix-bw -ntsc image.pix | bw-impress | ipr -qi300 -Limpress &
Locally, we also have RLE-IM, so another route is:
$ rle-im image.rle | ipr -qim118 -Limpress &
Please direct questions to <moss@brl>.
-moss
I have created a /usr/brlcad/ instead of having them live in /usr/brl/ so as to be similar to other machines. I have also updated your software to the following specifications. Please forward the following to those who will be using victor.brl.mil in the future.
Here is a brief description of the Silicon Graphics 4D Graphics Workstation frame buffer and mged support.
1. The machine benchmarks around 9-12 times a vax 780 using rt. 2. The graphics capability is ~140K vector per second. 3. A larger screen size 1280x1024.
This system is a bit different than the Iris 3030 workstations in that it always runs a window manager, so you don't have to run mex, the difference is that you can get the full 24 bit color pictures even running the window manager.
By default you are in "window mode" on the 4D, you can not open additional windows. To do this, DO NOT EXECUTE MEX because it will hang the console (it can be killed from an rlogin at another terminal), instead execute WSH. If you do not want the ill-fated CSH or TCSH, then execute WSH as follows:
$ wsh -c /usr/brl/bin/tbsh # same as /usr/5bin/sh
Type "man wsh" for details.
To use mged on this machine
1. Move the console window to the upper left position of the screen using the mouse menu options to the window manager.
2. Mged files which have been created on an Iris, Sun, or Alliant all use the same floating point format as the 4d. 3. type vacuum.brl.mil> mged file.g with sgi as the display type.
4. There are a few problems with the tedit and the text display of the solid in solid edit, which should get fixed shortly.
The frame buffer is a bit different.
There are four (4) different frame buffer modes for the 4d Workstation. They are:
/dev/sgi0 Private Memory non lingering window /dev/sgi1 Shared Memory non lingering window /dev/sgi2 Private Memory lingering window /dev/sgi3 Shared Memory linger window
Using private memory the image is not saved after the window goes away but allows for many different images to be placed on the screen without interference.
Shared Memory allows for future reference to the image using utilities such as fb-rle, fbed, fbzoom, but there is a problem with manipulating multiple images on the screen.
lingering windows will stay around until you log off the system or you kill the window. A menu button to exit the window is provided via the right most button on the mouse just attach to the window first....
A complete set of Documentation will be provided in the graphics lab in the near future.
As of yet the file system is not being backed up by the operators. So please save your files else where.
I just discovered that on the SGI 4-D, negative shifts on (at least) variables declared "register unsigned" don't work. It would appear that perhaps such a shift is being interpreted as a large positive shift. At any rate, the values always came up zero in the low byte.
I wouldn't ordinarily write code that does this sort of thing -- this particular piece of code was something that somebody else had written quite a while ago, and I just chose this evening to port it to the 4-D. On the other hand, the VAX and the Gould and probably many other machines all permit negative shifts, so this seems like something that other folks may encounter.
K&R are silent on this point (ref: pages 44, 189). No help there. So, I'm not asking that this be fixed, just surfacing it as an issue for others to watch out for.
The upshot of this is that CAT-FB (a port of Ron Natalie's ICAT program) now runs on the 4D, and very quickly. It takes TROFF output and "typesets" it into the current framebuffer, using the vfont bitmaps. Very nice for making slides. -Mike
> K&R are silent on this point (ref: pages 44, 189).
K&R second edition p.206: The result is undefined if the right operand is negative, ...
A neat trick to keep tabs on a batch RT run that is storing it's image in a file is to run:
tail +0f file.pix | pix-fb
This will keep the screen up to date as the picture is written into the file! Best, -Mike
Last evening, I talked to Paul Tanenbaum on the phone, and we exchanged some E-mail. Paul identified four key features in RTRAY that he wished to have added:
1. useair be turned on, at least w/ a command-line option 2. vldray.ob = (regionid > 0) ? regionid : -aircode 3. outside air (i.e. vldray.ob = -1) whenever I'm not in anything else 4. "paint" as in shotray(1V)
I deferred preparing the slides for my Boulder ARO talks until this weekend (sigh), and took this past evening to work on these issues. All four requests have been accomplished, to the best of my ability to test them (ie, not much testing yet). Here are some details:
1) All the RT programs now have a -U flag to set the use_air flag. It takes a boolean argument, so -U0 turns air use off, and -U1 turns air use on. All the RT family defaults to -U0, except for RTRAY, which defaults to -U1.
2) This rule has been implemented within librt(3), and reg_aircode no longer exists -- because it has been folded into reg_regionid value, with negative ID codes indicating air. This actually helpped simplify some of the librt code slightly, so it was an all-around win.
3&4) Paul described to me what he called the VLD standard paint and air codes, which I have implemented. The ``ob'' field of the ray(5V) file is set to the region id of each intersected region, or to the negative of the aircode for each air region, or to one of five VLD-standard reserved values:
-999 zero-thickness ``paint'' at ray's first entry into the model. -998 zero-thickness ``paint'' at any ray's exit interior to the model RPP. -1 (unmodeled) air between modeled regions. -997 zero-thickness ``paint'' at any ray's entry interior to the model RPP. -996 zero-thickness ``paint'' at ray's final exit from the model.
In addition, as I described a few days ago, the ``rt'' (ray tag) field of the ray(5V) file is a 32-bit value set to a combination of the grid X and grid Y coordinates, plus the recursion/iteration (a_level) value (used mostly for multibounce effects in radar simulation). This allows all ray(5V) records pertaining to the same grid cell to be identified.
The new code and updated manual pages have been installed on VMB and VIM in /usr/brlcad/bin (the usual place). RDIST should propagate them to the rest of the machines. Run "man rtray" for additional details.
I there are problems with what has been implemented so far, please let me know right away, and I'll work on them Friday night. Hopefully there won't be any additional features required until I return from TDY.
Best, -Mike
I agree entirely with Doug:
+ Outside air is not required on a shotline before anything else is hit, or after the last component. But, if for instance I come from the side and hit, say, road wheel, space, hull side, I'd like to have that space show up (automatically) as outside air. + The option of paint as implemented in shotray(1V) should serve our purposes admirably. + I don't see why we would need both regionid and aircode, IF we could get by with the convention that non-positive regionid were air. I don't even see why the sign of the regionid need be the characteristic to use in distinguishing air. But some convention across target descriptions and software is strongly desirable.
Now, as far as Gary's protestations against the violation of his sacred ideal of *clean* code, I have several comments:
First of all, talking about any of these things as "special case kludges" glommed onto a hapless GIFT ignores history. The <only> reason GIFT was built was to provide target data for vulnerability computations. Munitions versus vehicles. No CAD, or signature work, and not even terribly pretty pictures. GIFT has served quite faithfully for a long time, and it even provided a basis for a lot of subsequent *clean* code intended for broader applicability.
Furthermore, I don't think the three suggestions I made qualify at all as kludges. A ray-generating routine that ignores air is no less fluky to my mind than one that decides to report everything but the diesel fuel.
Now the good news, Gary. That scourge of conscientious software engineers everywhere, Phantom Armor, need never rear its ugly head in ray(4V). It was an artifact of the way GIFT behaved. Air is not treated like non-air in GIFT shotlines. Instead, every component has some amount (possibly 0) of air behind it. Thus, the only way to represent consecutive partitions with different aircodes is to provide a dummy solid between them that acts as a bracket behind which to hang the later air. When air is handled explicitly in a ray(4V) file, I don't need phantom armor to glue it to.
+++paul
"Outside air" is often found in "target interiors". It is defined as the "background", i.e. it exists where nothing else in the model is present. Entering and exiting rays are not normally found in RAY(4V) files. I have found it useful to provide (either as an option, or standardly) "exit paint" at the location of final exit of a shot. See SHOTRAY(1V) in the VLD/VMB UNIX Supplementary Manual for more information.
I wouldn't check for non-negative region IDs. There is no reason to disallow explicitly modeled air regions. In fact, with MGED I would think that would be the right way to model compartments.
All perfectly reasonable requests. Don't feel bad, remember that rtray and rtshot were written to help me debug some stuff; I documented them and made them available in the hope that they would be worth something to somebody else; they were not particularly designed for V/L work to start with. I'm pleased that they are pretty close to what you do need, and I appreciate your taking the time to clearly indicate what you want. That makes it easy to do something for you!
I have a question about the "outside air". From the start point to first hit point, I can invent an unmodeled air partition if that is helpful, although I'm not clear on what purpose it might serve (I don't really have to know, just curious). However, after the LAST exit point, does the outside air continue on to (a) the bounds of the model RPP, or (b) +infinity? Is the air ID of "-1", and the general practice of making the region number the negative air code when in air "the way" to do things? Should code be inserted to verify that all non-air regions have positive region IDs (there is presently no such checking)? What other assumptions should be wired in, and what other checking should be done to allow new V/L work to go forward with a minimum of baggage from the past, yet still supporting the older codes without too much effort? Best, -Mike
PS: I suspect that further dialog should probably be limited to the CAD list -- all of BRL Support probably does not care about raytracing.
I have found several. They are:
1) The struct rt_i (as defined in raytrace.h) has a field
int useair; /* "air" regions are used */
which is turned off. Thus I never get any air in my ray files. This is not good. Could it please be turned on, or at least provide a command-line option to do so? Paul Stay has already made me a version that does this, and it does give me the air I need.
2) Unfortunately, even with useair turned on, I don't get correct behavior. Every flavor of air has a regionid of 0. To differentiate between them, one needs their aircodes. So rtray should do something like
#include "db.h" #include "ray.h"
union record rec; struct ray vldray;
if ((vldray.ob = rec.c.c_regionid) == 0) vldray.ob = -rec.c.c_aircode;
This way, if vldray.ob is positive, I'm dealing with some object, and if it's non-positive, then I've got some kind of air (and I know what kind of air it is, too).
3) Finally, I also need "outside air." This one I could probably fake by enclosing the whole dumb target in an arb8 with aircode=1 and subtracting everything from it, but it'd sure be nice if rtray did it for me.
All three behaviors I've requested are standard procedure in the GIFT world of business. The principle of least surprise argues for making rtray act that way to.
By the way, I estimate that I'm making myself something of an annoyance with all these requests, but they're essential to AMC's meeting a suspense to DA on a project of extremely high priority. I know that everyone is busy with lots of work of his own, but this one plays right into a major systems analysis effort. And, on the bright side, once this shake-down cruise is completed, we should possess a bug-free piece of software that goes a long way toward integrating mged/rt and the Old School of V/L assessment.
+++paul
This evening, I got a variety of software working on the SGI 4-D, to enable running the Dunn instruments camera directly from the 4-D. No big deal, but a lot of little nits had to be chased down, including some more options to if_4d.c, bug fixes to dunnsnap and dunncolor, and a new -F flag to dunnsnap (to open a shared memory window before photographing the screen, natch).
On the 4-D, chars seem to be unsigned, which caused some difficulties for "fblabel".
It's nice to finally have most of the software working on the 4-D. -Mike
I have taken Phil's ucolor and uline tools, and added them to the util directory as plcolor and plline2, with a few minor improvements. I needed these as part of the standard set of tools, to enable me to do my performance plots on the SGI. -M
I have modified RT so that when it is run on UNIX systems, if the output file already exists and has pixels in it, RT starts computing with the first unfinished pixel, rather than starting over at the beginning.
This is a valuable feature when machines are not staying up a lot. -Mike
> ... indeed, perhaps an xwindows version of brlcad would > get you over many of the problems inherent in maintaining > versions of the package for many different machines.
One of these days I should write a paper on the functional, design, and philosophical differences between X and our frame buffer library. I have written an X Window System interface for MGED and plan to do so for the frame buffer library as well, but both of those interfaces will for the most part have to be "substandard" interfaces. While it is true that the current Sun interfaces could (and should) be much improved, they too will never be able to completely overcome insufficient hardware support (at least on current Sun hardware). X, while a very nice thing indeed, was simply not designed to allow the level of functionality at the level of performance that we desired.
The model of a frame buffer used in the library is one with dedicated display memory, 24bit color, color maps, hardware pan and zoom, and hardware cursor support. When forced to work with a device without some of these features, we have attempted to compensate for it in software, with such things as shared memory for reattachable image store, software pan and zoom imitation, etc.
The ideal hardware for the vector (MGED) interface is one with very high vector drawing rates, color, double buffering (assuming a raster display), hardware support of full 4x4 matrix transformations, knob button and pen or mouse input devices.
It is ironic that probably the most widely used hardware with BRL-CAD is Sun workstations, yet the Suns are the least appropriate machines that we support. We almost never run any of the graphical routines (MGED or frame buffer tools) on the Suns - one of the reasons we have worked so little on that interface.
You really need a full function frame buffer like an Ikonas, and a full function graphics engine like an SGI, (and a nice terminal like a Sun), in order to see our software in a reasonable light.
[I note for the record that X will become a more reasonable platform now that folks with real graphics hardware like SGI have begun supporting it. You need good hardware for good graphics. Software can't do it all.]
- Phil
ps: please don't think that I'm criticizing anything that you said, I just used it as a springboard for the above babbling.]
Tom,
I have incoporated your marble.c and solid texture routines (which I named stxt.c) into the master copy of the CAD sources in spark:/m/cad/rt -- if you plan to do additional work on them, I'd appreciate it if you would check out copies from SPARK, and proceed from there. I didn't change anything, but I did add some headers and fiddle a comment or two.
I have not had a chance to try them out, but I'm looking forward to it! Best, -Mike
After further discussions with Gary on Wednesday, he persuaded me to decouple the "VLD ray file object code encoding" from the behavior of librt w.r.t. the handling of air codes. I have implemented this change, and taken care of the subsequent few modifications to rtray to cope.
Therefore, RIP and other codes will NOT need to be changed when used with the new librt (when it is released).
Note that these changes have been applied to the experimental version of the code on SPARK; no production code has been changed yet. However, having resolved this issue means that we should be well positioned for placing the new librt into production within the next week or two, which will start of the first cycle of integration testing for Release 3.0.
I thank everybody for their input, understanding, and patience.
Best, -Mike
Ed Davisson came up with a better way of finding bounding planes on a torus. Previously, I had fit bounding planes to a "hockey-puck" shaped cylinder around the torus to avoid the quartic equations that would result from the general case. On non axis aligned tori this would over estimate the bounds by at worst 41% of r2 (the smaller radii of the torus); in the axis aligned case the estimate is exact.
Ed's method is strictly algebraic and gives exact answers for circular tori (the only ones we can presently handle anyway). I coded it up in LIBRT this evening, chose a couple of "random" tori, and got the following almost-meaningless-statistics-of-the-day:
Pruning efficiency increased from 61% to 80%. Total run time went down by 5.5%.
Your mileage will vary. Thanks Ed.
- Phil
A couple of days ago I added a new pseudo device to libfb called stack. I the spirit of rt's shader by the same name, stack takes a semicolon separated list of framebuffer specs and send a copy of all output to each one. Input comes from the first device.
e.g.
setenv FB_FILE '/dev/stack /dev/ik0;/dev/debug;'
to use ik0 but also dump a debug trace. Or perhaps
setenv FB_FILE '/dev/stack filename;host:device;'
to keep a file copy of the frame buffer image on the local machine. Good perhaps for demos when you want to string an arbitrary number of displays together. To appear in 3.0.
- Phil
In general the Q matrix is not diagonal, but it is with respect to the principle directions. (The notation is Do Carmo is pretty much standard.) What Andy calls the curvature matrix on p.67 (10.10) is what Do Carmo calls the (aij) matrix on page 155. This matrix is actually computed in spl_curve.
You ask if we really need II. Actually not if we have both principle directions. You can always conjugate the diagonal Q by a change of basis back to the global or local coordinate system. This can be done if both principle directions are known.
I would think that your modification to the curvature structure is enough. I personally prefer k1, k2 as principle curvatures rather than c1 and c2.
Did Andy send you a copy of Ri-Chee's thesis as well? The divergence equations on p48-49 are what we need to solve.
Alex
P.S. What application actually uses the curvature structure? Has you tried this application on splined solids? Like the teapot? We can send some simple spline objects like cone-spheres or toy jets if you would like.
(We usually use algebraic coefficients or hermite basis for our splines.)
> In general the Q matrix is not diagonal, but it is with respect to the > principle directions. (The notation is Do Carmo is pretty much standard.) > What Andy calls the curvature matrix on p.67 (10.10) is what Do Carmo > calls the (aij) matrix on page 155. This matrix is actually computed > in spl_curve.
Agree. Less a sign difference and an a12 <-> a21 swap (at least w.r.t. Andy's paper). I don't have a copy of Do Carmo. Paul Stay and Peter Stiller worked out the formulas in spl_curve. Paul probably has them on paper.
> You ask if we really need II. Actually not if we have both principle > directions. You can always conjugate the diagonal Q by a change of basis > back to the global or local coordinate system. This can be done if both > principle directions are known.
You always had pdir2 via: VCROSS( pdir2, normal, pdir1 ), i.e. pdir2 = normal x pdir1. Right? I think we might as well return it in the curvature structure though.
> Did Andy send you a copy of Ri-Chee's thesis as well? The divergence > equations on p48-49 are what we need to solve.
No, but I would love to get a copy. I was working from T.B.A. Senior's paper on divergence factors (which use trig formulas based on the principle curvatures, not the full Q or II matrix).
> P.S. What application actually uses the curvature structure? Has you > tried this application on splined solids? Like the teapot?
We have tried the Teapot with my SAR code, and as I recall spline curvature was causing some problems. Paul has done a fair amount of work on the splines since that time though, but I don't think that we have checked them out since then. You are the first person besides "us" that has wanted curvature! So, its good that you bring the spline curvature issue back up. I just hope you don't mind being a test case.
- Phil
Thanks for a copy of Ed's paper on Curvatures in MGED but I'm afraid that I am still very confused by the code in /librt/spline.c. Here is the offending section:
denom = ( (E*G) - (F*F) );
a11 = (( f * F ) - (e * G) ) / denom;
a21 = ((e*F) - (f * E))/ denom;
a12 = ((g * F) - (f * G))/ denom;
a22 = ((f * F) - (g * E))/ denom;
a = 1.0; b = - ( a11 + a22); c = (a11 * a22) - (a12 * a21);
rt_orthovec( uvec, hitp->hit_normal ); VCROSS( vvec, hitp->hit_normal, uvec );
eigen2x2( &cvp->crv_c1, &cvp->crv_c2, vec1, vec2, a, b, c ); VCOMB2( cvp->crv_pdir, vec1[X], uvec, vec1[Y], vvec ); VUNITIZE( cvp->crv_pdir );
It would seem to me that the trace = 2*mean curvature and the determinant= Gaussian curvative are invariant. The a,b,c transformation above does not respect this invariance. Since the coordinates from a parametric spline surface are not necessarily orthogonal, the matrix of DN_p is not necessarily symmetric. Unless the e,f,g,E,F,and G are not the standard notation found in DoCarmo, then I think that the direction vector and curvatures produced by eigen2x2 above are not correct???
Please let me know if these comments are in left field, but it would be fairly easy to compute the curvatures and principle directions from the a11,a12,a21,a22 above.
Alex Woo woo@pioneer.arc.nasa.gov
For starters let me say that we probably can change the curvature call and structure if need be. I believe that I am the only person with code that uses it at the moment. We can check.
Two, I just noticed that the comment above the curvature structure in raytrace.h is wrong. The sign convention was changed and this comment wasn't. It also might be worth while adding the other principle direction vector, since it is usually computed and if needed it would save the user from computing it all over again. Thus raytrace.h should probably look like:
/* * Information about curvature of the surface at a hit point. * The principal direction pdir1 has unit length and principal curvature c1. * |c1| <= |c2|, i.e. c1 is the most nearly flat principle curvature. * A POSITIVE curvature indicates that the surface bends TOWARD the * (outward pointing) normal vector at that point. * c1 and c2 are the inverse radii of curvature. * pdir2 = normal x pdir1. */ struct curvature { vect_t crv_pdir1; /* Principle direction */ fastf_t crv_c1; /* curvature in principle dir */ vect_t crv_pdir2; /* other principle direction */ fastf_t crv_c2; /* curvature in other direction */ };
Perhaps c1, c2 should be k1, k2 per common notation, I dunno. I should probably sample the waters via the CAD list to see if anyone else uses curvature yet!
Okay, now to your note:
> I would like to modify these routines and return the second > fundamental form (structure II).
Just to get my terms straight (I just got Andy Lee's GTD manuscript two days ago so at least now I know what a "Q" curvature matrix is!), the curvature matrix Q can be found from the above information by:
[ c1 0 ] Q = [ ] [ 0 c2 ]
The first fundamental matrix I, and the second fundamental matrix II, are related by Q via:
II = Q I
So to find II, we need I (which consists of the partials of the basis vectors dotted together). Its not clear to me that we have the needed information. I also note that in some cases, i.e. torus, we compute the curvatures and directions geometrically, rather than from the second fundamental form. I have formulas for the latter, but the former is more efficient.
So a couple of questions:
You say that you want II. What do you need in II that you can't get from Q? Just curious.
> In ell_curve, tgc_curve and spl_curve, you appear to compute the trace > and determinant of the second fundamental form ....
Are you saying that what you need is already in there, just not returned? I have no objections to changing any of this code, I just want to understand exactly what information is needed.
- Phil
Mike took the liberty to forward your comments about BRL-CAD to me. I found them interesting and would like to be privy to your discussions with Mike.
Probably more than Mike, I have attempted to carry the flag into some classic meeting grounds which typically advertise an interest in CAD, CAE and sometimes CAM and CIM. In thinking about this experience I found the following dates from my back electronic calendars in which I have presented papers to groups with direct industry representation.
------------------- 05/18-20/82 JTCG/AS Meeting at Wright-Pat 06/13-16/82 NCGA: Anaheim, CA Wed 10/20/82 PHD in Phoenix to give MTAG paper 10/12-14/83 Wash. DC Defense Computers-Graphics'83 Computer Graphics Conf: Wash Conv Center Mon 03/26/84 0900 Presentation at McCormick Place (ASME) Wed 11/28/84 0930 Paper @ CAD/CAM MTAG Symposium - Seattle Wed 05/14/86 0845 FMC Presentation: San Jose Hyatt Tue 08/25/87 1300 DC JTCG Mtg: PHD Presentation @ Center for Naval Analysis Wed 09/30/87 0900 DC PHD Presentation at Defense & Government Computer Graphics Conf: Wash Conv Center Wed 05/11/88 - - ADPA Mtg: San Diego: Day #2 -------------------
Back in the 83-84 time frame, I also had extensive interaction with the DARCOM Office of Manufacturing Technology (OMT) and Rock Island Industrial Based Engineering Activity (IBEA).
Let me summarize briefly.
o First Commercial CAD Capabilities: This has probably changed a bit, but the commercial sector generally was interested in generating an electronic data base of a part/item/etc., turning this data base into a 3-D mesh for structural analysis, and also generating blue prints. Note that in general, analysis meant structural analysis. Few of the modelers were solid geometric modelers and, until a few years ago, absolutely none could even possibly model systems of the number of parts that we require today in, say, an M1A1 or Bradley description. Even today there may not be a commerical system that can match this requirement.
o CAD for the Army was under OMT (which I suspect is defunct). And all OMT cared about was manufacturing problems.
o Having worked hard to establish common ground between the early threads of BRL-CAD and the commercial market place, I found a disappointingly small intersection. Note for example, in 1984 I spoke by invitation at the ASME meeting in Chicago. Typically the audience at such meetings is made up of folks who want to design electric drills without paper. Usually few if any of these folks were interested in the very broad class of military problems those in SECAD and VLD care about.
o On the other hand, BRL-CAD has found a very large market which is growing very quickly. It is generally not with people who have classically associated with CAD/CAM, but with another very large group of people who are interested in performing item-level analyses of military equipment. That includes all kinds of topics from vulnerability to signatures, to weights, neutron transport, high-power microwave damage, . . . The fact that the BRL-CAD software distribution has now reached 350 sites is testament to that need.
Monday I'll send you a couple of papers which illustrate what we typically do with what we call CAD and analysis.
Am looking forward to your views on this all.
Best, phd
Thanks for your nice note about my paper and the BRL-CAD Package. If it should happen that you are able to use the BRL-CAD software to assist you in some of your work, I would be most pleased.
TOPIC 1: Computer Aided Design
Please understand that I am not in the business of "selling" the BRL-CAD software. We distribute it in the hopes that it will be useful to others, but we accrue no benefits from having other people use it, so there certainly is no compulsion for anybody outside BRL/VLD to use it.
Every few years, BRL/VLD has conducted a market survey of commerical CAD systems, in an attempt to switch to using commercial software, rather than having to develope it locally. Unfortunately, on every market survey, the complex analysis demands of the BRL/VLD mission could not be satisfied by commercial software. Therefore, BRL has been forced to remain active the in CAD software field.
The roots of the BRL-CAD Package date back to 1958, with early work by the VLD folks in solid modeling and ray-tracing. The present software represents the third generation of this capability. The strategy has always been to focus on providing capabilities that BRL/VLD has required that were not available in commercial packages, while avoiding spending effort duplicating capabilities that are well supported in the commercial community. This strategy has positioned the BRL-CAD Package in a special "niche" which many people do not fully appreciate. Outside evaulations of our package have assessed the BRL-CAD Package as being as much as five years ahead of commercial packages, **in certain areas only**.
For example, the BRL-CAD Package does not presently have the ability to produce annotated engineering drawings, and, although VLD does have a contractor working on adding this capability, it will probably be over a year before this is in the hands of the user community.
On the other hand, the range of engineering assessments that can be performed on complex 3-D geometry using the BRL-CAD Package is quite wide. It is a testimony to the quality of the underlying geometric representation that new analysis applications continue to be built, very quickly, and with only modest effort.
In your message, you wrote:
>> The problem that I see is that BRL-CAD is not what engineers commonly >> call CAD. It doesn't do the traditional "design" kinds of things that >> all of the commercial CAD packages do. It does do things that the >> commercial CAD packages can only hope to do in the future.
I would like to suggest that the difference you have noted, rather than being a "problem", is our success -- it is a result of having built a software package that allows us to tackle problems that can not be done any other way. This cutting-edge capability is our "value added" -- the reason that BRL is in the CAD business at all.
For example, Kurt Fickie can use the BRL-CAD Package to combine 3-D solid geometry, vector flow fields from analytic computations, and digitized photographic data from laboratory experiments. These three types of information exist within the single framework of the BRL-CAD package, to produce images that show the relationship between the models and the experiments. This is one example of the sort of analysis capabilities that do not, to my knowledge, exist in commercially available packages.
There are a great many things that the BRL-CAD Package does NOT do, and I try to be very frank in informing potential users of those areas. However, at the same time, there are lots of problems that the BRL-CAD Package seems to do particularly well. There are now over 300 sites that have copies of our software, several dozen of which have committed very heavily to it.
The BRL-CAD software is a central part of the engineering "design loop", and across all of the organizations that use the BRL-CAD software, it is used for creating and optimizing the designs of a great variety of items. Within BRL/VLD, it is used to design, analyze, assess, and optimize all ground vehicles in the U. S. Army. At the same time, it is also used to drive the design of new radar and sensor systems, and to help evaluate the benefits of various signature reduction measures. Outside BRL/VLD, it finds significant use, with the Army Engineer's Topographic Laboratory using it for terrain studies, etc, etc. It is used at Northrop for various stages of aircraft design and evaluation, and also in their "factory of the future" project, to provide the coupling between their existing drafting-based CAD systems and their computer-vision system that supervises their (experimental) robotic factory. In the University sector, it is used for visualizing medical data, teaching Naval Architecture, and a great variety of other tasks. There is even a group in Europe that is using BRL-CAD for the design of optimized sawmills!
Also, a group totally outside BRL, in the Joint Intelligence community, after a two year long market survey by a team of about 40 experts (hired for the occasion from Universities, Industry, and Government Agencies), have selected the BRL-CAD Package as the single platform to be used for all INTEL signature modeling. I consider this to be a very significant "vote of confidence" in the quality and capability of our software.
One of the very special aspects of the BRL-CAD Package is that we distribute the complete source code to the system. Sophisticated users who wish to add discipline-specific features, or wish to couple new kinds of analysis codes to the capabilities that already exist within the BRL-CAD system, can do so without impediment.
I would be pleased to chat with you about your particular application, to help you decide if the BRL-CAD software is likely to be a "good fit", or whether there may be other alternatives that might serve your needs better.
TOPIC 2: Vendor Assessments and Future Directions
The Advanced Computer Systems Team (ACST) spends about 6-8 weeks a year engaged in keeping up to date with computer hardware vendor plans, not only for the present, but also to track (and sometimes steer) their plans for the 2-3 year time frame. There certainly are a lot of vendors, and there are always a few that we do not have full status on, but I feel that we do an excellent job of covering futures. We also invest a certain amount of time in conducting benchmarks of these different machines, to be certain that we have a performance assessment which is solid. In our benchmarking, we have generally found the results of the Whetstone, LINPACK, and BRL-CAD tests to be strongly correlated, but we always insist on running all three.
ACST performs this market evaluation and benchmarking function to advise SECAD and VLD on how to position themselves to derive maximum price/performance benefit **on SECAD & VLD computational problems** when purchasing new computers.
In the case of the particular vendors that you mentioned (Alliant, Convex, Multiflow), I have had the pleasure of spending several days each with the main processor designers for these companies, and I feel that I have a very good handle on where they are now, and where they are likely to be in several years. Our non-disclosure agreements prevent discussing details in this forum.
Perhaps when we get together, we can exchange design information about various systems, as you probably have information on some systems that I have not yet had the opportunity to study in detail.
TOPIC 3: Conferences
In the first week in August, all of ACST will be attending SIGGRAPH, the world's main conference concerning research activity in computer graphics and geometric modeling. I regret that we will be unable to send anyone to the more applications oriented ASME Computers in Engineering conference.
Fortunately, SIGGRAPH also has a superb vendor show, which we will attend. As of 1-March-88, there were over 250 vendors already registered for the SIGGRAPH exhibition. It sounds to me like we should get together after our respective conferences, and compare notes on the latest unveilings!
SUMMARY
I'm looking forward to a chance to get together, to get to know you better, and to share with you some of ACST's recent work. Looking at my calendar, just about any afternoon from 11-Aug onward would be fine. Do you have a preference for a date?
Best, -Mike
In ell_curve, tgc_curve and spl_curve, you appear to compute the trace and determinant of the second fundamental form and return the curvature structure. I would like to modify these routines and return the second fundamental form (structure II). For compatibility, I think that I should make new routines and add an entirely new structure to raytrace.h. It would be nice if your group concurred with this decision and included these things in your subsequent releases. Any comments? Concurrence?
Do you have any notes on the various xxx_curve functions? I suppose I can back it the equations out of the code but some notes would be helpful. For splines, there doesn't appear to be any need for changes to spl_curve except for returning the form structure II.
Alex Woo
P.S. Can you send me a sample spline solid in asci form? There doesn't appear to be any in the sample databases. (I have been reading the IGES manual for entities 114 and 126. Your spline format is closest to the 126 format for NURB's. Unfortunately we have been using the simpler 114 format for bicubics. Also, IGES, version 4.0 supports CSG entities.)
I have gotten the RGB <-> XYZ transformation information for the Iris 4D/60T monitor. It is:
R G B X 0.6100 0.2980 0.1510 Y 0.3420 0.5880 0.0640 Z 0.0480 0.1240 0.7850
X Y Z R 2.2708 -1.0772 -0.3490 multiply the XYZ values of the color you want G -1.3285 2.3607 0.0631 by this matrix for the RGB (not normalized) B 0.0710 -0.3070 1.2853 values for the 4D/60T monitor.
Have a colorful experience today,
Michael Mascagni mascagni@nyu.edu mascagni@ncifcrf.gov
There are some people here looking into ground clutter. The following references will give an idea of what models they are considering. 1. M. Borgeaud, R.T. Shin, and J.A. Kong, "Theoretical Models for Polarimetric Radar Clutter", Journal of E.M. Waves and App., pp73-89, Jan 1987. 2. A.K.Fung, H.J. Eom, "Multiple Scattering and Depolarization by a Randomly Rough Kirchhoff Surface", IEEE Trans. Ant. and Prop., pp. 463-471, May 1981. 3. F.T. Ulaby, A.K. Fung, R.K. Moore (1982), Microwave Remote Sensing, Addison-Wesley, Mass., chap. 12 4. G.R. Valenzuela, "Depolarization of EM waves by Slightly Rough Surfaces", IEEE Trans. Ant. and Prop., pp. 552-557, July 1967. I am working on sending you some internal memos on finite impedance surfaces. I need to clear this with the author's first so it may take a few more days. Charlie Arnold
Phil mentioned to me that Tom wanted to take a videotape with him to some conference on Monday. Right now we are rather short on videotape -- we have 5 reels, all borrowed from IBD. We have one that isn't being used yet, so we can get started, but having more tape around is a must. They are stocked at the self-service supply store (Piggly Wiggly), so getting a case or two shouldn't be a problem.
Also, having a second VTR would be very handy, so that we could duplicate tapes as needed, although the A/V folks have a well equipped TV studio that I'm sure we can call on, too.
The video tape that we need is standard professional 3/4" U-matic videocasette format. Any one of three types will work, I list them in order of preference:
1) Any "KSP-S" and "KSP" series tape would be preferred. 20 minute lengths would be best, 60 minutes is also OK. Ie, KSP-S-20 or KSP-20.
2) The only tape that still has it's stock sticker is Ampex 187 tape, style KCA-60. It has stock numbers: 5836010294285 FSCM 088068 MFR/PN 187KCA60C TAPE, videocassette 1 EACH F04606-86-C-0152 A 2/86
3) A slightly less desirable tape is Ampex 197 BCA-20.
Thanks! -Mike
Why not try weighted averaging post-filtering using a Bartlett filter. For details see
Crow, Frank, c. "A comparison of Antialiasing Techniques," IEEE CG & A, Vol. 1, pp 40-47, 1981
or
Rogers, D. F. Procedural Elements for Computer Graphics pp 93-95.
> ...can anyone tell me how to extract from a 1/4 inch cartridge, > written on a MASSCOMP, from a SUN?? I had no trouble whatsoever > reading and writing tapes between Masscomp and Intel machines, but > am unable to read the tape on a Sun. Any ideas??
Yes. Use /dev/rst8. I've passed a number of tapes from burroughs xe550, (really a ct megaframe), masscomp, sun, sequent, tower, apollo, etc. Nearly everyone, (except 3b2's which use a different encoding), uses QIC 24 as their default.
Sun uses QIC 11, (/dev/rst0), for distributions, although I can't see why, but they do provide QIC 24 in the form of /dev/rst8. (man 4 st).
Some machines, (some towers), byteswap the tar/cpio archive so you have to dd swab them off the tape. Ansii headers are a pain for unix. tar is the easiest format, (what with pd-tar and all).
Two hints... Remember to retension the tape *prior* to using it on a new drive. Some drivers do this every time you load a tape, others only on request. (man 1 mt). Also, you can't just cat from one drive to another to copy tapes. (buffer sizes, I'm told, I don't have source). Instead, you must dd (man 1 dd) them and if you machine swabs, it's anybody's guess what the output byte ordering will be.
If you need to illuminate an object from the keyboard, type: mged> press oill mged> ill <name>
Its much easier to use the mouse to select the pull down menus, then select <object illuminate> or press the <object illuminate> button on your button box, then move the mouse vertically on the pad to select the object. The keyboard <press> command and <ill> are there mainly for Tektronix or other less brain-damaged hardware that don't happen to have button boxes or mouses (*most* button functions can be done with the mouse).
~moss
I would like to briefly recapitulate the "rtray" events, so that BRL folks can gain additional understanding, and so that non-BRL folks on the CAD list can understand how the scale of the BRL environment can occasionally lead to oscilation.
PJT had a high-priority request for the addition of features to RTRAY. They were needed within one day, and over the course of several hours that evening, he and I worked out some of the knotty details (did his codes expect the surface normals on air to point outward, like everything else, or inward?, etc, etc). PJT also described to me in great detail the "Doug Gwyn Approved VLD Standard" handling of air and paint in VLD-standard ray(5V) files, and suggested that it would be best if the "regionid" and "aircode" numbers from the MGED database were combined within LIBRT using the VLD Standard procedure. I had no preference, and decided to consider the possibility, since VLD are the folks who care about aircodes -- might was well conform to their standard.
I coded until 4 AM. One of the small issues to be decided was the handling of the air code. It had not been seriously addressed previously as an issue. The declaration in raytrace.h read:
short reg_aircode; /* ?? */
signifying it's uncertain status, but the value was copied in religiously from the MGED database, and the overlap checker in LIBRT did use this value. Concerned about possible compatability issues, I executed these commands:
cd /m/cad fgrep reg_aircode */*.[hc]
These commands swept the entire R&D CAD source tree for use of this symbol. There was one "hit", a printf() call in LGT. Because no installed CAD Package software used this field in a significant way, and I was confident that PJT had accurately portrayed the VLD Standard, I decided to proceed with the modification. Several vital points here:
1) I did not go looking for source code that was not part of the installed CAD PAckage software. If I had happened across the RIP sources, I surely would have implemented Moss' suggestion directly (more on this below). We might profit from some contemplation about the different groups, and how they manage their source code here. I have several good explanations why I didn't examine the various VLD sources, but it was mostly due to being rushed and tired. If there is any blame to be placed in this whole sequence of events, this is the place, and I'll take the blame. 2) I notified Moss via E-mail about the impact on LGT, with a suggested fix. 3) The source code was modified in the "R&D" tree only. 4) I recompiled all of the relevant CAD software (except LGT, as noted above) to ensure compatability with the change.
I tested the new RTRAY until about 0600, at which point I decided that things were "good enough", generated production binaries of "rtray" and "rtshot", installed just the binaries on VMB and VIM, **without doing a "make install**, to satisfy PJT's need (carefully leaving older versions as rtray.bak and rtshot.bak), wrote my E-mail reporting the work, and went home to sleep.
Generaly, I would not have installed new binaries at this point. However, given that:
1) This was a rush job, and 2) There was not (yet) any other use of the RTRAY program,
this seemed the most effective way to get things into the hands of PJT and the folks working with him. I felt confident that if there were any hidden problems with this change, they would either surface:
1) as PJT began using the software, 2) as the R&D process continued, or 3) at the next Integration and Test Cycle.
Let me elaborate on some of the subtle details hidden in all this:
Please recall that at any time, there are no fewer than three "current" copies of the CAD software:
1) The TAR archive of the current distribution relese (now Rel 2.3). 2) The tree spark:/m/dist, which contains source code for the FORMALLY INSTALLED versions of the software (ie, that software which was installed by saying "make install" or "cake install"). 3) The tree spark:/m/cad, which is the development area. The sources for the very latest software live here, and are under RCS (source code Revision Control System) archival control. This is the "R&D" copy of the software, and is where all changes are made.
Copy #1 is always frozen, and changes only at the END of a full Integration and Test cycle (more on this later). Copy #2 is updated only when new software is FORMALLY RELEASED from R&D status to Production status for BRL internal use only (ie, "make install"). This happens several times during an Integration and Test Cycle, and occasionally, as required, at other times.
So far, the history of the BRL CAD Package has been such that a Distribution Release has been produced once every 5-6 months. Our goal is to produce between one and two distributions a year, so I feel that we have been doing very well. The formalism of the release cycle has been in place for nearly two years now. There are so many different groups in BRL that have some interest in the CAD Package, but outside of ACST, few people bother with worrying about all this formalism. There is a general tendency for folks to "ship code" whenever there is a need, and worry about compatability later. Ironicly, they very concerns that have been raised by the "fast response" to the RTRAY need.
All of this release formalism, like most technology, is a two edged sword. On the advantage side, there is the fact that BRL CAD Release tapes tend to be very well tested software, and virtually everything on the tapes works on a wide variety of machines. Problems experienced with the softwrae on the release tapes generally stems either from:
1) Errors in configuring or installing the software at a recipient site, or 2) Bugs that exist also at BRL and have never been encountered before.
To address item #1, I can assure you that Release 3.0 will be significantly easier to configure and install, partly thanks to the power of CAKE, and partly because I have spent almost four days improving the packaging. I take a great deal of pride in how effective our testing cycle has been. We are not quite as good as some companies, but we are better than probably 90% of them.
The negative side of this complex integration and test cycle is that we are generally shipping code that is six months out of date, and many requests for features get answered with a "we already did that -- wait for the next release" answer, which isn't always much comfort to the person asking.
I have directed that nobody that works for ACST should distribute software outside of the normal release cycle, except to our designated alpha-test sites, or in case of serious need to meet a Government requirement. The reason for this is that mixing software from different release versions, or mixing released and unreleased software has the potential for difficulties. There have been some non-ACST folks at BRL that have been distributing chunks of software outside of the release cycle, and on several occasions, the resulting incompatability problems have resulted in howls of anger from the recipient.
Part of the complexity is being able to discern which recipients wish to use this software as a nearly "turn key" package, and which ones are also interested in the "insides", and could cope with the potential complexity of mixing versions. Because the number of people working on the BRL CAD Package at BRL is smaller than the numer of people using the BRL CAD Package at some single outside sites, and we have over 300 sites now, there isn't much time for site-specific attention. "Mass production" is the only way we can usually afford to handle things. (In-government users, and relevant defense contractors, obviously receive a higher level of service).
Returning from the philosophy lecture now, let me return to the technical details. Moss' original suggestion that the "reg_aircode" field be re-instated, with its old semantics, and that the new reg_regionid field remain in it's new form. This is exactly the strategy that I had adopted when it was pointed out that there was an issue. I did this over the weekend, but was too busy preparing slides for the trip I'm leaving on in a few hours to describe it immediately. The definition now reads:
short reg_regionid; /* Region ID code. +=solid, -=air */ short reg_aircode; /* THIS FIELD CONSIDERED OBSOLETE */
so that old code will compile. This definition, and the one line of code to fill it in, are now checked in as the latest "R&D" version of the code on SPARK in /m/cad. No installed software has been changed, and effectively, no other software should have to be changed (although the keeper of RIP might want to add a check for negative reg_regionid values).
Gary does make an interesting point in one of his subsequent letters from Monday morning, where he points out that if he mixes a new version of an application code which cares about Air with an old library, or vice versa, then there will be problems. This is more a problem with the fact that Gary perfers to mix and match software, rather than following the formalism of the software Integration and Test cycle, but this should at least be thought about.
Anyways, I am open to further discussion about how to handle the Air field. If folks can persuade me that it makes more sense to have two VLD-Standard ways of signifying air, then I'll gladly accomodate that. As I said earlier, I don't have any personal use for the notion of Air, so I don't feel very strongly about it. On the other hand, after all this chattering, I am most definitely NOT going to make a third change until we have had a chance to get a whole bunch of VLD people together to talk about it -- face to face. Because I'm on TDY for 2 weeks, it will have to keep until then.
One final point I would like to make. Please note how at no time did the format of the stored MGED database change, nor was there any reason for it to change. Whoever brought that up inserted a moby red herring into the disucssion. I assure all of you that I consider database format changes to be a "really big deal", and they will be done only for good cause, and with lots of trumpet tooting in advance, so that we can enjoy our usual vigorous debate before actually doing anything.
The electronic discussion of this topic is now closed. -Mike
Ian writes: > > I sent this letter two weeks ago,I am not sure whether it got to you > or if it got lost in the pipeline;anyway here goes again! We got it, I was just hoping someone else would answer it since I only know some of the answers, but here goes... > 1. When trying to use the ARS command I get the reply > "not implemented yet", > we have version 2.1 (Jul 87) on our 3130 IRIS. How can we implement > the ARS's function and what commands are used to create them? There is no ARS editing capability. The ones that we have were described by typing in coordinates before MGED was ever written. > 2. What are the commands to create "Rendered Splines" as shown on > plate caption 1.2 in your manual (i.e. how can we add a spline > surface to a mged model)? MGED does not edit splines either. We get our splines from the U. of Utah Alpha_1 spline modeler and we have no intention of duplicating that capability from within MGED, it is a very impressive geometric modeling system in its own right. If you want to get the Alpha_1 software, I don't know the availability or supported hardware, but you can contact Russ Fish <russ@cs.utah.edu> for information. Paul Stay wrote some software to convert the splines to MGED format, but it is not part of the distribution. > 3.Can one move the light source point in mged models (for rt)? > Can you also introduce extra light sources? > if so what commands are used? Yes. Check the RT manual page for this one, I'm not sure what version you have, and this mechanism has undergone some changes. > 4. Also could you tell me how to add a texture map to an > MGED model please. (either solid or object)? This one is un-documented and subject to change, but I believe that the material property string of a region (see the "mater" command of MGED), can specify texture maps. I will forward you an old message on the subject, but its not really considered supported yet, just experimental, so it may take some work on your part to make it do what you want.
Now, can you tell that I don't know what I'm talking about? ~moss
ARS stands for arbitrary surface and is a triangular-faceted primitive described by a rectangular array of points. See the paper "Understanding the Preparation and Analysis of Solid Models" by Muuss which follows the manual pages in your hardcopy documentation. Fig. 1.8 and section 1.6.6 describe the ARS. There is no facility for editing these within MGED except for object-edit operations. Most of the existing ARS's were hand-built by typing coordinates in, you can still do that, but I wouldn't recommend it. B-splines or polygons are more general primitives for describing surfaces, but the same restrictions apply within MGED (object-edit only). We use U. of Utah's Alpha_1 software to create B-splines and convert them for input into MGED models.
AIR is air. We need to model it for vulnerability analysis. It is like solid material, but has some special properties. It may overlap solid objects and will automatically be displaced by them (as far as the ray tracer is concerned) without causing overlap diagnostics. However, there are different types of air (i.e. engine compartment air, crew air, etc.) and these must not overlap. The type of the air is indicated by a non-zero integer in the region record (sometimes refered to as "air code") and should have a zero "id" (sometimes refered to as "region id"). So, one or the other of region id and air code must be zero. There is a flag in the ray tracing library (librt) that by default is set to ignore air. If you have an application that cares about it, you must set this flag. In other words, if you don't need to model air, just try to ignore it.
The MATER command in MGED allows one to assign a character string description of the material making up a region. The RT program parses this string using a specific language. This is still in high flux and is therefore not documented or used by any but the developers. The only documentation is the source code for RT. The supported means of describing material properties is with the material id or "GIFTmater" field of the region. This is an index into a data base. The LGT program has a facility to create, modify and print these data bases, but, in general, the ids are application specific.
We have not modeled the cruise missile at all.
Hope this helps, I would be happy to answer more specific question also.
~moss
I'm no Tektronix expert, and I have no experience running mged on a Tek, but I think the situation there is something like this:
We have a 4014 module called "tek" and a 4109 (I assume that means color?) module from NRTC called "tek4109". To get the crosshairs to work requires that the display be in "graphics mode," BUT (the catch), you can't type regular commands to mged while in graphics mode. So, there are two ways to live with this problem:
1) If your tek display is connected to a host computer running mged, start up mged on some OTHER terminal, and when is asks "Output tty [stdout]?" enter the /dev/ttyXX line of the Tek display. This way terminal input can be done on the other terminal and the graphics output (including crosshairs) is done on the Tek.
2) From a Tek (or emulator), answer the "Output..." question with "/dev/tty", i.e. your self. This will cause the system to switch in and out a graphics mode (after a CR I believe), so you can move the mouse (or crosshairs), type CR, give a command to mged, type CR, move the mouse, type CR, give a command to mged, type CR, ....
As you can see, its pretty crude. If anyone makes any improvements to the Tek situation, we would be happy to get them back.
- Phil
I have created a new program called "buffer", which reads (and buffers) all of stdin until EOF, then sends all the buffered data to stdout. This is sometimes useful in complex pipelines. -Mike
/dev/sgi21 gives NTSC, centered, non-lingering, shared memory. FYI. Also, vas4 has been modified to take a -F flag, so that it can open a window to grab video from. I have successfully recorded a little bit this way, and except for the bad black levels, it seems to work. -M
Both methods will work. The first requires writing code to create the mged script which would be executed by mged file.g < script and look something like:
in name1 rpp 0 1 0 1 0 1 in name2 rpp 2 3 2 3 2 3 q
Or you can write a code which should look alot like this using libwdb: ( I called the code "conman" for convert man )
/* */ /* Set up code for creating rpp's. */ /* Parts are in psuedo code. */ /* */ /* conman -n inputfilename > output.g */ /* */
#include <stdio.h> #include <math.h> #include "machine.h" #include "db.h" #include "vmath.h"
main(argc,argv)
int argc; char *argv[]; point_t min, max; char *name; { argc--,argv++;
if (argc < 1){ fprintf(stderr, "usage: conman [ -n ][ filename ]\n"); exit(1); }
/* Read command line arguments */
while (argc > 0 && argv[0][0] == '-') { switch (argv[0][1]) {
case 'n': nflg = 0; argc--,argv++; break;
case 'd': debug = 1; argc--,argv++; break; default: fprintf(stderr, "usage: conman [ -n ][ filename ]\n"); exit(1); } argc--, argv++; } if((fd = open( cmanfile, 0664)) < 0) { fprintf(stderr,"conman: Can't open %s\n",cmanfile); exit(1); } mk_id(stdout,cmanfile);
/* Stay in loop until all entities have been created, i.e. eof */ /* while not end of file */{ /* Read parameters */
VSET(min,xmin,ymin,zmin); /* Set variables */ VSET(max,xmax,ymax,zmax); sprintf(name,"cman.%d",param); /* Create name of rpp */
/* Create rpp */ mk_rpp(stdout, name, min, max ); } /* while not eof control loop */
}/* End of program */
If you have any difficulties making these work, give me a call.
Good Luck!,
Bill
This evening, Phil and I removed the limit of 128 solids per region that rt_bool_eval() had imposed. It is now dynamic, in such a way that will also work on the multiprocessors. -Mike
spark:/m/cad/util/rle-fb.[c1] contains the source and manual pages for the new RLE-FB program, which handles existing (Edition-2) and new (Edition-3, or Utah Raster Toolkit) format RLE files. Please take a look, and let me know what you think.
I will be trying this program on a bunch of older images from VGR Monday evening as a final test; so far I have only tested it on Goulds. My final additions were from home this weekend, so I could not verify that everything still works, being unable to see any pictures. Therfore, I have postponed the BRL-CAD installation until Monday evening (19th), to allow time for a full set of tests. (Obviously, this is one of the most "user visible" programs).
Best, -Mike
On Friday, 16-Sept, after COB, I will install the Release 3.0 software on BRL's VAXen and Goulds (VGR and VMB, rdist will do the rest), plus on the Suns served by SPARK and the SGIs served by VECTOR. This message is intended to be a "heads up" warning, to alert people of the impending change.
This software has been ported to quite a few machines, and we have been using it daily on the Crays, SPARK, our SGIs, and our Suns, so I have high confidence in it. However, as with any major software release, there is some possibility of problems, which we will fix as rapidly as possible. All the present software will be moved to ".bak" names, so that nothing should be a show-stopper.
The only known incompatability is that .RLE files written with non-linear colormaps will display as black, due to the change in the interpretation of the colormap area of the .RLE header. Other than that, the Edition-2 to Edition-3 change in the .RLE format is upwards compatible (but not backwards compatible). "rle-fb" will become "orle-fb" to permit reading old format files with non-linear colormaps. The advantage to this change is that it allows the full suite of Utah Raster Toolkit software to be used with our .RLE files, eg, those saved with fb-rle, etc.
When the software has run for a few days without serious difficulty, it will also be installed on VECTOR (the Alliant), the Crays, and any non-rdist machines that want it.
Once problems have been addressed, this software will be bundled up and Release 3.0 will be formalized. My target is still 30-Sept.
Best, -Mike
It is finally here. Tapes have been spinning for the past couple of days now.
BRL-CAD Release 3.0 10 October 1988
Supported Machines: Alliant FX/8, FX/80 Ardent (preliminary) New Convex C1 New Cray X-MP UNICOS 3.0.10 Cray-2 UNICOS 4.0 DEC Vax-11 4.2 BSD, 4.3 BSD ETA-10 (preliminary) New Gould PN6080, PN9080 Pyramid 9820 New SGI 3030 SGI 4D (version 2+MEX) New SGI 4D (version 3.1+4Sight) New SGI 4D/GT New Stellar (preliminary) New Sun 3 Sun 4 New
New MGED Interfaces: X Window System (X11R2) PostScript output A much improved SunWindow interface
New Frame Buffer Support: SGI 4Ds Preliminary X11R2 interface Enhanced Sun interface (shared memory, pans, zooms) Stackable devices fbhelp - help on FB_FILE options available
Other New Software: Extended UnixPlot support Color, 3D command, IEEE floating point plotting Display programs for SGI's, Frame buffers, X Rotate, convert, debug utilities libwdb - for writing MGED databases from programs RLE - now compatible with current Utah Toolkit programs Contributed Software Utah Raster Toolkit Release 2.0 The "Standard Procedural Databases" package Cake - a make replacement
Numerous Bug Fixes and Enhancements: Most notably to LIBRT, RT, and MGED
New Manual: The manual has grown significantly and has split into two parts. There is now a separate 260 page MGED manual.
New Installation Procedure: We now use a program called "cake" ("make" ran out of steam). For the above listed machines we can now detect what kind we are running on and configure things accordingly. We are also now able to compile binarys for multiple types of machines from one source tree.