Bugs item #1277535, was opened at 2005-08-31 11:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=640802&aid=1277535&group_id=105292
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Lee Butler (lbutler)
Assigned to: Nobody/Anonymous (nobody)
Summary: fblcear behavior in mged
Initial Comment:
If the user want's an external framebuffer in mged, they might set
the -F option in the advanced panel. Once done, the fbclear button
doesn't "work" because it isn't getting the framebuffer from the
"advanced" options. Suggest a change to the raytrace control panel
to support an external framebuffer.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=640802&aid=1277535&group_id=105292

Feature Requests item #1220711, was opened at 2005-06-14 16:19
Message generated for change (Comment added) made by lbutler
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=640805&aid=1220711&group_id=105292
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Modeling
Group: next release
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Lee Butler (lbutler)
>Assigned to: Lee Butler (lbutler)
Summary: Need unified geometry QA tool
Initial Comment:
At the moment, we have 3 tools which do most of the QA process:
rtcheck, rtweight, and g_lint. The functionality needs to be
combined into an uber-tool for assessing geometry.
The rtcheck and rtweight tools are limited by constraints on image
size set forth in the rtuif. g_lint is crippled by being single threaded.
rtweight reads a .density file which is typically external. This data
needs to be imported to the .g file to make sure it does not get
separated. The rtweight function needs to use these densities from
the .g file.
The current tools shoot a grid of rays and extrapolate the ray to a
rectangular prism. But the bounds of only one axis of the prism are
well defined (along the direction of the ray).
The new/revised tool should shoot 3 orthogonal grids at the
geometry to more accurately constrain the volume of the geometry
(relative to the existing tools which shoot a single grid of rays). For
overlap checking, this should incorporate progressive refinement,
and report volumes of overlap, rather than shot-line specific list of
overlaps as current tools do. The user should be able to ask for
overlap checking to stop refinement when it finds a given number of
distinct overlap pairs. It should be a parallel application to reduce
runtime on SMP architectures. The user should be able to specify a
tolerance for the answers. for example, weight within a certain
tolerancce (eg. to the nearest gram, overlaps to the nearest mm).
If we can establish a registry for material densities, then the weight
calculation tool should report if unregisterd materials are specified in
the file.
A tool (separate) should also check for things like: valid air/region
codes (not both), no regions unioned into regions, no instancing, and
checking that all components have non-default values where
reasonable. This checking supports typical analysis codes.
It would be good to establish a material id registry on the BRL-CAD
website. This would map region-id to material, which would in turn
identify a density, and perhaps a birnell hardness. Ideally, this
would NOT use regionID, but rather map an attribute value to store a
material name. One issue with this is how materials could be
assigned to non-regions such that they propogate down the DAG
similar to shader properties.
----------------------------------------------------------------------
Comment By: Lee Butler (lbutler)
Date: 2005-08-31 11:46
Message:
Logged In: YES
user_id=1179270
This feature request is now implemented and should be available with the next
release, thanks!
----------------------------------------------------------------------
Comment By: Dwayne (dwaynelk)
Date: 2005-06-21 17:30
Message:
Logged In: YES
user_id=1209946
Outstanding!
Being that much of our V/L work is tied very closely to
materials and the fact that there is ofter a disconcerting
disconnect between the geometry files and the analysis, the
improvements you mention are sorely needed. It would be
very good to see a nice simple right click - apply material
type - select from a list of names functionality in mged
(likewise with color). That coupled with a more
centralized/standardized list of materials based on names
(not numbers) bundled with the package would greatly
improve functionality and user friendlyness. A strength of the
current system is the capability to create your own material if
you need to, so another option to consider is a user defined
material type and density value if none of the 'canned' values
work for your modeling need.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=640805&aid=1220711&group_id=105292

Feature Requests item #1277516, was opened at 2005-08-31 11:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=640805&aid=1277516&group_id=105292
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Geometry Editing
Group: dreaming
Status: Open
Resolution: None
Priority: 5
Submitted By: Lee Butler (lbutler)
Assigned to: Nobody/Anonymous (nobody)
Summary: Annotation wireframes?
Initial Comment:
I'd like to have a method for stashing some wireframe stuff in the
database that could be called up on demand. For example, the plot
files that g_qa produces could be broken down to per-object items to
be called up in the database. We could also support annotations,
dimensions, etc to be stored this way.
This could be implemented as a new primitive type that doesn't
raytrace, but can be drawn. Alternatively, a convention for stashing
such information as an attribute on database objects, with an MGED
command to display it. Perhaps an option to the e, and E
commands?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=640805&aid=1277516&group_id=105292