AngelScript's API is C++, so it makes embedding it into C++ programs (and exposing those data structures) a bit easier than Lua's C API.
For practical purposes for users, the main difference is that AngelScript has a very C/C++ like syntax -- vs. Lua's Scheme like syntax. Just one less programming language to learn. I don't have a strong suggestion -- just when I see C++ projects contemplating Lua, I like to suggest they consider AngelScript as they've probably never heard of it. Rob On Tue, Jan 19, 2021 at 11:53 AM Christopher Sean Morrison via brlcad-devel <brlcad-devel@lists.sourceforge.net> wrote: > Hi Rob, > > Thanks for the suggestion. How is AngelScript differentiated from Lua? > Sounds very similar to Lua and Tcl. > > For what it’s worth, BRL-CAD already has an embedded scripting language in > the GUI — it’s Tcl quite pervasively. That embedding is also exposed in > config file parsing, numerous extensions, and some converters. > > We also already have a very simple swiggable API for that already (LIBGED > and LIBWDB), but we’ve just not hooked it through to our lowest-level > primitive I/O layer. Nothing terribly hard, just hasn’t happened yet due > to competing priorities. We’ve wrapped the libs in swig several times over > the years but they didn’t result in compelling features (lack of > follow-through), so they’ve been ignored. > > What I was referring to, however, is a much much lower-level embedding for > describing dynamic geometry objects that get serialized as implicit CAD > geometry on the fly. Any scripting interface will work easily, it’s just > again a matter of priorities and who gets excited to work on the task. > > Cheers! > Sean > > > On Jan 19, 2021, at 2:15 PM, Rob McDonald <rob.a.mcdon...@gmail.com> > wrote: > > Not to take this thread in a different direction.... > > Sean - if you get serious about embedding a scripting language into > BRL-CAD, you might also consider AngelScript > <https://www.angelcode.com/angelscript/>. It is much less well known > than many of the alternatives, but it has the feature that it was designed > to be embedded in C++ programs. > > We use it in OpenVSP and have found it very easy to embed and to work > with. We use it for user-defined functions and plugin-like capabilities. > We also use it as a built-in scripting capability so users can automate > OpenVSP with no dependencies (no Python, no compiler, etc). In addition, > we have a C++ API that users could use to develop their own application > that uses OpenVSP's capabilities as a library -- we wrap/bind that API > using Swig. We publish Python bindings and give instructions for Matlab > bindings as those are the two most used by our users. > > There is some work keeping the AngelScript side of the API and the C++ API > consistent -- but Swig makes supporting additional languages easy. > > Rob > > > > On Tue, Jan 19, 2021 at 10:50 AM Christopher Sean Morrison via > brlcad-devel <brlcad-devel@lists.sourceforge.net> wrote: > >> Hi Daniel, >> >> Yes, import via 3dm-g or step-g are the two main methods. They can also >> be created directly with openNURBS — there are several source code examples >> in src/proc-db (see the C++ files). >> >> Lua is good stuff and obviously really easy to integrate.. but there has >> also been good progress made on a direct python interface too. That code >> currently resides in a repo fork, but was last worked on by Jaipal in 2018 >> — he’s got a nice article up at >> https://medium.com/@Mr_Jaypee/brl-cads-python-procedural-geometry-990e3c286a63 >> and >> the code is on github. >> >> I don’t think python or lua as a new required dep are a problem at all. >> I’ve had a goal for years to have a built-in procedural primitive where one >> can describe geometry and define behavior with code (starting with either >> tcl, lua, python, or pure “ged” command listings). Orthogonal to creating >> NURBS entities of course.. >> >> Cheers! >> Sean >> >> >> On Jan 19, 2021, at 1:39 PM, Daniel Roßberg <danielmrossb...@gmail.com> >> wrote: >> >> Hello all, >> >> I was recently asked, how to create a NURBS solid in BRL-CAD. >> Unfortunately, I didn't know another possibility than importing them from >> Rhino. It should however be possible to create them with openNURBS >> functionality. >> >> My idea is to wrap the openNURBS classes by the Lua scripting language. >> Because of its compactness, it would be possible to bundle it with BRL-CAD >> and have it accessible from mged. >> >> It should also be mentioned that there is already a Python scripting >> interface with the rhino3dm interface. But, making this standard for >> BRL-CAD would bloat the program a bit, or? >> >> What do you think? >> >> Regards, >> Daniel >> _______________________________________________ >> BRL-CAD Developer mailing list >> brlcad-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> >> >> _______________________________________________ >> BRL-CAD Developer mailing list >> brlcad-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> > _______________________________________________ > BRL-CAD Developer mailing list > brlcad-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > > > _______________________________________________ > BRL-CAD Developer mailing list > brlcad-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/brlcad-devel >
_______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
