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 > <mailto: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 > > <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 >> <mailto: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 >> <mailto:brlcad-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/brlcad-devel >> <https://lists.sourceforge.net/lists/listinfo/brlcad-devel> > > _______________________________________________ > BRL-CAD Developer mailing list > brlcad-devel@lists.sourceforge.net <mailto:brlcad-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/brlcad-devel > <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
