Welcome (again) Csaba!

On Mar 29, 2013, Csaba Nagy wrote:

> I really would like to have an open discussion about what is expected
> from a good CAD software, where BRL-CAD stands and where it wants to go
> - the documentation on the web is too scattered, partially outdated, and
> generally not very conclusive (sometimes even confusing) about these
> points.

This sort of discussion is highly and always welcome.  I've actually been 
working on a features roadmap that I hope to share in a few days, but you're 
completely right about the stuff on the web.  It's a mess.  A couple guys were 
working on a redesign that should help reorganize the site better, but the past 
two weeks have been busy.

> For the record (as the IRC archives have no public logs I guess), this
> is what I like about brl-cad:

Logs are at http://ibot.rikers.org/%23brlcad/
Many years of discussion archived up there.

> Things which need improvement in my opinion:
> 
> * cleanup: both the utilities and the web is sometimes confusing due to
> legacy parts - I learned in the discussions that this is worked on;

Feedback on http://brlcad.org/wiki/TOC (from anyone) would be appreciated.  
That's the work-in-progress plan for organizing all of our online information.

> * more analysis tools directly built in to the primitives, and ways to
> get them via GUI and scripting (e.g. key points and curves usable in
> constraints applied to the primitives);

Related to that idea, our GCI students this past winter implemented a ton of 
new primitive analysis functions for surface area, volume, and centroid 
calculations.  They are still awaiting review, validation, and integration.  
They're along the same line though, supporting analysis information.

> * some of the external tools (like the "shapes", e.g. the coil tool)
> would be nice to have also available inside mged for scripting purposes;

Agreed.  I'd like to see us eventually implement a fully parametric object.  
That is, a primitive that is fully defined at *run-time* by some textual 
description (set of equations and parameters).  With that, a user could 
conceivably implement their own shape and share it with others as procedural 
geometry.  I see this as the mechanism for eventually implementing 
feature-based editing (e.g., a chamfered hole is just a parameterized union of 
cylinders subtracted from an object with implicit constraints).

> In the future I would like to have more constraint based
> query/positioning of objects, like getting corner points of a cube or
> the center axis of a cylinder, and setting the same for the purpose of
> positioning the objects.

That's been a goal for a long time.  Code-wise, it's mostly a matter of 
refactoring all of the switch statements that access idb_type, pushing them up 
into librt, and updating accordingly.

> The ultimate test for a good CAD for me would be a system which allows
> easy building of LEGO systems - that means usually a very good
> constraint based positioning combined with library based building block
> selection. While LEGO sounds like a toy, from engineering POV it is the
> real thing ;-)

That sounds like a fun project regardless of being a real thing or not.  Would 
make for some great pictures too.  :)

Cheers!
Sean


------------------------------------------------------------------------------
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to greatness in Intel's independent game demo contest. Compete 
for recognition, cash, and the chance to get your game on Steam. 
$5K grand prize plus 10 genre and skill prizes. Submit your demo 
by 6/6/13. http://altfarm.mediaplex.com/ad/ck/12124-176961-30367-2
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel

Reply via email to