/*******************************************************************/ /* REMINDER * REMINDER * REMINDER * REMINDER * REMINDER * REMINDER */ /*******************************************************************/
SURVIAC will be offering its two introductory BRL-CAD training courses according to the following schedule:
BRL-CAD COURSE | DATES ----------------------------------------------|------------------------------ 101 Construction, Interrogation, and Imaging | 22-23 Feb 95 17-18 May 95 102 Geometry Conversion | 24 Feb 95 19 May 95
Advanced courses are available upon request to address in-depth BRL-CAD topics and specific student requirements. For additional information, contact Lisa Garriques at the SURVIAC Aberdeen Satellite Office via the routes provided below.
*************************************************************************** * __ __ ___ __ __ __ __ __ * * |__ | | |_/ \ / | |__| | |__| |__ | | * * __| |__| | \ \/ _|_ | | |__ | | __| |__| * * * *************************************************************************** * The DoD-sponsored Survivability/Vulnerability Information Analysis * * Center (SURVIAC) Aberdeen Satellite Office (ASO), located adjacent to * * the Aberdeen Proving Ground in Maryland, provides full service * * distribution and support for the BRL-CAD model for a $500 fee. This * * includes the initial distribution of the model and documentation, * * installation support, maintenance release updates, technical support, * * and future activities information. Additionally, we sponsor an annual * * BRL-CAD User's Group Meeting each fall. Training courses are also * * offered periodically each year. * * * * SURVIAC provides the DoD community with a one-stop resource for all * * aspects of nonnuclear survivability, lethality, and mission * * effectiveness, which includes dissemination of information and models * * to support this community. * *************************************************************************** * SURVIAC Aberdeen Satellite Office Phone: (410) 273-7794 * * 1003 Old Philadelphia Road FAX: (410) 272-6763 * * Suite 103 E-mail: cad-dist@arl.mil * * Aberdeen, MD 21001-4011 lisag@arl.mil * ***************************************************************************
To our Air Force and Navy users: good news! ARL has been authorized to directly distribute the "BURST" code (see attachment). BURST provides FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files.
BURST will be a standard item in the next full BRL-CAD distribution. If you require a version of BURST for use with BRL-CAD Release 4.4, please drop a line to John Anderson <jra@arl.mil> or FAX 410-278-5058 to alert him to your need. I imagine that as an interim measure we will provide a supplemental encrypted TAR file on the anonymous FTP server as our primary means of making this software available to the community.
Please join me in saying a warm "Thank-You" to Mr. Stovall!
Best, -Mike
----- Forwarded message # 1:
Date: Fri, 27 Jan 1995 15:56:57 -0600 (CST) From: "STOVALL, ROBERT L." <STOVALL@eglin.af.mil> Subject: Burst Release Authority
Dr Deitz and Mr Anderson,
Recently, the CHICKEN LITTLE program office has received another request for the "burst" code. We have reassessed our previous need to maintain control over this code and have determined that it would be in the best interests of the DOD Vulnerability/Lethality community to release control of this code to you for inclusion and distribution with the BRL-CAD package if you see fit. If you have any questions, please contact me at DSN 872-9243 [(904) 882-9243) or my technical representative, Mr. Bud Bruenning, (904) 729-6497.
Mr. Robert Stovall Joint Munitions T&E Program Office
----- End of forwarded messages
On Feb 1, 2:52am, Mike Muuss wrote: > Subject: "BURST" now available with BRL-CAD 4.4 > > To our Air Force and Navy users: good news! ARL has been authorized to > directly distribute the "BURST" code (see attachment). BURST provides > FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files. > > BURST will be a standard item in the next full BRL-CAD distribution. If > you require a veOn Feb 1, 2:52am, Mike Muuss wrote: > Subject: "BURST" now available with BRL-CAD 4.4 > > To our Air Force and Navy users: good news! ARL has been authorized to > directly distribute the "BURST" code (see attachment). BURST provides > FASTGEN3 and FASTGEN4 ray files from BRL-CAD geometry files.
Mike, This is perhaps an oversimplification. ;-) BURST provides Shotline files and Burst Point Library files which contain the same information used by the PDAM code and previously provided by PGEN from FASTGEN descriptions. In any case, the format of BURST's output files are syntactically different, so a conversion is necessary to read them from codes like PDAM. The file burst/burst.format describes the file formats so that it is straightforward to write a Fortran or C routine to read them. They are much easier to for a human to read than the compressed Fortran format previously used.
-Gary
--
"Sometimes nothing fails like success." - W. Wayt Gibbs [Scientific American, Sep 1994, "Software's Chronic Crisis"]
> When attempting to select a region in "Object Illum", we get an error > message in mged that says: > > rt_id_solid: u_id=x43 > rt_nul_import unimplemented > init_objedit(<region name>) > > The sequence ALWAYS occurs when we do the following in mged: > > E <region name> > E: <n> vectors in <m> sec > > > Then select "Object Illum" > highlight the region, select with the middle mouse button. > > Are we doing something wrong, though. Perhaps we shouldn't be editing > using E instead of e, or...?
Yes, editing only works if you view the object using the "e" command. The "E" command and the "ev" command evaluate things below the region level, and are not compatible with either Solid or Object editing.
I admit that it isn't a good error message. Formerly there was a better message, someone needs to find out why it no longer prints. Probably some new checking code got inserted before the old checking code.
Best, -Mike
Glenn, The messages you are getting are from 'rld' the run time linker which resolves dynamic shared objects. Under Irix5* the default build uses shared libraries, which will really save you a lot of disk space. The BRLCAD4.4 should be adding the '-rpath' option on the link command followed by a path specifying where to find the DSO's. Check to make sure that this this option is being used and if so, check to make sure the path looks correct. If this option is not being used run the the 'sh machinetype.sh -v' script and make sure your machine is being recognized as 'MACHINE=6d'. If the path looks incorrect check the setting of LIBDIR in 'Cakefile.defs'. If you are not installing in the default '/usr/brlcad' directory make sure to run the 'newbindir.sh' script which will replace '/usr/brlcad' with new correct install location in several places including 'Cakefile.defs'. Using the '-rpath' option on the load command puts the DSO resolve path in the executable so be sure not to move your libraries after the build. There are other ways to tell 'rld' where to look but I think fixing the install is the best approach.
- Keith
I am trying to get BRL-CAD running on a SUN SPARC 10 running SunOS 4.3.1. The program compiles without any errors and mged works without any trouble. I can create models with mged. I can ray-trace the models without errors but when I try to display the pix file in the frame buffer I get the following error:
fb_open (0x8c70, "/dev/debug", 1024, 1024) fb_write (0x8c70, 0, 0, 0x8d50, 1024) the last line is repeated for every line in the pix file.
any suggestions about this problem.
--Glenn Allison, MSIC, (205) 313-6251
> We have been using the ProE to BRL converter in the latest release of > the BRL-CAD package, and greatly appreciate its being included. Now > the question has arisen as to whether anyone has developed a > capability to import BRL models into ProE.
Not yet, but I hope to provide such a capability in the not too distant future.
> We got a ProE model of an airplane from one of the airframe > manufacturers, converted it to MGED, then added a number of internal > features. We'd like to ship those internal features back to ProE, > without having to re-create them in ProE. Has anyone written anything > to allow this to be done? > You might try "g-iges" and then try importing the IGES file into Pro-Engineer. That won't work on the version of Pro/E that I am running (I still have version 13!!!), it expects only surface files, not solid models. If Pro/E has improved its IGES capability beyond what was available in version 13, there might be a chance.
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
>1) Does XMGED support RIB output for RenderMan?
There is an outboard program to convert NMG solids to RIB polygons. It's called "nmg-rib".
>2) Is there a port of XMGED for Linux boxes (without Motif)?
You'll have to run "mged". XMGED requires MOTIF.
>3) Are any models created for BRL-CAD available for viewing? >(Specifically, that Tank car on the BRL WWW pages look >really cool... and any other train-related ones?)
Look in the "db" directory of your distribution. The ".asc" files there can be turned into BRL-CAD binary databases using the asc-g program.
>4) Since I am already a registered user of BRL-CAD, how can I >get the crypt key for the latest version?
I think your 4.0 decryption key will work on the 4.4 distribution.
Lee Butler
Jim Urbanowicz asks:
> Is millimeters the only output unit of measure for rtg3?
No. Actually, inches is the only output unit for RTG3.
> If I call up a model inmged, and set the local units to inches, > then run the model through rtg3, will the line of sight thicknesses > for each ray trace be output in inches? Thanks.
Yes. See above. Note that the "units" command in MGED only affects what you see while running MGED. It specifies what units you want to work with while using MGED with that particular model. The model is assumed to be stored in mm and RTG3 uses a conversion factor to produce inches.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
James,
You can fix this by adding
XMged*fontList: fixed
to an Xresource file (i.e. .Xdefaults) and then using "xrdb -load .Xdefaults" to load this info into the X server. Or you can edit dm-X.h by changing the corresponding value in the fallback_resources and then recompiling.
Brl-cad release 4.4 already has these modifications. If you haven't already done so, I'd recommend getting the latest release. I hope this helps.
-Bob
Kathryn M. Cook writes:
> > I am familiar with creating BRLCAD models using the standard primitives. I have > seen references in the mail traffic about NMG solids. I have not been able to > locate any documentation on how to create and work with these solids. Can they > be created and edited in xmged?
The NMG solids are still experimental and not fully supported yet. You can make an NMG solid of extrusion in MGED. The same should work in XMGED, but I don't think it does. Here is the procedure:
After starting MGED, make a nearly empty NMG solid by "make s.nmg nmg". Replace "s.nmg" with any solid name you like. Then use the mouse to select "Solid Ilum" (or type "press sill"). This will get you into Solid Edit Mode. Then use the middle mouse button to select your NMG solid (or type "ill s.nmg"). This selects the new NMG solid for editing. Next, select "pick edge" from the Solid Edit Menu and move the mouse to the MGED display window (not in the menu) and click the middle mouse button. This selects the only edge in the newly created NMG. Now select "split edge" from the Solid Edit Menu. You may now draw a loop of edges by clicking the middle mouse button at the locations of the desired points (or use the "p" command). The result is a closed loop of edges. You may continue to select edges, split edges, deletes edges, and move edges until you have the shape you desire. When you are satisfied with the loop you have created, you can extrude it by changing your viewing direction and selecting "extrude loop". Clicking the middle mouse button will extrude the loop to the selected point. You may continue selecting different points until you are satisfied with the final NMG solid. Then select "Accept Edit" (or "press accept").
> Is there any documentation on creating > polysolids (I also seen reference to these)? I am familiar with FASTGEN > triangles and SHAZAM points and faces. Do they work in a similar manner? I > have used patch-g to translate my FASTGEN models but I can't figure out how to > edit the resulting faceted components or how to add additional similar > components.
There is no way in MGED to create a polysolid, but you can write a program that uses "libwdb" to create polysolids. You would need the following routines: mk_id() to create an ID record for the new model. mk_polysolid() to make a header record for the polysolid mk_poly() or mk_fpoly() to make each face. See libwdb/poly.c for these routines.
The BRL-CAD polysolid is similar to the FASTGEN triangles in that they both describe a solid by listing the vertices of planar faces. The polysolid may have up to 5 vertices per face and does not have the sequencing complication that FASTGEN triangular facets do. The polysolid faces must have their vertices listed in CCW order (use the right-hand rule) so that the outward normal is well defined.
> Thanks,
You're welcome. I hope this helps,
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
> > This is possible even in release 4.0, using the '-X80000000' option > > to RT and sending the output to "pl-sgi" or to a file, and then > > viewing with "pl-sgi" or with the "overlay" command in "mged". > > > > The platform that we are working on is Sun Sparc server 10, solaris 2.3. I created a mged file trial.g containing a box and I tried to raytrace it using the following command: > > rt -a90 -e0 -s32 trial.g box > output.pix > > Next, I tried to see the interception animation by typing > pix-fb output.pix > > I do not get an image file. Instead, I got only lines of fb_open, fb_write and fb_close commands. I had also tried viewing the pix file in mged using overlay command, but I still do not get any image. Would appreciate very much if you could assist.
The problem here is that environment variable FB_FILE has not been properly set. Run "man brlcad" and read the section on FB_FILE. Considering you are using Solaris, I suggest that you will get much better results using the new versions of the display software in BRL-CAD Release 4.4.
What this will show you is the optical image of the box. In order to see the ray history file, which is what I think you mean when you say "interception animation", you need to do what I wrote earlier. Try:
rt -P1 -X80000000 -a90 -e0 -s32 -o output.pix trial.g box > output.pl
Then view the ray history file in MGED like this:
mged trial.g e box overlay output.pl
And then rotate the view as you please.
Best, -Mike
Rick,
The problem isn't with the geometries having different codes, its the assessment models which use different codes. For example ...
MATERIAL VAST COVART HEIVAM -------- ------ -------- -------- 1 steel steel(BHN 100) magnesium 2 rha steel(BHN 150) aluminum 3 fha steel(BHN 200) titanium 4 cast iron steel(BHN 250) cast iron 5 aluminum steel(BHN 300) fha 6 magnesium steel(BHN 350) steel 7 copper titanium rha etc.
So the material assigned in the target description is correct for a given assessment model but if another analyst wants to use that geometry with a different assessment model, all of the material code assignments must be checked against the alternate model's understanding of what a material code number of xx is. This is also true for updated versions of assessment codes (COVART 4 brought HEVART and HEIVAM internally so the material definitions had to be made common).
This being the case, even with the ability to read the material ids from the geometry database, the codes must still be verified to match whatever assessment model is being used (and a conversion utility must still know what id table was used in the geometry so it knows what id numbers to swap to get to the desired id table).
Too good to pass up my two cents worth,
Bob Strausser SURVICE Engineering
Dave asks -
> Is the free unsupported version of brlcad the same as the supported > version (the source code)?
The software provided is identical in either case. The only difference is human time and supplies:
*) Select the FREE distribution if (a) you have InterNet FTP access +and+ (b) you don't need assistance installing/configuring/using the software.
*) Select the SUPPORTED distribution if (a) you need the software on tape -or- (b) you desire assistance installing/configuring/using the software.
Best, -Mike
--PART-BOUNDARY=.19506131039.ZM10807.bturner-pc Content-Description: Text Content-Type: text/plain ; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Zm-Decoding-Hint: mimencode -q -u
On Jun 9, 9:46am, David S. Pesetsky wrote: > Subject: HTML to PS? > I'm looking for a way to convert the HTML pages that come with the > distribution to postscript so I can print them all at once. >-- End of excerpt from David S. Pesetsky
You may find Jan K=E4rrman's html2ps perl script useful. I've used it with perl versions 5.001 and 4.0 (the latter is distributed with SGI IRIX 5.3). This script does not handle in-line images (substitutes [IMAGE]).
Exerpt from the html2ps info page <http://www.tdb.uu.se/~jan/html2ps.html>: | The Perl script html2ps is an HTML-to-PostScript converter. Perl is | available from any comp.sources.misc archive. | | The latest version of html2ps is available via anonymous ftp from | ftp.tdb.uu.se in /pub/sources/html2ps as a tar file: | html2ps_0.1beta.tar. You can also fetch the files individually from | the same directory: README, html2ps,, html2ps.1 (a manual page) and | manpage.txt (a plaintext version of the manual page).
Best, Ben
--PART-BOUNDARY=.19506131039.ZM10807.bturner-pc--
Phil Cogan (ZEROMOLD@aol.com) writes: > I've been using mged for a couple of months and recently tired compiling > tmged. The compile went smoothly, however when I went to run tmged, all I > got was was a blank window itled Tkmged and the standard mged window. > > All the tcl/Tk demos work flawlessly. > > What did I do wrong?
To try out the sample user interface, you need to do the following: Find "tmged.tcl" (it should be in the tmged directory. For this example, we will assume it is in the subdirectory "../tmged"). Then, at the mged> prompt, type "source ../tmged/tmged.tcl" (or whatever path is appropriate). You should then get the sample interface (a button menu and an interaction window).
The main reason the interface is not loaded automatically is that users may wish to write their own, customized, interfaces in Tcl/Tk for use in tmged.
If you want this to be loaded automatically each time you start tmged, copy "tmged.tcl" to "~/.tmgedrc" (or put the "source foo/tmged.tcl" command in your ~/.tmgedrc file).
Hope this helps, Glenn
This evening I got the prototype versions of RTSYNC and RTNODE running. Right now I've got 3 systems with a total of 38 CPUs rendering the viewpoint from my MGED session as fast as they can into a shared framebuffer. I'm getting about 0.5 frames/sec, at 512x512, and that isn't close to the final number of CPUs....
I set the MGED to spinning, and it's really cool to watch the framebuffer flipping up a new image every other second, fully ray-traced.
Until the HIPPI framebuffer gets installed, I think I'm going to be Ethernet limited.... Ugh.
Progress! -Mike
This evening I added the "pathlist" command to MGED at the request of Glenn Durfee. This new command makes it easy for TCL functions to build menus containing the list of paths below a given combination.
With Glenn working on TCL/Tk "power functions" for creating new geometry, and with PJT working on a TCL/Tk "power function" for point-n-click solid editing, I'm really excited about where MGED is heading!
Best, -Mike
This evening I added the "OED" command to MGED, allowing a direct transition from VIEW state to ObjectEdit state in one step, without having to go through the steps of "press oill", "ill leaf", and "matpick a/b".
This should further improve our ability to drive MGED from TCL scripts.
Usage is "oed path_lhs path_rhs"
Examples: "oed all.g box.r/box.s" and "oed all.g/box.r box.s"
The matrix which will recieve the object edit transform is located at the implicit slash where the space between path_lhs and path_rhs.
Best, -Mike
In the experimental version of TCL MGED I've changed the internal handling of the left and right mouse buttons. They now generate "L" and "R" commands with the same syntax as the "M" middle-mouse command. The default bindings are for zoom-in and zoom-out as before, but this new arrangement allows users to re-bind the mouse buttons as they wish. For example, to make all three buttons act as the middle mouse has always done, these two commands would suffice:
proc L {up x y} {_mged_M $up $x $y} proc R {up x y} {_mged_M $up $x $y}
Best, -Mike
Kathy,
The rtweight program is part of the distribution but it is not compiled in the default configuration. The reference program is in the "rt" directory called "viewweight.c". You will need to modify the cakefile to compile the program. It compiles and runs on the SGI without problem.
reposted for your information: ******************************************************************** Date: Thu, 12 Jan 95 12:31:32 GMT From: Jim Hunt <jehunt@arl.mil> Subject: Re: rtweight Message-ID: <9501120731.aa07047@whim.arl.mil>
Rtweight was a piece of sample code to show one way that weights and centroids can be calculated using librt. It is not very "portably" written and thus not part of a standard compile. Find it under your source tree in the rt directory (file name "viewweight.c"). Here is the patch for the Cakefile if you want to try to compile it:
*** Cakefile.orig Thu Jan 5 08:56:04 1995 --- Cakefile Thu Jan 12 07:27:14 1995 *************** *** 8,14 **** #define SRCDIR rt #define PRODUCTS rt rtrad rtpp rtray rtshot rtwalk rtcheck \ rtg3 rtcell rtxray rthide rtfrac rtrange \ ! rtregis rtscale #define SRCSUFF .c #define MANSECTION 1 --- 8,14 ---- #define SRCDIR rt #define PRODUCTS rt rtrad rtpp rtray rtshot rtwalk rtcheck \ rtg3 rtcell rtxray rthide rtfrac rtrange \ ! rtregis rtscale rtweight #define SRCSUFF .c #define MANSECTION 1 *************** *** 40,45 **** --- 40,52 ---- CC CFLAGS -c vers.c CC LDFLAGS RT_OBJ vers.o LIBRT LIBFB LIBFB_LIBES LIBRT_LIBES LIBES -o rt + + #define RTWEIGHT_OBJ RTUIF viewweight.o + + rtweight: RTWEIGHT_OBJ LIBRT_DEP LIBFB_DEP + sh ../newvers.sh version "RT Weight" + CC CFLAGS -c vers.c + CC LDFLAGS RTWEIGHT_OBJ vers.o LIBRT LIBFB LIBFB_LIBES LIBRT_LIBES LIBES -o rtweight #define RTRAY_OBJ RTUIF viewray.o wray.o ********************************************************************
Bob Strausser SURVIAC ASO
Today Paul Stay and I converted all the routines in LIBNURB over to using the t-NURBS data structures from the NMG package. Thus, all "snurb" structures are now "face_g_snurb", and all "cnurb" structures are now "edge_g_cnurb".
This means that routines in MGED and LIBRT can directly use the LIBNURB routines for processing t-NURBS NMG objects. This has been imporant for us to have in furthering our trimmed-NURBS capability, and is an (overdue) good thing to do.
For those of you who may have programmed using the old LIBNURB data structures, when you get the new code (currently found only in the development tree), you can use the attached "ed" script to convert your code over to the new form.
Best, -Mike
f g/u_knots/s//u/gp g/v_knots/s//v/gp g/struct cnurb/s//struct edge_g_cnurb/gp g/struct snurb/s//struct face_g_snurb/gp g/ cnurb/s// edge_g_cnurb/gp g/ snurb/s// face_g_snurb/gp g/knots/s//__KNOTS__/g g/\\.knot/s//.k/gp g/->knot/s//->k/gp g/__KNOTS__/s//knots/g f w q
The key to your difficulty is highlighted by the message:
fb_open( 0x3e000, "/dev/debug", 512, 512 )
This means that you neglected to set your FB_FILE environment variable.
Check out "man brlcad", and "man 3 libfb". You might also try running the "fbhelp" program to get it's (extensive) help message.
Best, -Mike
The FRED code distribution is handled out of the Dayton, Ohio office of Optimetrics. The point-of-contact for FRED distribution is Susie Pryce. Her phone number is 513-264-1466. The FAX number there is 513-264-1414.
I hope this information helps.
Jim Rapp
I've updated the source to pixhalve, so that it now converts from RGB to YUV, then applies a 3x3 filter to Y and a 5x5 filter to U and V, so as to preserve the maximum amount of detail when the destination is NTSC television, the main application of this tool.
It does make a difference, but for the Bradley image that I tried it on, it's very subtle. Perhaps in other images it will be more beneficial. In any case, I'm leaving the code installed.
Best, -Mike
I've created two new utilities, pix-yuv and yuv-pix. They write Abekas-compatible .yuv files. This provides some additional options for dealing with Abekas files.
It uses the same code as libfb/if_ab.c
Best, -Mike
I've created a new utility, called bary, to compute weighted sums of points in 3-space. You specify "sites" on the command line and then in the input stream you give lines of one-weight-per-site. It has options to normalize the weights (thus giving you barycentric combinations of the sites) and to copy unmolested any/all fields beyond the first three. The motivation was PHD's request for a ray-traced plot of unit cube data into an equilateral triangle. I can easily imagine other such visualization applications where the tool would be of use. And, most surprising, it even has a man page. Paul
The IGES5.1 support is designed for basic solid entities and for spline surfaces. It will also import an IGES5.1 drawing entity (option -d) which you can position to use as a view template. A minimum of two templates (front and side, top and side, back and bottom, etc.) are required to provide the l-w-h data for each of the solids you will build from the templates. The templates if viewed from its "side" will be a single line (like the edge of a piece of paper) but from its "face" will provide a transparent line drawing guide (with dimensions if in the original IGES5.1 drawing).
Bob Strausser The SURVIAC ASO
I have added a new command to MGED. The command is "nmg_simplify" This takes an existing NMG solid and attempts to represent it as a simpler BRL-CAD primitive and build that simpler solid. Currently, it can recognize arb4's through arb8's and circular cross section cones and cylinders. The syntax is:
nmg_simplify [arb|tgc|poly] new_solid existing_nmg_solid
The default behavior is to attempt to build and arb first, if that is not possible, it attempts a tgc, and if that is also not possible, the last resort is to build a polysolid. If an optional arguement is provided, then only that particular type of solid is attempted.
This command was inspired by a request from Bill Hruz and uses routines developed for the Pro/E to BRL-CAD translater.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
On Wed, 21 Feb 1996, David J. Yemc wrote: > I am trying to work with the HF solid in BRL-CAD, v4.4 running on a DEC alpha. ... > Can anyone point me in the proper direction?
I've worked with the hf. There are some problems with ray-tracing the hf with the released version.
My height field is a 257x257 array of unsigned shorts (2 byte int).
mged> in hff.s hf dfile="01.hf" fmt="us" w=257 n=257 shorts=1 file2mm=31.25 v=0,0,0 x=1,0,0 y=0,1,0 xlen=256000 ylen=256000 zscale=1
That should all be typed in on one line, but I've broken the line for readability. As far as I can tell this means:
dfile="01.hf" The data is in the file "01.hf" fmt="us" The data is unsigned shorts w=257 257 samples wide n=257 257 samples long shorts=1 1 short per sample file2mm=31.25 heights are multiplied by 31.25 to get mm size v=0,0,0 origin of HF is at 0,0,0 x=1,0,0 X axis aligned along 1,0,0 y=0,1,0 Y axis aligned along 0,1,0 xlen=256000 X axis is 256000mm ylen=256000 Y axis is 256000mm zscale=1 Heights are not scaled
Lee Butler
Lee A. Butler Attn: AMSRL-SL-BV Internet: butler@arl.mil U.S. Army Research Laboratory Phone: (410) 278-9200 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
On Mar 12, 9:32am, Thomas M. Browder Jr. wrote: > Subject: burst > I am having trouble trying to produce the documents available with the > burst package. Is it possible to have a README file, or something similar, > to give the instructions for the proper syntax for appropriate troff > commands? The same goes for the 'talk' subdirectory where it appears there > is an interesting paper, but no clue for novices about how to produce it.
Tom, It's been lots of years since typesetting of these documents has been attempted by me (the author), and I can't test it out conveniently because I'm no longer familiar with how/which TROFF fonts and macro packages are configured on our various workstations and servers. However, if you have a troff capability, it used to work as follows:
1) For burst/paper, typeset with a command like:
"troff -mm -T[printer] paper.mm"
where the [printer] selects the target printer type (ie -Ti300 for an 300 DPI Imagen). This assumes that the ".tbl" files have been preprocessed with there ".mm" source files (ie "tbl ids.tbl > ids.mm"). Note that "paper.mm" sources all other needed files.
2) For burst/talk, you need to use the "mv" macros instead of "mm" on and run troff on each ".mv" source file:
"troff -mv -T[printer] *.mv"
If you have a "domv" script in that directory, it is intended to be used like so:
"domv [file]"
where [file] is missing the ".mv" suffix. This script would need to be changed to select the proper printer, etc. Currently it pipes the output through "dimp" which is a Device Independent Troff preprocessor for the Imagen printers, and then it pipes the result to "ipr" which is our Imagen spooler.
If you have problems, perhaps someone who still uses TROFF can be of more help. NOTE that the burst paper is published in at least one BRL-CAD Symposium Proceedings and if you have the set of blue manuals that came out with BRL-CAD Release 4.0 and beyond, it's in Volume III, The BRL-CAD Applications, on a page marked "88" at the bottom, also "V3S07A00" in the lower right corner (the page numbering is extremely not useful in this document).
Hope this helps, -Gary
--
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Gary S. Moss email: moss@arl.mil _/ _/ Computer Scientist WWW: http://web.arl.mil/~moss _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
On Wed, 5 Jun 1996, COOK-KM-KATHY (156791) wrote:
> Does there exist any method or routine to convert a BRLCAD geometry to > VRML/Open Inventor(*.iv) format? The platform indepentent VRML viewers and > open inventor routines (which come with SGIs) would provide a convienent way to > display/present a solid read-only representation of a BRLCAD model without > ray-tracing multiple views. > > SGIs Showcase software will allow open inventor files to be embedded into a > presentation. The geometric model can then be positioned to any convienent > view at will using the mouse. Future versions of other presentation software > will probably allow insertion of VRML objects. > > Are there any plans to develop such a tool in a future release of BRLCAD? I > assume this would require exporting a representation of the evaluated objects > in a form similar to nmg.
There is a primitive "g-vrml" converter that will be in the next release of BRL-CAD. It is primitive in that it does not take advantage of all the capabilities of VRML. It does handle the geometry, and colors, but all light sources are reduced to point sources. Also relfection, transparency and textures are not handled yet (I don't recall how much of that VRML will actually do). You are correct in your expectation that this would require exporting a representation of the evaluated objects in a form similar to nmg. In fact, the converter produces NMG objects, then outputs them in VRML format. This means that "g-vrml" will only convert what our NMG codes can successfully handle, and while this is not 100%, recently we have seen about 95% success.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
I wrote some software and have made it free to download at www.ontv.com called "webfetcher" that should work for anybody that needs to download large manual/code sets from the web. It runs on most all platforms. Not pretty, but it should work pending a CD run. I am a serious fan of not cutting down trees.
I have added an "a_ray_length" field to librt's application structure. This is intended to work similar to "a_onehit", and has been implemented in much the same way. If this field is set to a non-zero value, then ray tracing is stopped as soon as we get beyond the "a_ray_length". The raytracing is done in increments of the space partitions, so this will not stop at exactly "a_ray_length", but it will stop before raytracing any space partition beyond "a_ray_length". I tested this out on the bradley and found that it works as I expected and does in fact reduce the time. Of course, if this is used on a very simple model, you will actually increase the raytrace time.
Both "a_ray_length" and "a_onehit" can be specified and raytracing will stop as soon as either one is satisfied.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
For anyone out there using BRL-CAD, there is finally a Unix flavor available natively for the PowerPC-based Apple Macintosh. Specifically, it is mklinux running on a Mach microkernel. Currently, it only runs on PPC601 chips (PM 6100, 7100, 8100), and the official release is in September. It is possible to purchase a reference release on CD for $10 now or download the rather large files online. Anyone interested should see these sites:
http://www.mklinux.apple.com and http://www.gr.osf.org/~stephen/linux.html
If anyone does successfully port BRL-CAD to MkLinux, please let me know.
Matt Warner
> I got the embarrassing problem of having .g files, but no adequate version of > g2asc for them, although I still have the right machine (a SGI iris3130) ! > My .g files were made with mged version 3.7, and I do not have this version > handy.
It turns out that you are in luck -- I grew up in an IBM mainframe envirnoment (long ago), and upwards compatability is something that I work hard to maintain in BRL-CAD.
Binary ".g" databases from BRL-CAD Release 2.0, 2.3, 3.0, 3.7, 4.0, and 4.4 are all upwards compatible, meaning that databases created on software with a smaller number can be read with more recent software.
(The reverse is sometimes, but NOT ALWAYS true -- if you write a database on a higher numbered version of the software, it may or may not be readable by a lower numbered version, depending on whether you happen to invoke any of the newer features or not.)
Also, the ".g" format databases are directly binary compatible between SGI 3030, SGI "4-D", Sun-3, Sun-4 (SPARC), and Alliant computers.
So you can just move your old ".g" file from the SGI 3030 onto a modern SGI or Sun workstation running Release 4.4, and pick up where you left off.
Best, -Mike Muuss
Senior Computer Scientist Ballistic Vulnerability/Lethality Division Survivability and Lethality Analysis Directorate The U.S. Army Research Laboratory Attn: AMSRL-SL-BV APG, MD 21005-5068 USA
My E-mail is <Mike @ ARL.MIL> My World-Wide-Web URL is http://ftp.arl.mil/~mike/
410-278-6678 Voice 410-278-6656 Secretary 410-278-5058 FAX
Carl wrote -
> In mged (at least the way I have it here at ARL), there are some functions > available on the Function keys on a Silicon Graphics terminal.
> I do not see any description of these in the on-line help provided in mged.
These are SGI-specific features.
On an SGI, you can get information about any of the buttons and knobs in MGED by pressing and holding the HELP button on the button box (upper left button), then pressing the button or twisting the knob you want help on.
Here is a quick summary:
F1 Toggle depthcueing F2 Toggle Z-clipping F3 Toggle perspective on/off F4 Toggle Z-buffering F5 Toggle Lighting model (flat -vs- smooth shaded polygons) F6 Select next perspective angle from list: 30, 45, 60, 90 degrees F7 Toggle MGED faceplate off/on F8 Toggle menu F12 Zaps knobs/sliders back to zero
You can ascertain the status of the vendor-specific features currently in effect by running the command "dm set" -- that will print the vendor-specific settings of the current display manager.
Best, -Mike
Ken,
I have added the support for plate mode wedges as described below in patch-g.
> 2. 'inside' solids were NOT generated and subtracted for 'plate' mode > wedges. Inside solids were generated/subtracted for all OTHER plate > mode objects. > This should cover your bug report for the patch-g convertor. We should make arrangements to get the updated source or executable to you.
-Bill
-- Bill Mermagen Jr.
James Urbanowicz wrote: >I'm having problems with the "area" command in xmged. When I "E" an object, >then try to use "area" on it, all that is displayed is a line that says >something about area, but there is no output value displayed. Any ideas?
You've uncovered a bug. The output is going to stdout via another process (i.e. cad_parea) instead of being captured and stuffed into XMGED's command window. For now, you can look in the window in which XMGED was started to see the return value.
-Bob
This evening I converted the last of the old-style bit-vectors in raytrace.h over to a bu_ptbl variable-length pointer array. This affected the pt_solhits field in the partition structure; it's new name is pt_solids_hit, and it is now a bu_ptbl.
This means that when rt_boolfinal() needs to evaluate the boolean trees for the regions containing the solids found in each partition, rather than having to scan a bit vector of length "nsolids" for non-zero bits, it can just read the elements of a compact array. For models with more than about 80 solids this should be much faster. I don't have any time comparisons yet, because my development version is compiled -g (full debug, no optimization) while the 4.4 version is compiled -O (optimized), and that makes a big difference in runtime.
This change, combined with yesterday's work to eliminate the bit vectors from the soltab and region structures, the overall memory (RAM) consumption of LIBRT should be reduced, especially on larger models. To test this theory, I compared memory use on the benchmark run of the M35 truck. This database is very small, having 1126 solids in 893 regions.
Stage (VAX Ref) Release 4.4 Development Savings
The column marked "VAX Ref" is from the "pix" directory in Release 4.4, but it looks like it may actually represent Release 4.0 memory use. The pattern of "savings" between the development and 4.4 versions looks like it might be an artifact of the system malloc() routine obtaining memory from UNIX in bigish chunks, perhaps 128Kbytes at a gulp. I find the 6% savings of 128Kbytes to be of value, although I had hoped for something more dramatic. For models 50 times larger the savings should be substantial.
The 25% reduction in size over the old "VAX Ref" run shows that we continue to travel in the proper direction!
Best, -Mike
I've made the effects of the -J2 flags much more subtle, with the amplitude reduced in half, from +/- 1/2 pixel width to +/- 1/4 pixel width, and with period lengthened from 2 seconds to 10 seconds.
I'd be curious to see a "stationary camera" sequence calculated with this new code.
Best, -Mike
This evening I've moved two more sets of fundamental data-structure support routines into LIBBU: a nicely generalized version of the variable-length bit-vector routines from LIBRT, and a slightly improved version of that workhorse variable-length pointer-table-array routine: nmg_tbl() from the NMG library.
Delving into how rt_shootray() and rt_boolfinal() use bit vectors, I discovered that with the new bu_ptbl() at my disposal, I was able to make the partition boolean code *much* more efficient, particularly when large numbers of regions are involved. Code that had been O(nsolids)*O(nregions) became O(nsolids)*O(7) in runtime, and I think I see a way to make that still faster, to roughly O(7)*O(7).
Having the bu_ptbl() routines handy, I was also able to plug a "memory leak", regarding the "union cutter" structures not being properly freed from frame to frame in an animation. The problem had been that they were "bulk allocated" and diced up, after which time it was impossible to tell which items on the freelist corresponded to the head of the blocks (and thus should be handed to bu_free()), and which ones were "interior" to the blocks and should just be ignored. With the new routines handy, it was a simple matter to just collect a table of the things to be freed using bu_ptbl_ins(), and then free up all the items in the table at the proper moment.
Having power-tools like variable-length-strings and variable-length pointer arrays makes life so much simpler!
Onwards! -Mike
Paul of MIT asked -
> is RT automatically dividing between both processors in the benchmark?
By default, RT will use all the processors installed in the machine. It prints a message letting you know about this, right at the beginning. Here is an example:
BRL-CAD Release 4.5 Ray-Tracer Sat Aug 31 07:40:28 EDT 1996, Compilation 1691 mike@vapor.arl.mil:/m/cad/.rt.6d Planning to run with 24 processors <<<<<---------- db title: Gary Moss's "World on a Platter"
So if your machine has 2 CPUs installed, the default benchmark would use both CPUs. You can specify the -P flag to RT to select a different number of processors, a negative number indicates to use "all but" that many processors. For example, -P -4 on a 24-processor machine would indicate using 20 processors.
Best, -Mike
This is probably so obvious to most it doesn't need to be said, but I may not be as swift as some others and maybe there are some others like me.
While waiting for the new release that will work on IRIX 6.2, I simply copied the binaries and other files in my /usr/brlcad directory (and sub directories) from my SGI Personal IRIS 4D35 running IRIX 5.3 to a tar tape and moved them to my new Indigo 2, Impact 10000 running IRIX 6.2 and all that I've used so far (except patch-g) work quite nicely. As a matter of fact, some utilities like fb-pix that complained of a "sgi_getmem" error on my PI don't pesent such errors on the new Indy. (Perhaps the old PI is starting to wear out.) Anyway, for those who need a SIMPLE SOLUTION and DO NOT NEED TO COMPILE new code, this seems to work.
Bud Bruenning VOICE: (904) 729-6497 FAX: (904) 729-6400 214 Government Street, Niceville, FL 32578 e-mail: bruennin@eglin.af.mil (official business) bruennin@gnt.net (personal-unofficial)
Here is the information you need to enable your Web site (server) to allow viewing of AutoCAD or DXF drawings online with industry standard Netscape & Internet Explorer plug-ins.
MIME Types
MIME types are how the Internet applications know what type a file is This is similar to associating an application with a file on a Macintosh or associating a program with a file extension under Windows. In order for browsers to recognize AutoCAD drawing and DXF files so the appropriate action can take place (e.g. for the proper plug-in to be run in Netscape), the server needs to have a MIME type associated with the proper files. Contact your system administrator for more information on how to do this.
extensions Official MIME types
AutoCAD drawing .DWG or .dwg image/vnd.dwg
DXF .DXF or .dxf image/vnd.dxf
NOTE: On April 4, 1996 the IANA (Internet Assigned Numbers Authority) officially registered the following new Media Types, content-type/subtype pairs to SoftSource: image/vnd.dwg, and image/vnd.dxf.
After adding MIME types, your server may need to be restarted. Additionally, Netscape may have cached any images and associated MIME types you have previously viewed, so you may need to clean out the local cache before retrying images.
See the FAQ in the SoftSource Files plugin page for Optional Tags settings to control display of AutoCAD and DXF drawings at your site.
http://www.softsource.com/plugins/faq.html http://www.softsource.com
On Fri, 13 Sep 1996, Daniel J. Rinald wrote:
> 1. What is the current status on an mged to vrml(inventor) translator?
Look at "http://ftp.arl.mil/~jra/" and you will find that John Anderson has done some work in this area. Alas, VRML and BRL-CAD use radically different modeling constructs. It is therefore not always possible to build an elegant VRML representation of a BRL-CAD object. I suspect John's converter will be in the next release.
> 2. I wish to have an emissive target, i.e., no shiny reflections from ambient > lighting. Is this possible? I have tried setting material properties to > plastic, diffuse -> 1.0, reflect -> 0.0, and the rt ambient light option > A -> 0, but I still seem to get a strong reflective light back from > perpendicular facets to the eye. I even tried using "rt -l 1". Any thoughts?
Look at the "light" shader. It does essentially what you seek.
Lee
Daniel,
Concerning, the raytracing problem. The only way I know of getting rid of the eyepoint bright spot is to put your own light into the model. This of course creates a bright spot relative to the position of your light and its color.
I placed a sphere in a sample geometry, used the mater command to assign the material "light" and a color of black (0 0 0). I placed it below my geometry objects in the display and raytraced the view with ambient lighting set to 100%. This gave a very nice flat image without any bright spots from any light sources.
Without setting the color to black and setting ambient lighting to 0% gave a very nice halo effect image. A similar halo occurs with the default level of ambient lighting. Setting ambient lighting to 100% once again gives a nice non-spotlighted image. The black light source with zero ambient lighting gives a completely black image of course.
Bob Strausser SURVIAC ASO
I've recently had both the CyrixP166+ and the Intel Pentium166 in a Tyan Tomcat motherboard. I thought I'd pass on what I've learned to the list.
First of all, both parts performed flawlessly. I had no unexpected reboots or hangs.
The short of it is this:
Code Cyrix Intel -------------------------------------- Boot Delay Multiplier 5644 4244 RT Benchmark 26 43
Price (US$) 273 427
In both benchmarks a bigger number indicates faster operation.
The "Boot Delay Multiplier" calculation is an entirely integer process. Here the speed advantage of the Cyrix chip is clear. The speculative execution and/or branch prediction hardware pays off big. This is especially true since the Cyrix chip is running at 133Mhz internally, instead of 166Mhz.
The "RT Benchmark" is a raytracing application and does a relatively large amount of floating point operations in addition to some complex coding structures. While the Cyrix chip does well at optimizing the branching and looping conditions, the floating point unit just isn't a match for the Intel part. Floating point performance on the 133Mhz Cyrix is roughly equal to a Pentium90.
Certainly if you are running an ISP and just serving web pages and running E-mail boxes, I'd seriously consider the Cyrix part. Better, faster, cheaper for that type of application. It's also a bit faster at typical GUI painting for X-workstations (mostly integer bit shuffling).
There are two things that recommend the Intel part. The first is if you do more than a little floating point computation. If you're doing anything like scientific computing, I'd go with the Intel chip.
The second is if you want to run multiple CPU's on one motherboard. While Cyrix cpu's can support multi-processor motherboards, they use a different standard than the (proprietary) one that Intel uses. I've heard that dual CPU motherboards will soon be available for the Cyrix chips, but they don't seem to be out there today.
Lee Butler butler@hawks.ha.md.us
As nightfall does not come at once, neither does oppression. In both instances, there is a twilight when everything remains seemingly unchanged. And it is in such twilight that we all must be most aware of change in the air--however slight--lest we become unwitting victims of the darkness. --- Justice William O. Douglas
On Mon, 23 Sep 1996, Fredrick V. Heitkamp wrote:
> Mike, > > Thanks for the reply. I have yet another question. Is there a way presently, > to > convert IGES 114 to BRL-CAD?
No, the IGES 114 is a parametric spline surface, and we haven't done any support for that yet. You may be able to find some software to convert the 114 entities to 128 entities (NURBS) which we can import from IGES. Check at http://www.eeel.nist.gov/iges/igesTools.htm. They have some free tools available there.
-John
> Fred Heitkamp > WL/AAJS (formerly WL/AARI-1) > WPAFB OH > 513 255 5922 x271 > > > > >The BRL-CAD ray-tracer is rather nice. > > > >We have a BRL-CAD to ACAD geometry converter. I know that a flat-facet > >ACAD to BRL-CAD converter is "in the works", I don't know if it's done > >yet or not. It's a small project, about 10 pages of code. > > > > Best, > > -Mike Muuss > > > > Senior Computer Scientist > > Ballistic Vulnerability/Lethality Division > > Survivability and Lethality Analysis Directorate > > The U.S. Army Research Laboratory > > Attn: AMSRL-SL-BV > > APG, MD 21005-5068 USA > > > > My E-mail is <Mike @ ARL.MIL> > > My World-Wide-Web URL is http://ftp.arl.mil/~mike/ > > > > 410-278-6678 Voice > > 410-278-6656 Secretary > > 410-278-5058 FAX >
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
I've created a file in h/sed4 which you can use to feed to ED to mostly automatically convert a C source file written for Release 4.4 to the new bu.h and bn.h routines for Release 5.0.
I've run it on the NMG code in LIBRT, it required minimal hand-tweeking afterward.
Best, -Mike
Just to clarify: It is NOT necessary to apply h/sed4 to C source in order to get it to work with Release 5.0; the h/compat4.h header file is auto-included by raytrace.h, and provides 100% source compatability.
It just seemed appropriate to me that the libraries be internally converted, rather than relying on h/compat4.h.
Best, -Mike
On Mon, 14 Oct 1996 eorddyo@techunix.technion.ac.il wrote:
> Hello all, > I have some problems doing some things in Xmged I hope you will help me with,I am stuck in the > middle of a big project so fast replies will be greatly appreciated. > > 1)"rotobj" rotates an object a specified angle around the objects key point.I need to rotate an > objectaround a point of my choice, I thought "qorot" will do it but it doesn't seems to rotate > the object the way I wish. I may be doing something wrong???
"Qrot" allows you to rotate an object about an arbitrary axis. The regular "rotobj" rotates about the "X", "Y", or "Z" axes only.
> 2)is it possible to redefine an obejct's key point?
Yes, see the "keypoint" command"
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
Hi Rich -
> OK, I'll bite. What are v4/v5 (version numbers)? You've > got so many BRL-CAD irons in the fire that I'm not sure to which > new capability this message refers.
Oops, yes, that's likely to be confusing without context. Here I'm referring to the geometry database format. v1, v2, and v3 were the original ".g" (aka ".vg") formats for GED (pre MGED, pre BRL-CAD), v4 has been the production ".g" format for BRL-CAD since 1985, v5 is the fabled "new database" format that we've been talking about for the past year or so.
I realize these numbers are confusing, as there is also BRL-CAD Release 4.4 (production and 5.0 (development), FASTGEN 4 and FASTGEN 5, COMGEOM 4 and COMGEOM 5, SunOS 4 and SunOS 5, etc.etc. Seems to be "the time" for 4 and 5 as version numbers in mature products. *grin*
Anyway, the progress report was just to let you know that important pieces of the v5 database are beginning to solidify into actual working C code, rather than just being specifications on a Web page.
http://ftp.arl.mil/~mike/papers/brlcad5.0/newdb.html for the specs. :-)
Best, -Mike
On Mon, 4 Nov 1996, ndaglis@acs.itd.uts.edu.au wrote:
> Hi, > I've gotten brlcad to compile on my Linux box, and subsequently > hit a solid wall at every turn. My configuration is: > > Linux kernel 2.(something) > Motif 2.0 > X11 R6 - xfree3.1.2 > > The biggest problem I think I have is that when I do > xmged world.g all > > I get an error about the world.g file not being in the right form - > it says its lacking the header or something. > > Also xmged dumps core straight after it gives this error. > > > I'm that new to this that I don't now what it is I don't know about > getting this to work. > > Perhaps someone could direct me to a modern compiled version of > brlcad for linux. ie ELF, recent C libs, X11R6 etc. > > thanks ndaglis@acs.itd.uts.edu.au >
Here is a message I posted to "cad" earlier this year:
From jra@ARL.milMon Aug 12 14:50:57 1996 Date: Wed, 5 Jun 1996 08:27:43 -0400 (EDT) From: "John R. Anderson (USARL/SLAD/BVLD/VMB)" <jra@ARL.mil> To: Dwight M Evers <evers@plains.nodak.edu> Cc: cad@ARL.mil Subject: Re: [Q] Who has installed BRL on a linux box???
On 4 Jun 1996, Dwight M Evers wrote:
> Could someone give some helpful hints on installing brl-cad R4.4 on a > linux box??? > > -TIA > > ============================================================================ > | "...peace is a thing which a person > Dwight M. Evers | must be willing to fight for..." > evers@plains.NoDak.edu | > NDSU | -Abe Lincoln > ============================================================================ > ---------- Forwarded message ---------- Date: Thu, 28 Dec 1995 12:10:13 -0500 (EST) From: John R. Anderson (USARL/SLAD/BVLD/VMB) <jra@arl.mil> To: ged@walrus.arl.mil Subject: BRL-CAD 4.4 under Linux 1.2.8
I finally got around to installing BRL-CAD 4.4 on my PC. I am running Linux 1.2.8 on a Packard Bell with a Pentium 75 Mhz Processor and 16Mb of memory. My compiler is gcc version 2.6.3. I needed to make a few changes to get BRL-CAD compiled, here they are:
1. The makefile for cake ("cake/Makefile") calls lex to process "cake_s.l". There are some ifdefs in "cake_s.l" to account for the fact that "flex" (the GNU version of lex) does not define "yylineno". However, under this version of Linux, "lex" is defined as "flex -l". The "-l" option to "flex" tells it to be compatible with the orignal AT&T "lex". The result of all this is that the ifdefs are trying to correct for differences that aren't there. The easy fix here is to replace "lex" in the cake "Makefile" with "flex".
2. In libplot3, version 2.6.3 of gcc cannot compile plot3.c with the default O2 optimization. This has been reported to MIT as a compiler bug. The fix is to compile plot3.c with no optimization or use GCC version 2.7.2.
3. After compilation, "mged" worked fine, but "rt" complained: "db_scan ERROR: File is lacking a proper MGED database header". I'm not yet sure of the basic problem behind this, but it has to do with opening a file twice (once to get a file descriptor and once to get a FILE pointer). In "librt/db_open.c" there is a block of code :
if( !dbip->dbi_inmem && sb.st_size <= INMEM_LIM ) { dbip->dbi_inmem = rt_malloc( sb.st_size, "in-memory database" ); if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) goto fail; if(rt_g.debug&DEBUG_DB) rt_log("db_open: in-memory file\n"); }
This reads the entire database file into memory if it is small enough. Later "db_scan" rewinds the database file and looks for the "proper MGED database header" using "fread" (note that "db_open" used "read") . It appears that under Linux 1.2.8 there is some missing communication between the file descriptor and the FILE pointer. The "fread" call in "db_scan" returns "0" and "foef" returns true. This means that even though the file was just rewound, it is still at EOF. The fix for this one is to just replace
if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) in "db_open.c" with
if( fread( dbip->dbi_inmem, sb.st_size, 1, dbip->dbi_fp ) != 1 )
With this last change, "rt" now works. I ran the benchmark and got the following:
Abs 4021.12 1963.12 1752.41 1630.53 1995.19 2272.47 Thu Dec 28 01:41:28 EST 1995 *vgr 29.34 29.27 31.25 30.55 28.22 29.72
Not bad for 75 Mhz Pentium!!! (I verified a couple of the timings by hand)
---------- Forwarded message ---------- Date: Wed, 14 Feb 1996 09:22:45 -0500 (EST) From: John R. Anderson (USARL/SLAD/BVLD/VMB) <jra@arl.mil> To: "Thomas M. Browder Jr." <browder@eglin.af.mil> Cc: cad@ARL.MIL Subject: Re: Linux version of BRL-CAD (mged)
On Tue, 13 Feb 1996, Thomas M. Browder Jr. wrote:
> we have a working installation of Linux BRL-CAD, and everything seems > to be working (or at least usable) except one thing: > > in mged, the concat command finds an error with the model data base > one is trying to concatenate > > the model data base checks out ok independently, and it can be opened > with dbopen, it just cannot be merged inside the primary model > > the actual lines from a session are as follows: > > mged> concat model.g > concat: Enter prefix string or / for no prefix: / > db_read(model.g) ERROR offset=128, count=128, dbi_eof=-1 > Database read error, aborting > mged> > > Any help would be appreciated. > > Tom Browder > ASI Systems International
I suspect the problem is one I mentioned in a message I posted when I first installed BRL-CAD on my Linux system:
----------------------------- 3. After compilation, "mged" worked fine, but "rt" complained: "db_scan ERROR: File is lacking a proper MGED database header". I'm not yet sure of the basic problem behind this, but it has to do with opening a file twice (once to get a file descriptor and once to get a FILE pointer). In "librt/db_open.c" there is a block of code :
if( !dbip->dbi_inmem && sb.st_size <= INMEM_LIM ) { dbip->dbi_inmem = rt_malloc( sb.st_size, "in-memory database" ); if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) goto fail; if(rt_g.debug&DEBUG_DB) rt_log("db_open: in-memory file\n"); }
This reads the entire database file into memory if it is small enough. Later "db_scan" rewinds the database file and looks for the "proper MGED database header" using "fread" (note that "db_open" used "read") . It appears that under Linux 1.2.8 there is some missing communication between the file descriptor and the FILE pointer. The "fread" call in "db_scan" returns "0" and "foef" returns true. This means that even though the file was just rewound, it is still at EOF. The fix for this one is to just replace
if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) in "db_open.c" with
if( fread( dbip->dbi_inmem, sb.st_size, 1, dbip->dbi_fp ) != 1 ) -----------------------------
Looking at the code just now, I notice that this block of code seems to be missing a line setting the value of "dbip->dbi_eof". This could be the cause of the error. I would try adding a "dbip->dbi_eof =sb.st_size;" in the same block of code discussed above as shown:
if( !dbip->dbi_inmem && sb.st_size <= INMEM_LIM ) { dbip->dbi_inmem = rt_malloc( sb.st_size, "in-memory database" ); if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) goto fail; dbip->dbi_eof = sb.st_size; if(rt_g.debug&DEBUG_DB) rt_log("db_open: in-memory file\n"); }
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On Mon, 20 Jan 1997 eorddyo@techunix.technion.ac.il wrote:
> Hi all, > I"ve encounterd some problems using xmged: > after building an object which is a group composed of two regions > I tried to make a mirror image of it using yjr "mirror" comand. The copy was created, I then > tried placing it in the right place but when I placed "accept edit" the object I moved jumped to > it's original location and I got a message sayin the objects could not be reploted. > I encountered this phenomenon using the "copy" comand as well. > any sugestions?
I tried this myself and couldn't duplicate this behavior. When the mirror command is applied to a group or region, it does not create a new copy of the underlying objects. Only the new object mentioned on the "mirror" command line is created. The new combination (group or region) references the same underlying objects, but uses transformation matrices to position them. If you edit the underlying objects, they will change in both the original and the copy, but the relationship between the original and the copy will stay the same. What you really want to do is to use "object edit". The first step in doing an object edit (after selecting "Object Illum" on the menu) is to pick the object you want to edit. Move the mouse vertically to highlight different solids from the objects on the screen until you find the one you want in the object you want to edit. After you click the mouse to select the object, you will be in "OBJ PATH" mode. In this mode, you move the mouse vertically to select which transformation matrix to edit. Place the "[MATRIX]" directly above the object you want to move. This will typically be the new object that you created with the mirror command.
> P.S. > there may be something wrong with my subscription since I have recieved no mail from cad@ARL.MIL > since the begining of November, please resubscribe me if nesesary and e-mail me answers directly > untill I can be sure I"m back on the general mailing list > thanks Yoav
Yes, I removed your old address from the email list after getting numerous failed mail messages. I have placed your new email address back in the "cad" list.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On Tue, 21 Jan 1997, C. D. Turner wrote:
> The included file (created with brlcad 4.4) contains one region, box.r. When I > attempt to convert to gift using vdeck rev 11.1 (from brlcad 4.4) I get the > following: > > --------------------------------- > zia% ~/cad/bin/vdeck test.g > > command( ? for menu )>> insert box.r > > command( ? for menu )>> list > box.r > > command( ? for menu )>> deck > > ERROR: bad pointer x39070: s/b union tree(x91191191), was NULL(x0), file > ../librt/db_tree.c, line 908 > ---------------------------------- > > When I use the old rev of vdeck, 10.2 (from brlcad 4.0) it works fine. > Any suggestions? > > Thanks, > David Turner > SNL/A
Yes, a line needs to be added to vdeck.c near the end of the routine gettree_leaf(). The "magic" number for the curtree structure is not getting set. The existing code is:
GETUNION( curtree, tree ); curtree->tr_op = OP_SOLID; curtree->tr_a.tu_stp = stp; curtree->tr_a.tu_regionp = (struct region *)0;
return(curtree);
It should be changed to:
GETUNION( curtree, tree ); curtree->magic = RT_TREE_MAGIC; curtree->tr_op = OP_SOLID; curtree->tr_a.tu_stp = stp; curtree->tr_a.tu_regionp = (struct region *)0;
return(curtree);
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
Does anyone have a patch to compile BRL-CAD under a more recent release of Linux? The patch available at SUNSITE is from 1995 and appears to depend on some fairly old versions of libraries. Just wondering if anyone has already slogged through this, before I start the trudge:)
I am running Linux 2.0.28 libc 5.4.17 libg++2.7.2.1 XFree86 3.2
Thanks for any assistance
----------------------------------------------------------------- Craig P Earls cpearls@ziplink.net LT US Navy, MIT Ocean Engineering cpearls@mit.edu -----------------------------------------------------------------
> From: Craig Earls <NoSpam@my.house> > Newsgroups: info.brl-cad > Date: 26 Jan 1997 09:01:11 -0500
> Does anyone have a patch to compile BRL-CAD under a more recent > release of Linux? The patch available at SUNSITE is from 1995 and > appears to depend on some fairly old versions of libraries. Just > wondering if anyone has already slogged through this, before I start > the trudge:)
Someone should look into getting that old patch off of sunsite. It is obsolete. The latest patch for BRLCAD 4.4 comes courtesy of John Anderson, attached.
--jim
---------- Forwarded message ---------- Date: Thu, 28 Dec 1995 12:10:13 -0500 (EST) From: John R. Anderson (USARL/SLAD/BVLD/VMB) <jra@arl.mil> To: ged@walrus.arl.mil Subject: BRL-CAD 4.4 under Linux 1.2.8
I finally got around to installing BRL-CAD 4.4 on my PC. I am running Linux 1.2.8 on a Packard Bell with a Pentium 75 Mhz Processor and 16Mb of memory. My compiler is gcc version 2.6.3. I needed to make a few changes to get BRL-CAD compiled, here they are:
1. The makefile for cake ("cake/Makefile") calls lex to process "cake_s.l". There are some ifdefs in "cake_s.l" to account for the fact that "flex" (the GNU version of lex) does not define "yylineno". However, under this version of Linux, "lex" is defined as "flex -l". The "-l" option to "flex" tells it to be compatible with the orignal AT&T "lex". The result of all this is that the ifdefs are trying to correct for differences that aren't there. The easy fix here is to replace "lex" in the cake "Makefile" with "flex".
2. In libplot3, version 2.6.3 of gcc cannot compile plot3.c with the default O2 optimization. This has been reported to MIT as a compiler bug. The fix is to compile plot3.c with no optimization or use GCC version 2.7.2.
3. After compilation, "mged" worked fine, but "rt" complained: "db_scan ERROR: File is lacking a proper MGED database header". I'm not yet sure of the basic problem behind this, but it has to do with opening a file twice (once to get a file descriptor and once to get a FILE pointer). In "librt/db_open.c" there is a block of code :
if( !dbip->dbi_inmem && sb.st_size <= INMEM_LIM ) { dbip->dbi_inmem = rt_malloc( sb.st_size, "in-memory database" ); if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) goto fail; if(rt_g.debug&DEBUG_DB) rt_log("db_open: in-memory file\n"); }
This reads the entire database file into memory if it is small enough. Later "db_scan" rewinds the database file and looks for the "proper MGED database header" using "fread" (note that "db_open" used "read") . It appears that under Linux 1.2.8 there is some missing communication between the file descriptor and the FILE pointer. The "fread" call in "db_scan" returns "0" and "foef" returns true. This means that even though the file was just rewound, it is still at EOF. The fix for this one is to just replace
if( read( dbip->dbi_fd, dbip->dbi_inmem, sb.st_size ) != sb.st_size ) in "db_open.c" with
if( fread( dbip->dbi_inmem, sb.st_size, 1, dbip->dbi_fp ) != 1 )
With this last change, "rt" now works. I ran the benchmark and got the following:
Abs 4021.12 1963.12 1752.41 1630.53 1995.19 2272.47 Thu Dec 28 01:41:28 EST 1995 *vgr 29.34 29.27 31.25 30.55 28.22 29.72
Not bad for 75 Mhz Pentium!!! (I verified a couple of the timings by hand)
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
---------- End forwarded message ----------
Dear MUVES types, You may recall that some while ago (probably in the early stages of AGS) we discussed various ideas about component kill algorithms that might want to know which face of an object got hit--so one could treat the front of a radio differently from its bottom, say. We kicked around several solutions, including building/converting the component to NMG so you could have faces as explicitly modeled entities. We also talked about MUVES supporting yet another outboard file that would specify an orientation for each component, so an EM could look at an entry or exit normal and infer what face was involved. Well, in a discussion with Mike yesterday about improvements to our texture-map shader, I learned that BRL-CAD already makes available pretty much exactly what you need. The (struct hit) has a member of type int called hit_surfno, which encodes the surface of the solid in question. BTW, for each partition you get a pair of (struct hit)s, one each for entry and exit. There is a convention for naming the surfaces of solids of various types, for instance,
ARB8 TGC --------------------- --------------------- Surface # Face Surface # Face --------------------- --------------------- 0 1234 1 5678 1 side 2 1485 2 top cap 3 2376 3 bottom cap 4 1265 --------------------- 5 4378 ---------------------
In the case of the ARB, the modeler even has some control over which face gets assigned which surface number: some time ago I implemented a permute command in MGED that allows one to rearrange the vertex labels of an ARB. The bad news is that not all the solid types currently report surface numbers (e.g. the ARS). And of course for others, like the SPH or TOR, there is only one face. But it shouldn't be too much work for us to police up all the misbehaving solid types and teach them how to report something sensible. So if an EM wanted to be able to treat particular faces of components differently, one approach would be to support an outboard file mapping lists of ordered pairs of the form (solid_name, surfno) to component surfaces. One caution... any such EM would then have an unprecedented sensitivity to details of the .g file. For example, if you create one ARB by mirroring another, they really are mirror images, so their surface numbers will be mirror image, too. To further support this approach, I've enhanced nirt by adding two output items, surf_num_in and surf_num_out. This way somebody preparing target files for MUVES would not have to know the vagaries of the surface encoding conventions, he can just get in mged, point nirt at the spot he's interested in, and read off the required surface number(s). Paul
David,
We discussed two useful utilities that I thought might be handy for your conversions and re-conversions of Pro/E models:
1. Capability to assign idents, air codes, material codes and los numbers to BRL-CAD models from a file. The developmental version of MGED has an "rcodes" command that will read just such a file and assign the codes. The format is nearly the same as the output from the "idents" command, but with the first column of "region numbers" deleted. (I don't know why the formats are not exactly the same). You could do an "idents" command on a model already converted from Pro/E (after you have invested the time to assign the codes), then edit that file to eliminate the first column (see the Unix "cut" command). The result would be useful to assign idents to the next version of the Pro/E model that comes down the pike. Note that the names of regions would have to be the same between the two models.
2. Capability to create a "trail" file that could be fed to MGED to re-do all the commands that were performed in an earlier session. There is a "journal" command in the developmental version of MGED that stores your keyboard commands in an ascii file. This script can later be fed to MGED to run the same commands again. Not all commands end up in the "journal" file. Solid and object editing and mouse/knob/button commands are not included. And I'm sure that commands requiring user interaction (like "edcodes", "red", or "ted") will also not be in the "journal" file. However, commands, like "r" commands that you would use to correct overlaps, would be in the file and could then be run on another file.
These capabilities exist only in the developmental version, but will be in the next release. I suspect we can arrange something if you think these capabilities are needed for the Crusader project.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
I have re-written the 'E' command in MGED using the algorithm I sent out last week. I modified the algorithm slightly in the process. Originally, I intended to do it all with NMG's, but this was much too slow. I ended up alowing an option to the 'E' command.
With no options, it does it the fastest way, by using the NMG edges to plot the solids and intersecting the face planes to get the solid intersection lines, but shooting rays at the original solids. This is about as fast as the old 'E' command (I believe), but since the NMG edge/faces don't exactly match the real solid (in curved surfaces), edges often don't quite match up. In most cases, this is not a problem.
When an option is supplied (actually ANY option, but the command syntax says '-s'), a polysolid version of the solid is used for the raytracing so that the edges and faces agree exactly with the NMG version, so edges match. This is still very much faster than than my original attempt using NMG's all the way, but considerably slower than with no options.
This nearly completes the conversion of MGED to a database format independent code. There are still a few references to db.h MACROS, and the code to handle the color tables (based on ident numbers) still uses 'union record'. But that's all, I believe.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On Tue, 15 Apr 1997, Bob Strausser wrote:
> Good morning John, > > I spoke with Ron Dexter today (apparently my email didn't get to him > about the PSHELL record). Based on the "real" -60B NASTRAN file, Ron > guesses that the PSHELL record could be considered as a plate mode > indicator. It only exists (in the -60B) for skin elements and all > occurrences have a thickness assigned. Hes not sure that a zero > thickness would actually be valid in a true NASTRAN file even though > CATIA outputs a meshed NASTRAN file with a zero thickness entry (the > sample files).
Sounds reasonable to me. Perhaps CATIA is doing just a "surface" mesh as opposed to a "solid" mesh.
> He will be sending copies of the latest sample files hes been working > with and some excerpts from the -60B NASTRAN file. I'll pass them along > when they come in.
Great, I'll be looking forward to seeing them.
> The CATIA meshed outputs are still CTRIA3 elements > but I've asked for some other element types from the -60B file. Based > on our initial conversion samples, Ron has several questions concerning > the NASTRAN conversion you're working: > > 1. What is ARL planning / doing concerning the file sizes (NMG and > polysolid) which are unacceptably large (not practical for working > with)? He converted a control rod and had a BRL-CAD file (polysolids) > that was over 225Kb. He's noticed that CATIA handles its large file > sizes fairly well (response times) but BRL-CAD tends to bog down (on the > same hardware) when its file sizes get to be large (>15 Mb).
Both the NMG and the polysolid are very sensitive to tessellation tolerances. It is very easy to create an outrageously large NMG or polysolid file from a simple curved surface primitive, just by selecting a very small tolerance. The polysolid is more compact than the NMG solid, just a list of polygons. If the files come from CATIA, then CATIA is creating the polygons.
We are investigating the possibility of using some compression methods which could be applied to these situations, but that will definitely not be in the next release.
My experience has been that MGED will bog down when you try to display too much geometry, but otherwise runs fairly nicely even with very large databases. The two important memory users in MGED are the display list and the directory of objects. You can have a database containing only a single object that creates millions of vectors in the display list when displayed. You may also have a database that contains millions of objects that create no vectors in the display list when edited. The large display list can potentially slow down the graphics. The large number of objects in the database can potentially slow down everything. When I have seen this behavior it was due to excessive swapping (not enough memory on the system). We have been looking at a new database format for BRL-CAD, perhaps a more compact form for NMG's and/or polysolids could be considered.
> 2. How does ARL plan to handle the non-geometry data in the NASTRAN > file, given that NASTRAN (as used at Sikorsky) models load paths not > necessarily physical geometry? Will the converter be caveated like the > IGES / AutoCad converters that only XX portions are processed?
Currently, the plan is to ignore non-geometry. However, we might use material ID nunbers from NASTRAN somehow in assigning materials in BRL-CAD.
> 3. Who is ARLs sponsor for the NASTRAN conversion / what are they > expecting to get out of the NASTRAN file conversion (ties in with the > non-geometry data aspects)? Ron is wondering if Sikorsky uses NASTRAN > differently from other companies - is Sikorsky the only company whose > NASTRAN files don't "match the physical geometry" of the vehicle (for > anything but portions of the structure / skin). If this is an in-house > effort, Ron may be willing to support with limited file samples.
This is an entirely in-house effort. Our FASTGEN competitors have been touting their capability to convert NASTRAN to FASTGEN as a reason why they don't want to use BRL-CAD, so we are attempting to quiet that excuse. I am certainly not a NASTRAN expert, but from what I have read, it is fairly common for the NASTRAN geometry not to match the physical geometry. I would appreciate any sample NASTRAN files that I could get my hands on.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On 30 May 1997, Federico Carminati wrote:
> Reply to: X-Window interface > > Good Morning, > one remark on the X-window interface. As you know is very slow, but it can > be made several times faster changing the line width from 1 to 0. Width 0 > means the hardware default, which is 1 pixel, but much faster (for some > reason!). All you have to do is to change the third argument of > XsetLineAttributes in dm-X.c in mged anx xmged. Regards, Carminati > >
Thanks!!! We tried your suggestion an it does make a significant improvement. That change will be in the next release.
Thanks again, -John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On 28 May 1997, Federico Carminati wrote:
> Reply to: RE>>BUG in BRL? > > Good morning, > thank you for your quick answer. In fact I was not sure, so I continued > investigating in the problem. Now I do have the right answers, but I still do > not understand why. I have a box with a hole, and in the hole a cylinder which > fills it completely. I have constructed it with the following input: > > killall * > press reset > title TARC Lead Block > units m > in block.s box -0.075 -0.075 -0.075 0.15 0 0 0 0.15 0 0 0 0.15 > in hollow.s rcc 0 0 -0.080 0 0 0.160 0.032 > in hole.s rcc 0 0 -0.075 0 0 0.150 0.032 > regdef 1 > r block.r + block.s - hollow.s > r hole.r + hole.s > g block.g block.r hole.r > size 0.5 > B block.g > > Then I wrote a very simple application which, given a ray (inside the model!) > returns the distance to the first (i.e. closest) hit. And I set onehit=1. What > happens then is that all rays starting in the quadrant x>-0.032 y>-0.032 > intersect the cylinder correctly, while all the other do not see it and go > directly to the border of the box. > If I set onehit=2, I still have one only hit in the hit routine, and I can > tell because p->part_forw->part_forw == p, but this time it is the right one! > The fact is that I want only the first hit, so I thought that onehit should be > one. So now it works but I do not see why. Regards and thank you again for > your help. Carminati
It looks like you are confusing ``partitions'' withs ``hits''. Each ``partition'' structure has pointers to two ``hits''. A ``hit'' is an intersection between the ray and an object surface. A ``partition'' is a length of the ray that is entirely within an object. The ``partition'' extends from an entrance ``hit'' (pt_inhit) to an exit ``hit'' (pt_outhit).
The ``onehit'' flag sets the desired number of ``hits''. If ``onehit'' is set to one, then only the first ``pt_inhit'' is valid.
Another consideration is that if you fire a ray from within a solid object, then the ray will also be traced backward to find the ``pt_inhit'' point, as well as forward to find the ``pt_outhit''. Note that, in this case, the ``hit_dist'' for the ``pt_inhit'' will be less than zero. However, if ``onehit'' is one, only the ``pt_inhit'' will be valid.
If you set ``onehit'' to two, you should only get one ``partition'' (which is two hits), and both hits will be valid.
Hope this helps, -John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On Fri, 13 Jun 1997 gdpayne@dra.hmg.gb wrote:
> Now that it looks like BRLCAD release 5 is coming over the horizon, > is it possible to get a copy of the expected feature list for the new > version ?
The most significant changes that you will notice are: completeley new mged (better than xmged) based upon Tcl/Tk no xmged OpenGL support for both framebuffer and mged. greatly improved booleans of NMG's new converters VRML - can convert from BRL-CAD to VRML only This conforms to VRML 1.0.
ACAD - can convert from BRL-CAD to ACAD only The ACAD format used is entirely triangular facets.
Laser scan - can convert from laser scan data to BRL-CAD only This code is currently limited to Cyberware Digitizer Data in cylindrical scan format and is limited to simple shapes only.
Wavefront - can export polygons in Wavfront .obj format
new shaders camo cammoflage air/fog (homogenous mist) noise (fBm/turbulence effects on color/surface_normal) cloud Noise-based "solid cloud" shader fire reminicient of brush-fire type flames
librt extensively reorganized new utility and numerical handling libraries (broken out from librt)
> We are particularly interested in the BRLCAD to polygon convertor > which was expected to form part of the new release. How well does > this work ?
It's still not foolproof. But it does a better job now.
> Are we likely to see online / downloadable manuals for the new > version? Online manuals for the old version seemed to wither away > after the first few elements were completed.
There is a fair bit of documentation that has been written for the new release. Especially on the new mged. We are doing what we can to extend and improve the documentation. It will be available online, and as a part of the distribution. Summary: The documentation will be better, but it still won't be ... what I wish it was.
Lee A. Butler Internet: butler@arl.mil Attn: AMSRL-SL-BV Phone: (410) 278-9200 U.S. Army Research Laboratory DSN: 298-9200 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
As nightfall does not come at once, neither does oppression. In both instances, there is a twilight when everything remains seemingly unchanged. And it is in such twilight that we all must be most aware of change in the air--however slight--lest we become unwitting victims of the darkness. --- Justice William O. Douglas
I am currently using BRL-CAD Ver 4.0 and AutoCad Release 12. My intention is to use AutoCad to generate either an IGES-file or DXF-file, and ask BRL-CAD to read it as a G-file. I have problems in both cases. 1. I exported a 3-D drawing into an IGES-file from AutoCad 12.The drawing does not contain any solids, everything is in terms of lines and mesh. Then i used iges-g -o file.g file.igs the program ran, but it gave me a flattened 2-D drawing in mged. it appears that the 3rd dimension is not being taken care of. i tried it with other flags, but to no avail. the help file for iges-g indicates that the program recognises only the IGES 5.1. i think AutoCad 12's IGES is not 5.1. what do you think is the problem here? is it the IGES version which is the culprit? do you know of any CAD drawers whose IGES is compatible with BRL-CAD? 2. I repeated the same procedure with a DXF-file from AutoCad 12. the help did indicate that the dxf-g works for Autodesk greater than 10 (i think). i tried dxf-g -i file.dxf -o file.g and an error indicates that an unexpected EOF is detected in input file. i removed the EOF line in the input file, still the same error. i tried dxf-g <file.dxf> file.g the program ran, but an empty G-file was created, in a sense, no drawing was shown in mged. what do you think is the problem here? is it a version thing again? if it is, do you know of any CAD drawers which will work with their dxf files?
Thank You ! >
On Tue, 24 Jun 1997, Cheong Mei Teng wrote:
> I am currently using BRL-CAD Ver 4.0 and AutoCad Release 12. > My intention is to use AutoCad to generate either an IGES-file or DXF-file, > and ask BRL-CAD to read it as a G-file. I have problems in both cases. > > 1. I exported a 3-D drawing into an IGES-file from AutoCad 12.The drawing > does not contain any solids, everything is in terms of lines and mesh. Then > i used > iges-g -o file.g file.igs > the program ran, but it gave me a flattened 2-D drawing in mged. it appears > that the 3rd dimension is not being taken care of. i tried it with other > flags, but to no avail. the help file for iges-g indicates that the program > recognises only the IGES 5.1. i think AutoCad 12's IGES is not 5.1. > what do you think is the problem here? is it the IGES version which is the > culprit? do you know of any CAD drawers whose IGES is compatible with BRL-CAD?
This is the correct result. When AutoCad exports a drawing to IGES, it flattens it.
> 2. I repeated the same procedure with a DXF-file from AutoCad 12. the help > did indicate that the dxf-g works for Autodesk greater than 10 (i think). i > tried > dxf-g -i file.dxf -o file.g > and an error indicates that an unexpected EOF is detected in input file. i > removed the EOF line in the input file, still the same error. i tried > dxf-g <file.dxf> file.g > the program ran, but an empty G-file was created, in a sense, no drawing was > shown in mged. > what do you think is the problem here? is it a version thing again? if it > is, do you know of any CAD drawers which will work with their dxf files?
Our DXF to BRL-CAD converter only considers 3DFACES and 3DMESH objects in the DXF file. A drawing (2D or 3D) will not have either of these.
BRL-CAD is solid modeling system with very little support for "drawings". Generally, all objects in a BRL-CAD model are solids. You might try creating a solid model in AutoCad and converting that to BRL-CAD via either DXF or IGES.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
on 22 Jul 1997, frost wrote: > When I startup brlcad's mged I use for an example:
> cd /usr/brlcad/db # this puts me in the sample dir. > mged cube.g # to start the editor using cube.g > attach (nu|tek|tek4109|ps|plot|X|)[nu] # what it asks me > X # my answer (I think this uses the "X" display) > Xdisplay [:0.0]? # what it asks me > "enter" # I hit enter in responce
> At this point the editor pulls up, but all that can be seen is a dot > in the center of the screen. I've tried zooming in using the slide > bar, but this seems to do nothing. Is this normal, is there > something I not doing, Is there something I need to check.
Yes that is normal behavior.
What you have accomplished at this point is opening a geometry database and attaching a graphic display window.
The program is now waiting for you to tell it what to do. You have a text window to type commands into and a graphic window for wireframe displays and mouse commands. The white dot (in the graphic display) is the location of the 'center' of the 'camera - eyepoint' focus. Its X/Y/Z coordinate value in three dimensional space should be listed in the lower left corner of the graphical display.
You can list the commands by typing "?" (no quote symbols) and pressing return. Typing "help" and pressing return includes the usage syntax for the commands (scrolling your window). Typing "help command" (replace command with one of the commands from the list) will echo to the text window the usage syntax for just that command.
Since you opened an existing geometry database, you should type "tops" and press return. This will list all of the database objects which are on the top level (not members in a group or region). For the cube.g file the top level objects are:
all.g/ cloud.r.bak/R light.r/R
where all.g is a group of regions and groups, cloud.r.bak is a region containing solids, and light.r is a region (with a single solid) which has been defined as a light source (internal to the geometry as opposed to the default 'camera - eyepoint' light sources).
Typing "e all.g"<return> will display the object all.g on the graphic display window as a wireframe representation of all the solids at the root of the all.g heirarchical tree. This is identified as 'viewing' mode. You can use the mouse in the graphic window or commands typed in the text window to change the viewing angle, size, and location.
Solid edit mode will permit you to change the individual coordinate parameters which define a solid object - its individual length, width, height, radius, location in space, and orientation.
Object edit mode will permit you to change a collection of region and group objects with regard to their location, orientation, and overall size in space. The solids which are the defining root of the regions and groups still retain the same (original) coordinate data defined in their respective individual solid edit mode sessions. Object edit changes may be pushed to the root solids (changing the solids' coordinate data) if there are no conflicts. A conflict occurs when a solid is used in multiple regions and the regions (or groups containing those regions) have been object edited to different locations/orientations/scales.
Bob Strausser SURVIAC Aberdeen Satellite Office
On 23 Jul 1997 RDexter@zoomit.sikorsky.com wrote:
> Is there a quick way to remove all of the edcode assigned > colors, materials, etc. from within a model database to > "clean-up" a description? > > Thanks in advance. > > >> Ron Dexter > Survivability & Low Observables > Sikorsky Aircraft Corporation > PH: (203) 386-7922 FX: (203) 386-5925 > EM: rdexter@sikorsky.com > > >
Ron,
The easiest way I know of (using the distributed MGED) is to use the "idents" command to get the current data in a file, then edit that file into a list of "edcomb" commands to accomplish whatever you want with the edcodes info. Then use execute MGED using that file for redirected input.
By the way, "edcodes" does not set the color, just ident, air code, GIFT material code, and LOS.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On Thu, 11 Sep 1997, Tom Browder wrote:
> Is there any easy way to get the BIG > compilation process to HALT at the first > compile error? > > Thanks. > > Tom Browder > > > >
In the file "gen.sh" at about line #297, you will find the section of the script which drives the "BIG" compilation ("cake all"). You might try changing "cake -k" to "cake -a". The "-k" option says "don't abort" while the "-a" option says "abort the whole run if cake sees an action return with a nonzero status".
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On Tue, 30 Sep 1997, Tom Browder wrote: > We are working on larger and larger models, and > see slower and slower results during typical > mged operations such as 'tops', 'e', etc. > We are using PC Linux and SGI IRIX hosts and the > behavior is seen on both. > It sounds as if mged goes to the disk for > each mged data base command, even if nothing > is changed. The question is, is this behavior > correct?
This is correct. The original design goals for MGED included that the database file should always be in a stable state. All actions on the database are as atomic as we could make them. Thus if the machine went down in the middle of an edit, you would loose very little.
Modern practice for editors (text and otherwise) tends to emphasize speed at the cost of reliability. As a result the tendecy is to read the whole file into memory, operate on it, and only write to disk under direct user guidance. This has limitations in terms of the size and complexity of the database to be edited.
Both approaches have drawbacks.
Realize that the "tops" command has to process each item in the database. Ergo, the larger the database, the longer tops will take. As for "e", that should only slow down when the number of objects you are displaying goes up. If you "e" up 1000 solids, it's going to take longer than if you "e" up 10.
Lee A. Butler Internet: butler@arl.mil Attn: AMSRL-SL-BV Phone: (410) 278-9200 U.S. Army Research Laboratory DSN: 298-9200 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
As nightfall does not come at once, neither does oppression. In both instances, there is a twilight when everything remains seemingly unchanged. And it is in such twilight that we all must be most aware of change in the air--however slight--lest we become unwitting victims of the darkness. --- Justice William O. Douglas
There is a new LIBBN routine called bn_mat_ck() which can be used to ensure that a rotation matrix preserves axis perpendicularity and doesn't have a scale factor of zero. Handy when your matricies are getting corrupted and you aren't sure where it's happening.
Best, -Mike
This evening, after a tremendous amount of infrastructure work in librt/db_tree.c, I've finally been able to fix on the bug in MGED, whereby adjusting the color of a region and giving the "redraw_vlist" command gets the color updated on the screen.
Also, if I "B" or "e" the object after changing it, the screen shows the new color.
Here is an example of how to reproduce it:
19 vj> ./mged -n ../.db.6d/moss.g BRL-CAD Release 4.5 Graphics Editor (MGED) Tue Dec 23 04:40:51 EST 1997, Compilation 6633 mike@vapor.arl.mil:/m/cad/.mged.6d
Gary Moss's "World on a Platter" (units=mm) attach (nu|X|ogl|glx)[nu]? glx mged> e light.r 51 vectors in 0.001403 sec mged> .inmem adjust light.r rgb {0 255 0} mged> redraw_vlist light.r light.r/LIGHT
The light sphere turns green. Yay!
This also means that the "sun" turns yellow in the MGED window in "dynamic geometry" demo, just like it does in the ray-traced view. A very important bit of progress, as much will be built on this.
Best, -Mike
>> Modified "shader" command so that it returns current shader if >> a new material string isn't given. >> Even on a read-only database.
Probably a number of other commands ought to work like that too, to make them more useful in building Tcl scripts.
Best, -Mike
Jill,
Mark Burdeshaw (now of ARA) asked me to stop by to discuss the problem that some SURVICE people were having with BRL-CAD raytracing (someone claimed BRL-CAD was ~400 times slower than FASTGEN, I believe).
SURVICE is developing a sort of "seeker" model for AJEM (funded by JTCG). They are using a FASTGEN model (converted to BRL-CAD) as the target being seeked. The seeker model uses librt raytracing to simulate whatever the real seeking technique is, so many rays are fired in the direction of the target. It turns out that when the target was converted from FASTGEN (using patch-g), it was converted into NMG solids. Remember that we are talking release 4.4 here, NMG raytracing was still experimental and extremely slow. It was easy to spot this problem (their profile listing showed "rt_isect_faceuse" as a big time consumer). I suggested that they re-convert the FASTGEN model using the "-p" option to patch-g (this creates polysolids rather than NMG solids). Just using polysolids instead of NMG solids should improve their raytracing performance immensely.
I should point out that the documentation for patch-g does not mention the "-p" option (an oversight on my part). In the next release(?), patch-g will produce polysolids by default, and the user will be required to provide an option to get NMG solids.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
This afternoon John and I implemented the -j flag to RT, allowing the specification of a sub-rectangle within screen space to be specified. Ray-tracing is limited to those pixels within the sub-rectangle.
This support was needed so that Bob could implement the "sweep out a rectangle for ray-tracing" capability in MGED.
Dynamic scanline buffering and full load-balanced parallel support are working. Incremental mode (-i) isn't working yet.
Man page has been updated.
Best, -Mike
Mark wrote -
> Umm... mged.ps was generated with some kind of reverse-page option > such the first printed page is the last page of the document.
Yes, it was intended to be that way. Something to do with the way that Bill's Apple LaserWriter handled the paper.
On some printers, you can flip down a door to have the pages stacked in the other order.
> Do you have the TeX (or LaTeX) source for mged.ps available on-line? > I'd like to generate the .ps file for double-sided printing and > correct ordering.
Sure, the TeX version is a standard part of the distribution, as a SHAR archive in doc/mged.tr, feel free to print from that instead.
The whole reason I provided the .ps file was because some folks were having difficulty printing the TeX files on a modern version of TeX.
Best, -Mike
Carl,
Sorry to take so long to respond, but as you surmise, LGT assumes a square frame buffer. This is a throwback from it's origin using square standalone frame buffers rather than workstations with built-in graphics. Except for very minor porting to new OS releases, LGT has undergone virtually no change in 10 years or more and it shows.
-Gary
On Fri, 6 Mar 1998, Carl Moore wrote:
> I used a script which ran lgt and made an outline drawing in black which > was put onto a white background in a .pix file. There is a slight incon- > venience, since I usually work with full-screen .pix files: the .pix file > from said lgt run was 1024 x 1024. The workaround to get it into a full- > screen (1280 x 1024) size file is to bring the 1024 x 1024 .pix file into > my frame buffer, then run fb-pix with the 1280 x 1024 size selected in its > parameters. > > Did I miss something or did I see that lgt could only create square (i.e. > same number of pixels horizontal & vertical) .pix files? >
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ _/ Gary S. Moss email: moss@arl.mil _/ _/ Computer Scientist WWW: http://web.arl.mil/~moss _/ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
This evening I decided to eliminate the RFBD program; nobody uses it any more, it's been replaced by FBSERV.
I've also moved the guts (event handlers) of FBSERV to libfb/server.c. I was going to try and get MGED to use the LIBFB routines, but couldn't because of the way Bob had to #define the fbp variable to make it part of the current dm context. Oh well, was worth a try.
Best, -Mike
This evening I modified the calling sequence to libbu/bu_parallel() so that threads are started with one additional parameter, a caller-supplied void *, which can be used to pass in a private state structure.
This allowed me to eliminate some ugly use of global state variables in db_tree.c and cut.c, and allowed me to make db_walk_tree() fully recursive even in parallel mode, which is something that Lee and I have been wanting for a long time, and I need to have now to hit one of my TAPES bullets. :-)
If you encounter something I didn't convert, the extra arg may safely be provided as NULL.
Best, -Mike
Hello * -
For the past couple of weeks I've been trying to find a combination of AutoCAD and BRL-CAD tools to permit the exchange of images between the two systems.
My test drawing (in the AutoCAD world) is of a cube with a small rectangular cavity in one side. My most recent success has been in setting AutoCAD to output the drawing in "B-REP solid with analytical surfaces" and using iges-g to translate to BRL-CAD g-format.
This works.. partway. In an attempt to raytrace the object, 'rt' runs for a while, emits a message "This better be a 2-manifold surface" and dumps core (Platform: UltraSparc 2 with Solaris 2.5.1, running BRLCAD 4.5).
The same behaviour occurs when dealing with a "B-REP solid with NURB surfaces."
Another curiousity is that modelling the cube-with-cavity in BRLCAD shows the cavity with dotted-lines (indicating a subtraction?) but modelling the AutoCAD-modelled cube-with-cavity has solid cavity lines.
Suggestions?
Your time is appreciated.
Regards,
Mark
On Thu, 21 May 1998, Mark Becker wrote: > For the past couple of weeks I've been trying to find a combination of > AutoCAD and BRL-CAD tools to permit the exchange of images between the > two systems. > > My test drawing (in the AutoCAD world) is of a cube with a small > rectangular cavity in one side. My most recent success has been in > setting AutoCAD to output the drawing in "B-REP solid with analytical > surfaces" and using iges-g to translate to BRL-CAD g-format. > > This works.. partway. In an attempt to raytrace the object, 'rt' runs > for a while, emits a message "This better be a 2-manifold surface" and > dumps core (Platform: UltraSparc 2 with Solaris 2.5.1, running BRLCAD > 4.5).
This implies that you are creating a B-REP NMG solid in BRL-CAD for your object. The NMG code in release 4.x is what I would call "experimental" in quality. However, for some database formats, it is the only way to achieve a conversion.
In your case, it seems that you are not creating a closed solid, but rather a collection of planar surfaces which touch but are not topologically connected. You may wish to investigate the "asc-nmg" program.
In some cases, there are large performance improvements which can be achieved by re-modeling the object (or parts of it) in BRL-CAD. For example, ray-tracing a BRL-CAD object consisting of an arb8 with a subtracted arb8 will be much faster than ray-tracing the equivalent NMG planar suface representation.
For large models the effort to re-model may not be practical. In these cases I suggest investigating conversion of certain key sections for performance.
Lee
Carl, You wrote...
> If I use -k argument and ALSO use -d "0. 3" argument, the color key > comes out the same LENGTH as above, with the white (zero) value in > the same place (far left) as before. *But* the right end of the color > key becomes a blue shade (apparently the equivalent of 0.3333333 value), > and in-between parts of the color key are interpolated between this > value and the left endpoint's zero.
> The intent of the normalization is to get data into the "0 to 1" range, > so I would expect the color key to show the 0 to 1 range. Why is the > color key altered when I do said normalization?
The color key is altered because of a bug. Your hunch about the program's behavior was correct, and I've fixed it in the developmental sources. By the way, in tracking your bug, I discovered another one, too, which I've also fixed.
And I've implemented a new option, '-M r1 g1 b1 r2 g2 b2', which specifies that the color scale should be--instead of the standard blue-to-red w/ 0=white--interpolated between r1/g1/b1 and r2/g2/b2. With the -M option it's now easier to be less wasteful of the colors at one's disposal. For instance, ramping the cell data, say, from white to red leaves all the other colors (greens, blues, yellows, etc.) available to encode additional information in the image (e.g., text, aimpoints, delivery accuracy, etc.)
Thanks for your bug report, Paul
Mike asked me to notify when I changed the combination import/export routines. I have done that. They now convert the shader info to/from the TCL format. I also modified db_apply_state_from_comb() to convert from TCL format back to the "keyword=value" format, so that rt will still work. Note that when you supply shader info to the "mater" command in MGED, it must now be in TCL format. The format is a list where the first member is the shader name and the second member is a list of (white space separated) shader keywords/values. For example,
plastic sh=5 is now: plastic {sh 5}, and, stack camo c3="255 255 255";plastic is now: stack { {camo {c3 {255 255 255}}} {plastic {}}}
each member of the stack shaders parameter list is a shader list itself.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
On Mon, 6 Jul 1998, Marcel RICARD wrote:
> Dear BRL-CAD users, > > We are just trying to use the BRL-CAD package in the field of Medical > Physics concerning internal dosimetry. We use a SUN SPARCKstation 20 under > Solaris 2.4 and the software seems to be well installed on our computer. We > are able to build and edit objets but the rt command (do raytrace of view) > doesn't work. As we didn't find any information to view the result of rt > command, we want to know if anybody knows how to fix this problem. > > Thank you very much in advance for your help. > > Best regards, > > Marcel.
The "rt" code will try to send its output to a framebuffer, so you may need to tell it which framebuffer to use. You can use the "-F" option or set the "FB_FILE" environment variable. A pretty safe choice for framebuffer on a SUN is "/dev/Xl". Try the "fbhelp" command to see the available framebuffers.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
> On Mon, 6 Jul 1998, Marcel RICARD wrote: > > > Solaris 2.4 and the software seems to be well installed on our computer. We > > are able to build and edit objets but the rt command (do raytrace of view) > > doesn't work. As we didn't find any information to view the result of rt > > command, we want to know if anybody knows how to fix this problem.
Marcel,
Sometimes our students have trouble getting RT to work and the cause of this problem is usually easy to correct.
First: Make sure that "/usr/brlcad/bin" is in your PATH. The PATH is a UNIX environment variable that tells what directories are to be searched to find commands. Even though you are in MGED, the RT command invokes an outside code known as RT. If your PATH is not set up correctly, then RT is not found and therefore does not run.
To determine whether this is your problem, try running RT outside of MGED. If the RT command is not found when it is run outside of MGED, then it also will not be found if invoked inside of MGED.
SECOND: As John pointed out, perhaps your frame buffer variables are not set up correctly. I do not suspect this in your case since the MGED screen appears correctly.
To determine whether this is the case, try invoking RT INSIDE MGED with "rt -o junk.pix -s 512". This will attempt, if everything else is working correctly, a file named "junk.pix" in your current directory that contains the image of whatever was on the MGED editor screen. If the file was created correctly and is somewhere around .75 MB in size, then your problem is with the frame buffer. Otherwise, perhaps the FIRST problem or some other RT compilation problem may have occurred.
Hope this helps, Viva La France!
Harry Reed Geometric Solutions, INC +1 410 273 7058 Office Hours: Monday - Thursday 0930-1530, U.S. Eastern Standard Time
Correction, if you're running 8-bit X, you might want to do this under 'bash' which is probably your default Linux shell (otherwise use 'setenv' instead of 'export'
export FB_FILE="/dev/XsPl"
You might or might not want to use the 's' option depending on how much memory you've got.
On Fri, 28 Aug 1998, klaatu wrote:
> On Fri, 28 Aug 1998, Karen A. Swartz wrote: > > > I installed BRL-CAD and I worked through the tutorials for Mged. However, > > when I got to the ray tracing it didn't work like the tutorials said. In > > fact nothing really happened at all with the display. Is there any major > > differences when running in linux or Xwindows? Is there some way of > > checking if everything was installed correctly? > > Um, lessee - if I recall correctly, this is probably because you haven't > got your FB-FILE environment variable set right. There's more to it than > this, but I know that it must be set. > > In my /etc/profile (possibly you'd rather have this in your own 'bash' > ~/.profile file) add a line > > export FB_FILE="/dev/XsTl" > > Definitely read your 'man libfb' and related files, probably you've got a > different device from the XsTl device. But this works for me in 8-bit > SVGA under X. > > > > > > > Any input would be great. > > I appreciate all your help. > > > > > > Karen Swartz > > Teledyne Brown Engineering > > swartzk@email.uah.edu > > > > > > > > > > Be kind to your neighbors, | "When the going gets weird the weird turn pro." > even though they be | http://www.clark.net/pub/klaatu/home.html > transgenic chimerae. | Now. Chock full of uninteresting links. > --------- Whom thou'st vex'd waxeth wroth ---------------- > Re-transmission of this e-mail is a violation of Federal Copyright Law and > subject to a per-instance violation damages charge of $250,000.00 >
Be kind to your neighbors, | "When the going gets weird the weird turn pro." even though they be | http://www.clark.net/pub/klaatu/home.html transgenic chimerae. | Now. Chock full of uninteresting links. --------- Whom thou'st vex'd waxeth wroth ---------------- Re-transmission of this e-mail is a violation of Federal Copyright Law and subject to a per-instance violation damages charge of $250,000.00
Of all the image file formats supported by Microsoft PowerPoint(tm), Adobe PhotoShop (tm), Web browsers, and BRL-CAD(tm), the new PNG format (Portable Network Graphics) is the best choice for the two-way exchange of images.
PNG offers a typical compression ratio of 10:1, and uses a lossless algorithm, so that there is no degradation of quality in the decompressed image.
As you probably know, Jill has directed that all developmental BRL-CAD and MUVES software is to be carefully protected. With Jill's express permission, executable copies of these new PNG tools from the developmental ("5.0") version of BRL-CAD have been added to the "Production" BRL-CAD 4.4 executable tree stored in /usr/brlcad/ on the IRIX 5.3 (wilson.arl.mil) and IRIX 6 (raven.arl.mil) RDIST master machines. These binaries will be available to every machine that subscribes to the ARL rdist service, including machines at ARDEC, TECOM, CECOM, and elsewhere.
The programs png-fb, fb-png, and any-png.sh have been added, and the programs pixinfo.sh and show.sh have been upgraded to support PNG. Manual pages for png-fb and fb-png have also been installed. These files should go out on the Friday night RDIST.
The any-png.sh script is a convenient tool which can convert one image in any of our common formats (pix, bw, rle, yuv, jpeg, and gif) into PNG. To convert an entire directory of images into PNG format, just run:
for i in * do any-png.sh $i done
The PNG files are written in the current directory even if the input file is taken from another directory. So to get your own PNG version of the radar teapot, you can just run:
any-png.sh /n/wolf/demo/rt/radar-teapot.rle
You can then view the resulting image by running either:
png-fb radar-teapot.png or show.sh radar-teapot.png
(The show.sh program can display most image formats on your BRL-CAD framebuffer.)
This is a great way to zap your V/L analysis results painlessly into PowerPoint or PhotoShop!
Credit: As an interesting historical note, the PNG format was developed by a large group of people, including Glenn Randers-Pehrson, a long-time Army employee (ARDEC, BRL-TBD, ARL-WMRD), now retired. John Anderson ported the PNG library into the BRL-CAD source tree, and he and I wrote these new converter tools.
Enjoy! -Mike
As an additional tool for us developers, I've broken out the parts of setup.sh that checked the settings of $PATH, cake, machinetype.sh and Cakefile.defs into a separate shell script named "brlcad-check.sh".
setup.sh runs brlcad-check.sh, but if you're unsure about whether your path is set right, you can run it directly.
Best of all, if you're struggling to get machinetype.sh and cake and Cakefile.defs to all agree, you don't have to re-run setup.sh (and be forced to recompile CAKE) each time you experiment.
Best, -Mike
As a starting point today, I modified gen.sh and Cakefile.defs to support using the vendor-provided versions of the TCL and Tk libraries, when compatible versions are provided. In the case of both FreeBSD and Linux, libtcl8.0 and libtk8.0 are available. In those cases, one less thing we need to ship along.
This evening I succeeded in taking the final step in the FreeBSD port: getting the package to build using shared libraries and optimization. Now that I've figured out all the magical compiler options needed, it works just fine! The full install tree for FreeBSD is 13.7 Mbytes, just slightly larger than a full install for Linux (12.7 Mbytes).
This is an extremely small disk requirement for modern software; the full BRL-CAD package can fit nicely on any laptop computer running FreeBSD or Linux.
Best, -Mike
I have modified db_tcl_comb_adjust() in tcl.c such that a "db adjust any_comb_parameter none" will set that parameter to its "not used", or its default value.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.
A new shader called "extern" was born in about 40 lines of code today. It's just a version of the venerable "stack" shader that takes it's parameters from an external file. The only parameter is the name of the file containing the real parameters. Usage:
mged> mater foo.r "extern {shader.txt}" 255 255 255 1
Then you need to fill in the file "shader.txt" with the actual parameters you wanted on the command line.
mged> exec cat shader.txt camo s=200 t1=-.3 t2=.125;plastic di=.8
This lame little hack allows us to sneak around the buffer length limits in the v4 database format.
Lee
On Fri, 12 Mar 1999, Tom Browder wrote:
> The stock mged has a useful tree depth of twelve levels. Is there a simple > constant change in the source code to increase that or is it more than a > trivial change? > > Thanks. > > Tom Browder > > >
Yes, in "h/solid.h", there is a line that defines MAX_PATH. You can adjust this, then recompile mged. Making this larger will increase the memory used for each solid in MGED's display.
-John
John R. Anderson Attn: AMSRL-SL-BV Internet: jra@arl.mil U.S. Army Research Laboratory Phone: (410) 278-7267 Aberdeen Proving Ground, MD 21005-5068 FAX: (410) 278-5058
AMC says that my views do not represent an official Government position.