This is a minor change to make mged/dm-xgl.c compile on a Sun workstation with XGL. XGL is an add-on product for the Sun, desirable primarily if you have a Sun GX hardware graphics processor. Unless you have added dm-xgl to your MGED configuration, you do not need this fix.
Thanks to the folks at U.S. Army MICOM for contributing the dm-xgl.c module. This error is entirely my fault, it crept in when I converted their code to use the new "chunky" vlist structures. Since BRL does not have a copy of XGL, the modifications could not be tested. Thanks to David Turner of Sandia National Labs for pointing out the error, and debugging with me via "remote control" on the telephone one long afternoon.
Best, -Mike
923,925c923,925 < ptr->x = pt[0]; < ptr->y = pt[1]; < ptr->z = pt[2]; --- > ptr->x = pt[0][0]; > ptr->y = pt[0][1]; > ptr->z = pt[0][2]; 932,934c932,934 < ptr->x = pt[0]; < ptr->y = pt[1]; < ptr->z = pt[2]; --- > ptr->x = pt[0][0]; > ptr->y = pt[0][1]; > ptr->z = pt[0][2];
Inside MGED, I have eliminated the subroutine pr_solid(), and replaced it with a new one that uses import/export ft_describe() interface instead. This is an important step in the cleanup of solid editing. -Mike
>I am not much of a hacker, but I need to compile BRLCAD on >my Sparc 1+ running the MIT's X11R4, not OpenWindows.
In Cakefile.defs, change these two lines: # define sun_no_opts /* Production configuration */ # undef sun_x11
to these two lines: # undef sun_no_opts /* Production configuration */ # define sun_x11
If your X11 software is not in /usr/X11 (/usr/X11/include, /usr/X11/lib) then you will need to modify the following section to reflect where the include files and libraries are located:
# ifdef sun_x11 /* Sun with X11 configuration */ # define LIBFB_OBJS if_remote if_ab if_sun if_X # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB -DIF_SUN \ -I/usr/X11/include -DIF_X # define LIBFB_LIBES LIBPKG -lsuntool -lsunwindow -lpixrect \ -L/usr/X11/lib -lX11 # define MGED_OBJS dm-sun dm-X # define MGED_CONFIG -DDM_SUNPW -DDM_X -I/usr/X11/include # define MGED_LIBES -lsuntool -lsunwindow -lpixrect \ -L/usr/X11/lib -lX11 # endif
Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (301) 278-9200
There is a bug in the "pixscale" utility as distributed under 4.0 which causes it to dump core. The following patch should correct the problem.
155,156c155,156 < if (inx < outx) i = outx; < else i = inx; --- > if (inx < outx) i = outx * 3; > else i = inx * 3;
Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (301) 278-9200
There is a bug in "fbserv" as distributed under 4.0 which causes a problem when used as a "lingering" window on some systems. Lingering windows which have been dismissed will disappear, but the process remains and consumes non-tirvial amounts of CPU time until the user logs out. The following patch to "fbserv.c" in the fbserv directory will fix this problem.
370a371,372 > else > break;
Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (301) 278-9200
Considering the number of user sites that we have, and that we don't have any staff allocated for external user support, it can be a bit annoying when people don't experiment a bit with configuration before calling for help. We have tried to make configuration choices as clear and simple as possible.
Anyway, for some reason it was not clear to me that you wanted an X-only configuration. Simply change the lines to remove the if_sun, -DIF_SUN, dm-sun, -DDM_SUNPW entries, and remove the suntools library references.
I have expanded our copy of Cakefile.defs to make an X11-only version an easily configured option. I did it for Sun-4 machines, the same idea can be applied to other platforms:
#if defined(sparc) /* Sun-4 "SparcStation" hardware */ # undef sun # undef sun4 # define MTYPE sun4 # define BSD 43 # define HAS_TCP 1 # if 0 # define OPTIMIZER -O2 # else # define OPTIMIZER -g # endif /*# define CC_DEFS -DAUTOSPEC /* What does this do? */ # define LIBMALLOC /* use vendor library */ # define LIBRT_TIMER timer42 # if 1 /* Bare Sun configuration */ # define LIBFB_OBJS if_remote if_sun # define LIBFB_CONFIG -DIF_REMOTE -DIF_SUN # define LIBFB_LIBES LIBPKG -lsuntool -lsunwindow -lpixrect # define LIBRT_TIMER timer42 # define MGED_OBJS dm-sun # define MGED_CONFIG -DDM_SUNPW # define MGED_LIBES -lsuntool -lsunwindow -lpixrect # else # if 1 /* Sun with X11 (aka "openwin") & Suntools. Default for SunOS 4.1.1 */ # define LIBFB_OBJS if_remote if_ab if_sun if_X # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB -DIF_SUN \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG -lsuntool -lsunwindow -lpixrect \ -L/usr/openwin/lib -lX11 # if 1 /* Sun with X11 only */ # define MGED_OBJS dm-sun dm-X # define MGED_CONFIG -DDM_SUNPW -DDM_X -I/usr/openwin/include # define MGED_LIBES -lsuntool -lsunwindow -lpixrect \ -L/usr/openwin/lib -lX11 # else /* Sun with X11 and XGL (an unbundled product) */ /* Note that at MSIC, -lgks may also be needed */ # define MGED_OBJS dm-xgl dm-X # define MGED_CONFIG -DDM_XGL -DDM_X -I/usr/openwin/include # define MGED_LIBES -lxgl -L/usr/openwin/lib -lX11 # endif # else /* Sun with X11 ("openwin") ONLY. No Suntools support. */ # define LIBFB_OBJS if_remote if_ab if_X # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG \ -L/usr/openwin/lib -lX11 # define MGED_OBJS dm-X # define MGED_CONFIG -DDM_X -I/usr/openwin/include # define MGED_LIBES -L/usr/openwin/lib -lX11 # endif # endif # endif # if 0 /* "Unbundled" (i.e. "improved") compilers. Use if you have them */ # define CC /usr/lang/cc # define FC /usr/lang/f77 # endif #endif
I hope this helps. Best, -Mike
Mike, how have you been? I've gotten a survey and some info from the Surviac people and returned the questionaire. I talked to Keith Bowman about rt'ing a .g file and he wasn't able to answer my question. I am trying to find the exact solid that i hit when I rt a file, I'd also like to be able to find some of the data for the solid. thanks - John.
Dear Keith:
John Ecker <eckerjal@aplcomm.jhuapl.edu>, from the Johns Hopkins Applied Physics Laboratory, wanted to know how well supported the Apollo DN10000 is supported by BRL-CAD. He knows there is a configuration set up in the "cakefiles" but would like some more information. Keith (Bowman) is not familiar with the hardware, so he suggested to me that I forward this on to you. John's telephone number is (410) 792-6000 ext. 7902.
Thanks,
Carla
The Apollo DN1000 is not on the "supported" list, but it works OK last I checked (which was 2 years ago). I expect that it will take minor polishing, but can probably be made to work. If the machine is on the net, and problems are encountered, I might be able to help for an hour sometime. But if Apollo has changed things drasticly, no telling.
Also worthy of note is that there is no "local" support for image output on the DN1000; only the X-windows interface is available. And that isn't the best way to use our software, but it does work. Best, -Mike
Hi John -
When your a_hit() routine gets called, you have a doubly linked list of partition structures. Each partition represents a chunk of solid. From the partition structure, the element pt_regionp gives you a pointer to the region structure, which will give you your material properties info, and the partition name (pt_regionp->reg_namep). The elements pt_inseg and pt_outseg will give you pointers to the segment of the solid that the in and out points actually struck; from there, the primitive solid's name (as opposed to the region name) is found from pt_inseg->seg_stp->st_dp->d_namep, the entry solid type is in pt_inseg->seg_stp->st_id, and the particular surface number (specific to each st_id value) is in pt_inseg->seg_in->hit_surfno.
Does this give you enough to go on? If not, perhaps you can give me some kind of idea what info you need. Best, -Mike
While Mike's duties temporarily took him away from our mged solid edit restructuring, I decided to add another solid, the elliptical torus, to brl-cad. Like the others, the only portion untested is surface curvature.
The full list of new solids is now:
RPC, Right Parabolic Cylinder RHC, Right Hyperbolic Cylinder EPA, Elliptical Paraboloid EHY, Elliptical Hyperboloid ETO, Elliptical Torus
Mike
Sue,
Thank you for pointing out the problem with the MGED "concat" command under 4.0 of BRLCAD. I've fixed this locally. For everyone else, the context diff below should fix the problem. Apply to cad/mged/concat.c:
24a25 > #include <stdio.h> 27d27 < #include <stdio.h> 182c182 < (void)strncpy( local+ncharadd, name, NAMESIZE-ncharadd ); --- > (void)strncpy( local+ncharadd, name, NAMESIZE-1-ncharadd ); 186c186 < local[NAMESIZE] = '\0'; --- > local[NAMESIZE-1] = '\0'; 198c198 < local[NAMESIZE] = '\0'; /* ensure null termination */ --- > local[NAMESIZE-1] = '\0'; /* ensure null termination */ 230a231,234 > if ((ncharadd + strlen(name)) >= NAMESIZE) > printf("WARNING: solid name \"%s%s\" truncated to \"%s\"\n", > prestr,name, local); >
Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (410) 278-9200
I have noticed that in rtip->mdl_min and rtip->mdl_min is stored the bouding rectangular parallel piped for a model. But it seems that the values stored in the above points are not reflective of any combinatorial regions.
For example when a cube of 10x10x10 is cut in half by 5x10x10 object, rtip->mdl_min and rtip->mdl_max still give me 10x10x10.
Am I using them incorrectly or does anyone know of a (painless) simply way of getting at the bouding RPP for model made up of many combinations.
Thanks fo any help.
john ko mrj, inc ko@max.mrj.com
The values mdl_min and mdl_max are the corners of the bounding RPP for the model. The bound is computed at "prep" time, and is made as tight as it can be, without extensive effort.
In essence, the model RPP is the convex hull of all the solids in the model which are mentioned at least once in either a non subtracted or non intersected sense.
Thus, if you had a small object with a huge object subtracted out, the model RPP would be that of the small object.
In your example, of a larger object having a smaller object subtracted out, the model RPP remains that of the larger (non-subtracted) object. (The same thing holds true if you are using intersection to discard unwanted material).
Best, -Mike
Mike,
Suppose I have n solids, { S1, S2, .., Sn } with bounding RPP's for each Si, RPP(Si), characterized by the two vectors,
[ minXSi, minYSi, minZSi ] & [ maxXSi, maxYSi, maxZSi ],
and I combine the Si's with boolean operations OPi, i.e.
region = OP1 S1 OP2 S2 .. OPn Sn ( where OPi is "+","u", or "-").
I want to define an RPP, RPP(k), characterized by
[ minXRk, minYRk, minZRk ] & [ maxXRk, maxYRk, maxZRk ],
for the object resulting from the first k combinations in the region list in terms of RPP(k-1), the bounding box of Sk, and the operation OPk.
Starting with the first solid and operation ( I assume it is not "-"), define
RPP(1) = RPP(S1) i.e. [ minXR1, minYR1, minZR1 ] = [ minXS1, minYS1, minZS1 ] and [ maxXR1, maxYR1, maxZR1 ] = [ maxXS1, maxYS1, maxZS1 ]
For RPP(k), k>1 the definition depends on the specific operation OPk:
if OPk = "u" then
minXRk = min ( minXRk-1, minXSk ) minYRk = min ( minYRk-1, minYSk ) minZRk = min ( minZRk-1, minZSk )
maxXRk = max ( maxXRk-1, maxXSk ) maxYRk = max ( maxYRk-1, maxYSk ) maxZRk = max ( maxZRk-1, maxZSk )
if OPk = "+" then
minXRk = max ( minXRk-1, minXSk ) minYRk = max ( minYRk-1, minYSk ) minZRk = max ( minZRk-1, minZSk )
maxXRk = min ( maxXRk-1, maxXSk ) maxYRk = min ( maxYRk-1, maxYSk ) maxZRk = min ( maxZRk-1, maxZSk )
if OPk = "-" then
minXRk = minXRk-1 minYRk = minYRk-1 minZRk = minZRk-1
maxXRk = maxXRk-1 maxYRk = maxYRk-1 maxZRk = maxZRk-1
Thus, for a union operation, the bounding RPP becomes the smallest (axis-aligned) RPP that contains the previously defined RPP and the RPP of the current solid. This is not the convex hull of these RPP's, but it is the smallest RPP that contains the convex hull of these RPP's. ( A convex hull of two sets is the smallest convex set that contains the two given sets.)
For the intersection operation it is possible for the RPP's to get smaller. In fact, if any of the min components are bigger than the max components for RPP(k), you have a null region.
For the subtraction operation, you have just ignored the the RPP of the subtracted solid.
Is this the way the RPP's for REGIONS are defined in terms of the RPPs of the SOLIDS and the corresponding operations in BRLCAD? Your last parenthetical comment leads me to believe that your intersection algorithm does not reduce the region RPP when it sometimes could.
Ed
> Bill Mermagen discussed the current status of the intermediate > rayhistory file generator for SRIM that uses RT for raytracing > functions. The generator uses a FORTRAN call to write the properly > formatted FITS header and ray information to a file that can be read by > SRIM 4.0. This then makes it possible for a user to use RT and still > run SRIM 4.0, a relatively painless transition from the current > approach. Users of SRIM have been given the option of tagging specific > solid faces with certain material properties; this can lead to ambiguous > material definition. Mermagen's approach has only allowed the user > access to the region identifiers--if a certain surface needs a > particular material type, the geometry must be explicitly modeled. > Mike Muuss indicated at some point that surface identifiers could be > provided with some small work, but that hasn't happened. ...
In BRL-CAD Release 4.0, I call your attention to
struct hit { : : int hit_surfno; /* solid-specific surface indicator */ };
which is provided at every point a ray enters and exits a region.
If you have some way of making sense of the different surfaces of the different solids that go into making up a region, you are welcome to use the information. It has always been present for purposes internal to the library; in Release 4.0 I gave the variable a more descriptive name, knowing that the ERIM folks had need of it. There isn't any documentation on how to use it, other than the source code of the geometry modules, but the legal values are all clearly #defined. A header file could be created if they are going to start getting used by applications.
I would be interested in learning more about what use these numbers would be put to.
Best, -Mike
John Anderson writes:
> Along the same lines, Mike, are the bounding boxes for each > individual object in the model available somewhere. We have occasion > to need this info and it would be convenient to have a little code to > spew them out.
The answer is yes, if you don't mind calling a subroutine.
If you have a ray partition (struct partition), pp->pt_regionp gives you a pointer to the (struct region) that you hit. So, declare a region pointer, and the min and max points of your RPP:
struct region *regp = pp->pt_regionp; point_t rpp_min, rpp_max;
rt_bound_tree( regp->reg_treetop, rpp_min, rpp_max );
Now you have the RPP of that region in rpp_min and rpp_max. Note that if
if( region_max[X] >= INFINITY )
then this region is infinite, e.g., it has a non-subtracted halfspace in it, and the RPP has no meaning -- it's infinite too. (For computation purposes, a specific number has been chosen to represent infinity, so that it can be tested against. The exact value is machine specific, but is always at least 1.0e+20 mm, which satisfies all but the astronomers in the crowd.
A similar procedure can be used to find the bounding RPP of an individual solid, but I'd be surprised if you really wanted that.
Hope this helps! Best, -Mike
Thanks for the nice note, Ed. In fact, I mis-"spoke" when I said "convex hull"; the bound is tighter than that, and the algorithm used is precisely the one you spelled out. You described it to me some years ago, and the new tree walker implements it.
But this observation does not help the fellow I was responding to, because, as you noted:
> For the subtraction operation, you have just ignored the the RPP of the > subtracted solid.
whereas he was expecting the RPP to shrink after a subtraction. While I would enjoy having a tighter bound in that case, I don't know any cheap way it could be calculated. About the best I could suggest would be to tessellate, evaluate the boolean using the NMG code, and find the bounding RPP of that. Not exactly cheap. And I wouldn't suggest depending on the BRL-CAD 4.0 release to do any hard booleans.
I'm sure that folks will be happy to know that after a nearly year-long haiatus, NMGs are again getting active attention. Forward progress (as opposed to congress) is being made.
Best, -Mike
Mike,
Perhaps it is the downfall of a mathematician to be perpetually nitpicky but,
>Thanks for the nice note, Ed. In fact, I mis-"spoke" when I said >"convex hull"; the bound is tighter than that.. > ^^^^^^ > no.
Example:
u S1 u S2
with S1 and S2 as RPP's and so they are their own bounding RPP's:
|---------------| | | | | | | | | | | | |---------|-----| | | | | | | | | | | | | |-----|---------| | | | | | | | | | |---------------|
but the convex hull of the RPP's ( here both the solids and the bounding RPPs look like this:
|----------------\ | \ | \ | \ | \ | \ | | | | | | | | \ | \ | \ | \ | \ | \----------------|
whereas the resulting RPP would be this:
|---------------------| | | | | | | | | | | | | | | | | | | | | | | | | |---------------------|
which is less restrictive than the convex hull would be.
One other thing: you didn't address the question of whether the current method reduces the bounding RPP when intersections take place. Your first note implied in the last sentence that the intersection would simply ignore the second RPP upon intersection. The method I described reduces the RPP in such a case:
if in the case above we had S1+S2, then the bounding RPP would be the little box:
|---------------| | | | | | | | |
| |---------| ---| | | | | | | | | | | | | |-- |---------| |
| | | | |---------------|
Ed
Lgt users,
I have improved the hidden-line algorithm so that highly oblique surfaces no long get erroneously filled in. Thanks to Tyler Brown and Keith Applin for showing me a particularly pathological example of this problem; I was aware of it as a design flaw, but didn't have a solution for it. The severity of the example inspired me to revisit the problem. The fix involves testing for high obliquity against a built-in tolerance so if anyone still sees black areas I may need to tweak the tolerance a bit or make it user selectable. Note that low resolution will typically result in filled in areas (thick lines) where adjacent edges merge, but a 1024x1024 resolution can typically resolve the edges better, this is not a fault in the algorithm. Use of the anti-alias lgt option can further improve the apparent resolution with hidden-line drawings, it's not just for color shaded images. I am not aware of any remaining shortcomings in the hidden-line algorithm, let me know if you see any missing or spurious edges in your lgt images in the future.
There was also a minor bug where lgt would claim that a certain number of processors were in use when the user had in fact configured in a different number. This was due to printing the message after all UNIX shell command-line options were processed, but before all user commands were read from the standard input. This was easily fixed, thanks to Sue Coates for reporting this bug.
I have installed the fixed lgt yesterday on walrus in the BRL-CAD distribution, so all of the SGIs that get the rdist should receive it by today or tomorrow. The older version is still available as lgt.bak.
-Gary
This evening, I made some modifications to librt, so that per-cpu statistics are now kept secretly in struct resource, and then merged into the rt_i struct after parallel processing ends.
This has resulted in the SGI results for 8 processors going from 4X one processor, up to 6X.
A pretty good fix, but I think some more performance can still be found.
My tentative conclusion is that multi-processor interlocks may have gotten somewhat more expensive in IRIX 4.0, but I don't have any firm indictment.
Best, -Mike
Just now, I have placed the file "brl-cad/errata4.0-irix4" on ftp.brl.mil for anonymous FTP, containing a script which will upgrade your BRL-CAD Release 4.0 distribution for use on an SGI running IRIX 4.0.1.
-r--r--r-- 1 mike graphics 256381 Mar 17 00:54 errata4.0-irix4
Here is the head of that file:
++++++++++++++++++++ ++++++++++++++++++++
As promised, this file contains a comprehensive set changes to the BRL-CAD Release 4.0 which are necessary to compile the software on Silicon Graphics (SGI) workstation with the latest operating system releases, IRIX 4.0.0, and IRIX 4.0.1. In general, these changes should also be applied on other kinds of systems as well.
This file *includes* all the modifications from these four existing errata sheets:
-r--r--r-- 1 mike graphics 4245 Mar 16 20:58 errata4.0-cake -r--r--r-- 1 butler graphics 444 Nov 15 12:23 errata4.0-fbserv -r--r--r-- 1 butler graphics 349 Nov 15 12:23 errata4.0-pixscale -r--r--r-- 1 mike graphics 1054 Nov 2 03:13 errata4.0-sun-xgl
This means that you only have to run this one script before starting to compile everything.
Note that on IRIX 4.0.1, programs which link with LIBRT will produce the following two warning messages, which are due to a harmless (but annoying) SGI library bug. They can be safely ignored:
/usr/bin/ld: Warning: _oserror: multiply defined previous (used) definition from '/usr/lib/libmpc.a'; new (ignored) definition from '/usr/lib/libc_s.a' Warning: _setoserror: multiply defined previous (used) definition from '/usr/lib/libmpc.a'; new (ignored) definition from '/usr/lib/libc_s.a'
Cut off this top part of the file, and run the rest as a shell script. Note that it must be run from the top directory of your CAD source tree. "cd cad" before running it.
Best, -Mike Muuss
++++++++++++++++++++ ++++++++++++++++++++
E G L I N A F B
From: LEONARD E. BRUENNING Date: 17-Mar-1992 02:47pm CST BRUENNIN Tel No: 904 729 6226 Dept: ASD/YBES*SVERDRUP
TO: Internet Addressee ( _SMTP[CAD@BRL.MIL] )
CC: ROBERT L. STOVALL ( STOVALL ) CC: ELIZABETH T. THORN ( THORN ) CC: MILFORD A. REYNOLDS ( REYNOLDS ) CC: JOHN A. COLLINS ( COLLINS )
Subject: errata4.0-irix4 install report
Received and installed errata4.0-irix4 today on an SGI-4D/35. (Used to be a 4D20 but was upgraded) running IRIX 4.0.1. Everything went pretty smooth and "- most" stuff seems to be ok. However, a few difficulties were encountered:
1) 'edpix' utility was not compiled or installed. I think this is because of the code in gen.sh that skips the edpix code if the machine is NOT defined as a 4D. Strangely enough, this machine now responds to machinetype.sh as a 5D which apparently causes the edpix code to be skipped.
2) rpatch and patch-g executables not compiled or installed. This seems to be because the 'patch' directory is listed in the CDIRS list in gen.sh which, according to the comments, is for codes without cakefiles which really isn't the case for the rpatch and patch-g programs.
3) This machine has a 360MB internal hard drive holding the / and /usr file systems and an external 1.2GB drive holding the /usr2 file system. With the advent of IRIX4.0.1, there was not enough room on the /usr file system for the brlcad executables. Therefore, I elected the option indicated in the install.tr file and redefined by BINDIR, LIBDIR, and ETCDIR definitions in the appropriate files. This seemed to work fine EXCEPT for the man pages. The 'brlman' command was found - would respond with a usage prompt if no args were given - but would respond with nothing if any arg was provided. Turned out, definitions in the brlman and awf scripts in the ./bin directory ALSO had to be changed to reflect my non-standard installation.
4) I have executed most of the utilities I normally used and all seem OK EXCEPT rle-fb. This sits there apparently awaiting additional input. It seems that a file pointer (*infp at line 33 in rle-fb.c) had to be changed so it would compile but the change to 'stdin' seems to cause some problems here. I would appreciate some assistance in this area.
Hope this report is useful.
Bud Bruenning, Sverdrup/TEAS Group, (904) 729-6226
Bud -
Thanks for the detailed report, it was most helpful!
At BRL we are running both IRIX 3 and IRIX 4 systems. They are sufficiently different, that we needed "machinetype.sh" to distinguish between them. Since IRIX 3 systems are called "4d", IRIX 4 systems got named "5d".
1) re: edpix. You are correct, gen.sh has a special case for EDPIX that only works on "4d", but not "5d". Fixed, below.
2) re: patch directory. Correct again. Now that the patch tools have a Cakefile, they need to move from the CDIRS to BDIRS list. Fixed, below
3) re: /usr overflow. In a case such as yours, I would recommend using a symbolic link, rather than changing the definitions, although it *is* useful to know what got overlooked.... More specifically, what I'd do is something like this:
mkdir /usr2/brlcad ln -s /usr2/brlcad /usr/brlcad cd /usr/brlcad mkdir bin lib etc man .....
The symbolic link will not present a performance problem. However, I'll look into what got overlooked. (I note that newbindir.sh has the brlman/awf and brlman/brlman entries, even though install.tr does not. I have updated the development copy to reflect this change).
If you hadn't updated the setting of $MANPATH in your environment, that might have been the problem with the "brlman" command, especially if you also had not changed the MANPATH=/usr/brlcad/man line in brlman/brlman.
4) re: rle-fb. I blew it, the fix was wrong. Fixed, below.
> Hope this report is useful. > Bud Bruenning, Sverdrup/TEAS Group, (904) 729-6226
The report was very useful. In response to it, I have created a new version of the errata sheet which addresses items 1, 2, and 4, above. I have installed this updated version into FTP.BRL.MIL's brl-cad directory in place of yesterday's version. When this new version is applied, the CAD software will identify itself as BRL-CAD Release 4.1, to distinguish it from the unpatched software.
Here is the heading of the new, second edition, patch file:
++++++++++++++++++++ ++++++++++++++++++++
This document is at $Revision: 61118 $.
As promised, this file contains a comprehensive set changes to the BRL-CAD Release 4.0 which are necessary to compile the software on Silicon Graphics (SGI) workstation with the latest operating system releases, IRIX 4.0.0, and IRIX 4.0.1. In general, these changes should also be applied on other kinds of systems as well.
Applying this patch file will bring your software up to BRL-CAD Release 4.1.
This file *includes* all the modifications from these four existing errata sheets:
-r--r--r-- 1 mike graphics 4245 Mar 16 20:58 errata4.0-cake -r--r--r-- 1 butler graphics 444 Nov 15 12:23 errata4.0-fbserv -r--r--r-- 1 butler graphics 349 Nov 15 12:23 errata4.0-pixscale -r--r--r-- 1 mike graphics 1054 Nov 2 03:13 errata4.0-sun-xgl and -r--r--r-- 1 mike graphics 30388 Nov 9 04:58 cad4.0.tar-patch.Z
This means that you only have to run this one script before starting to compile everything.
Note that on IRIX 4.0.1, programs which link with LIBRT will produce the following two warning messages, which are due to a harmless (but annoying) SGI library bug. They can be safely ignored:
/usr/bin/ld: Warning: _oserror: multiply defined previous (used) definition from '/usr/lib/libmpc.a'; new (ignored) definition from '/usr/lib/libc_s.a' Warning: _setoserror: multiply defined previous (used) definition from '/usr/lib/libmpc.a'; new (ignored) definition from '/usr/lib/libc_s.a'
Cut off this top part of the file, and run the rest as a shell script. Note that it must be run from the top directory of your CAD source tree. "cd cad" before running it.
Best, -Mike Muuss
++++++++++++++++++++ ++++++++++++++++++++
> To: fsbrn@BRL.MIL, gwyn@BRL.MIL, mike@BRL.MIL, stay@BRL.MIL > Subject: free(2) Question > From: Paul Tanenbaum <pjt@server.cs.jhu.edu> > > Sorry for the unsophisticated approach to the selection of addressees: > I just thought up a bunch of people, some set of whom would probably know the > answer to this question (I've RTFM already, and not found the answer)... > Is the following hunk of code kosher: > > foo () > { > widget *wp; /* data type defined elsewhere */ > > if ((wp = (widget *) malloc(10 * sizeof(widget))) == NULL) > { > fputs("foo(): Can't fit 10 widgets\n", stderr); > exit (1); > } > > do_something(wp); > > /* Hereafter need only the first 2 widgets */ > free(wp + 2); > } > > In other words, is it reasonable to pass free() an address in the middle of > an allocated block, instead of the address of the start of the block?
No. Quoting from the SGI man page, which is most handy:
The argument to free is a pointer to a block previously allocated by malloc.
If you didn't get it with malloc(), you shouldn't feed it to free(). The reason for this is that malloc/free use a small data structure just before the dynamic memory block is. The contents are system-specific, but often include things like:
*) Forward and backwards links of free/busy memory blocks *) The size of the memory block. *) The busy/free status of the memory block. *) Magic numbers to check for pointer corruption
> The > application was calling malloc() to get a starting chunk and then repeatedly > calling realloc() to double that amount as needed. Since in the worst case > this approach will use twice the required memory, I thought I'd give back > what I didn't need. I ended up dumping core, however, and inferred that > malloc()/free() might not be as sophisticated as I had assumed.
Or more sophisticated! In this case, what you should be doing is calling realloc() again to trim down the size of the block to exactly what is needed. Then the library will be able to shuffle the remainder off to it's internal free list, building new headers & other internal info as appropriate for that implementation.
Using realloc() to shrink the size of an allocation is not an expensive operation, and won't move the actual data (although it would be safest not to depend on that behavior).
Best, -Mike
> ... I have some questions regarding BRL-CAD's ability > to create production drawings. The documentation mentioned some work > being done with automatic dimension, is anything available for > incorporating into BRL-CAD? Even a primitive (Beta) version would be > useful. Also, is there a command to make BRL-CAD produce the drafting > drawings, or does one have to use seperate commands?
What we have, so far, is RTHIDE, RTSCALE, and RTREGIS.
> Also, the documentation mentions a numerical milling program, is > there a version of this avaliabe? I would be very interested in one.
Nope, sorry.
> I also was wondering what the vector font directory (vfont) was for, > is there some way to annotate the images, and what is libnurb for, > does BRL-CAD have a method for produceing nurb solids, or does one > have to create those outside of BRL-CAD?
vfont directory is used by CAT-FB, which puts troff output onto framebuffers and image files, and FBLABEL which is used for annotating images, usually from shell scripts.
libnurb is for the analysis of NURB solids. We don't allow interactive creation or editing of NURBS yet, but if you have a program that wants to create a NURB, it's easy! Look at proc-db/teapot.c for one example.
> These questions where some things I came up with while reading the > documintation and which I would like more information before I go to > the effort of porting the package to my MAC. Being in the NMR software > busness myself I can understand how easy it is to let the documentation > fall behind.
Actually, the documentation is in pretty fair shape. Problem is, our support contractor that was organizing all the camera-ready copy for the printshop is now 6 months late in delivering, so all you users don't actually HAVE the latest documentation. Sigh. It's a 5 volume set now.
Best, -Mike
realloc() might or might not move the data and it might fail, even for a request to shorten the allocation. Standard-conforming implementations of realloc() will not lose the original data when they report failure. (Older implementations sometimes did.) The programming idiom for this is: /* using p to refer to the start of the data block */ if ( (np = realloc( p, new_size )) != NULL ) /* and only if */ p = np; /* continue to use p to refer to the start of the data block */ (For clarity, I omitted details such as declarations, etc.)
An easy mistake to make is to store addresses within the previous data block into various pointer variables (e.g. sparse-array links), then fail to update them upon realloc()ation (probably because you didn't leave yourself any way to find them!). If you key off (base,offset) instead, then updating just the base pointer to the data block is all that is necessary to track a realloc()ation (the offsets don't change).
On vsb50.brl.dis, using a Silicon Graphics terminal, I ran MGED, which said BRL-CAD 4.0 (mike@walrus.brl.mil:/sunvld/mike/mged), and if I try to edit a certain region:
E regionname
I get:
proc_reg: Cannot draw solid type 21 (ARS) Error in converting solid regionname to ARBN E: 0 vectors in 0 sec
(but little "e" works OK; this region is not all that complicated, and big E should have worked pretty quickly) Let me know if you want a closer look at this case.
Carl:
The "E" command doesn't do ARSs or TORs and never has.
-keith-
This evening, while working on part of our experimental Virtual Reality (VR) support in MGED, I was able to make an optimization to dm-4d.c, the display manager for the SGI Iris 4D workstations, which improved graphics drawing speed by 25% in the test case I tried.
The model was bldg391.g. I gave these commands: e all.g ae 35 25 size 4000 knob x 1
On the Release 4.1 version of the code, I obtained 12.5 frames/sec, while with the new version, I obtained 15.75 frames/sec. (I might note that the new MGED also continuously monitors it's drawing performance now, making it easy to read off frame rates).
Onwards! -Mike
As another part of the VR modifications, the handling of perspective viewing in MGED has been moved up from dm-4d.c into dozoom.c, so that all display managers (such as X, PostScript, Tektronix, Unix-Plot, etc) now have support for perspective drawing, rather than just the SGI. Best, -Mike
FYI, I installed some updates in the BRL-CAD tree today:
1) pix-ps Fixes problem with unusual file sizes that would cause stripes at the top, or failure to print. Quite a bit faster (uses builtin hex printer rather than printf) Page centering now default (with -l for lower left - which I doubt anyone used anyway).
2) loop John Grosh's latest floating point and leading zero version.
3) c-d argv dereference bug (would dump core on SGI's) protected atan2 against 0,0 calls.
- Phil
Paul,
The lack of a shared memory framebuffer on the Indigo is not as burning an issue as you might at first think. The reason is that with release 4.0 BRLCAD has "fbserv". This is known as the "framebuffer server". The idea is that you create a process which opens a framebuffer and handles requests for that framebuffer. This allows you to create 1 framebuffer window for working with images, and removes the "popping window" syndrome. One of the great misfortunes of release 4.0 is that there is no man page for fbserv, and the useage message is of limited help. I will try to give a brief overview here.
fbserv opens a framebuffer window and lingers around waiting to service framebuffer requests. An application opens this framebuffer and reads/writes just like normal. The difference is that when the application closes the framebuffer the server does not close down the window and go away. Instead it goes back to waiting for new framebuffer requests. The next application to open framebuffer 0 gets the same fbserv, with the same framebuffer window and display memory as before. When the user finally wants to dismiss the framebuffer entirely (ie: at logout time) the command "fbfree" will caues fbserv to dismiss the actual framebuffer and then exit.
This method of operation has several advantages over previous methods of operation. The first is that the user gets a framebuffer window that doesn't "disappear" as soon as the application closes the framebuffer (as is the case with a framebuffer of "/dev/sgi"). Traditionally the workaround was to use a "lingering" framebuffer. The problem with this was that the window had to be dismissed by the user after each use or there would be a buildup of "duplicate" windows on the screen.
In addition to the "user interface" problem, there was the problem of using "shared memory" to hold the image. On many (if not all) systems, a shared memory segment was not pageable/swappable. This meant that a single paint of a 1024x1024 image would lock up 3MBytes of main memory until a user explicitly freed the shared memory segment. Few people remember to do this. On many workstations, the loss of 3MB poses a severe penalty on system performance.
Finally, it is possible with fbserv to maintain 2 independent framebuffers on the same system. This can be useful for comparing images, or allow rendering into one framebuffer while other images are viewed into a second.
Example:
% fbserv -S 512 0 /dev/sgip & # start server #1 % fbserv -S 512 1 /dev/sgip & # start server #2 % setenv FB_FILE 1 % pix-fb -F 0 image.pix % pix-fb picture.pix % rt -a 35 -e 25 moss.g all.g >& moss.log & [1] 10671 % setenv FB_FILE 0 % fb-rle image.rle % jobs [1] + Running rt -s 512 -a 35 -e 25 moss.g all.g >& moss.log % [1] Done rt -s512 -a 35 -e 25 moss.g all.g >& moss.log
It is important to note that "fbserv" can use any valid framebuffer name. Fbserv works equally well on a sun, sgi, cray....
Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (410) 278-9200
I've got a problem running the fb routines on my SGI 4D/220. The window that the fb opens comes up and plots the image and then disappears as soon as the image is complete (along with the image). Any hints as to how I can fix this? Thanks.
---------------------------------------------------------------------------
R. Douglas Everhart (614)424-3214 Principal Research Scientist FAX:(614)424-3776 doug@dragon.dst.battelle.org Battelle Memorial Institute 505 King Ave. Columbus, Ohio 43201
---------------------------------------------------------------------------
Try "setenv FB_FILE /dev/sgipl" and then pix-fb. The 'p' option means private memory (not shared) and the 'l' means to linger, i.e. stay around after the program that created the window has exited. See "fbhelp" for more information.
Another option is fbserv, which creates a reusable window. E.g.
% fbserv -w720 -n486 0 /dev/sgip & % setenv FB_FILE 0 % pix-fb -s512 file.pix % fbzoom
etc.
You can have several fbserv's known as '0', '1', etc. They work remotely as well:
remotehost% setenv FB_FILE yourfbservhost:0 remotehost% pix-fb
[Not to be confused with the X11 setenv DISPLAY hostname:0, but the syntax is very similar. If you are using the /dev/X frame buffer, you still need to set DISPLAY, xhost, etc.]
- Phil
Thanks to Mike Muuss, future releases of LIBRT now can renumber instanced region's item numbers. I have recompiled a version of RIP that uses the new LIBRT. You will need a file that contains regular expressions like those used in ED(1) that will be used to match region path names and remap their region ids. The file should have the same base name as your database file but with a ".regexp" suffix (e.g. target.regexp for the file target.g). Comments may be placed in the regular expression file on lines beginning with a '#'. The following is an example:
# # Each of the following lines follows the format: # # Regular_Expression TAB(s) command SEMICOLON # # Examples of valid "command"s for remapping region ids are: # # 99 replace old region id with 99 (or any number) # +99 increment old region id by 99 (or any number) # +uses increment the old region id by the # current instance (use) count # # Note that all regular expressions from ed(1), the line editor, are supported # Note that all commands MUST end with a semicolon ";" # Note that all backslashes have to be doubled. # Note that ., \, [, and * are special pattern matching characters # Blank lines are not significant. # Commands may extend over multiple lines -- they are terminated only by ";" # # Note that the regular expression may specify as much or as little # of the full path name as needed to get the desired effect. # # The order that commands are given is significant, if # several regular expressions select the same region. # # These lines demonstrate all currently supported features.
# discriminate between each instance of block.r /b./block\\.r +uses; # ditto for sph.r /s./sph\\.r +uses;
# For fourth instance of block.r only, go back and force the region ID to 321. /b4/block\\.r 321;
# For the third instance of sph.r only, go back and add 42 to prev. result /s3/sph\\.r +42;
# # Note that the above database had a tree that looked like: # #mged> tree all.g #all.g/ # u floor.r/R # u floor # u b1/ # u block.r/R # u block # u b2/ # u block.r/R # u block # u b3/ # u block.r/R # u block # u b4/ # u block.r/R # u block # u s1/ # u sph.r/R # u sph # u s2/ # u sph.r/R # u sph
# I think "+++paul" has brought up a good point, in fact, why not make # the lingering frame buffer the default.
I'll tell you why. The lingering frame buffer support is an ugly kludge that has serious consequences for interactive libfb clients like 'lgt' and 'fbed'. When the libfb/fbclose() function is called from an interactive program specifying a 'lingering' window, the client gets killed off. I have spent mega-hours answering calls from people whose 'lgt' run gets killed when they close a lingering window. Note that specifying a remote device (ie remote-host:/dev/sgipl) or using 'fbserv' is safe because the lingering window is a remote process, not a child of the client process.
# How often does one want a frame buffer that disappears as soon as its # displayed??
Not very often. Fbserv is definitely the way to go. Unfortunately, the man page didn't get distributed (an oversight apparently), and the inetd configuration is not part of the automatic BRL-CAD installation as far as I know. Getting fbserv properly installed and learning to use it is not a big deal and is definitely worth the trouble. There is the drawback that you can't get a remote fbserv window to resize itself from the client application, but this usually is not a big hardship for the user.
-Gary
Gary mentioned a couple of reasons for not defaulting to lingering windows. I would add to that that if you are using shared memory windows for compositing or what have you, you may not want a stack of windows to pile up on the screen (easy to do). And while lingering may be more common for pix-fb, it often isn't correct for other programs that use frame buffers (take fbzoom for example). [I have however considered suggesting that private memory become the default (rather than shared). I almost *never* use shared any more. fbserv is usually better if you need to do the things shared memory buys you.]
I think a big problem is that answers to FAQ's like this are very hard to find in the documentation. How to use fbserv is almost non existant (my fault, since I wrote fbserv and didn't "finish" the job), and there are other charms in there like memory frame buffers with and without attached displays that let you do some neat things.
I have wanted to write a tutorial example on using these features for many months now. I think having such examples would help first time users (and even others) a lot.
- Phil
Today I added a new addition to the converter directory: it is a shell script that will "compact" mged databases. It takes two arguments: the database to be compacted and the new database. These two arguments must be different. The objective is to remove allocated space that remains when a component is killed. The program relies on g2asc and asc2g to do the actual compacting.
Beware: at this time there is no provision made to cover the following situation. When one of the converters skips a solid/solids, then the database is also "compacted", and the solids skipped by the converters are are omitted.
Cheers, Sue
Lee just found and fixed a horrible and subtle memory leak in nmg_bool.c
I just added a "labelvert" command, which labels the vertices of the vlist of an object with it's model-space coordinates. Designed to help understand some of the NMG debugging plots, I suspect that it will prove valuable to modelers as well. -Mike
FYI.
phd
----- Forwarded message # 1:
Received: from amigo.brl.mil by VMB.BRL.MIL id aa03767; 30 Sep 91 10:19 EDT Received: from AMIGO.BRL.MIL by AMIGO.BRL.MIL id ac07589; 30 Sep 91 10:11 EDT Date: Mon, 30 Sep 91 10:08:20 EDT From: Ann Silirie (OD) <silirie@BRL.MIL> To: senior-staff@BRL.MIL Subject: BRL TAP Report Message-ID: <9109301008.aa07517@AMIGO.BRL.MIL>
BRL TAP Report 30 September 91
VULNERABILITY/LETHALITY DIVISION
COMPARISON BETWEEN BLACK HAWK COMPONENTS HIT BY SMALL ARMS PROJECTILES IN GRENADA AND GEOMETRIC MODEL INTERROGATION PREDICTIONS
Interrogations of the three dimensional graphical model for The BLACK HAWK, UH-60A, were made along the same 7.62mm projectile hit shotlines encountered during "OPERATION URGENT FURY", the Grenada rescue mission. The combat damage data results were compared with the predictions from the Geometric Information For Targets (GIFT) code for the same shotlines encountered in combat. A total of 26 shotlines were examined from two helicopters involved in the conflict. The results of the GIFT code output correlated well with the actual combat damage. The results of this comparative study will be presented in a paper at the US Army Thirtieth Operation Research Symposium (AORS XXX) to be held this November at Fort Lee, VA. POC: Dr. Don Haskell, Ext. 2032.
INTERACTIVE SCREEN EDITOR STYLE COMMAND DEVELOPED FOR BRL-CAD'S MGED
The BRL-CAD, the Army's primary solid modeling system, is used by the BRL, other government agencies, and private industry. Its graphics-based user interface, MGED (Multidevice Graphics EDitor), now can be upgraded to employ screen editor-like capabilities in editing building blocks (called regions and groups) of models. Users can select from a variety of familiar screen editor environments such as "jove," "emacs," or "vi" to define or modify region and group definitions. Heretofore, users were forced to execute the "r" (region) or "g" (group) commands whose data inputs were completely free of syntax and model construction errors. The occurrence of an error in one of these commands often would require the user to completely retype the command and inputs. Now the new command "red" (Region EDitor) will invoke the user's choice of screen editor and allow the user to modify group and region definitions as easily as editing a simple file. POC: Donald Haskell, Ext. 2608.
For the first evening this week, I actually got to do some programming, and I finished my first cut at interactive editing of NURB solids in MGED. It is now possible to interactively select a surface and control point, by pointing and clicking with the mouse, and then draging that control point around on the screen. The spline surface follows along beneath it.
My thanks to Mike Markowski for creating two support subroutines to assist with the point picking.
I'd be happy to show it folks. I've created a really deformed teapot with almost no effort... You can see for yourself in wolf:/m/cad/.mged.5d/ugly-teapot.pix (512).
The user interface needs some refinement before I'd turn anyone loose on it, but all the pieces are there now. (Finally). I've been waiting years to be able to do this!
Best, -Mike
I agree with Lee Butler. Factors are:
1) If there is a lot of constant color, run length encoding (RLE) really wins. See the Utah Raster Toolkit utilities (included in BRL-CAD). 2) For general images (e.g. with noise or lots of varying colors), general compression techniques (such as compress/uncompress) work every bit as well as "image" techniques for the lossless case. 3) Sometimes it helps to do color separations first, and then compress. 4) If you don't need lossless compression, there are some very good image oriented compression techniques available (e.g. JPEG).
Around here we use compress/uncompress a lot. It's lossless, and in general works as well or better than RLE (but slower).
- Phil
Just a warning that I updated VOTE with MIT's official patches 11-13. I I have been using this software for several weeks so it should be fine, but you may notice a large number of Sun4 files being updated via rdist; it's just a side-effect of rebuilding the core MIT X11R5 distribution.
Included in this update is the xrolo utility (mimics the functionality of a rolodex). I installed this because Jill asked for such a capability, but I haven't got the time to test it out properly, so use at your own risk (as usual ;-) and let me know if there are any problems. I noticed that it dumps core immediately on Sun3s, but so do many other xview clients. Apparently, the xview library has problems there, so I am not making it available at this point in time on Sun3s.
Finally, I installed xpa on VOTE; this is the X11 front end to my presented area, mass, moments and products of inertia, etc. program. The ray-tracing back end for xpa is called "paslave" and lives under /usr/vld/bin; it is typically run on a different host than the X11 part and is installed on some of the SGI servers. These programs (xpa/paslave) are experimental meaning that I have tested the results to the best of my ability, but it is the user's responsibility to convince himself that the answers are correct. I just do not have the resources to come up with a robust set of test cases with known answers for moments and products of inertia. It works for simple test cases (ie a cube), and there is no reason to suspect that the complexity of the MGED region should make any difference, but "caveat emptor" anyway.
-Gary
This evening I have made modifications to MGED to permit the "preview" command to process "anim", "tree", and "clean" commands from an RT animation script, and generate the correct display.
-M
CAD world,
When using mged and attaching sgi (either at the start of editing or attaching later) mged is (randomly) killed sending me back to my prompt
I am using the latest (?) version of mged BRL-CAD Release 4.1 Graphics Editor (MGED) Thu Sep 3 13:10:56 EDT 1992, Compilation 4 stay@wildcat:/n/wolf/m/dist4.1/mged
and running tvtwm with IRIX 4.0.5
Has anyone seen this problem and have a solution???????
thanks jodi
>When using mged and attaching sgi (either at the start of editing or >attaching later) mged is (randomly) killed sending me back to my prompt
Mike Markowski also noticed this. On the occasions it's been noticed, it seems to be related to an unusual state of the graphics engine. Applying the "Vulcan Death Grip" (simultaneous Lctrl,Lshift,F12,keypad-/) to reset the graphics hardware seems to correct the problem. If you can come up with a repeatable test case, please let us know.
Lee A. Butler Ballistic Research Laboratory Internet: butler@brl.mil Aberdeen P.G., MD 21005-5066 Phone: (410) 278-9200
The short answer is that you didn't miss anything while you were sick. I hope you are feeling better now!
The files to read in preparation for doing something with NMGs are h/nmg.h, librt/nmg_*.c, librt/g_nmg.c, and mged/dodraw.c
For an example of some code that creates an NMG object, you might examine librt/g_arb.c: rt_arb_tess() and librt/g_ell.c: rt_ell_tess(). I don't promise that either are "clean" or the "best" way to accomplish that task, but they arn't bad, and work.
You are welcome to consider either the Release 4.0 versions, or the latest sources from wolf:/m/cad, although I note that the later may be in a state of disrepair on occasion, as Lee and I are working hard on the code, between briefings, TDY, and other excitement provided from on high.
After you've spent a little while looking around, it would probably be appropriate to get together and chat for an hour or two some afternoon, to answer whatever questions have come up.
Best, -Mike
Bruce writes -
> What do the options -s squaresize, -w width, and > -h height do?
They specify the size of the input file. For a more full description of these options (which show up on almost every image processing command in BRL-CAD), run "man brlcad". That man page documents the overall conventions for command line options.
Best, -Mike
I can not reproduce this error on Irix 4.0.5, but do recall the exact same trouble when we were running 4.0.1. The fix is to put the Font Manager Library ( libfm_s.a ) before the other libraries:
./cad/edpix/Cakefile: 20c20 < CC LDFLAGS -o edpix OBJ LIB_PRE''LIBRLE -lgl_s -lfm_s LIBES --- > CC LDFLAGS -o edpix OBJ -lfm_s LIB_PRE''LIBRLE -lgl_s LIBES
I believe the C compiler is going through some groing pains? At leaset it has had other difficulties between 4.0.1 and 4.0.5 so for now I will blame it. Let me know if the problem persists.
-jim Hunt
I had sent a previous message to PJT about this. Here, I am providing a sample run. Sending to "cad" reaches too many people at this time; besides, people outside the former BRL can't get at this sample.
On WUMPUS, look up the directory /vld/cmoore/CELLFBTEST , and run the executable (user-readable) file "runstream". For starters: Why do I get white space instead of red space (the latter indicating a value of 1) at (y = -40) x=+16,+12,-32,-40? x is the first field, y is the 2nd field, and I am plotting the 3rd field.
Disregard this message (and I am deleting the copy to myself). Field number 3 is the third field AFTER the x and y columns. In other words, I was comparing field 3 to field 1.
----- Forwarded message # 1:
Date: Wed, 28 Oct 92 14:29:19 EST From: Carl Moore (VLD/VMB) <cmoore@BRL> To: acst@BRL.MIL, pjt@BRL.MIL cc: cmoore@BRL Subject: noise around the edges? Message-ID: <9210281429.aa18179@WUMPUS.BRL.MIL>
I had sent a previous message to PJT about this. Here, I am providing a sample run. Sending to "cad" reaches too many people at this time; besides, people outside the former BRL can't get at this sample.
On WUMPUS, look up the directory /vld/cmoore/CELLFBTEST , and run the executable (user-readable) file "runstream". For starters: Why do I get white space instead of red space (the latter indicating a value of 1) at (y = -40) x=+16,+12,-32,-40? x is the first field, y is the 2nd field, and I am plotting the 3rd field.
----- End of forwarded messages
It seems like external interest in animation using BRL-CAD is suddenly picking up:
> From: "Kenneth H. Fielding" <kfieldin@afit.af.mil> > > I would like to generate say a 10 frame sequence where I can define > scale, orientation, and position for the object in each frame. The > frames can then be ganged together to make a "movie". > > what is the easiest and most straight forward way to do this in > either "rt" or "lgt"?
> From: "Gary S. Moss" (VLD/VMB) <moss@BRL.MIL> > > I don't know the easiest way. Hopefully, if tools exist to do in-betweening > or other useful steps in generating smooth animation sequences, someone else > will speak up. I recall some buggy frame-interpolation software that used > to be available at BRL, but it was never made available for general use.
I'm not sure what software Gary is making reference to, but in Release 4.0 you will find the two primary tools that I have used for making animations: TABINTERP and TABSUB. They don't have manual pages at the moment.
TABINTERP is a table-based interpolator that can take an arbitrary collection of columns from an arbitrary number of input files, and resamples them using a selection of interpolators (including spline).
TABSUB is a macro processor especially suited for generating RT animation scripts from the output of TABINTERP.
Keyframes can be specified using MGED, by hand, or using an external program. I've done it all three ways.
Once an animation script has been prepared, it can be fed to either RT or REMRT on stdin by giving the -M flag on the commandline. All frames will be computed in sequence, with "checkpoint-restart" handled automaticly, so that the machine going down won't cost you more than a few pixels of the final result.
Note that the RT animation script facility can BOTH (a) move the eyepoint around stationary geometry, and (b) articulate the geometry at any number of arcs in the database DAG (tree). For example, the eye (camera) could by flying, while a rotation was being superimposed on the arc tank.g/turret.g.
Lee Butler has a draft of a paper on how to use this capability. It is not complete, but should serve as a useful baseline. Contact him at <butler@brl.mil>.
Also note that there is a tutorial session on using this capability being given by Chris Johnson at the BRL-CAD Users Conference this week. Contact the conferenct at 800-466-4862 for info. While I have not seen his presentation materials, he has produced quite a number of successful animation sequences using the RT animation capability, so his talk should be quite informative.
I'm sorry that there isn't more written about this stuff, but writing takes time. After you have looked over the intro materials, I'd be happy to send you an example of a simple animation.
Best, -Mike
At the BRLCAD conference it was demonstrated that their is a toggle switch for perspective viewing in MGED. On the SGI machines I beleive it was F2 or F3. One of the other keys could then be used to flip through the major perspective angles (90,60,30).
I have tried to put MGED into perspective viewing mode, and it doesn't seem to work. We have BRLCAD running on SPARC IPX. Is perspective viewing supported for the SUN running X? If so, what is the keystroke to turn it on?
Harry Campbell
Alas, I believe the perspective function button is only available on the SGI at the moment.
Lee A. Butler U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200
> The perspective viewing mode is not available under X. The reason is that > the perspective is generated in the view module of mged. Under the sgi > view module each vector is passed through a (hardware) matrix multiply. > There is no such manipulation in the X window support.
The details here are incorrect. In Release 4.0, the perspective is generated in the SGI-specific display manager module mged/dm-4d.c (*not* the view module). Both the SGI and the X display managers already transform each vector by a 4x4 transform matrix. But the conclusion is right -- in Release 4.0, there is no perspective viewing on the X interface.
However, in the development version of MGED, perspective support has been pushed up into the "top half" of the display interface, and thus automaticly operates properly on X displays, and all other displays.
No function key has been assigned on the X display yet, but keyboard commands can be used to assign the viewing angle, like:
set perspective=90 and set perspective=42.5
It can be turned off (orthoview) with
set perspective=0
Something to look forward to in the next release. Best, -Mike
All,
Can anyone help Jim get is display diplaying?
Jill
----- Forwarded message # 1:
Received: from wharf.brl.mil by WORM.BRL.MIL id aa19456; 13 Nov 92 9:59 EST Received: from fivs01.flight.wpafb.af.mil by WHARF.BRL.MIL id aa08436; 13 Nov 92 9:40 EST Received: from fovea.mbvlab.wpafb.af.mil ([134.131.203.6]) by mbv (4.1/SMI-4.1) id AA13590; Fri, 13 Nov 92 09:39:04 EST Date: Fri, 13 Nov 92 09:39:04 EST From: Jim Leonard <jleonard@mbvlab.wpafb.af.mil> Message-Id: <9211131439.AA13590@mbv> To: jill@BRL.MIL Subject: X term with BRLCAD
Jill, I'm Jim Leonard and I talked with you at the conference last week. I am running the CAD on a Sun 4 using X11R4 on a Mac running AUX. Running mged everything is fine until I do a ray trace. The frame buffer opens and stays but the window stays black. I have: setenv DISPLAY to my Mac computer setenv FB_FILE /dev/Xl
Does anyone have any ideas what I need to do to get the frame buffer displayed? Thanks Jim Leonard jleonard@mbv.mbvlab.wpafb.af.mil phone DSN 785-1115 or commercial (513)255-1115
----- End of forwarded messages
>everything is fine until I do a ray trace. The frame buffer opens and stays >but the window stays black. I have: >setenv DISPLAY to my Mac computer >setenv FB_FILE /dev/Xl
I'm just guessing, but it could be that you need to make sure the mouse pointer moves into the framebuffer window. Since the X server will probably need to load a new color map for that window, you may not see anything until the mouse is in the window.
Taking another stab in the dark, can you display one of the pix files that came with BRL-CAD? Try: pix-fb -F /dev/Xl brlcad/pix/moss.pix
Since I don't have a Mac to try this on, I can't offer much else.
Lee
>To: jill@BRL.MIL >Subject: X term with BRLCAD > >Jill, >I'm Jim Leonard and I talked with you at the conference last week. I am >running the CAD on a Sun 4 using X11R4 on a Mac running AUX. Running mged >everything is fine until I do a ray trace. The frame buffer opens and stays >but the window stays black. I have: >setenv DISPLAY to my Mac computer >setenv FB_FILE /dev/Xl > >Does anyone have any ideas what I need to do to get the frame buffer displayed? >Thanks >Jim Leonard >jleonard@mbv.mbvlab.wpafb.af.mil
Jim,
The most likely problem you are having with your X display under A/UX (assuming that you are using MacX) is that you are using the wrong screen. The method that I use is: Make a version of libfb under A/UX that has X support compiled in. (There is a #if 0/1 in /m/cad/Cakefile.defs to do this) cd /m/cad/libfb cake clean; cake libfb.a cd ../fbserv cake (install fbserv) edit /m/cad/Cakefile.defs to change the frame buffer support to no X) cd /m/cad/libfb;cake clean; cake libfb.a
Once fbserv is installed, try the following: DISPLAY=localhost:0.2;export DISPLAY fbserv -F/dev/X 0& on your sun: FB_FILE=mac_name:0;export FB_FILE pix-fb /m/cad/pix/world.pix
This should work. Be aware that color support is not very good for X yet.
Chris Johnson -- Support@results.com 1-800-497-6165 BRL-CAD Support Group. Installations, technical support, animations, printing, plus more.
Responding to the suggestion of Tom Sullivan of SANDIA at the recent BRL-CAD Users Conference, I have modified the development copy of VDECK to support the creation of .cg files containing more than 9999 solids. This can be important for the calculation of radar signatures of certain large geometry files on Sandia's parallel machines.
Here is the RCS log entry:
date: 92/11/18 22:21:02; author: mike; state: Exp; lines added/del: 20/6 Added improvement suggeted by Tom Sullivan of Sandia to permit solids with numbers > 9999 to be referenced by a subtraction operation in the region table, by substituting operator "nn#" for " -#".
If you need this modification to support your work, please drop me a line and I'll E-mail it to you.
Best, -Mike
PS: Thanks to Harry Reed of GSI for the use of the Havoc 'chopper model, which I instanced 8 times to make a suitably large database to test the >9999 solids condition.
Following up on a remark that Chris Johnson made at the BRL-CAD User's Conference, and motivated by having to process some SIGS images, I have expanded the autosize functionality of LIBFB (usually obtained with the "-a" flag on programs) so that if the image is exactly square (of any dimension), it will autosize.
This means that, e.g., 1800x1800 or 200x200 images or 52x52 images will all autosize, without having to add those sizes to the table.
Something to look forward to in the next release. Best, -Mike
This evening, I added an 'f' option to the LIBFB routine if_ab.c, so that instead of writing .YUV data over the EtherNet to a network connected Abekas, the .YUV data is written into a disk file.
For example, the command:
pix-fb -F /dev/abovf@prefix#42 dragon.pix
will create the disk file:
prefix42.yuv
When the 'f' flag is given, what is usually the host name (following the '@') is now interpreted as a prefix string, which may include slashes to indicate a full path. The suffix of ".yuv" is always provided.
Similarly, the command
fb-pix -F /dev/abvf@/tmp/#42 newfile.pix
will read the (framebuffer) disk file "/tmp/42.yuv" and store it in "newfile.pix".
This new option should allow more efficient use of disk space when creating animations destined exclusively for an Abekas, because .YUV files are smaller than .PIX files. Also, if frames are stored in .YUV format, they can be bulk loaded to the Abekas without having to pay the 4-seconds per frame processing time for converting .PIX to .YUV. The transmission then becomes simply:
rcp *.yuv abekas:
This also makes it easy to write Abekas backup/restore formatted 8mm Exabyte tapes directly from the UNIX host. The Abekas loads images about twice as fast from the Exabyte as it does over the Ethernet. That, plus the advantage of getting a tape backup copy as a "free" by-product, makes this attractive for longer animations. More on this in some future note.
Best, -Mike
The line that read:
fb-pix -F /dev/abvf@/tmp/#42 newfile.pix
is likely to be more satisfying if it reads:
fb-pix -w720 -n486 -F /dev/abvf@/tmp/#42 newfile.pix
so that all the pixels are converted. (The default is -s512, which does not process all 720 pixels across).
Best, -Mike
Many brl-cad users have been interested in extruding into 3d an arbitrary polygon or in adding thickness to faceted objects.
Yesterday I finished a subroutine that given an NMG face and a vector, will extrude the face based on the direction and magnitude of the vector. The routine handles a single face of one or more loops. This is the 1st step towards a routine allowing general (multiple face) extrusion of faceted objects.
Stay tuned, Mike
At a recent meeting it was asked how to produce HPGL or Postscript files for line plots (hidden line drawings). Since it seems to of general interest in the community I thought that I would give a brief description on how to do this.
The first phase is to get a plot file made. I will use the m35 truck found in the database to illustrate on how this is done.
To get a top view of the m35 truck made into a plot file you can use the rthide command. rthide -o top.pl -s 1024 -a 90 -e 90 m35.g component
This creates an Extended Unix Plot file, the extended Plot format allows for 3D data, color, space bounding boxes, etc. You can look in the libplot directory for more info.
We now need to Rotate the plotfile, Scale it, convert it to the standard Unix Plot format.
plrot -a 90 -e 90 -g top.pl | pl-pl -S > top2.pl
The plot file is now ready to convert to a number of different formats and there are several converters, pl-tek Plot to Tektronix pl-ps Plot to Postscript pl-hpgl Plot to HP GL format pl-fb Plot to BRLCAD Frame buffer
If you want hpgl then do
pl-hpgl < top2.pl > top.hpgl
I tested the above including sending the top.hpgl to our Tektronix Phaser III in hpgl mode.
You will want to look at the man pages for details on each of the above programs.
The following script can be used to generate a side view of the database
and can be called by
side.sh m35.g component
----------------------------- side.sh ---------------------------
#!/bin/sh
PATH=/usr/brlcad/bin
rthide -s 512 -a 90 -e 0 $1 $2 | plrot -a 90 -e 0 -g \ | pl-pl -S | pl-hpgl
-----------------------------------------------------------------
Hope this helps.
-Paul
One major item which I forgot to mention on Friday was the creation of a new support module, nmg_visit.c, which handles recursive descent of the NMG data structures, invoking caller-provided functions at relevant stops along the way. This makes tasks like "visit all the vertices" (which can be reached 5 different ways) very simple to program. Best, -Mike
This evening I got the 2D (co-planar face) code to do it's first test case successfully, which is very encouraging.
Along the way I re-learned that eu->eumate_p->vu_p is not at all the same as RT_LIST_PNEXT_CIRC(edgeuse,eu)->vu_p -- the vu's UP pointer is in the faceuse of *opposite* orientation in the first case, and the correct orientation in the second case. Important difference, even if the first formula is easier to type.
Best, -Mike
> I just got my 4.0 documentation, and after just scanning through > it looks pretty impressive. I think everyone did a good job.
Thanks! It's also good to know that the boxes are making it through the mail, too.
> On to the actual topic. I was very impressed by the complexity of > some of the models displayed (created in mged), and I thought it would > be a big help in learning how to design complex models if I had one > or two of these to play with and see how they were built.
Probably the best way to gear up a staff for a large model building task would be to contact one of several companies which provide BRL-CAD training courses, and take a class. CSG model building is a little bit different than traditional modeling, and the current documentation is not oriented towards this.
A lack which we are aware of. There are plans afoot to have more documentation created, but it won't be in the hands of end-users for at least another year.
> So, is > it possible to get via ftp some of these models, like the M1A1 > and/or the Bradley.
There are some restrictions on what geometric models can be distributed, and there is a small handling fee associated with acquiring each model and it's supporting documentation. Please contact Keith Applin at N/A-N/A-NANA <xxx@xxx.xxx> for information about what models are available, and what the distribution arrangements are.
On the other hand, you might want to examine the "db/" directory in BRL-CAD Release 4.0 -- it contains a railroad tank car (db/tank_car.asc) and a Havoc 'chopper (db/havoc.asc), both very nice looking models which were provided courtesy of Harry Reed, Geometric Solutions Inc.
Best, -Mike Muuss
The US Army Research Laboratory APG, MD 21005-5068
> From: joe edward meier <jem@bruker.com> > > Does the "ev" command work in the 4.0 version of meged. When I > use the command the whole program quits.
In the 4.0 Release, the "ev" command does occasionally work, but only on exceedingly simple cases. It is provided more so that interested developers can examine the code to learn more about how the NMG routines can be used, than to provide an end-user service.
We felt it important to ship Release 4.0 with a non-working NMG library so that users could take advantage of the many other improvements and optimizations it contains, rather than delaying the rest of the software a substantial length of time (years, as it has turned out). The maintenance release will provide a functional NMG library.
Expect this pattern to recur. Release 5.0 will probably have initial support for trimmed-NURBS (t-NURBS), and in Release 5.1 the t-NURBS support will be complete.
Best, -Mike
In preparation for doing code review on the first set of modules which comprise the NMG support library, I encountered the routine nmg_esplit(), the function of which was difficult to describe.
To make the function more precise, easier to understand, and much easier for calling routines to use, the second argument was changed from being an edge to an edgeuse (of that edge), and the return code was changed from being an edge to an edgeuse, also.
The new calling sequence is:
struct edgeuse * nmg_esplit(v, eu) struct vertex *v; struct edgeuse *eu; { }
This routine was only used by internal routines, and in only a few places, so the change was not disruptive. Furthermore, in every instance, the previous call had been
nmg_esplit( v, eu->e_p );
so changing that to be
nmg_esplit( v, eu );
was no hardship. Since this routine is mentioned in the documentation, there is a slight chance that other code developers have written something which makes use of it. That is the purpose of this message, to warn of the impending change.
Both the compile time argument checking (on ANSI C compilers) and the customary NMG library's run-time argument checking (on all systems) will assist in swiftly isolating any non-library code which needs to be modified to deal with this change.
Best, -Mike
A question reached me about cross-section area in mged, and I was able to provide only a partial answer (i.e., I don't know of being able to cut a plane through a target and get the area showing up on that plane).
The partial answer was that I can do the "area" command within mged and get the presented area of the view that I am currently displaying.
The presented area calculated with a view normal to the cutting plane would be the area of the cross-section provided that the projection of the rest of the object does not spill into places outside of the 2-d regions defined by the planar cut.
There may be elegant MGED solutions to this in place, but I don't know of them.
If you are planning to get a good approximation--one which avoids the problem mentioned above, you can make a second planar cut parallel and near to the first and subtract the backside of the region before making the presented area calculation. That will improve your chances of getting the area of the slice of baloney of interest.
Ed
Yes, I got the cross-section in a test I just ran with a 1-inch cube. At azim 0 & elev 0, I was looking head on at one of the faces (with another face being flush with the ground), and at that view "area" gave me 1 square inch. Then I went to azim 45 & elev 0, and "area" gave me square-root-of-two (about 1.414) square inches.
I also don't know what I'd do to pass a different cutting plane through. The best I could do would be to delete (using "d") objects which project beyond the area I want to see.
Another test with the cube was to go back to azim 0 & elev 0 and hollow out a portion of it so that what's left looked something like:
***** ***** * * instead of ***** ***** *****
and I still got 1 square inch. Notice that the face which is showing still has all its edges intact. I then expanded the subtraction so that part of one of those edges was chopped off:
* * * * *****
and that reduced what "area" gave me. "area" is obviously ignoring holes except for holes which cut into the outer edge.
Stu-
The algorithm which is used by the BRL-CAD software is based on algorithms found in the SigGraph 1990 paper "Ray Tracing Trimmed rational Surface Patches" by Nishita, Sederburg, Kamimoto, The routines are a combination of librt and libnurb. The libnurb routines are included in the librt library.
A sample data base can be generated by using the teapot program found in the proc-db directory.
Currently the Nurb raytracing routines do not handle trimmed nurbs. Eventually there will be support for trimmed nurbs as part of the NMG routines. At the time of the last BRL-CAD meeting the libnurb library routines were still in a state of change. I hope to have some documentation on the libnurb library before the next release.
-Paul
On Friday, I was able to test the program "hpcdppm" which I obtained from the network. It worked, allowing my Sun-4 workstation to read images off a Kodak Photo-CD CD-ROM.
It was short work to mutate that program into "pcd-pix", and that works too.
Basically, any machine that can mount a CD-ROM with High Sierra (ISO 9660) filesystem and retrieve files from there is likely to be able to use this program.
This represents a new way that experimental and field data can be digitized and brought into the computer for analysis. Best, -Mike
Dr. Walbert has agreed to provide funding for me to TDY to the IPO meeting in Nashville the week of April 4. If both of you are agreeable, I would like to attend.
Mike, I haven't had a chance to talk to you about IGES, but there are a few problems with the standard for a hybrid system with boolean trees (like BRLCAD). One problem is that the CSG standard has a limited vocabulary of primitive solids, and in particular cannot handle our TGC, polysolid, or arb8's with non-right angles. When Earl and I heard about the BREP standard, we thought that these solids could be handled by making them BREP objects. Unfortunately, when the new standard came out, the CSG boolean trees were prohibited from containing BREP objects, so we are still stuck. It seems to us (Earl and me) that the solution is to remove the restriction on CSG boolean trees and possibly enrich the CSG vocabulary.
Another concern is that the same people who developed IGES are developing PDES. If we don't do something now, we are likely to end up with the same problems on PDES. This meeting in Nashville is a combined meeting of both the IGES and PDES people and is a convenient oppurtunity to start pushing those people around to "correct" thinking.
-John
I put the defaulting into MGED where "preview" uses the current MGED view if none is given in the script. Lets you preview animations from any angle, and saves the need to put view specs in your scripts.
- Phil
Here is a copy of NCD rgb.txt which contains lots of colors. Could you replace this file with one that we currently have for rdist?
Cindy
-------------------------------------------------------
255 250 250 snow 248 248 255 ghost white 248 248 255 GhostWhite 245 245 245 white smoke 245 245 245 WhiteSmoke 220 220 220 gainsboro 255 250 240 floral white 255 250 240 FloralWhite 253 245 230 old lace 253 245 230 OldLace 250 240 230 linen 250 235 215 antique white 250 235 215 AntiqueWhite 255 239 213 papaya whip 255 239 213 PapayaWhip 255 235 205 blanched almond 255 235 205 BlanchedAlmond 255 228 196 bisque 255 218 185 peach puff 255 218 185 PeachPuff 255 222 173 navajo white 255 222 173 NavajoWhite 255 228 181 moccasin 255 248 220 cornsilk 255 255 240 ivory 255 250 205 lemon chiffon 255 250 205 LemonChiffon 255 245 238 seashell 240 255 240 honeydew 245 255 250 mint cream 245 255 250 MintCream 240 255 255 azure 240 248 255 alice blue 240 248 255 AliceBlue 230 230 250 lavender 255 240 245 lavender blush 255 240 245 LavenderBlush 255 228 225 misty rose 255 228 225 MistyRose 255 255 255 white 0 0 0 black 47 79 79 dark slate gray 47 79 79 DarkSlateGray 47 79 79 dark slate grey 47 79 79 DarkSlateGrey 105 105 105 dim gray 105 105 105 DimGray 105 105 105 dim grey 105 105 105 DimGrey 112 128 144 slate gray 112 128 144 SlateGray 112 128 144 slate grey 112 128 144 SlateGrey 119 136 153 light slate gray 119 136 153 LightSlateGray 119 136 153 light slate grey 119 136 153 LightSlateGrey 192 192 192 gray 192 192 192 grey 211 211 211 light grey 211 211 211 LightGrey 211 211 211 light gray 211 211 211 LightGray 25 25 112 midnight blue 25 25 112 MidnightBlue 0 0 128 navy 0 0 128 navy blue 0 0 128 NavyBlue 100 149 237 cornflower blue 100 149 237 CornflowerBlue 72 61 139 dark slate blue 72 61 139 DarkSlateBlue 106 90 205 slate blue 106 90 205 SlateBlue 123 104 238 medium slate blue 123 104 238 MediumSlateBlue 132 112 255 light slate blue 132 112 255 LightSlateBlue 0 0 205 medium blue 0 0 205 MediumBlue 65 105 225 royal blue 65 105 225 RoyalBlue 0 0 255 blue 30 144 255 dodger blue 30 144 255 DodgerBlue 0 171 232 decwblue 0 171 232 DECWBlue 0 191 255 deep sky blue 0 191 255 DeepSkyBlue 135 206 235 sky blue 135 206 235 SkyBlue 135 206 250 light sky blue 135 206 250 LightSkyBlue 70 130 180 steel blue 70 130 180 SteelBlue 176 196 222 light steel blue 176 196 222 LightSteelBlue 173 216 230 light blue 173 216 230 LightBlue 176 224 230 powder blue 176 224 230 PowderBlue 175 238 238 pale turquoise 175 238 238 PaleTurquoise 0 206 209 dark turquoise 0 206 209 DarkTurquoise 72 209 204 medium turquoise 72 209 204 MediumTurquoise 64 224 208 turquoise 0 255 255 cyan 224 255 255 light cyan 224 255 255 LightCyan 95 158 160 cadet blue 95 158 160 CadetBlue 102 205 170 medium aquamarine 102 205 170 MediumAquamarine 127 255 212 aquamarine 0 100 0 dark green 0 100 0 DarkGreen 85 107 47 dark olive green 85 107 47 DarkOliveGreen 143 188 143 dark sea green 143 188 143 DarkSeaGreen 46 139 87 sea green 46 139 87 SeaGreen 60 179 113 medium sea green 60 179 113 MediumSeaGreen 32 178 170 light sea green 32 178 170 LightSeaGreen 152 251 152 pale green 152 251 152 PaleGreen 0 255 127 spring green 0 255 127 SpringGreen 124 252 0 lawn green 124 252 0 LawnGreen 0 255 0 green 127 255 0 chartreuse 0 250 154 medium spring green 0 250 154 MediumSpringGreen 173 255 47 green yellow 173 255 47 GreenYellow 50 205 50 lime green 50 205 50 LimeGreen 154 205 50 yellow green 154 205 50 YellowGreen 34 139 34 forest green 34 139 34 ForestGreen 107 143 36 medium forest green 107 143 36 MediumForestGreen 107 142 35 olive drab 107 142 35 OliveDrab 189 183 107 dark khaki 189 183 107 DarkKhaki 240 230 140 khaki 238 232 170 pale goldenrod 238 232 170 PaleGoldenrod 250 250 210 light goldenrod yellow 250 250 210 LightGoldenrodYellow 255 255 224 light yellow 255 255 224 LightYellow 255 255 0 yellow 255 215 0 gold 238 221 130 light goldenrod 238 221 130 LightGoldenrod 235 235 173 medium goldenrod 235 235 173 MediumGoldenrod 218 165 32 goldenrod 184 134 11 dark goldenrod 184 134 11 DarkGoldenrod 188 143 143 rosy brown 188 143 143 RosyBrown 205 92 92 indian red 205 92 92 IndianRed 139 69 19 saddle brown 139 69 19 SaddleBrown 160 82 45 sienna 205 133 63 peru 222 184 135 burlywood 245 245 220 beige 245 222 179 wheat 244 164 96 sandy brown 244 164 96 SandyBrown 210 180 140 tan 210 105 30 chocolate 178 34 34 firebrick 165 42 42 brown 233 150 122 dark salmon 233 150 122 DarkSalmon 250 128 114 salmon 255 160 122 light salmon 255 160 122 LightSalmon 255 165 0 orange 255 140 0 dark orange 255 140 0 DarkOrange 255 127 80 coral 240 128 128 light coral 240 128 128 LightCoral 255 99 71 tomato 255 69 0 orange red 255 69 0 OrangeRed 255 0 0 red 255 105 180 hot pink 255 105 180 HotPink 255 20 147 deep pink 255 20 147 DeepPink 255 192 203 pink 255 182 193 light pink 255 182 193 LightPink 219 112 147 pale violet red 219 112 147 PaleVioletRed 176 48 96 maroon 199 21 133 medium violet red 199 21 133 MediumVioletRed 208 32 144 violet red 208 32 144 VioletRed 255 0 255 magenta 238 130 238 violet 221 160 221 plum 218 112 214 orchid 186 85 211 medium orchid 186 85 211 MediumOrchid 153 50 204 dark orchid 153 50 204 DarkOrchid 148 0 211 dark violet 148 0 211 DarkViolet 138 43 226 blue violet 138 43 226 BlueViolet 160 32 240 purple 147 112 219 medium purple 147 112 219 MediumPurple 216 191 216 thistle 255 250 250 snow1 238 233 233 snow2 205 201 201 snow3 139 137 137 snow4 255 245 238 seashell1 238 229 222 seashell2 205 197 191 seashell3 139 134 130 seashell4 255 239 219 AntiqueWhite1 238 223 204 AntiqueWhite2 205 192 176 AntiqueWhite3 139 131 120 AntiqueWhite4 255 228 196 bisque1 238 213 183 bisque2 205 183 158 bisque3 139 125 107 bisque4 255 218 185 PeachPuff1 238 203 173 PeachPuff2 205 175 149 PeachPuff3 139 119 101 PeachPuff4 255 222 173 NavajoWhite1 238 207 161 NavajoWhite2 205 179 139 NavajoWhite3 139 121 94 NavajoWhite4 255 250 205 LemonChiffon1 238 233 191 LemonChiffon2 205 201 165 LemonChiffon3 139 137 112 LemonChiffon4 255 248 220 cornsilk1 238 232 205 cornsilk2 205 200 177 cornsilk3 139 136 120 cornsilk4 255 255 240 ivory1 238 238 224 ivory2 205 205 193 ivory3 139 139 131 ivory4 240 255 240 honeydew1 224 238 224 honeydew2 193 205 193 honeydew3 131 139 131 honeydew4 255 240 245 LavenderBlush1 238 224 229 LavenderBlush2 205 193 197 LavenderBlush3 139 131 134 LavenderBlush4 255 228 225 MistyRose1 238 213 210 MistyRose2 205 183 181 MistyRose3 139 125 123 MistyRose4 240 255 255 azure1 224 238 238 azure2 193 205 205 azure3 131 139 139 azure4 131 111 255 SlateBlue1 122 103 238 SlateBlue2 105 89 205 SlateBlue3 71 60 139 SlateBlue4 72 118 255 RoyalBlue1 67 110 238 RoyalBlue2 58 95 205 RoyalBlue3 39 64 139 RoyalBlue4 0 0 255 blue1 0 0 238 blue2 0 0 205 blue3 0 0 139 blue4 30 144 255 DodgerBlue1 28 134 238 DodgerBlue2 24 116 205 DodgerBlue3 16 78 139 DodgerBlue4 99 184 255 SteelBlue1 92 172 238 SteelBlue2 79 148 205 SteelBlue3 54 100 139 SteelBlue4 0 191 255 DeepSkyBlue1 0 178 238 DeepSkyBlue2 0 154 205 DeepSkyBlue3 0 104 139 DeepSkyBlue4 135 206 255 SkyBlue1 126 192 238 SkyBlue2 108 166 205 SkyBlue3 74 112 139 SkyBlue4 176 226 255 LightSkyBlue1 164 211 238 LightSkyBlue2 141 182 205 LightSkyBlue3 96 123 139 LightSkyBlue4 198 226 255 SlateGray1 185 211 238 SlateGray2 159 182 205 SlateGray3 108 123 139 SlateGray4 202 225 255 LightSteelBlue1 188 210 238 LightSteelBlue2 162 181 205 LightSteelBlue3 110 123 139 LightSteelBlue4 191 239 255 LightBlue1 178 223 238 LightBlue2 154 192 205 LightBlue3 104 131 139 LightBlue4 224 255 255 LightCyan1 209 238 238 LightCyan2 180 205 205 LightCyan3 122 139 139 LightCyan4 187 255 255 PaleTurquoise1 174 238 238 PaleTurquoise2 150 205 205 PaleTurquoise3 102 139 139 PaleTurquoise4 152 245 255 CadetBlue1 142 229 238 CadetBlue2 122 197 205 CadetBlue3 83 134 139 CadetBlue4 0 245 255 turquoise1 0 229 238 turquoise2 0 197 205 turquoise3 0 134 139 turquoise4 0 255 255 cyan1 0 238 238 cyan2 0 205 205 cyan3 0 139 139 cyan4 151 255 255 DarkSlateGray1 141 238 238 DarkSlateGray2 121 205 205 DarkSlateGray3 82 139 139 DarkSlateGray4 127 255 212 aquamarine1 118 238 198 aquamarine2 102 205 170 aquamarine3 69 139 116 aquamarine4 193 255 193 DarkSeaGreen1 180 238 180 DarkSeaGreen2 155 205 155 DarkSeaGreen3 105 139 105 DarkSeaGreen4 84 255 159 SeaGreen1 78 238 148 SeaGreen2 67 205 128 SeaGreen3 46 139 87 SeaGreen4 154 255 154 PaleGreen1 144 238 144 PaleGreen2 124 205 124 PaleGreen3 84 139 84 PaleGreen4 0 255 127 SpringGreen1 0 238 118 SpringGreen2 0 205 102 SpringGreen3 0 139 69 SpringGreen4 0 255 0 green1 0 238 0 green2 0 205 0 green3 0 139 0 green4 127 255 0 chartreuse1 118 238 0 chartreuse2 102 205 0 chartreuse3 69 139 0 chartreuse4 192 255 62 OliveDrab1 179 238 58 OliveDrab2 154 205 50 OliveDrab3 105 139 34 OliveDrab4 202 255 112 DarkOliveGreen1 188 238 104 DarkOliveGreen2 162 205 90 DarkOliveGreen3 110 139 61 DarkOliveGreen4 255 246 143 khaki1 238 230 133 khaki2 205 198 115 khaki3 139 134 78 khaki4 255 236 139 LightGoldenrod1 238 220 130 LightGoldenrod2 205 190 112 LightGoldenrod3 139 129 76 LightGoldenrod4 255 255 224 LightYellow1 238 238 209 LightYellow2 205 205 180 LightYellow3 139 139 122 LightYellow4 255 255 0 yellow1 238 238 0 yellow2 205 205 0 yellow3 139 139 0 yellow4 255 215 0 gold1 238 201 0 gold2 205 173 0 gold3 139 117 0 gold4 255 193 37 goldenrod1 238 180 34 goldenrod2 205 155 29 goldenrod3 139 105 20 goldenrod4 255 185 15 DarkGoldenrod1 238 173 14 DarkGoldenrod2 205 149 12 DarkGoldenrod3 139 101 8 DarkGoldenrod4 255 193 193 RosyBrown1 238 180 180 RosyBrown2 205 155 155 RosyBrown3 139 105 105 RosyBrown4 255 106 106 IndianRed1 238 99 99 IndianRed2 205 85 85 IndianRed3 139 58 58 IndianRed4 255 130 71 sienna1 238 121 66 sienna2 205 104 57 sienna3 139 71 38 sienna4 255 211 155 burlywood1 238 197 145 burlywood2 205 170 125 burlywood3 139 115 85 burlywood4 255 231 186 wheat1 238 216 174 wheat2 205 186 150 wheat3 139 126 102 wheat4 255 165 79 tan1 238 154 73 tan2 205 133 63 tan3 139 90 43 tan4 255 127 36 chocolate1 238 118 33 chocolate2 205 102 29 chocolate3 139 69 19 chocolate4 255 48 48 firebrick1 238 44 44 firebrick2 205 38 38 firebrick3 139 26 26 firebrick4 255 64 64 brown1 238 59 59 brown2 205 51 51 brown3 139 35 35 brown4 255 140 105 salmon1 238 130 98 salmon2 205 112 84 salmon3 139 76 57 salmon4 255 160 122 LightSalmon1 238 149 114 LightSalmon2 205 129 98 LightSalmon3 139 87 66 LightSalmon4 255 165 0 orange1 238 154 0 orange2 205 133 0 orange3 139 90 0 orange4 255 127 0 DarkOrange1 238 118 0 DarkOrange2 205 102 0 DarkOrange3 139 69 0 DarkOrange4 255 114 86 coral1 238 106 80 coral2 205 91 69 coral3 139 62 47 coral4 255 99 71 tomato1 238 92 66 tomato2 205 79 57 tomato3 139 54 38 tomato4 255 69 0 OrangeRed1 238 64 0 OrangeRed2 205 55 0 OrangeRed3 139 37 0 OrangeRed4 255 0 0 red1 238 0 0 red2 205 0 0 red3 139 0 0 red4 255 20 147 DeepPink1 238 18 137 DeepPink2 205 16 118 DeepPink3 139 10 80 DeepPink4 255 110 180 HotPink1 238 106 167 HotPink2 205 96 144 HotPink3 139 58 98 HotPink4 255 181 197 pink1 238 169 184 pink2 205 145 158 pink3 139 99 108 pink4 255 174 185 LightPink1 238 162 173 LightPink2 205 140 149 LightPink3 139 95 101 LightPink4 255 130 171 PaleVioletRed1 238 121 159 PaleVioletRed2 205 104 137 PaleVioletRed3 139 71 93 PaleVioletRed4 255 52 179 maroon1 238 48 167 maroon2 205 41 144 maroon3 139 28 98 maroon4 255 62 150 VioletRed1 238 58 140 VioletRed2 205 50 120 VioletRed3 139 34 82 VioletRed4 255 0 255 magenta1 238 0 238 magenta2 205 0 205 magenta3 139 0 139 magenta4 255 131 250 orchid1 238 122 233 orchid2 205 105 201 orchid3 139 71 137 orchid4 255 187 255 plum1 238 174 238 plum2 205 150 205 plum3 139 102 139 plum4 224 102 255 MediumOrchid1 209 95 238 MediumOrchid2 180 82 205 MediumOrchid3 122 55 139 MediumOrchid4 191 62 255 DarkOrchid1 178 58 238 DarkOrchid2 154 50 205 DarkOrchid3 104 34 139 DarkOrchid4 155 48 255 purple1 145 44 238 purple2 125 38 205 purple3 85 26 139 purple4 171 130 255 MediumPurple1 159 121 238 MediumPurple2 137 104 205 MediumPurple3 93 71 139 MediumPurple4 255 225 255 thistle1 238 210 238 thistle2 205 181 205 thistle3 139 123 139 thistle4 0 0 0 gray0 0 0 0 grey0 3 3 3 gray1 3 3 3 grey1 5 5 5 gray2 5 5 5 grey2 8 8 8 gray3 8 8 8 grey3 10 10 10 gray4 10 10 10 grey4 13 13 13 gray5 13 13 13 grey5 15 15 15 gray6 15 15 15 grey6 18 18 18 gray7 18 18 18 grey7 20 20 20 gray8 20 20 20 grey8 23 23 23 gray9 23 23 23 grey9 26 26 26 gray10 26 26 26 grey10 28 28 28 gray11 28 28 28 grey11 31 31 31 gray12 31 31 31 grey12 33 33 33 gray13 33 33 33 grey13 36 36 36 gray14 36 36 36 grey14 38 38 38 gray15 38 38 38 grey15 41 41 41 gray16 41 41 41 grey16 43 43 43 gray17 43 43 43 grey17 46 46 46 gray18 46 46 46 grey18 48 48 48 gray19 48 48 48 grey19 51 51 51 gray20 51 51 51 grey20 54 54 54 gray21 54 54 54 grey21 56 56 56 gray22 56 56 56 grey22 59 59 59 gray23 59 59 59 grey23 61 61 61 gray24 61 61 61 grey24 64 64 64 gray25 64 64 64 grey25 66 66 66 gray26 66 66 66 grey26 69 69 69 gray27 69 69 69 grey27 71 71 71 gray28 71 71 71 grey28 74 74 74 gray29 74 74 74 grey29 77 77 77 gray30 77 77 77 grey30 79 79 79 gray31 79 79 79 grey31 82 82 82 gray32 82 82 82 grey32 84 84 84 gray33 84 84 84 grey33 87 87 87 gray34 87 87 87 grey34 89 89 89 gray35 89 89 89 grey35 92 92 92 gray36 92 92 92 grey36 94 94 94 gray37 94 94 94 grey37 97 97 97 gray38 97 97 97 grey38 99 99 99 gray39 99 99 99 grey39 102 102 102 gray40 102 102 102 grey40 105 105 105 gray41 105 105 105 grey41 107 107 107 gray42 107 107 107 grey42 110 110 110 gray43 110 110 110 grey43 112 112 112 gray44 112 112 112 grey44 115 115 115 gray45 115 115 115 grey45 117 117 117 gray46 117 117 117 grey46 120 120 120 gray47 120 120 120 grey47 122 122 122 gray48 122 122 122 grey48 125 125 125 gray49 125 125 125 grey49 127 127 127 gray50 127 127 127 grey50 130 130 130 gray51 130 130 130 grey51 133 133 133 gray52 133 133 133 grey52 135 135 135 gray53 135 135 135 grey53 138 138 138 gray54 138 138 138 grey54 140 140 140 gray55 140 140 140 grey55 143 143 143 gray56 143 143 143 grey56 145 145 145 gray57 145 145 145 grey57 148 148 148 gray58 148 148 148 grey58 150 150 150 gray59 150 150 150 grey59 153 153 153 gray60 153 153 153 grey60 156 156 156 gray61 156 156 156 grey61 158 158 158 gray62 158 158 158 grey62 161 161 161 gray63 161 161 161 grey63 163 163 163 gray64 163 163 163 grey64 166 166 166 gray65 166 166 166 grey65 168 168 168 gray66 168 168 168 grey66 171 171 171 gray67 171 171 171 grey67 173 173 173 gray68 173 173 173 grey68 176 176 176 gray69 176 176 176 grey69 179 179 179 gray70 179 179 179 grey70 181 181 181 gray71 181 181 181 grey71 184 184 184 gray72 184 184 184 grey72 186 186 186 gray73 186 186 186 grey73 189 189 189 gray74 189 189 189 grey74 191 191 191 gray75 191 191 191 grey75 194 194 194 gray76 194 194 194 grey76 196 196 196 gray77 196 196 196 grey77 199 199 199 gray78 199 199 199 grey78 201 201 201 gray79 201 201 201 grey79 204 204 204 gray80 204 204 204 grey80 207 207 207 gray81 207 207 207 grey81 209 209 209 gray82 209 209 209 grey82 212 212 212 gray83 212 212 212 grey83 214 214 214 gray84 214 214 214 grey84 217 217 217 gray85 217 217 217 grey85 219 219 219 gray86 219 219 219 grey86 222 222 222 gray87 222 222 222 grey87 224 224 224 gray88 224 224 224 grey88 227 227 227 gray89 227 227 227 grey89 229 229 229 gray90 229 229 229 grey90 232 232 232 gray91 232 232 232 grey91 235 235 235 gray92 235 235 235 grey92 237 237 237 gray93 237 237 237 grey93 240 240 240 gray94 240 240 240 grey94 242 242 242 gray95 242 242 242 grey95 245 245 245 gray96 245 245 245 grey96 247 247 247 gray97 247 247 247 grey97 250 250 250 gray98 250 250 250 grey98 252 252 252 gray99 252 252 252 grey99 255 255 255 gray100 255 255 255 grey100
John found another bug today: If you change the view parameters from frame to frame, RT gives the wrong results (i.e. the wrong view), while MGED was correct.
What was happening was that since you can either set the width/height (via -n -w; or set width=xxx) or the cell_width/cell_height (via -g -G; or; opt -g -G), RT was checking for a zero value in one of these pairs (to see which the user set), and computing the OTHER pair based on the ones given. If neither was zero, it did nothing (assuming it has already been computed - which it was). However, in an animation, if you change the viewsize, or any of the above named parameters, these values need to be recomputed. This wasn't happening.
I added a cell_newsize flag to indicate when a new -g or -G was given, and then ALWAYS do the grid computation code, choosing the version based on cell_newsize. Changes are checked into rt/ext.h, opt.c, worker.c.
- Phil
I have just installed BRL-CAD 4.1 on an SGI SKYWRITER (two graphics heads) running 4.0.5(A). The software was built to run in /data3/brlcad..... When I run MGED, useing one of the sample databases, the MGED window comes up, but no buttons show up on the left had side of the screen. When I issue the B command to draw the database, the figure flashes on the screen for about 1 scan then the contents of the window goes black. The same for left/center/right button - the figure appears for about 1 scan and then the window contents goes to black again. Any suggestions as to the cause/cure???
Michael N. LeVine Naval Air Weapons Station, China Lake, Ca 93555, USA Internet: levine@fidler.chinalake.navy.mil (619) 939-2614 avn 437-2614
"Waiter, there's a bug in my soup!" "No, Sir, it's not a bug, it's a feature!"
> I have just installed BRL-CAD 4.1 on an SGI SKYWRITER ... > When I issue the B command to draw the database, the figure >flashes on the screen for about 1 scan then the contents of the window >goes black. The same for left/center/right button - the figure >appears for about 1 scan and then the window contents goes to black >again. > Any suggestions as to the cause/cure???
The place to look is in "mged/dm-4d.c". The problem may have to do with the SKYWRITER's implementation of double/single buffered modes. Since I don't have one of these displays, I'm afraid I can't help much more than that.
Lee A. Butler Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: butler@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-9200
I thought that I had announced the availability of "xpa", but perhaps I never got around to it.
This is an official warning that the products and moments of inertia calculation has not undergone extensive validation. If someone has an alternative means for checking the numbers for some fairly complicated geometries, I would appreciate if they would report their findings back to me. I did check it against simple test cases for which the answer could be easily computed by hand.
----- Forwarded message # 1:
Date: Wed, 7 Apr 93 7:46:23 EDT From: Gary S. Moss (VLD/VMB) <moss@BRL> To: Carl Moore <cmoore@brl.mil> cc: moss@BRL.MIL Subject: Re: xpa utility Message-ID: <9304070746.aa03396@WORM.BRL.MIL>
# I am hearing of an "xpa" utility which can be used for cross-section area, # etc., from someone in the former TBD. Is there any documentation around for # it, as I had not heard of it before.
Carl, Xpa computes presented area, not cross-sectional area. It also computes volume, mass, centroids, moments and products of inertia.
Assuming you have /usr/X11/man in your MANPATH, you should be able to type "man xpa" to get the documentation on it. It is installed on the SGIs and Suns that have the X11 and vld software rdist distributions.
-Gary
----- End of forwarded messages
Haah,
I'm running BRLCAD on an SGI with remote output to a color Sun running X11R4. MGED runs ok (except for some ugly color choices) and the fb commands I tried (rle-fb and cell-fb) run correctly. I manually started fbserv on the Sun like this:
vacation> fbserv -S 1024 0 /dev/X
with these variables set on the SGI:
DISPLAY=vacation.brl.mil:0.0 FB_FILE=vacation.brl.mil:0
Running rle-fb on an existing RLE file displays the proper image (I'm using cell-fb output and the spectrum at the bottom looks correct). The framebuffer window is using a private colormap. However, if I run fb-rle the new RLE file is always grayscale. I ran rlehdr on the original and new files and got identical results, altho the new files are about one half the size of the originals. I played around with the '-c' option and it didn't make any visual difference.
The problem with rt is more serious. If I run rt from within MGED or directly from the command line it *seems* to work but I never get an image in the framebuffer.
I grep'd on X11 in the BRLCAD man tree and only 4 files even metioned X11 -- mged (reminding people to define DISPLAY), pl-X (display UnixPlot in an X11 window), urt (getx11 program), and libfb (use -lX11 when linking X programs). There's nothing about defining FB_FILE to point to an X11 client, nor is there an fbserv man page.
Now that SGI has switched to X11, is there going to be a greater emphasis on X11 support in BRLCAD? People have been writing to this list saying they can run BRLCAD on their Suns under OpenWindows and other X-ish things, but distributed SGI->Sun support is weak.
dsw, fferd <fsbrn@brl.mil>
Ferd,
Remember "fbhelp", it will show you frame buffer options. Try /dev/Xm. The "m" means that it allocates a 24-bit memory buffer to hold the image info, even if the display has e.g. only 1-bit. This way pixel readback (such as fb-pix) will get the right values, otherwise the best you can do is read the scant bitplanes from the X server. [You might have found a real bug, but this may work around it.]
The other way to get 24-bit readback is to use /dev/mem. On the SGI, you could do:
fbserv -S1024 0 "/dev/mem vacation:0" & FB_FILE=0
[possibly with 'r' (pre-read), and/or 'w' (write-through) option on /dev/mem] What this will do is to make a pseudo 24-bit frame buffer on the SGI in memory, do all libfb operations there, and when an application exits (or closes the frame buffer) the image will be flushed to any attached frame buffers (in this case vacation:0). Doing this also means that readbacks will be far faster, since they now come from your SGI memory, rather than the Sun.
Yes, fbserv, /dev/mem, /dev/X, mged dm-X, aren't well documented. Point noted. I have a small tutorial somewhere on using fbserv. I'll see if I can find it and send it to the list.
About X support in MGED, little known features: In the drawing window, certain keystrokes do things for you. 0 zero "knobs" (translates and rotates) x, y, z translate X, Y, Z rotate f, t, b, l, r, R, 3, 4 preset-views (front, top, ...)
| Now that SGI has switched to X11, is there going to be a greater | emphasis on X11 support in BRLCAD?
On an SGI, GL still beats the pants off of X as the prefered way to do graphics. However, to do GUI's, X is the thing to do. There is a much much better MGED X driver in the works (which will also drive GL windows). Expect to see it this Summer.
- Phil
Combinations, Groups, and Regions
New users of MGED are often confused over the differences and relationships between "combinations", "regions", and "groups". The latter two are special cases of a combination. A lot of the confusion in the documentation results from the history by which we got to the present system. Here is a "modern" way of looking at the three(*).
The fundamental command for building combinations of objects is:
comb name <op1 member1> [<op2 member2> ...]
Where the members are either other combinations or primitives (single solids). The first <op> is meaningless. Many people use union (u), but some argue that intersect (+) should be used. [To distinguish this from a group perhaps?? I've never understood their reasoning.]
If all of the operations are unions, there is a shorthand version of the above to make what is called a "group" (a combination of all unions):
g name <member1> [<member2> ...]
The result of this command is *exactly* the same as having made a combination (comb) with all union (u) operations. I.e.
comb name <u member1> <u member2> ...
Finally, any combination can have a "bit" set (i.e. have a property of any combination enabled) that makes that combination what is known as a "region". The idea of a region is that it consists of one solid piece of material. That is, however it was constructed in the editor, by combining any number of levels of primitive solids and combinations together, this finally result is one identifiable piece (e.g. a machined part perhaps). A combination so identified as a region can have various properties associated with it: its color, the type of material it is made out of, a "region id", etc. There is a special form of the combination (comb) command that makes a combination with this region property set:
r name <op1 member1> [<op2 member2> ...]
An existing region or combination (where "combination" is used here to refer to a non-region, even though technically a region is still a combination) can have this "bit" turned on or off via:
edcomb name regionflag [regionid air los GIFTmater]
Other ways of editing regions include:
item name item# [air] to change the region_id and mater name [material] to change the material
[regdef item [air] [los] [GIFTmaterial] - sets defaults for next "r" cmd]
Speaking of historical confusion, note that the following names all refer to the SAME single value!:
"region id", "region ident", "ident", "ident code", "item number", "item".
In my note about Combinations, Groups, and Regions, I had said in the footnote:
| You used to be able to be fast-and-loose about having regions that | contain regions, so everything could be built with "r". When | the ray tracer became more precise about not allowing two physical | pieces of material to occupy the same space (overlapping regions), | it became important to have combination nodes that did NOT have | the region property turned on, and could thus be freely used as | members in other combinations.
Mike Muuss corrected me here. I remembered "comb" being added, in part when I complained "If you can't have regions within regions, how are you supposed to make a non-region combination?" My reasons for why it didn't used to be there were wrong however. Here is a better footnote:
(*) Why I call it modern, is that for quite some time only the "r" and "g" commands existed. "comb" was added much later, yet in this author's opinion, is the most fundamental of the three. VDECK and GIFT (the predecessor to RT) did not support things such as regions within regions, booleans above regions, and non-unions below regions. Therefore MGED did not have support for them. Adding "comb" to MGED generalized and increased MGED's expressive power, but it also allowed a diversion from GIFT compatible databases.
I am having a problem with the mouse in mged installed on an HP9000 Model 750 HP-UX 8.05 attached to X. I must hit return at the mged> in the command window to get it to accept my mouse clicks.
Kevin Farrar E-mail: kfarrar@mbvlab.wpafb.af.mil Sverdrup Technology Voice: (513)255-1115
Chances are that select() is not working correctly. Look in "libsysv/bsdselect.c". If you are falling into the generic System V code that does a "return(32-1)", you will see the problem you described. You need to see if your HP supports a real select system call and enable it by changing the ifdef's in that module.
- Phil
As far as I know you are not missing anything with reguards to mged. The 'big e' command has never worked (to the best of my knowledge) on a torus (or an ars). The error below is the normal reaction to 'big eing' a torus (or an ars). I don't know anything about the same error with rt. My experience with tori and rt is that everything seems to work.
Susan Coates
----- Forwarded message # 1:
Received: from WALRUS.BRL.MIL by WALRUS.BRL.MIL id aa21299; 22 Apr 93 10:18 EDT Received: from wharf.brl.mil by WALRUS.BRL.MIL id aa21076; 22 Apr 93 10:10 EDT Received: from swrinde.nde.swri.edu by WHARF.BRL.MIL id aa25089; 22 Apr 93 10:04 EDT Received: by swrinde.nde.swri.edu (5.64swri/1.34) id AA15798; Thu, 22 Apr 93 09:03:53 -0500 From: "Joseph W. Brophy" <jwb@swrinde.nde.swri.edu> Message-Id: <9304221403.AA15798@swrinde.nde.swri.edu> Subject: Error messages from MGED To: cad@BRL.MIL Date: Thu, 22 Apr 1993 09:03:53 -0500 (CDT) X-Mailer: ELM [version 2.4 PL3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 720
Forwarded message: We have run into the following error situation with MGED, attempts to use torus in combination with other primitives gives the folowing error with 'Big E' (and RT as well) > mged> E test04 > > proc_reg: Cannot draw solid type 16 (TOR) > Error in converting solid test04 to ARBN > E: 0 vectors in 0 sec > > > mged> tree test04 > > > test04/R > u torus2 > + cyl3 > > The problem is the inability to edit the "tor" solid or > a solid to be edited by a "tor" and disply the results > with "E" > > -tony > Is there a patch for MGED, or are we missing something fundamental about MGED's operation?
We are using a Sun Sparc workstation with XGL and SunOS 4.1.3.
JWBrophy@swrinde
----- End of forwarded messages
I have completed the coding of a BRLCAD-to-IGES translator (g-iges). The code has two mutually exclusive options (plus a few others):
-f for facets (each region is converted to NMG's prior to output in IGES format).
-c for CSG (each object is output in IGES format unless there is no corresponding IGES entity, in which case it is converted to NMG's and then output).
The -f option is essentially Markowski's g-jack converter with different output and some additions. This option is dependent on the successful implementation of NMG booleans. One major issue with this option is that IGES expects BREP objects to consist of one or more outer shells with zero or more inner void shells, while BRLCAD combines all of this into a single shell. This issue is being shelved until we know for sure whether BRLCAD will use the IGES version of shells.
The -c option has been exercised on two real models - the MH60 and MH47 helicopters. The 3.8 Mb mh47.g file produces a 39 Mb, 484,000 line IGES file with all the ARS solids, 65% of the ARB's and 10% of the TGC's converted to NMG's. Everything else is written to the IGES file without conversion. The 4.5 Mb mh60k.g file produced a 59 Mb, 735,000 line IGES file with similar statistics. There are a few issues here:
1. What to do with solids that are not in IGES and are not tessellated (like the half-space solid).
2. IGES cannot handle an object that is scaled. If a scaled object that has not been "pushed" is encountered, it is translated to IGES without the scale factor and the user is warned.
3. I have not implemented the IGES right angle wedge (RAW) solid. This is just a matter of whether it's worth the effort of developing code to recognize if a BRLCAD arb meets the criteria to be an IGES RAW.
Issue #1 was not encountered in either of the two models converted. Issue #2 was encountered in one region and safely handled by a "push" command in MGED and then re-running g-iges.
Both options produce an IGES file that includes object names (using the IGES "name" entity), colors (using the IGES color entity), and region flag, region id, air code, GIFT material code, los, material name, and material parameters are included using the IGES attribute entities. The attribute entity sort of a free for all entity to assign any attributes to any IGES object. No other IGES translator will understand my attribute entity unless they code my conventions into their translator.
Obviously, the only verification I have done on this is visual inspection of the output files. Given the size of the files, the possibility of overlooking a bug is not insignificant. I propose upgrading the existing iges-g translator to the same level as the new g-iges and using them to help debug each other. This would also give me a chance to become familiar with the nmg "make" routines.
-John
For those of you fans of VDECK, it was reported today that VDECK will not compile on an SGI R4000 Indigo machine. In the Release 4.1 sources this can be worked around by removing line 162, which states:
int sortFunc RT_ARGS((const void * a, const void *b));
In the Release 4.0 sources (which probably won't work on an Indigo anyway), remove line 137, which states:
static int sortFunc RT_ARGS((const void *a, const void *b));
Best, -Mike
Ali writes:
> Also, I am trying to get BRL-CAD to work on a Sun > Sparcstation with SunOS 4.1.2 (and 4.1.3), under OpenWindows (not > SunView). I was wondering if anybody else had done this... >
I have compiled BRLCAD under OpenWindows some time ago. As I recall, the only changes I had to make were in the "Cakefile.defs" file. There is a section in that file for Sparcstations (look for "#if defined(sparc)"). The default is labelled with a comment: /* Bare Sun configuration */ You can switch to the OpenWindows support by changing the "if 1" for the bare sun configuration to an "if 0". This will enable the section labelled: /* Sun with X11 (aka "openwin"). Default for SunOS 4.1.1 */
Hope this helps,
-John
John R. Anderson Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: jra@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-7267
You know, you *are* allowed to edit the Cakefile.defs entries, if they don't suit your particular configuration. I've tried to provide a variety of useful selections via the #if mechanism, but once you have the baseline package working, if you want to make modifications, do feel free to do so! One of the benefits (and responsibilities) of getting software in source code form.
Best, -Mike
Hi, I'm interested in adding concurrent multi-user capability to MGED. I wanted to know if anybody had tried this, or if anybody had any tips on how I might go about it. I'm somewhat familiar with designing multi-user programs, but I am not familiar with mged yet. Any suggestions, warnings, etc would be greatly appreciated...
thanks,
-=> Ali
The new MGED user interface allows multiple X servers to be used to display geometry. The alternate displays are even mouse input sensitive. We have discussed the issue of whether or not to allow complete editing capability from every display, and issues such as whether or not to warp the mouse on one display as it is moved on another.
I personally don't see much utility in making it multi-user beyond seeing the output on multiple desktops and being able to interactively point out objects/actions to others. But I'm open to ideas. How would you use a multi-user geometric editor? In something other than a demonstration/teaching mode? How would you handle control, e.g. would all mouse clicks and key presses apply to every display in a first-come/first-serve fashion?
- Phil
Phil,
> The new MGED user interface allows multiple X servers to be used > to display geometry. The alternate displays are even mouse input > sensitive. We have discussed the issue of whether or not to allow > complete editing capability from every display, and issues such as > whether or not to warp the mouse on one display as it is moved on > another.
where could I get this new MGED UI? Sounds *very* much like what I'd want...
> I personally don't see much utility in making it multi-user beyond > seeing the output on multiple desktops and being able to interactively > point out objects/actions to others. But I'm open to ideas. How > would you use a multi-user geometric editor? In something other > than a demonstration/teaching mode? How would you handle control, > e.g. would all mouse clicks and key presses apply to every display > in a first-come/first-serve fashion?
well, that question has many long answers. The basic idea is collaborative design. That's my current area of research. There is alot of work being done in collaborative/multi-user programs, and there are several ways in which you can handle control. One solution is to do it the way it would be done in a meeting with a whiteboard. have one "pen" and allow only one person to edit at a time. Another way, (which, in my opinion is the way it should be done) is to allow people to have their own views of the 3D database, and allow them all to edit at the same time, but allow for "selection" of objects, and when somebody has something selected, nobody else can modify it. It would also be good to have a local instance running as well, which would allow users to work on a small part of the design outside of the main database, and then add it in when they want to show it to people. Of course, it would be very important for the designers to also be speaking to eachother to prevent problems. A masters student at MIT named Li Shu did a good piece of work on collaborative cad and had a paper in CSCW'92...
hope that answers part of your question...
-=> Ali
I just talked to Bill Seyfert regarding the Intergraph/BRLCAD translator that TACOM and FSTC sponsored. He gave me a brief description of the status:
The translators were written for Intergraph version 1.4 and BRLCAD version 3.7. Translation to BRLCAD converts about a half dozen equivalent solids directly to BRLCAD and the remainder are facetized and converted as polysolids. The translators are now being upgraded to Intergraph version 2.1 and BRLCAD version 4.0, and that effort is nearly finished. The current software runs only on an Intergraph workstation, but Mr. Seyfert is procuring Intergraph software that will run on an SGI, and then intends to port the translators to the SGI platform. Translation to Intergraph is also possible. For a successful translation to BRLCAD, the Intergraph user must follow some simple rules in the construction of the Intergraph model. For example, the user must build a solid model (not just surfaces hanging in space), and the user must utilize Intergraphs layer capability to create groups with names in the resulting brlcad model.
-John
John R. Anderson Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: jra@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-7267
Ali writes -
> I'm interested in adding concurrent multi-user capability > to MGED.
and Phil responded with some information about his new X interface to MGED.
I have taken another approach in my team's "Virtual Reality for CAD" project -- we support an arbitrary number of copies of MGED running, and coordinate them via a program called VRMGR (Virtual Reality Manager). This permits multiple people to wander within a single database, some using regular displays, some using stereo-capable workstations, some using a workstation pair driving an HMD, and some using an arbitrary number of workstations driving a "cave" display surface. Any combination is possible, and "overview" display stations can also be instantiated, to see how the users are moving through the virtual space.
Each MGED user has control over his own point of view, and can see the other users as a simple wireframe "eye" token.
A prototype of this much is more-or-less working now, the real issues of how to do distributed *editing* (rather than just viewing) remain to be tackled. Much of the infrastructure for that is already in place, but there are some key issues in interface design and in MGED internals that still need some work.
This is a low-priority project at the moment, but because it's fun it gets continuing attention, and I have some big plans for this effort, including integrating audio.
Naturally, a VR capability is most fun if you have polygons to render, which makes the "VR for CAD" project take a distinct second seat to the "finishing NMG Booleans" project....
There is a lot more that I could say about "VR for CAD". I hope that I've tantalized you a bit already!
Best, -Mike
Thanks for your help on compiling brl-cad on my sun sparcstation under openwindows. I modified the Cakefile.defs a slight bit to compile under the "Sun with X11 only" option, but I still have problems. mged works fine, except that it flickers horribly when rotating, zooming, etc. Is it true that it does not do double buffering because it's running under X? The main problem, however, is that rt doesn't work in mged. It just messes up the screen alot and leaves the screen in black and white mode when it stops. Then if I re-attach X (or type fix), everything goes back to normal, except that I have lots of debree left on the screen where rt popped up a "window".
I've included the part of the Cakefile.defs file that I think is relevant...
thanks,
-=> Ali
#if defined(sparc) /* Sun-4 "SparcStation" hardware */ # undef sun # undef sun4 # define MTYPE sun4 # define BSD 43 # define HAS_TCP 1 # define OPTIMIZER -O2 /*# define CC_DEFS -DAUTOSPEC /* What does this do? */ # define LIBMALLOC /* use vendor library */ # define LIBRT_TIMER timer42 # if 0 /* Bare Sun configuration */ # define LIBFB_OBJS if_remote if_sun # define LIBFB_CONFIG -DIF_REMOTE -DIF_SUN # define LIBFB_LIBES LIBPKG -lsuntool -lsunwindow -lpixrect # define LIBRT_TIMER timer42 # define MGED_OBJS dm-sun # define MGED_CONFIG -DDM_SUNPW # define MGED_LIBES -lsuntool -lsunwindow -lpixrect # else /* Sun with X11 (aka "openwin"). Default for SunOS 4.1.1 */ # define LIBFB_OBJS if_remote if_ab if_X if_sun # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB -DIF_SUN \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG -lsunwindow -lpixrect -lsuntool\ -L/usr/openwin/lib -lX11 # if 1 /* Sun with X11 only */ # define MGED_OBJS dm-sun dm-X # define MGED_CONFIG -DDM_SUNPW -DDM_X -I/usr/openwin/include # define MGED_LIBES -lsuntool -lsunwindow -lpixrect \ -L/usr/openwin/lib -lX11 # else /* Sun with X11 and XGL (an unbundled product) */ /* Note that at MSIC, -lgks may also be needed */ # define MGED_OBJS dm-xgl dm-X # define MGED_CONFIG -DDM_XGL -DDM_X -I/usr/openwin/include # define MGED_LIBES -lxgl -L/usr/openwin/lib -lX11 # endif # endif # if 0 /* "Unbundled" (i.e. "improved") compilers. Use if you have them */ # define CC /usr/lang/cc # define FC /usr/lang/f77 # endif #endif
> The main problem, however, is that rt doesn't work in mged. It > just messes up the screen alot and leaves the screen in black and > white mode when it stops. Then if I re-attach X (or type fix), > everything goes back to normal, except that I have lots of debree > left on the screen where rt popped up a "window".
Sounds like you are using the raw Sun "pixrect" interface (/dev/sun), rather than the X11 interface to the framebuffer. You can verify that this is in fact the case by running "fbhelp" from the shell once, and examining the lower half of it's output (after the "=== Current Selection ===") message.
> I've included the part of the Cakefile.defs file that I think is > relevant...
This was very helpful. Thanks! Where you said:
/* Sun with X11 (aka "openwin"). Default for SunOS 4.1.1 */ # define LIBFB_OBJS if_remote if_ab if_X if_sun # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB -DIF_SUN \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG -lsunwindow -lpixrect -lsuntool\ -L/usr/openwin/lib -lX11
remove the if_sun, -DIF_SUN stuff, so that it now looks like this:
/* Sun with X11 (aka "openwin"). Default for SunOS 4.1.1 */ # define LIBFB_OBJS if_remote if_ab if_X # define LIBFB_CONFIG -DIF_REMOTE -DIF_AB \ -I/usr/openwin/include -DIF_X # define LIBFB_LIBES LIBPKG \ -L/usr/openwin/lib -lX11
This will prevent you from accidentally getting the SunTools interface by default.
Alternatively (requiring no recompilation), remember to set your environment variable FB_FILE before starting up MGED or other BRL-CAD tools.
csh: setenv FB_FILE /dev/X sh: FB_FILE=/dev/X; export FB_FILE
I hope this helps.
Best, -Mike
Ali,
> Thanks for your help on compiling brl-cad on my sun sparcstation > under openwindows. I modified the Cakefile.defs a slight bit to > compile under the "Sun with X11 only" option, but I still have > problems. mged works fine, except that it flickers horribly when > rotating, zooming, etc. Is it true that it does not do double > buffering because it's running under X?
I believe that is just a characteristic of graphics under X.
> The main problem, however, is that rt doesn't work in mged. It > just messes up the screen alot and leaves the screen in black and > white mode when it stops. Then if I re-attach X (or type fix), > everything goes back to normal, except that I have lots of debree > left on the screen where rt popped up a "window".
Try setting your framebuffer to X. If you are using the Bourne shell do: FB_FILE=/dev/Xl export FB_FILE Or, if you use a csh do: setenv FB_FILE /dev/Xl
Also, try the "fbhelp" command for more info.
-John
John R. Anderson Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: jra@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-7267
I suspect that what Andre was really asking for was a pointer to the examples on how to use MGED.
In Vol IV (MGED User's Manual), try looking at chapters 13 and 14, then refer back to earlier chapters in that manual for details.
Best, -Mike
> Since I haven't been receiving *any* responses to my questions, this > will be the last time I will post a general mailing to cad@brl.mil.
Well, I answered at least one of your earlier messages, at least to say that you were welcome to ask away, and that the developers really could not commit to answering such detailed questions with any kind of promptness -- we have quite a few other things going on right now, and being only 4, can't invest too much time providing help to folks who obtained "no support" distributions.... I regret that we can't offer more help, but we can't. If we provided each of our 800 user sites even a few hours of help, we wouldn't have any time left for our own projects. I hope you can appreciate our limitation.
You are engaged in a difficult task (multi-user geometry editing). There are many different strategies that you might adopt for implementing this within MGED. You have not made it entirely clear what strategy you are considering, which makes it hard to provide concise suggestions.
> I also understand (I think) how the dbase works and when it is > accessed.
This is one of the main benefits that you obtain from having the source code -- you can study the code and figure things out for yourself. I'm glad it is yeilding some of it's secrets to you, already. :-)
> However, I am still in desperate need of getting in touch with > someone who "understands" how the actual memory management works and > perhaps why it was designed in certain ways in certain places...
I designed all the memory management; if you have a specific question that has a brief answer, I'll try to reply.
Much of the memory management code is more than 10 years old, and was designed to run on PDP-11 processors with limited address space. Thus, the notion of "database granules" (128 bytes each) which can be processed one at a time. This mode of operating is no longer necessary, but not all the code has been converted yet. So, you will see both the "old way" db_get()/db_put() usage, as well as the "new way" usage of db_get_external()/db_put_external() to move 'objects' between memory and the ".g" database file.
Best, -Mike
Yes, I do realize that it would require major redesign, but I was hoping somebody had done it. Actually, I was right! Unfortunately, the price is not right...
-=> Ali
p.s. I don't really need it anymore, so I didn't reply to him...
------- Forwarded Message
Return-Path: olasov@cs.columbia.edu Received: from cs.columbia.edu by archsci.arch.su.EDU.AU (5.61+/5.17) id AA21686; Mon, 19 Jul 1993 08:58:26 +1000 Received: from ground.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad+jtt) with SMTP id AA21871; Sun, 18 Jul 1993 18:58:19 -0400 Received: by ground.cs.columbia.edu id AA03805 (5.65c/IDA-1.4.4.5/jba/jtt/ad for ali@archsci.arch.su.edu.au); Sun, 18 Jul 1993 18:58:13 -0400 Date: Sun, 18 Jul 1993 18:58:13 -0400 From: Benjamin Olasov <olasov@cs.columbia.edu> Message-Id: <199307182258.AA03805@ground.cs.columbia.edu> To: ali@archsci.arch.su.edu.au Subject: converting Autocad files to .asc files (from BRL-CAD)
My consulting company has an AutoCad -> BRL translator (.dwg -> .asc) which it sells commercially. The price is $500 US.
Ben
------- End of Forwarded Message
> In other words, how can I do something to the effect of "e > /tank/fuel" instead of either "e tank" or "e fuel" (which would > ignore matrices higher up in the tree)?
Ah, an easy one! How about just doing "e tank/fuel" (or whatever the partial path spec is). That works. Or, better still, see my remarks below.
> An even shorter short-ish mged hacking question: > from within db_put(), how can I find the complete pathname > of the solid being "put"?
You can't do it, that far down in the library. Best you can do is to get the name of the object being written (dp->d_namep). In any case, this is what you actually need, because you should then go and search the MGED solid table for all objects on the screen that refer to this database item, and redraw those "involved" solids. There is handy support for this operation in the form of subroutine replot_modified_solid() in file mged/dodraw.c
Best, -Mike
Ali writes -
> Let's try a yes/no version of the question: when db_put stores s214, > from accepting changes on /tank/computer/r213/s214, does that mean that > all references to s214 are changed?
Alas, he didn't succeed in making it yes/no. Grin!
There are two kinds of editing in MGED: "solid edit", which transforms the parameters of a *leaf* node (solid) in the tree, and "object edit", which modifies the 4x4 transformation matrix stored along one *arc* of the tree.
So, if you did a solid edit on "s214", all instances of that solid would change. If you did an object edit on "/tank/computer/r213/s214" and replaced the matrix at the arc "r213/s214", then only that instance would change.
At present there is no way to specify changing an leaf-node's paramter(s) in an object edit. Instancing is primarily used for repeating many copies of identical parts. Some modelers (e.g. Harry Reed & crew) tend to avoid instances, while others (e.g. Jim Hunt & crew) couldn't live without them.
I agree that the instancing capability could be more flexible, but that leads the discussion in the direction of a non-global name space or an 'interpreted' database, neither of which are 'minor' changes to the design of the system. As it stands now, these lacks don't seem to be a serious hindrance, so this is not a 'hot topic', although we do kick it around from time to time.
Best, -Mike
I noticed the comments on instancing. I have had cases where I "inherited" instancing in a description, and I started getting annoyed when I tried to display a low-level solid and it did not appear where I thought, due to my missing a transformation at a higher level in the tree. Solution: I set up at least one transformation-free path leading down to each solid.
First Annual BRL-CAD Users Conference November 4-6, 1992 Omni International Hotel Inner harbor, Baltimore, Maryland, USA
This two and a half day conference will cover many topics of interest to users of the BRL-CAD Package. While other symposia have focused on presenting results of research and various theoretical applications, this conference will teach attendees how to use the power of BRL-CAD to accomplish their own tasks.
Presentations, papers, and tutorials will focus on a variety of subjects for users at all skill levels. Subject range from introductory materials for persons new to CSG to more esoteric subjects such as generation of synthetic images for the simulation of thermal and laser radar sensors. Intermediate topics will cover such practical considerations as printing images, animation, vulnerability analysis, and specific information on tools such as MUVES, FRED, LIBRT and others.
The conference fee includes a superb banquet of New York Strip Sirloin (vegetarian alternative available), spinach salad, crab bisque (A Maryland speciality), vegetables and potato, and a wonderful strawberry cheesecake, all served with red or white wine. Two lunches, three Continental breakfasts, numerous breaks, and a hospitality suite are also provided with equally handsome comestibles.
The Omni International Hotel provides a business center, gift shop, and exercise room, with skywalk access to the waterfront with its many historic sights, museums, theaters, restaurants, shops, and ships. within the hotel are Jackies Cafe which offers American cuisine and The Corner Bar with its Library of fine drink selections and complimentary hors d'oeuvres during week day happy hour.
----------------------------------------------------------------------- 1992 BRL-CAD USERS Conference Schedule
November 3rd, 1992
1200-1700 Check-In 2000-0100 Informal Reception hosted by RESULTS Now, Inc.
November 4th, 1992
0800-0900 Continental Breakfast. 0900-0915 Welcome and Announcements 0915-1000 "Practices and Standards in the Construction of BRL-CAD Target Descriptions", by Dr. Paul H. Deitz, Chief, Ballistic Vulnerability/Lethality Division, Army Research Laboratory and Mr. Keith A. Applin, Ballistic Vulnerability/Lethality Division, Army Research Laboratory. 1000-1015 Break 1015-1100 "Using BRL-CAD to Generate Synthetic Images for the Simulation of Thermal and Laser Radar Sensors", John Dome, Electro-Optics Division, U.S. Army Night Vision Laboratory 1105-1200 Three Short Presentations "Target Damage Modeling in EVA-3D", by R. Kathryn Tucker and Kellye C. Frew, Applied Research Associates, Inc. "Frangible Munition and the BRL-CAD Package; A Successful Combination", by Tom Keij, TNO Defense Research, Prins Maurits Laboratory "An Overview of the Modular Unix-Based Vulnerability Estimation Suite (MUVES)", by Karen R. Murray, Ballistic Vulnerability/Lethality Division, Army Research Laboratory 1200-1315 Lunch 1315-1400 "In-the-Field Modeling", by Harry J. Reed, Geometric Solutions, INC. 1405-1450 "Radar Range Profile Computation for BRL-CAD Models", Dr. S.W. Lee and David Reeves, University of Illinois, Dennis J. Andersh, USAF, C.L. Yu, Naval Pacific Missile Test Center 1450-1515 Break 1515-1600 "End-to-End Sensor Modeling Using BRL-CAD 4.0 with the Faceted Region Editor (FRED)" by Jack Jones, U.S. Army Tank Automotive Command 1605-1700 "Getting BRL-CAD Images Printed", by Christopher T. Johnson, Paladin Software 1800-1930 Banquet Dinner 1930-2000 Key Note Address, Dr. Richard Vitali, Acting Director, Army Research Laboratory 2000-0100 Hospitality Suite/Reception Hosted by RESULTS Now, Inc.
November 5, 1992
0800-0900 Continental Breakfast 0900-0915 Announcements 0915-1000 "Directions in the BRL-CAD Package" (Tentative Title), Michael J. Muuss, Ballistic Vulnerability/Lethality Division, Army Research Laboratory 1000-1015 Break 1015-1100 "Blueprints to BRL-CAD; The User Interface", Erik Lane, Student Contractor, Ballistic Vulnerability/Lethality Division, Army Research Laboratory 1105-1200 Three Short Presentations "Proliferation Concerns in Geometric Modeling", Victor Cericole, Jr. Geometric Solutions, INC. "I/EMS to BRL-CAD Translation: Converting from a B-REP Modeler to a CSG Modeler", Andrew J. Foglia, Intergraph Corporation, Federal Systems Division "Revision Control System (RCS) Configuration Management for BRL-CAD Target Descriptions", Susanne Muuss, Army Research Laboratory 1200-1330 Lunch 1330-1700 Tutorials (Concurrent Offerings)
1) "Animation with BRL-CAD", Christopher T. Johnson, Paladin Software 2) "How to Construct a Simple Model Using BRL-CAD", Victor Cericole, Jr., Geometric Solutions, INC. 3) "How to Use LIBRT, LIBWDB, and LIBFB", Harry J. Reed, Geometric Solutions, INC. 4) "Understanding Non-Manifold Geometry" (Tentative Offering)
2000-0100 Hospitality Suite/Reception Hosted by RESULTS Now, Inc.
November 6th, 1992
0800-0900 Continental Breakfast 0900-1230 Tutorials Repeated 1230-1300 Fare Well
Ed,
> In your algorithm for classifying a point as in or out of a >face, Mike claims you look at the nearest edge. How do you find that >nearest edge? Do you assume the polygonal boundary is convex? If >you use a similar approach to what was being described on the sphere >yesterday, you may have a problem.
The current version of the algorithm is something like this:
Given: a "plane point" in the plane of a face, a set of edges in the plane
For each edge in the face, determine the point of closest approach (PCA) of the edge to the "plane point". Remember the edge/PCA pair with the smallest distance to the "plane point."
iff the "closest" edge has its PCA along the length of the edge, or the "plane point" is on the edge: A) if the "plane point" is on the edge, declare it to be "on" the face", otherwise.... B) Determine if the plane point is "left" of the use of the edge in the normal-ward use of the face. 1) form the "left vector" for the edgeuse. 2) form a vector from the endpoint of the edgeuse to the "plane point" 3) form the Dot product of these two vectors.
If the sign of the Dot product is positive or zero, the plane point is inside the surface area of the face, otherwise it is outside the surface area of the face.
iff the "closest" edge has its PCA at a vertex (end point) and the vertex is NOT coincident with the plane point: A) form the vector from the endpoint to the "plane point". B) for each edgeuse of the face which touches the vertex: form the unit "left" vector for the edgeuse, (which points in the direction of the face area WRT the edge). C) find the edgeuse whose left vector has the smallest Dot product with the vector to the "plane point."
If the sign of the Dot product is positive or zero, the plane point is inside the surface area of the face, otherwise it is outside the surface area of the face.
Sorry, we have not had any opportunity to bring BRL-CAD up under Solaris 2.2, that I am aware of. Your best bet would be to remove all LIBFB and MGED display options from Cakefile.defs, and proceed from there. Once you get that working, adding back (say) X windows support shouldn't be too hard.
That is to say, delete all lines starting with:
# if 1 /* Bare Sun configuration */ # define LIBFB_OBJS if_remote if_sun
down through
# endif # endif
Thats about 32 lines worth (judging by eye).
Best, -Mike Muuss
I have added a routine called "nmg_break_long_edges" to "nmg_misc.c". This codes looks for situations as illustrated:
*------->*-------->*--------->* *<----------------------------*
where one long edgeuse (the bottom one above) and two or more shorter edgeusess (the tops ones) are collinear and have the same start and end vertices. The code breaks the longer edgeuse into ones that can be radials of the shorter ones. I ran into this situation in converting the "tankill" geometry.
-John
Sven Schroeter, tools-administrator. email schroeter@ls7.informatik.uni-dortmund.de
writes:
> i've just installed brl-cad on a sun4 system. > After compiling and installing everything right (?!), > i've got som problems : > 1. how can i rotate a single > solid, when i chose the rotate- > function in the edit-solid menu.
Choose the solid to edit. Select rotate with the mouse. Then type 'p x y z' Where x is the rotation about the x-axis, y is the rotation about the y-axis, and z is the rotation about the z-axis. For example 'p 0 0 -10' rotates the solid -10 degrees about the z-axis. I find it easier to rotate about one axis and accept the edit and then do a rotation about the next axis. I do this because I can not keep straight which rotation comes first (I want to say it is about the z-axis). Also I have trouble visualizing more than one rotation at a time. The rotation must be accepted before another rotation is typed in. For example if the following commands are issued. p 0 0 -10 p 0 0 -20 The result is that the solid is rotated -20 degrees about the z-axis not -30 degrees. An alternate way is to use the sliders. Select sliders and seven sliders appear at the top of the screen; xslew, yslew, zslew, zoom, xrot, yrot, zrot. The solid may be rotated using xrot, yrot, and zrot. Click the mouse to the left or right of the rotate sliders to get the solid to rotate. On my SUN this is extremely difficult I can't see the sliders (I had to log on to an sgi to read what they said). Select Zero Sliders to stop or click the mouse right in the middle of the slider.
I hope this answer helps. I don't know anything about the second problem you are experiencing. Susan Coates
Sven,
> 2. calling rt as key-command colors > the desktop black with red borders > to the windows, paints a picture > which is 50% right and 50% wrong > and returns to a b/w desktop. > The rt-window doesn't refresh.
I've had that problem before. the way you fix it is by typing "fbhelp" (which is in the fb directory). It should tell you how to set env options that should fix the problem. I know you're on a sun4, but what os version are you using? Sunview or OpenWindows or Solaris? What options did you compile with? I was running Openwindows...
-=> Ali
Sven Schroeter,
There is a problem with selecting solids on a SUN machine using the current version of BRL-CAD. The general process of selecting a solid for rotation is:
1) Display the items on the screen that you want to edit or will need for determining how the solid of interest should be processed. For example, if you want to rotate a cylinder and translate it to rest on the side of a box, then it may be interesting to not only display the cylinder, but the box as well. When the cylinder is modified, then the immediate feedback of the box and cylinder (in its new rotation and orientation) will uickly confirm that the processing action on the cylinder was either a success or a failure.
2) Select "solid edit" from the pop down menu. This action will place you in solid edit state rather than the initial (base) viewing state.
3) Since many different solids can be illuminated at one time, MGED expects you to select a particular solid for editing. One selects a particular solid by moving the cursor up and down until the desired solid outline is either changed in color (red to white on an SGI machine) or is redrawn with a tripple line thickness.
Once the solid you want to edit is highlighted by either of the previously mentioned methods, simply click on the center mouse button once to inalize the selection.
4) Select rotate from the pop down menu and either type in the desired X, Y, or Z axis rotation, or use the sliders or graphics station peripheral control knobs. Please note that if you type in an X, Y, or Z axis rotation value, you must exit rotation mode and re-enter rotation mode if a further rotation is desired. Otherwise, the old (previous) rotation will be replaced by the new rotation as if the old rotation never occurred.
5) Once rotated correctly, select the accept edit field in the pop down menu an the solid edit is complete.
Two final points, I hope that you understand the difference between solids, regions, and groups in a BRL-CAD CSG target description and that you are not referring to regions or group items as some complex surface editors often do. Secondly, there are more direct and sometimes easier to use methods for editing solids such as MGED's "sed" command that were not discussed here. As always, each method has its strengths and weaknesses.
For a more indepth answer to your problem (if you want one), feel ffree to call us at 1-800-598-BRLCAD (2752).
Thanks,
Harry J. Reed Geometric Solutions, INC.
Er, yes, but the problem with the X interface is that you seem to need xgl _v2.0_, which a lot of sites don't have (it's unbundled), and which is not upwards compatible with the current xgl (v3.0). This was a sufficient deterrent to send me back to suntools. Patrick Haggard --- ph@physiol.ox.ac.uk [WORLD] ph@uk.ac.ox.physiol [JANET]
Dr.M.G.E.Brand
In response to your questions concerning the FRED tool, we find it interesting, although not the most mathematically complete approach, but uite useful for general application none the less. Perhaps you would like to speak directly with the creator of FRED at TACOM. His name is Jack Jones (a good friend of mine) and his number is (313)574-7654 USA. If I can answer more questions about the methods we at GSI use to convert BRL-CAD databases into FACETS or B-surfaces, or why you may want to wait for NMG technology to be completed, please call us at 1-800-598-BRLCAD (2752).
Thanks, Harry J. Reed Geometric Solutions, INC
This evening, in an attempt to start porting BRL-CAD to our new SGI Power Challenge machine running IRIX 5, I once again had to wrestle with the issue of ANSI function prototypes for the routines in LIBFB. We had previously said that routines like fb_write() took arguments of type RGBpixel[]. RGBpixel was a typedef for an unsigned char[3] array. As Doug Gwyn pointed out when I brought this up the last time, arrays are not fundamental types in C, and so this construction can be a bit awkward.
With the necessity for (and desireability of) using function prototypes upon us, the difficulty presented by the old method was just too great. So, in the name of simplicity, I converted all the pixel parameters to type (unsigned char *), which more simply describes the "packed byte array" in which pixels are stored. This is better than saying "RGBpixel pp[]" everywhere, which would have had to be dereferenced as pp[i][RED].
I've changed h/fb.h, all of libfb/, all of fb/, all of util/, and odds and ends elsewhere to account for this change. Next time I need a break from working on NMGs I'll try to recompile all the sources, and chase down any other code that needs to be modified as a result of this.
Not surprisingly, a lot of the fb/ code was already using arrays of chars, so making this is proper way to do things actually fits well with a nice chunk (but certainly not all) of our current practice.
I'm sure that there are some of you who will find this change to be disturbing, because it implies that some existing code might not work with the new LIBFB interface. First, let me note that if you are not using an ANSII C compiler, this is an invisible change. And, if you *are* using an ANSII C compiler, you can't get the benefits of function prototypes without this change. Function prototypes are no panacea, but I'm sufficiently pleased with their utility to insist that they be used on all major interfaces.
I converted about 60 complete source modules in the course of about 6 hours, so in general changing a source file or two shouldn't take long. I really didn't want this change, I'm not looking for change just for the sake of change. This is something that is being forced upon us by the increasing availability of ANSI C compilers.
I think I've gotten everything in LIBFB except the X Windows module (libfb/if_X.c) ported to IRIX 5 already -- and X is only complaining about one thing (dpy->fd reference). Should be easy to fix.
Best, -Mike
The only reasonable alternative would be to change RGBpixel to be a structure type, but that means each RGBpixel could have from zero to five additional unusable "padding" bytes (most likely 1 byte) added by the compiler, which would (a) waste space and (b) be incompatible with existing code that handles pixel data as a packed byte array. Thus, while (a) might be deemed acceptable when designing new software (especially since it might lead to faster generated code), consideration (b) pretty much forces the solution Mike chose.
The "flavor" of code using constructs like pp[i][RED] can be retained by defining suitable macros, e.g.:
typedef unsigned char RGBpixel[3]; /* still useful! */ #define RED 0 #define GREEN 1 #define BLUE 2
#define PIX(a,i,c) ((RGBpixel *)(a))[i][c] #define PIX_RED(a,i) PIX(a,i,RED) #define PIX_GREEN(a,i) PIX(a,i,GREEN) #define PIX_BLUE(a,i) PIX(a,i,BLUE)
#define PP(i,c) PIX(pp,i,c)
PIX(pp,i,RED) /* was: pp[i][RED] */ PIX_RED(pp,i) /* ditto */ PP(i,RED) /* ditto */
Folks,
I am in the process of getting 4.0 up and running on Solaris 2.3. I have a fair amount of stuff already working and am on the way towards getting the rest of it working and have a couple of questions that someone out there might be able to answer.
I am not on the mailing list so if I am asking questions that have been discussed before (or discussed to death) please kindly refer me to the archives (if there are any) and excuse my interruption.
- The code classifies the world into two interface camps (BSD and SYSV). While historically this has been a good way to do things the days of vanilla BSD versus SYSV are waning. It looks like most vendors are going to hybrid systems that support a number of interfaces. Are there any plans to try adapt to the brave new hybrid world any time soon? I am going to have to butcher the code to make a number of things work properly and am not looking forward to perpetrating such bogosity if it can be avoided.
As an aside, I have worked on a couple of projects where we have taken the approach of using a single OS define to select a the right set of interfaces to use on a given platform. It has been my experience that this really cuts down on the "ifdef soup" in large projects and makes it fairly quick and painless to port to a new platform. It would be great to see the cad source set up like this although it would require a boat load of work.
- Is anyone using shared libraries? I have not really done any memory profiling yet but shared libraries usually tend to be a win and do not require too much extra effort.
- Is there any tentative release data for the next version yet and is there a working list of what will be in the next release?
- Is BRL interested in taking back diffs for solaris support and integrating them into the next release?
- When I worked at BRL the platform of choice for running the cad package was from SGI. I assume this is still true. Can someone fill me in on the config and performance numbers of typical SGI being used for CAD work? I would like to put together a similarly configured sun to see how it performs.
thanks, --tim
PS: Please make sure to include me, tgsmith@sun.com, directly in any replies since I am not on the cad mailing list.
Thomas Browder writes: > >A great aid in MGED would be a constant XYZ coord. system >orientation aid, say a small set of labeled unit vectors >in the lower right corner of the screen. >
Axes are not automatically available in MGED but can easily be built as an added element to a .g database. "The MGED User's Manual", Volume IV of the BRL-CAD Release 4.0 Documentation describes building coordinate axes in Chapter 13. Once built, the axes may be included in any output to aid in orientation and to provide scale.
Repetitive chores like adding coordinate axes, placing multiple copies of objects into databases (ex. illustrating burst points around a ground target), or generating a depiction of a shotline given impact coordinates and final azimuth/elevation can all be all be automated. Commands from a file can be redirected or commands from a program can be piped into MGED avoiding the repetitious interactive input.
ex: #mged test.g <build_test.cmd or #build_test <build.dat | mged test.g
The creator of the file or the program anticipates the needed MGED command sequence. MGED opens the database with null display, echoes the prompts the user would otherwise see and terminates on EOF.
The following shell and awk files provide a quick kludge to automate the process of adding a single set of coordinate axes to a .g database where the user specifies an offset (in model coordinates) and axis size parameters. The shell script simplifies parameter passing to awk. The awk script generates mged commands which can be piped to mged. Three cylinders are generated at the specified intersection, defined as regions, color coded (rgb <==> xyz) and grouped as __axes. If needed __axes may be object edited to a better location or they can be removed with "killtree __axes" and regenerated with more desirable properties. A sample of the input generated for MGED is also included.
- beginning of shell file "gen_axes.sh" - #!/bin/sh #shell file to invoke awk program to generate # mged commands to build coordinate axes # (shell file simplifies parameter passing) # #usage: sh gen_axes.sh x0 y0 z0 length diameter|mged db.g # invokes: # awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5 # where: x0 y0 z0 define the offset from the origin to place axes # length of the cylinders making up the axes and # diameter of the cylinders # and output is fed to mged to add to db.g # # ex: sh gen_axes.sh 0 -3000 0 1000 10|mged test.g # would generate axes in test.g 1 meter long, 1 cm diameter # with an intersection displaced -3 meters in y on the X/Y plane # # brute force (simple hard coding) employed, decorate at leisure # solids are named __axes_x.s __axes_y.s __axes_z.s # regions are named __axes_x.r __axes_y.r __axes_z.r # the group is named __axes ################################################################### awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5 - end of shell file "gen_axes.sh" -
- beginning of awk file gen_axes.awk - ################################################################### #awk program to generate mged commands to build coordinate axes # #usage: sh gen_axes.sh x0 y0 z0 length diameter # where gen_axes.sh invokes # awk -f gen_axes.awk x0=$1 y0=$2 z0=$3 len=$4 diam=$5 # where: x0 y0 z0 define the offset from the origin to place axes # length of the cylinders making up the axes and # diameter of the cylinders # # ex: sh gen_axes.sh 0 -3000 0 1000 10|mged test.g # would generate axes in test.g 1 meter long, 1 cm diameter # with an intersection displaced -3 meters in y on the X/Y plane # # brute force (simple hard coding) employed, decorate at leisure # solids are named __axes_x.s __axes_y.s __axes_z.s # regions are named __axes_x.r __axes_y.r __axes_z.r # colors are reddish (x), greenish (y), and bluish (z) # the group is named __axes ###################################################################
END{ radius = diam/2
printf("regdef 19997\n") #setup arbitrarily for idents 19997-9
# X axis printf("in __axes_x.s rcc %f %f %f", x0, y0, z0) #name, rcc, origin printf(" %f %f %f", len, 0, 0) #length along x printf(" %f\n", radius) #radius of rcc printf("r __axes_x.r u __axes_x.s\n") #region def printf("mater __axes_x.r\nplastic\n\n250 150 150\n\n") #color
# Y axis printf("in __axes_y.s rcc %f %f %f", x0, y0, z0) printf(" %f %f %f", 0, len, 0) printf(" %f\n", radius) printf("r __axes_y.r u __axes_y.s\n") printf("mater __axes_y.r\nplastic\n\n150 250 150\n\n")
# Z axis printf("in __axes_z.s rcc %f %f %f", x0, y0, z0) printf(" %f %f %f", 0, 0, len) printf(" %f\n", radius) printf("r __axes_z.r u __axes_z.s\n") printf("mater __axes_z.r\nplastic\n\n150 150 250\n\n")
# group printf("g __axes __axes_x.r __axes_y.r __axes_z.r\n")
} - end of awk file gen_axes.awk -
- sample of output that would be sent to mged for example given (\ is cont) - grendel 31% sh gen_axes.sh 0 -3000 0 1000 10 regdef 19997 in __axes_x.s rcc 0.000000 -3000.000000 0.000000 1000.000000 0.000000\ 0.000000 5.000000 r __axes_x.r u __axes_x.s mater __axes_x.r plastic
250 150 150
in __axes_y.s rcc 0.000000 -3000.000000 0.000000 0.000000 1000.000000\ 0.000000 5.000000 r __axes_y.r u __axes_y.s mater __axes_y.r plastic
150 250 150
in __axes_z.s rcc 0.000000 -3000.000000 0.000000 0.000000 0.000000\ 1000.000000 5.000000 r __axes_z.r u __axes_z.s mater __axes_z.r plastic
150 150 250
g __axes __axes_x.r __axes_y.r __axes_z.r - end of sample output -
----------------------------------------------------------------------- Dr. Benjamin W. Turner bturner@ida.org Operational Evaluation Division Office: (703) 845-6931 Institute for Defense Analyses Autovon: 289-1980 1801 N. Beauregard Street FAX: (703) 845-6911 Alexandria, VA 22311-1772 Verify: (703) 845-2544 -----------------------------------------------------------------------
I was trying to duplicate the things in the "Animation Techniques in BRL-CAD" WWEB file. Most everything went fine except when I tried to preview the animation script in "mged", in which case "mged" just quit on me when I typed the command "preview moss.rtanim". This happend in both the 4.1 and 4.2 version of BRL-CAD. Below is the output from meged:
50 jake/fj/jem_files/brl-cad4.2/db> mged moss.g BRL-CAD Release 4.2 Graphics Editor (MGED) Tue Nov 16 13:25:19 EST 1993, Compilation 18 jem@crim1:/disk4/jem_files/brl-cad4.2/mged
attach (nu|tek|tek4109|ps|plot|sgi|X)[nu]? sgi ATTACHING sgi (SGI 4d) Gary Moss's "World on a Platter" (units=mm) mged>preview moss.rtanim eyepoint at (0,0,1) viewspace rt_do_cmd(orientation): command not found command failed: orientation mat_inv: error! fabs(y)=0 MATRIX singular matrix: 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 0.000 200.000
mat_inv: singular matrix
The "moss.rtanim" script seems fine to me, because it works fine when I create the Postage stamp animations. Does any one know why this is not working? I am running on a 4D/35 with Irix 4.0.5.
I also have a few more questions. The first is how the mpeg movie for the animations in this paper were created? Is there some public domain software which can convert the BRL-CAD pix files into a MPEG file? Finally, whay are the main new features of the 4.2 version. Is it just a improved X11 version of "mged"? I could sure use the NURB editting capability that is being worked on. Any plans on a beta relase of this stuff?
Thanks,
Joe --
Bruker Instruments Inc. USA Billerica, MA. 01821
Phone: 508-667-9580 Fax: 508-663-9177
jem@bii.bruker.com Internet !{uunet,ulowell}!bii!jem UUCP
Attendees:
Jeff Foulk SURVIAC ASO (410) 273-7794 Carla Moyer SURVIAC ASO (410) 273-7794 Bob Strausser SURVIAC ASO (410) 273-7794 Jack Benkert SURVIAC BA&H (703) 280-8239 Ed Hathaway SURVIAC BA&H (703) 902-5829 Carl Hutzler SURVIAC BA&H (703) 902-5830 Dr. Paul Dietz ARL (410) 278-6282 Bill Mermagen, Jr. ARL (410) 278-8740 Joseph Silverstein ARL (301) 394-3170 Kellye C. Frew Applied Research Associates (505) 883-3636 Chris Johnson Geometric Solutions Inc. (410) 273-7058 George Anderson IDA (703) 845-2539 Ben Turner IDA (703) 845-6931 Carole Keyser Ketron (410) 583-8386 Steve McKay Pacific-Sierra Research Corp. (703) 516-0235 Bud Bruenning Sverdrup Technology (904) 729-6497
The SURVIAC BRL-CAD User's Group Meeting was held at the Booz- Allen Hamilton facilities in McLean, Virginia. Mr. Jeff Foulk, SURVIAC Aberdeen Satellite Office (ASO) project manager, welcomed the attendees, presented the purpose of the meeting, and provided an overview of the SURVIAC organization. The thrust of the meeting was presentation of uses for BRL-CAD, program updates, and discussion of user problems and ideas.
Ms. Carla Moyer, SURVIAC ASO administrative manager, presented the function of the SURVIAC ASO regarding BRL-CAD. SURVIAC full support includes distributing the BRL-CAD source code and documentation, providing telephone support for installation and operation technical inquiries, distributing maintenance release updates, and maintaining a mailing list database of users. Points of contact for BRL-CAD 4.0 are no longer relevant. Mr. Bob Strausser, SURVIAC ASO BRL-CAD technical POC, presented an overview of technical inquiries over the last 9 months. Inquiries were primarily administrative (67%) with the balance divided between installation and operation questions.
During the Technical Inquiry overview, Dr. Dietz stressed that the vdeck conversion program and gift shotlining program are obsolete. The principal problem with using vdeck lies with the expansion of BRL-CAD primitives beyond the supported primitives of the old comgeom format (generated by vdeck). This can result in the loss of data by the conversion back into the comgeom era. Joseph Silverstein is using vdeck and gift to interface between BRL-CAD geometries and the schrim radar signature program. Dr. Deitz and Bill Mermagen, Jr. recommended using rtrayhist and xpatch as better tools than the gift / schrim pair. The vdeck and gift programs are also used to feed hevart because the sequence of shotlines provided by rtg3 is not compatible with hevart's input requirements. Carole Keyser recommended using shotb2g, it converts rtg3 output into a format compatible with hevart. Contact John Anderson at ARL (278-7267) for copies of the shotb2g program.
Mr. Bob Strausser also presented a status update on the patch-g conversion program. This program provides initial conversion of FASTGEN faceted geometry descriptions into BRL-CAD format. The updated program has been sent to Bill Mermagen, Jr. for review and release.
Bill Mermagen, Jr. presented an overview of BRL-CAD status and plans. The next release of BRL-CAD anticipated Summer 1994, will have a production version of the N-manifold Geometry (NMG) capability. This will permit use of polygonal representations for import, export, and visualization and will provide better support for faceted-geometry dependent analysis codes. Along with the NMGs, new primitives (i.e.. elliptical tori, paraboloids, and hyperboloids) will be available. A second task area has been revising the MGED graphical user interface (GUI) to make the system more user friendly. Two GUIs are in development as replacements for the current interface. One GUI (being developed by Phil Dykstra) is based on MOTIFF and X-windows. The other GUI (being developed by Mike Muuss) is vendor independent (depart from X-window dependency). The BRL-CAD team (primarily Mike Muuss) is also examining the possibility of using virtual reality. The third task area has provided more conversion routines for importing foreign CAD geometries into BRL- CAD.
The importance of BRL-CAD's need to support faceted geometries (the NMG / tessellation upgrade) was reinforced by Kellye Frew , Applied Research Associates (ARA). She indicated that ARA is involved with an effort to generate a 3-D mesh to interface with epic. BRL-CAD was used for Phase I of this program.
Mr. Bud Bruenning, Sverdrup Technology, presented an overview of how he is using BRL-CAD and enhancements he would like to see. The highest priority was a simple tutorial document. He would also like some new image generation capabilities (cross sectional cuts, automated component id number labeling, easier overlays). Lesser issues concerned improvements to patch-g and better support from the developers. Dr. Dietz suggested that Bud visit with ARL for a "working group" session on generating images and plots. Any one interested in participating in an imaging working group, please contact the SURVIAC ASO (Resalee Bilka).
Geometric Solutions, Inc. (GSI) presented a report on the addition of joint information to BRL-CAD models. This new ability, as outlined by Chris Johnson, GSI, will allow users to change the configuration of targets with a simple click and drag interface.
This new capability is being integrated with BRL-CAD and will be available to all in the next BRL-CAD release. More information is available from Victor Cericole, Jr., GSI Software Director, 1-800- 598-BRLCAD (2752).
Mr. Steve McKay, Pacific-Sierra Research Corp., expressed an interest in accessing a model description database. He is aware of several and was wondering if any coordination existed between these databases. Information concerning geometry model databases would be appreciated as the SURVIAC ASO researches this issue.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Prepared by Bob Strausser, SURVIAC Aberdeen Satellite Office, (410) 273-7794.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> BTW, I had been using rt_malloc, [...]
Good, I'm glad it has been useful.
> Now, I have another question. The interactive program I am developing > may import many different BRL-CAD data bases during a single session. > Each may optionally be raytraced any number of times. When I am done > each raytrace, I am finished with the struct rt_i that rt_dirbuild > gave me. Is there a (kosher) way to free the memory allocated for this > rt_i and its members?
The answer is: YES. I already thought of that. :-) It's broken out in several pieces, so you can free different parts at different times.
/* Release dynamic storage */ rt_vlist_cleanup(); /* if you use vlist */
rt_clean( rtip ); /* eliminate prepping, but not db */ db_close( rtip->rti_dbip ); /* eliminate all db info */
#if MEMORY_LEAK_CHECKING rt_prmem("After complete processing"); #endif
I noticed that there was no way to dispose of the rt_i structure itself, so I've added:
rt_free_rti( rtip ); /* does rt_clean, db_close, rt_free */
Also note that if you are not changing the database, and not doing any articulations, you can just keep using the existing rt_i structure. No need to re-prep.
If you are doing articulations, you can rt_clean(), change articulation, and then just call rt_gettrees() and rt_prep().
If you are going to be changing databases in mid-stream, there is probably some additional minor library support that you will need. (Such as routines like rt_new_rti(), and perhaps reference counts on the db_i structures). I have always intended for this to be possible, but I've never actually tried it, so you know what that means. Please let me know what you have in mind, so we can support it.
> I'm already peeking (poking) at struct region > to put criticality information in the reg_udata member. Is that even > kosher?
reg_mfuncs and reg_udata are pointers for you to set as you need. It's entirely kosher for you to make them point at your own data structures. (Just don't serve them on the same plates as the Swiss cheese.)
> Maybe I should make a (short) list of the rules I am breaking > (especially w.r.t. union record) and see if you guys can come up with > an alternative for me (either a better way for me to do it, or new > library calls to be maintained outside of application code.)
That sounds like a very good idea. If there is some operation that you need to be able to do to the data structures, probably somebody else will have a similar need in the future. So it would be best to minimize special LIBRT interface code built into your application. Unless it turns out to be really hard, I'd rather just make sure that the library gives you all the support that you need. So speak up. :-)
So, now I'm curious: what are you doing to "union record"? That structure defines the on-disk database format, and is _the_ most difficult to change.... Hopefully you meant "union region"?
Best, -Mike
In response to:
>Date: Mon, 3 Jan 94 09:04 EST >From: Alex Kekesi <akekesi@nvl.army.mil> >Subject: BRL-CAD newsletter > >Hi, > > I understand there is an e-mail newsletter for BRL-CAD >users. I would be very interested in joining if such a >newsletter exists. > >Thanks in Advance! > >B.A. Kekesi >
Alex,
The SURVIAC ASO is currently providing a BRL-CAD newsletter for both SURVIAC and FTP registered users of BRL-CAD. It is published quarterly and mailed to the users. The December issue was mailed last week. If you do not receive it shortly, forward your name and address to me for addition to the mailing list(or I can e-mail it to you).
The newsletter was originally intended as an extension to this e-mail forum, providing announcements of events and extracts from the e-mail for non-E-mail users. All contributions and / or suggestions for topics of discussion are welcome.
Bob Strausser SURVIAC ASO Technical Rep
Jim,
ARL is not currently sponsoring courses on BRL-CAD, however, there are at least two commercial vendors in our area that offer BRL-CAD training:
Geometric Solutions Inc. 100 Custis St. Aberdeen, MD 21001 (410) 273-7058
Survice Engineering Co. 1003 Old Phila. Rd. Aberdeen, MD 21001 (410) 273-7722
Hope this helps.
Jill Smith Chief Vulnerability Methodology Br. ARL
To mdelapp,
BRL-CAD has been proposed as an AMC standard for geometric system data exchange through the AMC Functional Coordinating Group for Computer Interoperability and Interchange (FCG-CII). PDES/STEP are ultimately tackling a much broader spectrum of data, such as plumbing and sheet-metal-folding data, than what BRL-CAD represents. BRL-CAD however offers an OPEN (i.e. government owned) format for exchange of geometric information and associated properties at a level of information sufficient for most of the engineering analyses performed within AMC. No commercial CAD/CAE package can meet all the requirements for geometry representation/interrogation to meet the analysis needs of this community - hence the proliferation of different CAD/CAE systems.
BACKGROUND. The issue of geometric target data exchange came up between ARL (old BRL), ARDEC, Benet and TACOM when it was pointed out that each organization used a different modeling system. For efficient design, evaluation and integration of Army systems it would be of benefit if these organizations could exchange system information in electronic format. MICOM also asked to be included on the Technical Working Group to address these issues, since within MICOM they had as many or more different/non-compatible modeling systems as the rest of us put together. Most of the commercial modeling systems have proprietary data representations and although you can build geometric target descriptions in these modelers and perform various analyses, most do not allow you to export the geometry and associated information such as material properties. Additionally, the underlying mathematical representations of the data, if available, may not be compatible. That is, a format for exchange does not handle translation of data from one mathematical form to another.
CURRENT STATUS. PDES/STEP addresses only the problem of exchange, not translation. That is, if two modeling systems represent the geometric information in the same mathematical form - say splines, then PDES/STEP specifies the format for exchange. However, the PDES/STEP standardization effort is still fairly young and not all geometric entities are yet specified for exchange. For example, in the area of solids, there is no specification for the exchange of a truncated general cone, elliptical torus, paraboloid of one sheet, etc.
Within AMC we have both problems, that is, the underlying mathematical representations of the geometry are not the same and not all geometric representations are covered by exchange specifications. BRL-CAD, used by ARL, is a Constructive Solid Geometric modeling system with Boolean trees. Intergraph, used by TACOM, is believed to be a spline-based system, although the specific data representations are proprietary. Translators, which may be approximations, must be developed to transfer data between these systems.
TRANSLATORS
BRL-CAD <=> Intergraph. The Foreign Science and Technology Center and the Tank Automotive Command jointly sponsored BRL-CAD <=> Intergraph translators through a contract with Intergraph. The Intergraph => BRL-CAD translation is accomplished by converting GIFT (Geometric Information For Targets) and Booleans into the corresponding BRL-CAD representations. Any solid not represented in the GIFT format is tessellated and transferred as a polysolid. The Intergraph => BRL-CAD translator works reasonably well, when Intergraph models have been constructed following certain stylistic rules peculiar to the translator, however the BRL-CAD=> Intergraph translator has a much greater loss of information.
PATCH-G. The patch-g translator was developed by BRL (now ARL) under sponsorship by the Air Force. Patch-g translates FASTGEN2/FASTGEN3 target descriptions into BRL-CAD .g format. Plate-mode facets are difficult to convert.
Jack-G. Jack is an articulated human figure package developed by the University of Pennsylvania under the sponsorship of the Human Engineering Laboratory (now Human Research & Engineering Directorate, Army Research Laboratory). ARL/SLAD developed the jack-g translator to import articulated human figures into vehicles.
ACAD <=> BRL-CAD. ACAD is the geometric modeling system developed by General Dynamics in the Fort Worth office (this branch has since been sold to one of the aircraft companies). ACAD has developed and distributes the ACAD <=> BRL-CAD translators. ARL has no experience with the use of these translators.
BRL-CAD <=> Euclid. Euclid is a geometric modeling system developed by Matra Datavision of France. The underlying data representation is believed to be cubic Bezier patches (the simplest subset of B-splines), however, the users with whom we are coordinating the effort, have access to only a polygonal boundary representation of their geometry. ARL is currently extending our valid data representations to include N-Manifold Geometry (NMG) data structures. In the initial implementation, NMGs will include polygonal boundary representations and the associated topological information. We are currently able to import Euclid polygons into BRL-CAD and view them using the polygon fill hardware of the SGI, but cannot interrogate (i.e., raytrace) the geometry. Conversion routines for CSG to NMG forms must be completed to export BRL-CAD to Euclid.
BRL-CAD <=> IGES. The IGES=> BRL-CAD converter has been developed in-house (by ARL) and has recently been upgraded to include the IGES BREP (boundary representation) objects into N-Manifold Geometry (NMG) data structures for planar faces and IGES drawings (2D lines) to BRL-CAD NMG's. The iges-g converter translates IGES Constructive Solid Geometry (CSG) files into BRL-CAD CSG files with approximations for IGES solids of revolution and solids of linear extrusion. The g-iges translator allows for two types of IGES output from BRL-CAD. 1) A 100% facetized representation can be selected where each region is facetized to an NMG object before output as an IGES "Manifold Solid BREP Object (MSBO)", or 2) a mostly CSG file can be produced where each region is output as an IGES "Boolean Tree" entity and each solid is output as the corresponding IGES solid. In cases where there is no corresponding IGES solid (truncated general cone, elliptical torus, etc.), a facetized approximation of the BRL-CAD solid is output as an IGES MSBO. The efforts described here depend on the current NMG work mentioned in the previous paragraph. We expect the NMG work and translators to be available in the next BRL-CAD release.
Target descriptions in BRL-CAD format are a deliverable from the contractor on most ground system development programs. Since the BRL-CAD format is government developed and open, it can be specified as a deliverable in a contract. This facilitates the transfer to Intergraph for analyses by TACOM and directly feeds the vulnerability/lethality analyses required by ARL.
The Intelligence Community Modeling Group is also relying on BRL-CAD geometry both as input to various signature codes (e.g. Xpatch, TSAR) and also as an intermediate file format for exchange. We are currently investigating extending our geometry representations to include a "height field" data type to facilitate terrain modeling in support of a DMSO proposal for signature generation and automatic target recognition.
I have included below a note from one of our users who uses BRL-CAD specifically as an interface between other CAD tools.
At Mcdonnell Douglas, we are using BRL-CAD as an interface between other CAD tools (such as Unigraphics, PATRAN, and SMART) and radiation transport codes to calculate the radiation dose in space (e.g., from solar flare protons or cosmic ray heavy ions). The ray tracing capabilities of BRL-CAD are what led us to this configuration. As we gain experience with the package, we may use it as more of a total integrated product development tool (e.g., for determining mass properties, etc.). So far, we are very pleased with tho package.
Future uses for the radiation transport work include medical imaging and therapy, and risk calculations for the High-Speed Civil Transport.
-------------------------------------------------------- Stuart L. Huston McDonnell Douglas Aerospace 5301 Bolsa Ave. M/S 13-3 Huntington Beach, Calif. 92647 phone (714) 896-4787 fax (714) 896-6930 -------------------------------------------------------- huston@huston.mdc.com
If you have questions or require more information, please feel free to contact me.
Jill H. Smith Chief Vulnerability Methodology Branch (jill@arl.army.mil) 410-278-6644
I was trying to figure out how to use the pipe generating code, by playing around with pipetest.c, but it seems like all the pipes are generated with a infinitly small diameter. Even, if I try to change the id and od parameters. The pipes that are generated by the program cannot be zoomed in on. How do I increase the diameters of the pipes? I tried using the following for: { {(long)WDB_PIPESEG_MAGIC, 0, 0}, 0, 1, 0, 0, 0, 0, 500.10, 900.5, WDB_PIPESEG_TYPE_LINEAR }, From my understanding this should give an id=500.10 mm and an od=900.5, but I still cannot zoom in on the resulting pipe.
Also, how does one specify bends greater than 90 degrees (like say 180 degreees)?
--
Bruker Instruments Inc. USA Billerica, MA. 01821
Phone: 508-667-9580 Fax: 508-663-9177
jem@bii.bruker.com Internet !{uunet,ulowell}!bii!jem UUCP
Joseph Meier wrote -
> I was trying to figure out how to use the pipe generating code, by > playing around with pipetest.c, but it seems like all the pipes are > generated with a infinitly small diameter.
The old Television saying applies here: "The Problem is Not in Your Set".
The support for PIPE solids is very rudimentary. What you see was done as part of the proposal for a joint project with Air Systems Branch that was not funded. The data structures are defined, and the import/export routines exist, but the PIPEs can not be ray-traced. They can't really be edited in MGED either, and when drawn, only the centerline is displayed.
So, what you are seeing is not that the diameter is not being stored in the database, but instead that the drawing routine is not drawing the exterior of the pipes.
It is unlikely that anyone in ARL will be fleshing out the PIPE solid, at least not within this FY. If you wish to complete the code yourself, the changes are restricted to one file: librt/g_pipe.c. In the alternative, you might be able to use cylingders and spheres, as is often done now.
Best, -Mike
Those of you with Silicon Graphics machines running recent versions of the operating system (Irix 5) have probably noticed how programs linked with -lgl (most notably all the BRL-CAD programs that use LIBFB) won't work unless $DISPLAY is pointing to a GL-capable workstation.
Well, in the release notes for Irix 5.2, they make mention of this:
You can work around this in one of two easy ways:
1. Set your DISPLAY environment variable to a GL- capable system.
2. Set an environment variable called __SGI_NO_REMOTE_GL before executing the program. This prevents you from rendering remotely should you try to do so. The DISPLAY environment variable is always interpreted as rendering to local host.
I've added a reminder to my .login file:
# SGI Irix 5 bug workaround # setenv __SGI_NO_REMOTE_GL 1
This isn't something to set all the time, because there are occasions when using remote GL windows *is* what you intend to do.
Best, -Mike
In the cad distribution, see "doc/anim.txt" and "doc/matrix.txt" for a short discussion of BRL-CAD matricies and how to use them in animation.
Also, see the online paper on "Animation Techniques in BRL-CAD" via Mosaic at
http://www.arl.army.mil/reports/tr-313/index.html
- Phil
This occurs when you run across the network--running edpix on another machine using your workstation as the window server. It wasn't designed to do this and couldn't under Irix 3.3. Now, Irix 4+ permits this using X, but it is far from a smooth interface. I recommend only running on your local workstation.
--jim
PS; thanks for the fixxes to the man page :)
----- Forwarded message # 1:
Received: from wolf16.brl.mil by WHIM.BRL.MIL id aa03549; 8 Feb 94 16:51 EST Received: from wumpus.brl.mil by WOLF.BRL.MIL id aa22008; 8 Feb 94 13:34 EST Date: Tue, 8 Feb 94 13:33:47 EST From: Carl Moore <cmoore@BRL.MIL> To: acst@BRL.MIL Subject: edpix error messages Message-ID: <9402081333.aa13049@WUMPUS.BRL.MIL> Resent-Date: Tue, 8 Feb 94 16:48:27 EST Resent-From: Mike Muuss <mike@BRL.MIL> Resent-To: jehunt@BRL.MIL
For test purposes, I did an "edpix" run consisting only of "edpix -f filename.pix" and then immediately exiting. What would cause a slew of messages "dgl error (pup): too many callbacks" to appear? (I noticed those messages after leaving edpix.) Would you like to look at the file with that problem? It seems to behave normally otherwise. Let me know and I can supply a path to that file.
----- End of forwarded messages
Several people noted that the "pixmatte -w1" alternative that I added to Lee's EBM paper didn't work. Programmer's plus-or-minus one problem bites again. Here is the fix, in "diff -c" format, suitable for use with PATCH.
Best, -Mike
*** /usr/tmp/,RCSt1a29429 Wed Feb 16 22:44:01 1994 --- pixmatte.c Wed Feb 16 22:43:18 1994 *************** *** 171,178 **** break; case 'w': c = atoi(optarg); ! if( c > 1 && c < sizeof(pconst) ) width = c; break; default: /* '?' */ usage("unknown option\n", 1); --- 171,180 ---- break; case 'w': c = atoi(optarg); ! if( c >= 1 && c < sizeof(pconst) ) width = c; + else + usage("Illegal width specified\n", 1); break; default: /* '?' */ usage("unknown option\n", 1); *************** *** 349,355 **** exit(1); } } ! fprintf( stderr, "pixmatte: %d element comparisons true, %d false\n", ! true_cnt, false_cnt ); return(0); } --- 351,357 ---- exit(1); } } ! fprintf( stderr, "pixmatte: %d element comparisons true, %d false (width=%d)\n", ! true_cnt, false_cnt, width ); return(0); }
Dear John,
The target description in question contains 16,000 solids, regions, and groups. We can reduce this amount if we remove the slotted screws holding down the cupolas and reducing the number of solids per link well below 39.
Please note that the description is only an exterior description. Adding the interior will probably increase it by another 12,000. Thanks.
By the way, the target contains battle damage such as dents, third country effects (non-standard detail items), and test repair items such as surrogate storage boxes.
Thanks, Harry Reed Geometric Solutions, INC 1-800-598-BRLCad (2752)
BRLCAD users-
We are looking for images and geometry showing dual-use technology with BRL-CAD. Dual Use Technology is technology that is of use to the Defense Department and to other organizations for non-defense applications. We are looking for BRL-CAD images and or geometry that show a non-defense application in any one of these areas:
Computer Aided Design (CAD) Computer Aided Manufacturing (CAM) Animation Visualization Image Processing Graphic Arts Architectural Design Education Medical Technology Other (please elaborate)
All of the images and or geometry will be properly credited, and will not be distributed or displayed the to the general public unless you state otherwise. We will use these to help defend our budget and to show how BRL-CAD is being used by a large and diverse community. We may also want to use them for a brochure announcing a future BRL-CAD users conference (Spring of 1995). If you have further questions, or would like to contribute, please send me e-mail (stay@arl.army.mil). I can take images and or geometry from the network, or you can send them to me via regular postal mail. Let me know and we can work out the details.
Thanks, Paul Stay
p.s. I am unable to compensate any organization or individuals for images and or geometry that are sent.
p.s.s. Don't send mail asking me about the future conference, since the only thing we currently know is that it will be sometime in the spring of 1995.
Previously I asked for assistance to unpack the BRL distribution using Solaris 2.3, as makekey is missing. I have checked things with Sun Sweden. Makekey is only included in the Solaris Encryption kit which is not exported from the USA. I solved the problem as follows: Insert SunOS 4.1.1 CD ln -s /cdrom/cdrom0/s0/export/exec/sun4_sunos_4_1_1/usr ~/brl-dir cd ~/brl-dir tar xvf usr ./lib/makekey Further enigma.c need to be modified to use a local makekey by changing one of the paths to ./makekey. if (fork()==0) { close(0); close(1); dup(pf[0]); dup(pf[1]); execl("./makekey", "-", 0); execl("/usr/lib/exec/makekey", "-", 0); /* BSDI */ Thanks for all the help I received. - Goran Rydqvist CadCal Design
Yoav Oreg writes:
> what I tried to do is to build a simple object in auto-cad out of > primitive solids for instance a box and a cone, translate them to > IGES format (my autocad supports IGES 4.0) and then by using the > iges-g module translate the IGES file to brl-cad format. > everything seemed to be going fine until I applied iges-g. > The routine started working by counting the number of lines in the > objects but when it reached the part where it counts the number of > solids/regions it counted 0 (zero).
While IGES 4.0 supports solid models, what Autocad produced for you was an IGES "drawing" of the object you built, not a solid model. The key is that iges-g says it found no solids or regions in the IGES file. BRLCAD is a solid modeller, so it needs solid objects to operate on. The iges-g converter distributed with BRLCAD converts only IGES CSG (Constructive Solid Geometry) objects to BRLCAD format. Converting a drawing of a solid object (as Autocad provided) to a real solid model of that object is something people have been dreaming of for years, but so far it takes human intelligence in the loop. If Autocad would support the IGES CSG portion of IGES 4.0, then the conversion you attempted would work.
> can someone please give an answer to the problem :what kind (if > any) of objects made in autocad can be translated via IGES files to brlcad > and HOW CAN I DO IT?
As I mentioned above, if there is a version of Autcad that will produce IGES 4.0 CSG files, then you can convert them to BRLCAD. One other possibility is if Autocad can produce IGES 128 entities (NURBS), the iges-g converter will convert these entities to BRLCAD spline solids by combining all the 128's in the IGES file into a single spline solid. Note that this will not work for trimmed NURBS yet.
The next release of BRLCAD will include an improved iges-g converter that will also handle IGES BREP (Boundary Representation) solid models (restricted to planar-faced objects). There will also be a "dxf-g" to convert Autocad's DXF format to BRLCAD, however this will also be limited to 3D objects (3DFACES and 3DMESH objects) and 2D drawing entities will be ignored.
Hope this helps,
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
E G L I N A F B
From: MILFORD A. REYNOLDS Date: 05-May-1994 12:11pm CST REYNOLDS Tel No: 904 862 4188 Dept: 46TW/EALV*ASI
TO: (List Suppressed - Enter SH to read list. Use US SWC to remove suppression.)
Subject: RE: Modeling Question
Glenn, The only time we've had to deal with pointy-headed ogives we made do with an RCC at the end with a near-zero radius. In fact, a series of RCC's with appropriately decreasing radii might make a better approximation than an ellipsoid. Allen Reynolds ASI Sys Intn'l
A New Command-Line Option Parser for BRL-CAD
ACST Team Meeting 18-Feb-1994
--- GOALS ---
*) Backwards compatability with current getopt() style command usage, so that e.g. "pix-fb -hizs32" is understood as a series of 1-char options.
*) Opportunity for more options than with present getopt(), e.g. long option names a.la. X-windows (including abbreviated forms), while also retaining 1-char options.
*) Each 1-char option should have the opportunity for a long option that does exactly the same thing.
*) Eliminate redundancy. One table should suffice for usage message, arg/no-arg flagging ("g:"), verbose help message. It would be nice to also eliminate the getopt() style switch() statement, perhaps by including pointers to the variable to be set and/or by having a hooked function pointer in the table.
*) It would be nice to (a) check for proper number of positional arguments, and (b) perhaps parse them into variables as well.
*) It would be nice to have "supplemental text" to supplement the usage message with, tucked into the same table. (Perhaps as part of the NULL entry at the end?)
*) It would be nice to have a routine that could print out (or perhaps return a string with) a command-line which completely represented the state of the program's options, including showing the values for all options that were defaulted.
--- ISSUES ---
*) How to mix long and short forms? One proposal is to have all long forms start with a double-minus, e.g.:
pix-fb --width 32 -s128 --inverse foo.pix
This is not incompatible with the getopt() usage of "--" to mark end of option list, but it is a nuisance to type two minus signs.
*) How to determine the minimum acceptable abbreviation for long option names. The X strategy of taking the shortest unique substring is convenient for the programmer, but means that adding new options may break old shell scripts, e.g. -geometry abbreviated as -geo in a script would no longer work when a -geodesic flag was added. The VMS style alternative would require the programmer to designate the minimum acceptable substring, which seems preferable. For example, either "-geom*etry", or "-GEOMetry" could both be used.
*) Long argument names should be case insensitive. Shouldn't they?
AJ,
The following message should allow you to fix the malloc error in the iges-g converter. You still need "valid" geometry formats (IGES type 128, I think) for a valid imported spline.
Bob Strausser SURVIAC ASO
forwarded message: -----------------
Date: Mon, 7 Jun 93 13:39:21 EDT From: "John R. Anderson" <jra@brl> To: Shung-Wu Lee <u10480@u2.ncsa.uiuc.edu> cc: cad@BRL Subject: [John R. Anderson: BUG in iges-g]
There is a small bug is the "iges-g" code that causes it to die on an rt_malloc error in "rt_nurb_new_snurb".Here is a context diff for the fix:
*** spline.c.old Mon Dec 21 15:46:51 1992 --- spline.c Mon Dec 21 15:50:07 1992 *************** *** 89,95 **** b_patch = rt_nurb_new_snurb( m1+1, m2+1, n1+2*m1+1, n2+2*m2+1, ! k2+1, k1+1, 4); /* U knot vector */ for (i = 0; i <= n1+2*m1; i++) { --- 89,95 ---- b_patch = rt_nurb_new_snurb( m1+1, m2+1, n1+2*m1+1, n2+2*m2+1, ! k2+1, k1+1, MAKE_PT_TYPE( 4 , 2 , 0 ) ); /* U knot vector */ for (i = 0; i <= n1+2*m1; i++) {
************************************ John R. Anderson Attn: AMSRL-SL-BV U.S. Army Research Laboratory Internet: jra@brl.mil Aberdeen Proving Ground, MD 21005-5068 Phone: (410) 278-6674
--------------------- end forwarded message
> My problem now is: What and or where are <bsd/sys/types.h> and > <bsd/sys/time.h>? (Required in fbed/empty.c)
The use of <bsd/sys/whatever> in fbed/empty.c was to get to the BSD- flavored stuff under older IRIX releases (probably IRIX 3.x). Under IRIX 4.x the BSD stuff was apparently integrated into /usr/include, so you just want to use <sys/types.h> and <sys/time.h>, but the /usr/include/bsd directory was still there for backward compatibility. This compatibility was apparently removed in IRIX 5, so no /usr/ include/bsd anymore.
In your case, I would just change the CPP directives at the top of empty.c to always include <sys/types.h> and <sys/time.h>. I'm not sure what the politically-correct solution is for the official BRL-CAD copy. For instance, making rash statements like, if someone is still running IRIX 3 or earlier, they probably [...various things could go in here...], may not be acceptible policy. ;^)
-Gary
Yoav Oreg <phr22yo@phys4> writes:
> This is a follow up question to my last letter concerning conversion from > AUTOCAD to BRLCAD. I have been talking to some CAD people and for > some reason they keep on telling me that even if you have a CAD package > that works with solids, when you convert a solid to IGES format, the solid > is broken into wire frame which doesn't keep the solid properties. I am quite > confused now, since I was told last time that IGES does support solid entities? > could someone enlighten me?
The IGES specification includes support for both CSG and BREP solid models. It is up to the CAD vendor to decide how much of the IGES spec they are willing to support. Users of solid modelling CAD systems should let their vendors know that they expect to be able to exchange solid models via IGES without rebuilding the model from wireframe or just a collection of surfaces in space.
> also if ,as I understand importation of solids via IGES is possible,does > any one Know if it is possible to do it from UCLID,UNIGRAPHICS or CATIA? > and if it's possible than how?
The current BRL-CAD distribution include an "iges-g" that will import IGES CSG solids into the BRL-CAD format. This means IGES files that contain entities such as cones, cylinders, blocks, wedges, etc, along with the CSG specific entities such as Boolean trees, solid assemblies, and solid instances.
The next release of BRL-CAD will include an improved "iges-g" that will also handle IGES BREP files of a limited variety. These files must contain IGES FACE, EDGE, LOOP, and VERTEX entities (the first release of this converter will be limited to planar faces).
> Iam asking this in order to save me a few months work of rebuilding a vehicle > built in UCLID.
The next release of BRL-CAD will also include a EUCLID-G converter that converts what EUCLID calls a "decoded" file into the BRL-CAD format. This decoded file contains an ASCII representation of a facetted approximation of the solid model.
Neither of these converters are available until the next release. Both will be producing a variety of NMG objects that are not supported in the current release.
Hope this helps, -John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
John C. Stauffer <13746sta@kcu303.bv.com> writes:
> Have there been any proposals to allow for the creation of BRL-CAD model BReps? > I realize that there would probably be a lot of work involved (and I'm > expecting a negative reply), but I was curious if any thought had been given to > B-Reps at all. Is there anyone else out there that would like to see this?
As Gomer would say "Surprise, Surprise, Surprise!!!". The BRL-CAD development team is hard at work on NMG's. This new type of BRL-CAD solid will allow BRL-CAD users to create BREP objects. Initially, we will be limited to planar-face objects, but plans are already being made for extending that to Trimmed-NURB faces. The next release is expected to include planar-face NMG's.
-John
> When we go into the MGED editor, our default window display is black. > This makes it difficult to see our menu bar and the model in our display > window. Is there a way to change the color of the display window ?
There is currently no way to change the background in MGED to anything other than black. However, it should be easy to see the border of the window and MGED menus, which are drawn in yellow. The default drawing color for an object is full-brightness red, which should be easy to see.
Something else may be going wrong.
> BRLCAD is installed on our Silicon Graphics workstation.
What kind of SGI, running what version of the operating system? What release of BRL-CAD are you running? 4.2? (MGED prints this as it's first message).
If problems persist, please include the output of the SGI 'hinv' command, so that we can see what kind of CPU and graphics hardware you have.
Best, -Mike
> We are creating models of gamma camera collimators in MGED:
Sounds pretty cool!
> This seems to work well for point sources, but when we tried to go to > more complicated light sources, we discovered that the intensity of the > shadow cast by the collimator dropped dramatically as the source size > increased.
This is a general problem with modeling area light sources when ray-tracing. The general strategy that I implemented in RT is to represent the light region as a cube (described simply by the radius of the inscribed sphere). When firing light visibility rays, the aim point is perturbed off the centroid of the light region by drawing three random numbers and perturbing the X Y and Z components of the aim point separately. This is sometimes called "dithering the light visibility ray aim points".
Sampling area lights with only one ray per pixel tends to produce very poor (noisy) results in the penumbra areas. And, you guessed it....
> Is there a way to increase the number of rays used by rt?
Yes. Use the -H# command line option, to "hypersample". The positive integer argument ("#") indicates how many _additional_ rays to fire for each pixel. Note that this automaticly causes "-J1" to be set, to cause the start point of the rays to be dithered (which is an entirely different matter from dithering the light aim points).
-H causes a simple average of the collected samples to be stored for each pixel. This is not the best strategy, but is useful when output file size is an issue. (More below).
How many extra rays will be needed depends on how much noise you are willing to tolerate, and how large your light source is. The larger the light source, the more rays you will probably need to get a "good" penumbra.
Typical values for -H range from -H3 to -H15. Note that this also results in a linear increase in runtime. If the runtime for -H0 is X, then the runtime for -Hnnn is (nnn+1)*X.
A more satisfying solution is to increase the resolution of the pixel grid appropriately, and then set -H0 and -J1. This stores one ray per pixel, but with full dithering enabled. After the image has been written, low pass filter the result and decimate. One cheap, dirty, and fast program for doing this is PIXHALVE, which uses a simple 5x5 filter pyramid, and reduces image size by half in both dimensions.
More sophisticated filter techniques can also be implemented.
If disk space for the (perhaps 4x or 16x larger) initial .pix file is not a problem, this strategy gives much better results than the comparable -H3 or -H15 approach, at identical runtime. (Not counting the one or two passes of PIXHALVE, which doesn't add much).
Why not experiment with -H and/or the filter & decimate strategies, and see if that meets your needs.
I'd love to see an image of one of your collimators sometime. Sounds like a fascinating application!
Best, -Mike
Glenn,
Located in the menu bar is the FILE menu which contains an item called "Show Info". Selecting this will bring up an information window that will display everything about the current solid/object.
I hope this helps.
-Bob
Harry Campell writes: > Here at TI we do a lot of modelling with Pro/Engineer. I would be very > interested in hearing how you convert those models into BRL-CAD, and the > code that allows you to do that. > > Thanks.
There are actually two codes invloved in conversion from Pro/Engineer to BRL-CAD. The first is a Pro/Develop code. This code uses the Pro/Develop library that you only get with the Pro/Develop option of Pro/E. The resulting executable, however, may be used by other Pro/E sites without a Pro/Develop license. This code installs an additional menu item (labelled "BRL-CAD") under Pro/E's "export" menu. Selecting this menu option activates the code. It then traverses the current object in the Pro/E session and writes assembly information (member names and transformation matrices) to an ascii file. Assemblies and sub-assemblies are handled this way. Parts (the actual solids in a Pro/E model) are output to the same ascii file in render format using the same routine that Pro/E uses to output objects in render format (render format is a variety of triangulated facets). One might ask, "Why not just use Pro/E's render export option?". This was my first idea also, but as it is implimented in Pro/E, the entire model is exported as a single solid made up of lots of triangular facets. I wanted to get the individual parts as seperate objects and the assemblies as groupings of these objects.
The second code converts this ascii file to the BRL-CAD format. It reads the assembly information and creates BRL-CAD groups. The parts (solids) are converted to BRL-CAD NMG or polysolid objects according to a command line option. A region is constructed for each part and any color assigned to the part in Pro/E is assigned to the region.
Note that the resulting BRL-CAD objects are facetted approximations of the actual Pro/E model. The quality of the approximation can be controlled on a scale from 1 to 10, where a quality of 1 may approximate a cylinder as a rectangular parallelepiped and a quality of 10 might break the cylinder surface into 20 rectangular facets. It's not that simple as the Pro/E routine actually uses a combination of chord height (distance from actual surface to facet approximation) and an angle control that provides additional improvement along curves with small radii.
Other properties that are used in a BRL-CAD region or group (such as ident number, los, material code, etc) could be set as user parameters in Pro/E and detected and assigned to the BRL-CAD group or region. This has not yet been implimented, and would require a list of user parameter names to be agreed upon.
Hope this answers your question.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
On Thu, 4 Aug 1994, john dome wrote:
> try setting your MANDIR to /xxx/brlcad/man/man and give it a go! > works for us. hope you find the package useful.
Thanks. That worked just fine. Sorry about the duplicate post on this subject.
John
I just implemented one using mged_source_file().
Usage: source file/pipe (read and process file/pipe of commands)
Like MSG(1), it decides whether to use POPEN(2) or FOPEN(2) by checking whether arg[1][0] is '|'. Is there anybody else I should inform about it?
Paul
Harry Campbell writes:
> You sent me some information about software that will convert > Pro/Engineer databases into BRLCAD databases. Let me make sure that I > understood you correctly. > > I need to have the Pro/Develop library. This I assume is a purchased > add-on to the Pro/Engineer package.
No, You do not need any additional Pro/Engineer modules. You will obtain the executable from us (ARL), and you will create a small ascii file called "prodev.dat" that informs Pro/Engineer about the BRL-CAD Application. The Pro/Develop library is only required if you are going to write your own Pro/Develop applications.
> I need to have this second piece of > software that converts the ascii output from Pro/Engineer into a BRLCAD > database. I will guess that this second file is going to be freely > available with the BRLCAD software distribution?
Yes, that is correct.
Hope this clears things up! -John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
>> The thing which inspired this: I was playing around today with sh_marble.c, >> trying to create a link in a chain out of a couple of tori and cylinders, >> and noticed that a change in region caused the turbulence to change. > >As an alternative, perhaps the origin of the texture could optionally be >anchored to a point in space. Either specified numerically, or >symbolically, something like a/b/crod.r/foo.cyl[TIP]. > >That would seem like a more direct method of achieving the control sought. > >> My proposed suggestion: For the next release of BRL-CAD, could you please >> add a field to "struct region" in raytrace.h which points to the directory >> entry from which the region was created, [...] > >It's encoded in the reg_name, in an inconvient format. Perhaps instead >of storing the name, the db_full_path info should be kept instead. Takes >about the same amount of space either way. An rt_vls_??? routine to >format the db_full_path info into a VLS string would be the only thing >needed to make the interface clean. > > Thoughts? >
After posting my suggestion, I developed a workaround that basically does the same thing. In the case of sh_marble, it involves adding an "identification" integer to marble_specific, in order to group marble regions by some arbitrary, MATPARM-specified value. IE,
struct marble_specific { struct marble_specific *forw; int ident; ... };
static struct marble_specific *Marble_Chain;
and
struct structparse marble_parse[] ={ {"%d", 1, "id", MARB_O(ident), BU_STRUCTPARSE_FUNC_NULL }, ... };
When the regions are being set up, the Ident field is inspected to see if a non-zero value was returned by rt_structparse(). If so, it is added to a singly-linked list headed by "Marble_Chain". The list is then scanned to find all regions which match the Ident, and VMIN/VMAX is called against all of them to find a bounding RPP which encloses all regions of note. Once the scan is completed, the results of VMIN/VMAX are then propogated to all matching regions. This can obviously be improved, but it presently gets the job done.
An example of this has been uploaded to wolf:/incoming/link.pix.Z. "Link" is a 512x512 raytraced image of a link out of a chain, using the modified marble shader to produce the body color and an experimental dielectric shader to do shadowing (although the specular reflection did get overexposed in order to better contrast the turbulence). With the exception of the upper right joint, the results are nice and smooth.
From a modelling perspective, this approach wins hands down over changing LIBRT, because it allows the modeller to explicitly tell the shader which *combinations*, taken together, are "cut from the same stone."
Finally, I can see where this approach would be useful in rendering sculpted CSG glass by allowing you to explicitly declare which regions are of the same composite material, so that refract.c doesn't have to guess which regions are continuations of one another. An example of what I am referring to are the "Hurricane Lamps" on page 24 of the April 1994 issue of Computer Graphics World, and the seams which show up at the top of the lamps where the tori joins the body but not elsewhere.
-Bill
I fixed a bug in rt_get_timer()/rt_read_timer() that was resulting in improper performance measurements of runtime on SGI systems.
I upgraded rt/do.c to use rt_get_timer() in place of rt_read_timer() so that I could get wallclock as well as CPU time. And then upgraded the RT statistics output to display the statistics in *all* the different ways that are commonly interesting:
Frame 0: 65536 pixels in 3.04 sec = 21551.98 pixels/sec Frame 0: 76479 rays in 3.04 sec = 25150.67 rays/sec (RTFM) Frame 0: 76479 rays in 12.16 sec = 6287.67 rays/CPU_sec Frame 0: 76479 rays in 3.17 sec = 24157.05 rays/sec (wallclock)
The first two are conventional (and now are correct!), while the second two are new.
The "rays/sec" figure is a measure of the performance of the SYSTEM (presumably "all" CPUs running), while the "rays/CPU_sec" figure is a measure of the efficiency of the system. "rays/sec (wallclock)", on an unloaded system, is an indicator of actual results, and takes into account I/O speeds, paging, OS overhead, etc.
One of the most important bugs pending for this release has now been fixed! Onward to the rest of them.
Best, -Mike
Robert,
You are running into problems with changes in the IRIX operating system. The errata are for the IRIX 4.0.5 operating system but you are using IRIX 5.2.
The Cakefile.defs need to be edited for the current BRL-CAD release to compile on IRIX 5.2. The following comments were extracted / edited from email traffic concerning the install:
If you set the SGI_CC environment to -cckr This should fix your problems.
setenv SGI_CC -cckr
Also take a look at the Cakefile.defs and see the new CFLAGS definitions (Irix 5.2 uses the R4000; in the Cakefile.defs the following under machinetype 5d is found)
/* For R4000 machines you might want to include -KPIC -kpicopt -mips2 on the next line */ /* instead of -G 15 */ # define GFLAG -KPIC -kpicot -mips2 /*# define GFLAG -G 15 */ /* ANSI+POSIX mode is used over ANSI, to get fdopen(), etc, defined. */ /*# define CC_OPTS GFLAG -ansiposix -DXLIB_ILLEGAL_ACCESS=1 */ # define CC_OPTS -cckr GFLAG -DXLIB_ILLEGAL_ACCESS=1
Bob Strausser SURVIAC ASO
B. Laut asks:
> Is there a translator for converting CATIA to BRL-CAD and/or vice-versa?
Not directly, but the next release of BRL-CAD will include a Pro/Engineer to BRL-CAD converter, and Pro/Engineer can eat CATIA models.
-John
If there are vertexuse attribute normal vectors in an NMG, "ev -w -n" will now draw them as little hairs, just like the face normal vectors.
John's additions to the sphere tessellator to *calculate* the vertexuse attribute normals works very nicely, for the one case I tried. Good show, John!
Best, -Mike
It has come to my attention THROUGH A COLLEAGUE'S PROBLEM that using a long file name in mged's "idents" command is causing a strange failure (unexplained "sh" message and the idents file getting only the first half of its normal output). So I got a test case which I am including twice in this message (for the sake of readability, the second one has capital letter X replacing the word "supercalifragilisticexpialidocioius"). The colleague got the problem when he used a full directory path in the filename argument.
Here is the original display of my test case:
mged> idents supercalifragilisticexpialidocioussupercalifragilisticexpialidocious compartment Summary written in: supercalifragilisticexpialidocioussupercalifragilisticexpialidocious Processed 1614 Regions sh: isticexpialidocioussupercalifragilisticexpialidocioussupercalifragilisticexpialidocious: not found mged>
Here is the display with X edited in place of the long word:
mged> idents XX compartment Summary written in: XX Processed 1614 Regions sh: isticexpialidociousXX: not found mged>
If the command is going to fail because of a long file name, please make sure it fails in a sensible way. Thanks.
Carl Moore wrote about -
> long file name in mged's "idents" command is causing a strange failure
I have tracked this down to some ancient string handling code in mged/utility1.c which was using small pre-allocated arrays to hold the file name. (Does the number 80 characters ring any bells for people?)
I replaced the code with new code using rt_vls (variable length string) calls, and it works fine now. I also had mged print out the Shell commands it was running, so you could see what it was up to.
The fix will be available in the Alpha release, Real Soon Now.
Best, -Mike
| Are there any plans to fix/replace/significantly change libfb or | if_X.c in TNR?
Libfb and if_X.c have changed very little since the last release.
| I am halfway through implementing 24 bit support and would rather not | put much more effort into this if I am only going to have to redo | things for TNR.
We would be happy to get your code. It shouldn't be very hard to merge with our version.
| I only have True Color 24 bits framebuffers so I don't have to worry | about 24 bit color maps. How common are Direct Color framebuffers?
Libfb implements a Direct Color model (since back when real frame buffers were all 24-bit + colormaps and X didn't exist yet). So to do full libfb semantics on a True Color display you need to do software color mapping. The SGI X servers provide both True Color and Direct Color (though we don't use X for 24-bit color on the SGI's). I don't know how many other servers provide Direct Color.
- Phil
Are there any plans to fix/replace/significantly change libfb or if_X.c in TNR?
I am halfway through implementing 24 bit support and would rather not put much more effort into this if I am only going to have to redo things for TNR. I have things working well enough that I can now squirt 24 bit pix files to the screen which is all I need to get done for a demo on Wednesday.
I am currently going through all of the routines adding a switch to handle the 24, 8, and 1 bit code paths but don't know if I will finish it.
I only have True Color 24 bits framebuffers so I don't have to worry about 24 bit color maps. How common are Direct Color framebuffers?
thanks, --tim
> I run now in some problems running mged and xmged: > - mged attached to sgi displays a black window, program output flashes on > refresh so I think it could be a color map problem (?)
Inside cad/mged/dm-4d.c, you might need to add a few more "case" statements, so that the code looks something like this:
case INV_VGX: case INV_VGXT: /* VGX Turbo and SkyWriter */ case INV_GMDEV: /* GT graphics */ case INV_CG2: ir_is_gt = 1; ir_has_zbuf = 1; ir_has_rgb = 1; ir_has_doublebuffer = 1; break;
> - mged attached to X seems to work, on moss.g "ev all.g" works but the command > "facetize new.g all.g" causes a segmentation fault.
This is a known bug. BRL-CAD Release 4.0 and 4.2 will die like that on all platforms.
This is fixed in the development version of the software. We are in the final throes of getting the 4.4 Alpha release ready. 4 weeks after Alpha (internal tests) we will have a Beta release (for interested sites), and 4 weeks after that we will have a formal BRL-CAD 4.4 release.
> - xmged (on X) on the same command gives the messages: > "mged_nmg_doit: bad op 0" (repeated 6 times) > "facetize: no resulting region, aborting" > while "ev all.g" gives the same 6 bad op msgs and then core dumps writing > "db_free_tree: bad op". > > - xmged attached to sgi doesn't show the colormap problem but the NMG related > problems remains.
The fact that XMGED gives different error messages is disturbing. I would have expected it to fail in exactly the same way as MGED. :-) I'll check into this.
> BTW what's the difference between the 4.0 and 4.2 releases?
BRL-CAD 4.2 contains a small handful of patches, to keep up with SGI's continuously evolving and (only slightly) incompatible versions of IRIX.
Best, -Mike Muuss
This was first sent to the bugs list for the alpha test. I'm forwarding it to the main list because I'm more than a little impressed with what Mike has done to improve the speed of processing large models and also because there might be some people intrested in the discussion of swapping, paging and large models. Chris
Mike wrote: > The real problem here is that the subroutine rt_find_identical_solid() > has an O((nsolid/128)**2) search, in order to check to see if a new > solid about to be prepped is really an instance of an existing solid at > the same location and orientation. The reason for it being (nsolid/128) > and not (nsolid) is because there are 128 different solid hashes, > and rti_solidheads[128] heads 128 different linked lists of struct > soltabs. This reduces the search time by a constant factor, but does > not change the basic n**2 order of the search.
Very good point, I noticed the improvement when this code was installed. About an 8 or 10 times speed up in this stage of the prep code. Call it 12+ cpu minutes to 1.25 minutes. Now to track down the next slow part.
> This issue had come up once before, in terms of prep time for large > models. I had addressed this issue by speeding up the matrix > comparisons, and by permitting the rt_find_identical_solid() search to > spread across up to three processors. That provided perfectly > acceptable performance for models of O(5000) solids on ARL's multi-CPU > SGI machines.
Also, most of Mike's machines have a little more memory than mine. So the O(n**2) problem, while being very real, did not show the devistating VM crawl that shows up on a small memory machine.
> Chris is running on a single-CPU machine, has O(110,000) solids, and > lots of instancing, so this issue has returned. What is called for is a > less expensive algorithm. The current code searches the list of already > prepped solids to find other instances of the current solid.
As of last night O(500,000) and moving up. Each tree is O(2000) solids with out leaves and O(4000) with leaves, each target of interest is O(8000) solids. We are moving towards a scene with O(120,000) trees, O(500) targets of interest, O(10000) detail items (Telephone poles, roads, fences, dogs, cats, bears, sheds, churches et so forth).
We hope to be generating this sort of image sometime in the next two weeks. Oh yea, this doesn't include the 192 square kilometers of terrain data. That is also included.
Some comments on generating large models:
The size of our models are fairly large, but generally of O(10000) solids. It is only when we start combining them in interesting ways that the total size of the data base become large.
All of the large scale database generation is driven by control files describing placement of targets within the environment. I.e. where each tree goes, where each target goes, where each detail item goes.
These control files also describe transformations that help hide the fact that there are a limited number of types. For example, we only have 5 types of trees right now, but those trees get twisted, squashed, expanded, tilted and moved explicitly for each placement.
Each target can be individuly configured after the fact with anim scripts.
MEMORY: Somebody said: Swapping is BAD. This is not true. PAGING is bad.
The time to trace my complex images in a small memory box is not much different than the time to trace the same images in a large memory box. The reason for this is one Mike Muuss. The actuall raytracing is very memory coheasive. There is NO noticable PAGING going on during the tracing of a 180MB scene (Total size of rt process) in a 64MB machine.
The PREP time, on the other hand is very nasty and is memory dependent. The doubly linked list that Mike just added reduced the paging enormously while building the tree. The next step in the process seems to be doing an O(n^2) process as well, but I have not instrumented the code enough to be able to determine where this is happening.
Many thanks and Ataboys to Mike and his team.
> > By the way, this work was pretty easy, thanks to the new "multiple > rt_list per structure" support I added to rtlist.h a few weeks ago. > Without that support, this new algorithm would have been a pain to > code. Power tools!
Yes, a very nice addition. Now we can have cross threaded doubly linked lists to confuse the best of them. *GRIN* But this is a needed addition, thanks again.
Chris
From joe edward meier <jem@bruker.com>:
> If I am editting a large object/solid and I have the Angle Distance > Cusor (adc) showing and placed at say one end of the object, how can > I then change the view so that I see mostly the other end of the object, > without the adc moving also? I have not been able to figure out how > to do that.
Not sure exactly what you mean by this, but the ADC will not move when the view is changed. If you want to keep the ADC over a particular point in your model, you can use "adc xyz x_coord y_coord z_coord". This will position the ADC in front of the specified coordinates. You will need to execute the same command every time the view changes. Do an "adc help" for more info.
> I also was wondering how one does object selection via the keyborad? > If you have alot of objects displayed, then it can be imbossible to select > the object you want via the "object illum" command? > "press oill" will put you in object illuminate mode. "ill object" will illuminate the specified object and allow you to select which matrix along the path should be modified. One problem with this approach is that if the object appears in more than one path, you will get the message "object multiply referenced" and the "ill" command will fail. You can use "paths object" to see what paths the object appears in.
Hope this helps, -John John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
from Bruce C. Patterson (pattersb@uy1.eglin.af.mil):
> The ultimate goal is to use the Irma 3.2 USAF developed software package to > create images for optical filter construction. Irma 3.2 currently uses the > Advanced Computer Aided Design (ACAD) faceted model discription. Most of the > target models we require have been designed using BRL-CAD or FASTGEN. What > we need is an avenue that allows us to move BRL-CAD and FASTGEN models into > ACAD for internal component removal and facetization. What is the simplest > way to accomplish this?
"patch-g" will convert FASTGEN to BRL-CAD, but we don't have any ACAD converters. See forwarded message below:
-John
----- Forwarded message # 1:
Date: Wed, 10 Aug 94 23:01:23 GMT From: Mike Muuss <mike@arl.mil> To: Marlon Harris <harris@batman.dynetics.com> cc: John R. Anderson <jra@arl> Subject: Re: [Marlon Harris: ACAD conversion codes] Message-ID: <9408102301.aa26227@wolf.arl.mil>
> I would also like to find out if anyone has developed a code that can > convert ACAD models to BRL-CAD component models. We have used ACAD to > convert a file to BRL-CAD format, however when it was loaded into > BRL-CAD it turned out to be one solid object instead of a component > model.
Tools to convert between BRL-CAD and ACAD in both directions are provided by the ACAD group at Lockheed (formerly General Dynamics), not as part of BRL-CAD. You should probably address your difficulties to J.P. Abalane (unsure of spelling) in the ACAD group. Sorry I can't provide more information.
Best, -Mike Muuss
Leader, Advanced Computer Systems Team Survivability and Lethality Assessment Directorate The US Army Research Laboratory APG, MD 21005-5068 USA
<Mike @ ARL.MIL>
410-278-6678 Voice 410-278-5058 FAX
----- End of forwarded messages
Several people have recently asked whether they will have to re-register with us or send in a new copy of the agreement form in order to obtain a copy of BRL-CAD Release 4.4.
The answer to this question for FTP ("free") users is ---> NO <---.
Release 4.4 is a maintenance release, and is covered by your existing agreement. The files for anonymous FTP will be encrypted using the same encryption key as Release 4.0 and 4.2 were.
For folks who purchased the mag-tape version from SURVIAC, I don't know whether there will be an additional tape-copying fee or not.
We anticipate undertaking a complete re-registration, with slightly updated and streamlined agreement forms, for BRL-CAD Release 5.0, which is scheduled for the end of FY95 (e.g. October 95, if not before).
Best, -Mike
I'm pleased to announce that the Beta-test version of BRL-CAD Release 4.4 (numbered 4.3 to distinguish it from the final Release) is now available.
All current BRL-CAD users are invited to FTP the Beta test materials from host FTP.ARL.MIL, directory brl-cad/Rel4.3/src, where you will find these files:
-r--r--r-- 1 mike graphics 7228576 Nov 19 04:13 cad4.3.tar-a.Z -r--r--r-- 1 mike graphics 2136727 Nov 19 04:15 cad4.3.tar-b.Z -r--r--r-- 1 mike graphics 1696243 Nov 19 04:15 cad4.3.tar-c.Z -r--r--r-- 1 mike graphics 2134725 Nov 19 04:16 cad4.3.tar-d.Z -r--r--r-- 1 mike graphics 1063147 Nov 19 04:16 cad4.3.tar-e.Z -r--r--r-- 1 mike graphics 745347 Nov 19 04:17 cad4.3.tar-f.Z -r--r--r-- 1 mike graphics 1892694 Nov 19 04:17 cad4.3.tar-g.Z
The encryption key for these files is the same as was used for Release 4.0 files.
There is a mailing list which is being used for discussion of bugs and issues uncovered in the Beta test period. This list is <cad-beta@arl.mil>, and you are welcome to subscribe to it even if you are not planning to Beta-test the software. Send E-mail to <cad-beta-request@arl.mil> to join the list.
The Beta release contains a shell script "cadbug.sh" which all Beta-testers are encouraged to use to report bugs in Release 4.3 with.
I apologize for the 3 week delay in getting the Beta release out. The arrival of our first SGI "TFP" system with R8000 cpus caused far more work in porting and bug hunting than had been anticipated. During the Alpha test period more than 175 bug reports were filed. Of those, only 21 remain open as we enter the Beta test period. I'm confident that this will be a very successful release, even in light of the substantial amount of new code since Release 4.2 (more than 200,000 lines!)
Best, -Mike
Using a method suggested by Mike Muuss, I have added a rudimentary sketch capability to MGED. This allows a user to build a sketch (limited to a single loop currently) in MGED, and then extrude that loop linearly in any direction (except parallel to the plane of the loop). The sketch is actually an n-Manifold Geometry (NMG) loop and when extruded, it becomes an NMG solid.
The user begins by creating a nearly empty NMG using the "make" command in MGED. The only geometry in an NMG created this way is a single "wire" loop, consisting of a single edge that runs to and from the same vertex.
After selecting this new NMG for editing (you may have to use the "sed" command, since the new NMG is very tiny - one vertex), the user selects the only edge by using the "pick edge" menu item and selecting with the mouse anywhere in the MGED window (the only edge will be selected).
Next, the user may select "split edge" and then use the mouse to indicate where the new vertex should be positioned. The first mouse selection, splits the selected edge and places the new vertex at the mouse location creating a loop of two edges (looks like a single line). The currently selected edge automatically shifts to the new edge, and the user may select another location. This selection splits the current edge and moves the new vertex to the selected location, creating a triangular loop. The user may continue to build the sketch by repeatedly selecting points with the mouse or using the "p" command.
There is also a "delete edge" menu item that will delete the currently selected edge, and a "move edge" menu item to allow moving an edge perpendicular to its length.
The sketch is mantained always as a loop, and when the user is satisfied with the sketch, the "extrude loop" menu item may be selected to produce an extruded solid. This works similar to other solid editing items as the user may use any number of mouse point selections or "p" commands to produce different extrusions until the desired effect is accomplished. Then the usual "ACCEPT" or "REJECT" menu item is selected.
The "split edge" and "delete edge" menu items are currently restricted to use on "wire" loops or "wire" edges. They will not work on solid NMG objects. "Move edge" will work on simple NMG solids as well as "wire" edges, and the "extrude loop" will only work on NMG's that contain a single "wire" loop.
Most of these capabilities are in the current BETA release, but the "extrude loop" wasn't completed until last night (Nov 21). It will appear in any new BETA releases and in the final 4.4 release.
-John
SURVIAC full support users have two choices for acquiring the version 4.4 release (beta and final). Either:
1. Download the source files from the ftp site in the encrypted form and contact the SURVIAC ASO for the decryption key
phone: (410) 273-7794 fax: (410) 272-6763
or
2. Forward a 1/4" cartridge tape or a 4mm DAT tape to the SURVIAC ASO to have the files written to the tape and mailed back. The mailing address is:
SURVIAC ASO 1003 Old Philadelphia Road Suite 103 Aberdeen, Maryland 21001-4026
Bob Strausser SURVIAC ASO
Using a method suggested by Mike Muuss, I have added a rudimentary sketch capability to MGED. This has been accomplished by including NMG's to the "make" command, allowing the creation of a nearly empty NMG. The only geometry in an NMG created this way is a single "wire" loop, consisting of a single edge that runs to and from the same vertex. New menu items have been added to the NMG solid edit menu that allow splitting edges. The user may select "split edge" and then use the mouse to indicate where the new vertex should be positioned. The user may continue to build the sketch by repeatedly selecting points with the mouse or using the "p" command. There is also a "delete edge" menu item that will delete the currently selected edge, and a "move edge" menu item to allow moving an edge perpendicular to its length. Note that these menu items will not currently work for the typical NMG solid, but only "wire" loops. The "move edge" will work for simple NMG solid objects. The sketch is mantained always as a loop, and when the user is satisfied with the sketch, the "extrude loop" menu item may be selected to produce an extruded solid. This works similar to other solid editing items as the user may use any number of mouse point selections or "p" commands to produce different extrusions until the desired effect is accomplished. Then the usual "ACCEPT" or "REJECT" menu item is selected.
-John
Based upon the feedback we have received since the Beta test period has started, a number of small but important improvements have been made, primarily in the realm of portability, but also some new features.
The most notable new features are courtesy of Timothy Smith and the crew at Sun Microsystems, who have contributed a really nice X11 module for LIBFB which supports 24, 8, and 1 bit visuals. They have also contributed improved Sun XGL support for MGED which is compatible with Solaris and can take advantage of Sun graphics accelerator hardware.
Sun is working hard to make their systems run BRL-CAD "as well as an SGI does". While they still have some work to do in the area of graphics performance, their RT performance is astonishingly good. In my very rough initial testing, a 50 MHz (each) 4-CPU Hyper-SPARC SS10BSX system with Solaris 2.4 (summary RTFM=178.69) ran more than 2.5 times as fast as a 1-CPU 150 MHz R4400 based SGI Indigo**2 with Irix 5.2 (summary RTFM=63.89). More than just MegaHertz matters!
As before, the beta test sources can be found on host FTP.ARL.MIL in the directory "brl-cad/Rel4.3/src":
-r--r--r-- 1 mike graphics 7233902 Dec 2 00:32 cad4.3.tar-a.Z -r--r--r-- 1 mike graphics 2146289 Dec 2 00:33 cad4.3.tar-b.Z -r--r--r-- 1 mike graphics 1706300 Dec 2 00:33 cad4.3.tar-c.Z -r--r--r-- 1 mike graphics 2136811 Dec 2 00:34 cad4.3.tar-d.Z -r--r--r-- 1 mike graphics 1007393 Dec 2 00:35 cad4.3.tar-e.Z -r--r--r-- 1 mike graphics 744433 Dec 2 00:35 cad4.3.tar-f.Z -r--r--r-- 1 mike graphics 1893163 Dec 2 00:36 cad4.3.tar-g.Z
Please report any difficulties you might encounter, using the "cadbug.sh" script.
Enjoy! -Mike
If I'm not mistaken, Mike Muuss said: < Date: Fri, 2 Dec 94 6:34:05 GMT < From: Mike Muuss <mike@ARL.MIL> < To: CAD@ARL.MIL < Subject: 4.3 Beta2 < < Sun is working hard to make their systems run BRL-CAD "as well as an SGI < does". While they still have some work to do in the area of graphics < performance, their RT performance is astonishingly good. In my very < rough initial testing, a 50 MHz (each) 4-CPU Hyper-SPARC SS10BSX system < with Solaris 2.4 (summary RTFM=178.69) ran more than 2.5 times as fast < as a 1-CPU 150 MHz R4400 based SGI Indigo**2 with Irix 5.2 (summary < RTFM=63.89). More than just MegaHertz matters!
Thanks for all of the nice words, Mike.
One minor correction: The system you have has 4 SuperSPARC processors, not 4 hyperSPARC processors. The hyperSPARC was just recently introduced and only FCSed yesterday. It is a 100MHz part that is roughly a third faster (according to the SPEC numbers) than the SuperSPARC processors you currently have. I have not had a chance to benchmark the hyperSPARC yet but hope to soon. The hyperSPARC has a smaller cache than the SuperSPARC so it will be interesting to see how it compares on the RT benchmark.
--tim
A new release of BRL-CAD is coming soon, so for those of you who have been using FASTGEN, here is an update on what to expect in the new release.
PATCH-G has been updated to take advantage of the new NMG capabilities in BRL-CAD. Plate mode components in FASTGEN are described as triangular faces with a specified thickness. These triangles are converted to NMG triangular faces and then extruded by the thickness of the plate to create a true solid in BRL-CAD. Previously, these components were converted by building an ARB6 (an extruded triangle) for each triangle in the plate mode object. This resulted in cracks or overlaps where two adjacent triangles were not coplanar. The new method extrudes the entire surface of triangles to produce a single solid with no cracks or overlaps for the plate mode object. Volume mode component in FASTGEN may also be described using triangular faces. These are also converted to BRL-CAD NMG solids. There is a user option to have the final BRL-CAD NMG solids written to the database as polysolids rather than as NMG's. The NMG's are more flexible and carry more information about the solid (topology as well as geometry), but for most current vulnerability analyses the polysolids will be adequate. The remainder of the FASTGEN object types are converted to corresponding BRL-CAD solids in the same manner as the previous release.
A FASTGEN4 to BRL-CAD converter has been added to the BRL-CAD package. This code was described in an earlier note to this list. It converts the new NASTRAN-like FASTGEN4 to BRL-CAD in a manner similar to the PATCH-G converter.
FASTGEN users reading this should also be aware of the BURST code written by Gary Moss. This code produces shotline output for parallel ray grids or for bursting (disribution of rays emanating from a single point). This output may be used with the Air Force Point Burst Damage Assessment Model (PDAM), and is is in a format suitable for filtering to an unformatted file to mimic FASTGEN output. Leonard "Bud" Bruenning <bruennin@uv3.eglin.af.mil> is the keeper of the BURST code if you need more information.
There is also an RTG3 code to produce parallel ray shotlines from a BRL-CAD model in a form like that produced by the old GIFT code (3 components per line). This shotline output is compatible with the COVART family of vulnerability anaysis codes.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
> John, > > Great work. As someone who is constantly representing BRL-CAD to > the outside world (JTCG, TILV, etc., etc.), I really appreciate > the importance - political as well as technical - of your > accomplishment. Thanks for making my job much easier.
My pleasure, Thanks! > I had a thought (unaccustomed as I am ....): In the process of > bisecting the "cracks" or "overlaps" between plates, you had to > determine the intersection line between the plates on the top and > bottom surfaces, right? That means that - at that time - you new > where the edges of the plates were. Well, I would like to point > out that lots of people would really like the ability to determine > just that: folks who are trying to propagate ballistic shock, > folks that are trying to determine the extent of panels for blast > loading, folks that are trying to establish zones for combined > blast-fragment synergistic effects, etc. Is there potential > spin-off here?
Maybe, but let me give you a few more details. Then you can tell me if we are talking about the same thing.
The plate mode objects in a FASTGEN description are typically described as a series of triangles, each with an assigned thickness. This method is normally used for shapes that cannot be described any other way in FASTGEN. Things like aircraft skin, tank turrets, ... anything that is not a box, cylinder, cone, sphere, ellipsoid, or torus. In the previous version of the "patch-g" converter, each triangle was converted to an individual solid by extruding each triangle individually. The resulting solids produced the "cracks" or "overlaps" with their neighbors. The method I used, does not require bisecting these "cracks" or "overlaps". I combine all the triangles from one component into a single NMG surface (the surface consists of the triangles from the FASTGEN component). I then make a copy of this surface, calculate new plane equations for triangular faces (translating each plane by the assigned thickness in the appropriate direction), and (using the new plane equations) calculate new vertices at the intersection of the faces (much detail omitted here). More faces are added to connect the outer edges of the original surface and the extruded copy, resulting in a true NMG solid.
So, the "cracks" or "overlaps" had been occurring where two triangles of a plate mode component adjoined. This is just a artifact of the method used to describe the component (triangular facets used to approximate smooth surfaces). I doubt that is what you are looking for.
However, the new NMG capability in BRL-CAD may be what you want. As well as storing geometry, the NMG objects contain topology as well. If I have a face of an NMG object, I can easily get a list of its edges and vertices. It is simple to go on from there to find neighboring faces and their edges and vertices. The entire object can be traversed in this way. Also, edges in an NMG object are labelled as "real" if they represent real edges and are not just the result of tessellation. For example, a pilots head might be described as an ellipsoid. Currently, if this is converted to an NMG object, it will be approximated by a series of facets. None of the edges in this NMG will be flagged as "real" edges. If, however, his head was described as a box, all the edges in the corresponding NMG would be "real".
Just to be sure you are aware of what's coming, we are currently working to extend NMG objects to allow TNURB (Trimmed Non-Uniform Rational B-spline) faces instead of just planar faces. When this is complete, tank turrets, a/c skin, (and pilot heads, too) may be described without approximating facets.
I think I got carried away with this response, but does this sound like what you are looking for??
-John
The JTCG/ME ATV Subgroup task to develop a FASTGEN4 to BRL-CAD geometry translator has been completed. This capability will be distributed in the next BRL-CAD release.
The FASTGEN4 CHEX1, CQUAD, and CTRI elements (in plate-mode or volume-mode) are converted to the users choice of BRL-CAD NMG's or polysolids. In rare cases, the method used to create NMG's from plate-mode elements fails. When this happens, the converter makes a second attempt to convert the component by reverting back to the methodology used in earlier "patch-g" converters, i.e., each triangle in the plate-mode object is converted to an "arb6". CCONE1 and CCONE2 elements are converted to BRL-CAD "gentgc" solids with internal "gentgc" solids subtracted if necessary. CSPHERE elements are converted to BRL-CAD "genell" solids with interior "genell" solids subtracted for the plate-mode cases. CHEX2 elements are converted to BRL-CAD "arb8" solids. CLINE elements are converted to BRL-CAD "gentgc" solids with inner "gentgc" solids subtracted in the plate-mode cases. CLINE elements that share endpoints with other CLINE elements in the same component are connected by spheres ("genell" solids) at the common endpoints (again, with interior spheres subtracted in plate-mode). These "genell" solids have the same radii as the connecting CLINE elements. HOLE and WALL elements are handled by region subtraction in BRL-CAD.
Unique names are assigned to all the resulting BRL-CAD components. If the FASTGEN4 model includes $NAME records, that text information is used to build a name within the constraints of the BRL-CAD name-space. If no $NAME record is found for a component, a name is constructed from the group and component numbers. The user may specify a "-w" flag on the command line to get a warning for every component that does not have a $NAME record. The components are grouped according to the FASTGEN4 "group" number, and a top level group named "all" (containing all the other groups) is created.
BRL-CAD "region id" numbers are constructed as the FASTGEN4 "group number" times 1000 plus the FASTGEN4 "component number".
A BRL-CAD manual page has been prepared and is included in the BRL-CAD distribution along with the FASTGEN4 to BRL-CAD converter ("fast4-g").
This converter has been tested using two models received from Mr. Marty Lentz - the F4E and the MH60. Of the 954 components in the F4E, 918 are converted on the first try and an additional 32 are converted on the second try (using "arb6" solids). This leaves 4 components that failed to convert. The MH60 has 1016 components, 1006 converted on the first pass and 8 more converted as collections of "arb6" solids. Two components of the MH60 failed to convert. All six of the components that failed to convert can be attributed to errors in the FASTGEN4 model. The original MH60 FASTGEN4 model was modified during the development of this converter to eliminate some of the FASTGEN4 errors, and the results quoted are for the modified model. The F4E was not modified in any way.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
The HyperText Markup Language (HTML) files may be viewed using NCSA Mosaic. Available via FTP from: ftp.ncsa.uiuc.edu or unofficial mirror sites: ---------------------------------------------------------------------------- USA: site: sunsite.unc.edu location: /pub/packages/infosystems/WWW (all versions) Australia: site: miriworld.its.unimelb.edu.au location: /pub/clients/ (all versions) Europe: site: ftp.luth.se location: /pub/infosystems/www/ncsa (all versions)
site: ftp.sunet.se location: /pub/mac/Mosaic (mac version) /pub/pc/windows/www/Mosaic/ (pc version) /pub/www/Mosaic (X version)
Hope this helps, -John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
Hi Joe -
In your letter you didn't mention which version of BRL-CAD you are working with. That makes something of a difference. If you are running Release 4.0, 4.1, or 4.2, the NMG support is not very robust.
As of now, there are very few NMG-related commands in MGED, although those few deliver a lot of functionality. You can use MGED's built-in "help" command to give you a 1-line summary of each:
ev evaluate combinations into polygons for display. facetize evaluate region into an NMG solid, and store in database.
In addition, the "make" command will now (in 4.3beta2) allow you to create an NMG which is a loop of a single vertex and a single edge ("make name.s nmg"), which you can then select for solid editing ("sed name.s"). Using the solid editing menu, you can then use the "pick edge", and "split edge" items to sketch out a 2-D curve in the plane of the current view. Select another view, pick "extrude loop" from the menu, and then *voila!*, you have built yourself an NMG solid! The extrusion can also be controlled via the "p" command, where you specify the XYZ coordinates of a point to lie on the plane of the extruded face.
There are a few other commands that interact with the NMG support, such as "fracture", which can be useful for debugging, and "debugnmg".
For a fascinating visual display of how the NMG boolean library implementes the "ev" command, say "debugnmg 3" before running the "ev" command.
Suggestions for additional NMG support in MGED are welcomed. I've got plenty of ideas, myself. Contributions of code implementing those suggestions are even more welcome! :-)
Best, -Mike
>a quick qestion for a novice -- what do i need to use the "html" files? > >(and is there a freeware source on line?)
The most popular browser for WWW/html documents is "Mosaic" available from ftp.ncsa.uiuc.edu. It requires motif to compile, or you have to trust the binary they have out for ftp (ugh).
If you don't have motif and don't want to trust the NCSA binary out for ftp (and why should you?), I'd suggest getting a copy of "chimera" from ftp.cs.unlv.edu. It only requres X and the athena widget set to compile.
Lee
| Yes. There is an enhanced version of MGED known as XMGED that requires | Motif in order to compile and run. Regular MGED continues to be available | and supports X based on libx11 alone, but has a much more primitive | interface. We may someday build an XMGED that does not depend on Motif, | depending on how users like the current one and where they think it should | go (e.g. Mike's group is playing with a Tcl/Tk MGED).
It -is- a nice feature of BRL-CAD that it does not entirely depend upon Motif to work. Some vendors (read DEC) still insist upon "nickel-and-diming" you at every opportunity, and for awhile their Motif upgrade was big, BIG, $$$. Although, in fairness, they have become more reasonable of late.
If applications such as XMGED become the norm, then it would be nice to see BRL-CAD eventually adopt a standard metaphorically akin to LIBPKG which would allow the utilities to support differing windows technologies (ie, plain X, X-with-Motif, X-under-Windows, Windows-NT, etc).
Perhaps a better metaphor would be LIBFB instead of LIBPKG. Actually, maybe expanding LIBFB to include windowing might be a consideration. Have LIBFB return to the application the graphics ability of the "frame buffer," and there decide whether or not to support a windowing option. And, if selected, let LIBFB absorb all of the hardware/vendor-dependent stuff.
Thoughts?
-Bill
I implemented a new output item called "scaled_los" to complement the existing output item "los". The values of these two output items are
los line-of-sight distance through the current partition, equivalent to (d_in - d_out). This is unchanged from previous versions of NIRT(1).
scaled_los scaled line-of-sight distance through the current partition, the product of los and the region's solidity (also known variously as its percent LOS, thickness factor, and volumetric percentage of material (!)). This is a brand-new feature.
I would have called the new output item "weighted_los", but apparently that might have caused confusion in the MUVES community, where weighting an LOS means multiplying it by the region's solidity AND ITS DENSITY. Of course, to use this new output item one must tailor the output formats as explained in the man page nirt.1. Paul
Those of you trying to compile the 4.3beta3 release on IRIX 5.2 will need to modify the Cakefile.defs file. There are bad side effects from using -Wl,-w2 -- if *any* warning message is printed by the loader, it seems to abort the load. This wasn't the intention.
For the time being -Wl,-w1 seems to be having the desired effect.
The whole "-w" option on LD is not documented by SGI at all, but their Hotline suggested using it in place of the documented "-S" option, which does not work. Sorry about the blundering around in the dark.
Best, -Mike
Per Chris Johnson:
Hello, here is the exhostive 0-15 on -w options. only the valuses 1-3 are acceptable. 1 = surpress all warnings plus all errors (default) 2 = error off on any warning or error 3 = surpress all warnign s plus all errors AND error off on any warning or error.
Looks like -w1 is the best we can do, then.
-Mike
When writing portable BRL-CAD code, please do not use the #elif preprocessor directive. This is new with ANSI C, and can not be processed by earlier, non-ANSI compilers.
Best, -Mike
AJ wrote -
> I will be traveling to work in the United Kingdom (University College > London) for two years beginning in May 1995. I gather it would not be > proper to just take a take of the current version of BRLCAD with me to > England. I also understand it would not be proper to just ftp a new > copy (without some prior formal arrangement for permission acquire new > versions by anonymous ftp and decrypt the package in another country). > > Approaching the British Foreign Office to obtain a copy of BRLCAD for > a United States national seems a bit awkward. Nevertheless, it may be > the proper approach to obtaining permission to use BRLCAD in England. > > So, I would appreciate advice about the appropriate procedure to follow > to obtain BRLCAD for use in England.
Congratulations on your foreign appointment! UCL is a cool place, and I'm sure you will have a splendid time there.
Thanks for asking what the proper procedure is. It is no longer necessary to involve the Foreign Office for overseas distribution. Fortunately we were able to eliminate that step many years ago.
BRL-CAD agreements are executed either by (a) a private individual, when their use is for personal use, or (b) a corporation or institution. In your case, I believe that your current agreement is executed by your current University. Since you are temporarily changing affiliations, simply fill out and return an agreement through UCL, and rest easy.
Since you already have the BRL-CAD materials, and UCL is (will be) a registered site, you are free to take whatever materials you like along with you in whatever manner is most convenient to you. Your associates here in the States can continue to work with your original set.
That's all there is to it! Hopefully sending in the one form won't be much of an inconvenience to you. It will be a big help to us!
THE BIG PICTURE
I was recently informed that BRL-CAD is the U.S. Army's #1 "Technology Transfer Product". It's also the only one that is still available without charge to any who want it. These are both points of pride for those of us who developed it.
In this time of downsizing, it is important that the usefulness of our BRL-CAD work continue to be recognized, to help us protect our funding line. The "survey" form that you return with your BRL-CAD agreement is our primary source of documentation to support our position.
Over the years I have worked to streamline the agreement process as much as possible. I like to believe that the procedure and forms we have been using since Release 4.0 started are not overly burdensome. As we come up on Release 4.4 Mary Monk and I will be working on an improved version of the forms and procedures to further streamline distribution to foreign sites.
My thanks to all of you, the BRL-CAD users, for making BRL-CAD a success!
Happy Holidays! -Mike Muuss
This evening, while tracking a performance issue on the Sun XGL display manager relating to drawing speed of dot-dashed lines in MGED, I added two new options to the "e" and "ev" command in MGED:
-s Draws all subtraction and intersection solids with solid lines, rather than using the usual dot-dash pattern.
-v When used with EV, shade polygons with per-vertex surface normals, rather than flat-shading them with the face normal. This makes much "prettier" looking curved shapes, for presentations.
Best, -Mike
I don't know why the remote framebuffer library never had a routine to support remotely defining the shape of the cursor. However, Sue Coates' bug report is quite accurate -- it doesn't work. I defined a new kind of remote framebuffer PKG to implement the missing routine: MSG_FBSETCURSOR.
In order to prevent having a new LGT get stuck waiting forever for the MSG_RETURN package when using an old RFBD framebuffer server, I made if_remote.c send the request with flag MSG_NORETURN. This way old framebuffer servers will log the message "pkg_dispatch: no handler for message type 131, len 20" and harmlessly ignore it, without hanging the user application (like LGT).
libfb/if_remote.c revision 9.20, libfb/pkgtypes.h revision 9.4, fbserv/fbserv.c revision 10.7, fbserv/fbserv.h revision 10.3, rfbd/rfbd.c revision 10.7.
Best, -Mike
Bob wrote -
> As far as I am aware, there is no current editing capability in either > MGED or XMGED for NURBS. I believe the current beta release does permit > some editing of an NMG but not NURBs.
In the Beta release (BRL-CAD Release 4.3), there exists some modest MGED editing capability for *both* planar NMGs and the existing NURBS solids. In the case of NURBS solids, the editing is restricted to moving control points around using the mouse. This is probably acceptable for simple "by eye" touch-up, but is a far cry from "sophisticated" B-spline editing.
Best, -Mike