scorp08 (Jun 27 2019 at 10:34): scorp08 (Jun 27 2019 at 10:34):Hello all
Is "https://github.com/kanzure/python-brlcad" avaliable with py3. Tried but returned with errors, so I tried with 2to3 and did some changes in "post_install.py" but probably also ctypesgen is not available in py3 ??
Sean (Jun 27 2019 at 13:03):@scorp08 I don't think anyone has tried getting it to work with py3 yet. My guess is that it'll need to be switched to cffi or some other approach. There is a python binding that calls mged directly and avoids ctypesgen that may work better in the meantime.
scorp08 (Jun 27 2019 at 14:20):@Sean , what is cffi ? Did you mean https://github.com/nmz787/python-brlcad-tcl this package
Sean (Jun 27 2019 at 15:58):Yes, that one should still work just fine
Sean (Jun 27 2019 at 16:03):https://cffi.readthedocs.io/en/latest/
scorp08 (Jul 01 2019 at 11:57):I convert some issues to py3 for kanzure/python-brlcad but when it comes to parsing, ctypesgen is not compatible and seems that development is stopped. Currently I get error as "there is no optimize.lexer attribute". I do not know how to rewrite brlcad-python with cffi as it uses ctypesgen from beginning ?
Sean (Jul 02 2019 at 14:26):@scorp08 if I recall correctly (and it may not be), the brlcad-python project was an evolution from invoking mged directly to using ctypesgen. towards what you're wanting to do, though, I'm not sure why it matters whether it uses ctypesgen from the beginning -- it uses it now and that's obviously a problem if you want to use python3.
if you can't do the conversion to cffi, you'd either have to use the python-brlcad-tcl version that runs mged or wait indefinitely for someone to work on py3 support or use python2.7. fixing ctypesgen is no small task as it worked by directly outputting python code, which needs to be generated differently for py3.
scorp08 (Jul 03 2019 at 18:49):@Sean Thanks. How can I do conversion ? At leat once the starting point will be identified, rest will come through more easily.
Nathan McCorkle (Jul 04 2019 at 19:36):You'd need to read up on ctypesgen
Nathan McCorkle (Jul 04 2019 at 19:45):There are some hits here for ".lexer" https://github.com/davidjamesca/ctypesgen/pull/55/files?diff=split
Nathan McCorkle (Jul 04 2019 at 19:47):"Merge in various changes from kanzure and olsonse"
Nathan McCorkle (Jul 04 2019 at 19:47):Looks like these haven't been merged in and released, so you probably could try grabbing the unreleased code and running with that
Nathan McCorkle (Jul 04 2019 at 19:50):There's also SWIG, but I think kanzure had some thoughts on why that would be harder to use
Nathan McCorkle (Jul 04 2019 at 19:52):http://www.swig.org/Doc1.3/Python.html#Python_python3support
Sean (Jul 06 2019 at 00:03):Although in swig's defense, it would have survived all py2 to py3 changes unlike ctypesgen ;)
I think the concerns he had with swig were that it would pass through the C api and not be as clean as the wrapped version from ctypesgen. I'd think it's be possible to wrap the output from swig just as neatly though, at least as neatly as the ctypesgen wrap.
scorp08 (Jul 10 2019 at 12:35):@Nathan McCorkle , @Sean , I installed another repo of ctypesgen which is compatible with py3. Currently doing some conversion of brlcad-python to py3. Do I need to go for another dep. like ctypesgen or continue with it ?? What do you think ?
Sean (Jul 10 2019 at 14:07):@scorp08 I don’t think so but I guess you’ll find out :). Have to just look through the imports and try it. Keep the updates coming!
Nathan McCorkle (Jul 10 2019 at 16:47):I'm not sure, I never got kanzure's library to work even with Python2, or maybe it lacked hooks for the features I wanted to use. It was a lot less work to think about just wrapping command-line stuff with Python than all the work you're doing! I will gladly check your work as you progress though!! Let me know where your code lives and I'll grab your branch.
Nathan McCorkle (Jul 10 2019 at 16:48):For writing a custom GUI for building 3D models, the command-line stuff I did is actually too slow, so I'm definitely interested.
Sean (Jul 11 2019 at 04:17):We were just looking at mged's command-line performance a while back and noticed some massive slowness and room for optimization. Curious though what specifically you saw that was slow, whether it was the same issue or something else.
Sean (Jul 11 2019 at 04:24):Frankly, I think the wrapped approach is still going to be about 1/10th the effort of any binary method. Of course, it'll b about a 1/10th performance tradeoff no matter what just from binary startup time, but still should be fast enough for 90% of cases. If we fixed the slowness we found, it'd probably be 98% of cases.
scorp08 (Jul 11 2019 at 13:02):I manage to install to py3 but when I run an example below, returned with pointer error. Some help need related with brlcad.wdb
from brlcad.vmath import Transform
from brlcad.wdb import WDB
from brlcad import primitives
if __name__ == "__main__":
with WDB("test_wdb.g", "Test BRLCAD DB file") as brl_db:
brl_db.sphere(
"sph1.s",
center=(1, 2, 3),
radius=0.75
)
scorp08 (Jul 11 2019 at 13:03):If you want , I can create a repo and you can edit the code
Nathan McCorkle (Jul 11 2019 at 18:08):@scorp08 yeah throw it on github/etc and I'll give it a try.
Nathan McCorkle (Jul 11 2019 at 18:12):@Sean I can't remember what I was trying to do, but it was pretty dumb... Something like using nirt to export an image (or maybe mged has a function like that, it's been a while and I haven't checked my local code), then taking that image (JPG/PNG/BMP) and displayed it in a Python GUI image-frame. Then if the user clicked and dragged, it would adjust the rotation, re-request an image to be exported from BRLCAD, then re-display. Super dumb, but quite low effort exerted. I think I was getting like 1FPS.
Sean (Jul 11 2019 at 21:23):Ooooh, haha .. so basically using nirt to render an image?? Yeah.. that's crazy :)
scorp08 (Jul 13 2019 at 16:11):Nowadays I m on a long road, I'll try to upload and focus on nextweek. Examples in brlcad-python git is working in my py3 but could not run rt_shoot inside the librt...
scorp08 (Jul 16 2019 at 11:11):Are there any doc. for tcl bindings for qt (it seems that there is an example for treewidget) but could not find any project related with qt framework of brl_cad
Sean (Jul 19 2019 at 14:40):Nowadays I m on a long road, I'll try to upload and focus on nextweek. Examples in brlcad-python git is working in my py3 but could not run rt_shoot inside the librt...
Any progress @scorp08 ?
Sean (Jul 19 2019 at 14:43):Are there any doc. for tcl bindings for qt (it seems that there is an example for treewidget) but could not find any project related with qt framework of brl_cad
I assume you meant Tk bindings, and the answer is no. Regardless, we have no intention of sticking with Tk. Qt GUI can/should be pure Qt goodness.
Sean (Jul 19 2019 at 14:44):Tcl will likely linger for a while longer but even that is getting pushed into the foreground as just one of several scripting interface possibilities, out of libraries and application infrastructure.
scorp08 (Jul 29 2019 at 07:24):Hello
How brl-cad display 3d .g files in screen. I was searching to implement it to pyqt with opengl. Also checked this repo https://sourceforge.net/p/brlcad/code/HEAD/tree/rt%5E3/trunk/src/QtGUI/ but no tool to show in screen
Nathan McCorkle (Jul 30 2019 at 08:32):yeah I also tried to get that QtGUI to compile but don't believe I was able to... my memory on that effort is fuzzy, but I think it boils down to the documentation for that code not being too great, and the makefiles for the whole BRLCAD build not being kept syncronized to allow building that GUI... but I could be wrong, I think it was like a year ago, or more, that I tried.
Nathan McCorkle (Jul 30 2019 at 08:33):Did you ever get a chance to commit/upload your Python3 progress? I have a very simple Python GUI to show 3D .g files in, but it is VERY slow... I wonder if your code would give my GUI any reasonable speed-up
Nathan McCorkle (Jul 30 2019 at 08:34):@Daniel Rossberg any writeup on how to compile that QT GUI?
Daniel Rossberg (Jul 30 2019 at 13:45):make QtGUI scorp08 (Aug 01 2019 at 06:18):@Nathan McCorkle I'll try to upload today though there is a problem. When _bindings folder is generated, binders opens dll files in the libraries with ctypes. Some of dll's depends each other so setup.py need to see \bin folder otherwise as in my setup , it will return error "no module found". Is it done with os.chdir or any other better way ?
scorp08 (Aug 04 2019 at 10:20):Hello All
My repo is ready for py3 in here( https://github.com/scorp08/python-brlcad). Some small arrangements may be neccessary in ctypesgen side. I created a pull request in olsense's repo. If you install my repo, you may need to apply those changes. Before install you can do neccessary work in .cfg file to arrange path locations of brl-cad and mingw
scorp08 (Aug 04 2019 at 10:21):If there is a stuff to be added, please pull :)
scorp08 (Aug 05 2019 at 06:25):@Daniel Rossberg , @Nathan McCorkle Which repo is more usefull for the GUI : g3d or QtGUI , are they independent from each other ? maybe I will convert to PyQt ,use opengl etc.
scorp08 (Aug 05 2019 at 13:16):Are there a CAD kernel used in BRL-CAD (parasolid etc. ) ? Also are there a step to .g converter or a source code to open step file in database ?
Daniel Rossberg (Aug 05 2019 at 19:12):Daniel Rossberg , Nathan McCorkle Which repo is more usefull for the GUI : g3d or QtGUI , are they independent from each other ? maybe I will convert to PyQt ,use opengl etc.
I can't say much about g3d, but, QtGUI can be used as inspiration for the creation of an own Qt based BRL-CAD GUI. They are independent from each other.
Daniel Rossberg (Aug 05 2019 at 19:16):Are there a CAD kernel used in BRL-CAD (parasolid etc. ) ? Also are there a step to .g converter or a source code to open step file in database ?
BRL-CAD has its own CAD kernel, which is mainly the librt. There exists even a C++ interface for it.
And, yes there is a step-g converter, which is open source.
scorp08 (Aug 06 2019 at 05:41):Is interface open-source ?
Daniel Rossberg (Aug 06 2019 at 06:32):Do we talk about the same software suite? Which content of the BRL-CAD repository is not open source?
scorp08 (Aug 06 2019 at 11:29):Are there a CAD kernel used in BRL-CAD (parasolid etc. ) ? Also are there a step to .g converter or a source code to open step file in database ?
BRL-CAD has its own CAD kernel, which is mainly the librt. There exists even a C++ interface for it.
And, yes there is a step-g converter, which is open source.
I meant the interface for librt
Daniel Rossberg (Aug 06 2019 at 12:37):Sure, it is in the BRL-CAD repository, in the rt^3 branch. It's called coreinterface there.
In principle it's the same as the brlcad.dll (SDK download: https://sourceforge.net/projects/brlcad/files/BRL-CAD%20Runtime%20Libraries/7.26.0/, sources are in the main branch misc/win32-msvc/Dll directory (uses the stuff in rt^3 too), see also https://brlcad.org/wiki/BRL-CAD%27s_core_C%2B%2B_interface)
Daniel Rossberg (Aug 06 2019 at 12:40):The rt^3 QtGUI with the brlcad.dll as back-end: https://github.com/drossberg/BrlCadQtGUI
scorp08 (Aug 07 2019 at 08:05):Ctypesgen contains an UNCHECKED function in https://github.com/olsonse/ctypesgen/blob/master/ctypesgen/printer_python/preamble/3_2.py which cause callbacks of Cfunctypes to return void. Seems that need to put an __type__.encode() but why in the first place do we need it, do you think ?
scorp08 (Aug 08 2019 at 06:10):can libwdb be a kernel too ? or only librt ?
scorp08 (Aug 08 2019 at 07:49):After using step-g converter , raytrace worked a bit slow in resulting files.So are there any development in converter or is it neccessary to add some stuff ? What do you think ?
scorp08 (Aug 10 2019 at 06:42):@Sean When step-g convert Step Structures to brep structures, does resulting .g contains meshes or nurbs ? Does it contains brl-cad primitives too ?
Sean (Aug 10 2019 at 20:19):@scorp08 it imports brep nurbs
Sean (Aug 10 2019 at 20:21):It’d be nice to expand support to meshes, but they are rarely seen with real models
scorp08 (Aug 18 2019 at 09:22):@Sean is there a neccessity to modify step-g (increase performance, increase raytrace speed etc) ? is there a project idea?
scorp08 (Aug 21 2019 at 04:37):What kind of method is used raytrace for nurbs ? Are there a possible faster approach ? Maybe need to check articles etc.
Sean (Aug 21 2019 at 17:18):Sean is there a neccessity to modify step-g (increase performance, increase raytrace speed etc) ? is there a project idea?
@scorp08 "neccessity"? well that certainly depends on what one's requirements are. it imports ap203 (v1) nurbs models just fine. it doesn't import meshes, doesn't import surface-only model, doesn't handle ap203v2 or ap214 or ap242. those are all features that would be GREAT to have and would make for good project ideas, any of them.
Sean (Aug 21 2019 at 17:19):the performance of step-g is typically inconsequential, people would wait hours if they knew it always worked and could trust everything got imported.
Sean (Aug 21 2019 at 17:20):converters don't do ray tracing, so do you mean ray tracing of NURBS? that is absolutely a grand project idea.
Sean (Aug 21 2019 at 17:23):raytracing nurbs is a super complicated topic, but there is definitely room for improvement in our current implementation. our implementation is based loosely on a 2006 paper on Interactive ray tracing of NURBS. However, we build surface tree's that are unnecessarily deep and it would probably benefit greatly from dynamic surface trees, building them on the fly during ray tracing. it would also benefit greatly from simple memory coherency optimization, e.g., to evaluate bundles of rays at a time instead of individually as nurbs structures are memory-intensive.
scorp08 (Aug 23 2019 at 07:07):@Sean http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.7500&rep=rep1&type=pdf this paper ?
Sean (Aug 23 2019 at 08:45):Yes, that's the one! We didn't get to the coherent data packing technique they're using, but the general idea of directly evaluating the NURBS surfaces (as opposed to the historic method of subdividing into Bezier or B-Spline patches or polygonal meshes), is essentially the method we're using.
scorp08 (Aug 23 2019 at 12:17):@Sean Thnks, is brlcad 7.24 using it ? I checked the rt_shootray in librt/shoot.c but could not find a connection between that paper ?
Sean (Aug 23 2019 at 14:25):Yes it is. You'd have to follow much deeper to actual NURBS logic, which resides in src/librt/primitives/brep
scorp08 (Aug 25 2019 at 06:55):is rt_brep_shot used when shoot to brep ? I thought that theres only one single shoot function which is rt_shootray ?
Daniel Rossberg (Aug 25 2019 at 16:34):But, how does rt_shootray know how to ray-trace the primitives? You may have noticed stp->st_meth->ft_shot() in rt_shootray()'s source code. This is a function pointer which points to the primitive specific ray-trace algorithms. Look at it in a debugger.
scorp08 (Aug 26 2019 at 08:25):I would like to divide regions of e.g parasolid file in another CAD software, give names those regions and after convert to .g file via converters, see regions and same names. Is it possible. I tried UG but after converting, got all regions as "all" one single entity in archer
Sean (Aug 26 2019 at 17:59):@scorp08 you can think of the rt_*_shot() functions as a basic ray-primitive intersection test which does not typically involve scene traversal, whereas rt_shootray() does
Sean (Aug 26 2019 at 18:01):@scorp08 what does "l all" show? Geometry is typically a hierarchy. If you created multiple regions, then they will typically import as multiple regions but then a group is usually still created that combines everything together. The individual regions are still there though.
scorp08 (Aug 26 2019 at 20:22):@Sean Does brlcad has still fastest raytrace kernel ? Can it be powered with NVIDIA OptiX?
Sean (Aug 26 2019 at 21:03):@scorp08 that has become a heavily loaded question -- it very much depends what you are comparing, what is valued, and what is supported in a given ray tracing kernel to be able to talk about it's performance. BRL-CAD does have the fastest solid ray tracing with a substantial investment in verification and validation (i.e., it's "more correct" than most with regards to edge case behavior).
Sean (Aug 26 2019 at 21:05):there are faster ray tracing kernels for specific types of geometry (e.g., triangle-only ray tracing) or first-hit ray tracing, but they typically don't have verification and validation and if you need solidity, they can be non-starters
Sean (Aug 26 2019 at 21:07):We have an experimental OpenCL pipeline that will utilize GPU cores, but it has remained experimental because most real models our main customers ray trace do not come close to fitting on a video card.
Sean (Aug 26 2019 at 21:08):It remains an interesting and desirable area of research, particularly for NURBS ray tracing. Our NURBS ray tracing implementation is unoptimized, too, so even basic work there would be a huge benefit (orders of magnitude).
scorp08 (Aug 28 2019 at 07:12):Does brlcad use BSP trees ? or octree ?
scorp08 (Aug 28 2019 at 07:52):@Sean converted a parasolid file containing multiple bodies to stl in nx then convert it to .g with stl-g.exe. but parasolid-stl conversion in nx created one solid body so after stl-g, it is showing only one region as normally
scorp08 (Aug 28 2019 at 08:11):@Sean considering for example two huge (limits up to 14 m) geometries from stl to .g (12 MB size) and one is modeled with primitives (2 MB), is it possible to obtain same rt_shootray performance if shoot to different locations and a lot of times in resulting .g models??
Sean (Aug 28 2019 at 08:32):@scorp08 Eh... STL only supports one object per file. So whatever you exported got combined into one entity before it ever got to BRL-CAD.
Sean (Aug 28 2019 at 08:33):You should really avoid STL if at all possible. It's a terribly limited and typically lossy format.
Sean (Aug 28 2019 at 08:37):Sean considering for example two huge (limits up to 14 m) geometries from stl to .g (12 MB size) and one is modeled with primitives (2 MB), is it possible to obtain same rt_shootray performance if shoot to different locations and a lot of times in resulting .g models??
Primitives will typically out-perform triangles when your mesh density is approximately pixel-sized or smaller. You typically have to tessellate to sub-pixel (1M+ triangles) to get something with curvature equivalence (at least for any reasonable spectral / shading comparison).
scorp08 (Aug 28 2019 at 17:50):@Sean if we compare nurbs(powered with gpu support) vs primitives raytrace, can it be possible to reach to primitive shoot performance ??
Sean (Aug 28 2019 at 18:35):It depends. Are the primitives also GPU-accelerated? Does the model fit on a GPU? Are there more primitives and/or Boolean operations than there are NURBS control points? ... :)
scorp08 (Aug 29 2019 at 05:52):@Sean https://brlcad.org/wiki/OpenCL_GPGPU_Brep_Raytracing here is said that there needs to be conversion of object oriented C to strict ANSI C (C99- strict) for opencl . Why strict is neccessary ??
Sean (Aug 30 2019 at 20:02):@scorp08 I think that statement is out-of-date and was written well before we had a preliminary pipeline. The conversion that refers to is that the existing library uses a lot of function callbacks, which you can't do on the GPU. The simple workaround was to just call the appropriate OpenCL callback explicitly, I believe. Either way, it wasn't as complex as originally envisioned (or at least, it's all relative).
Sean (Aug 30 2019 at 20:04):OH, sorry, I misread -- that's specifically about converting BREP objects to OpenCL. Yes! That must be converted to C. I don't think the "strict" part is actually necessary in a language-sense. I believe it's referring to the source code itself, that you don't have objects in OpenCL, only functions. So if you're going to convert, you need functions to convert.
Sean (Aug 30 2019 at 20:05):Still, more than half the code is already C. It's the OpenNURBS portions (which are all C++) that would need to be extracted to be accelerated appropriately.
Sean (Aug 30 2019 at 20:06):That's a half-dozen or so functions.
scorp08 (Sep 04 2019 at 08:52):thnks for answers. I had convert parasolid to step then step to .g but some curves (due to complexity ) could not be seen in .g model and shootray was much more slower than the model that I created with primitives. That's why I thught to include a gpu support to see if there are speed ups. I have some basic knowledge about raytracing, nurbs and openCL. Could you recommend a source to study ??
Sean (Sep 05 2019 at 15:03):@scorp08 yes primitives will almost always be faster because they use less memory and are really fast to intersect. their downside is modeling time and usability, not performance.
Sean (Sep 05 2019 at 15:05):there are massive potential speed ups for nurbs with both coherency optimization (shooting sets of rays instead of individually) as well as gpu or simd optimization. it would be approximately 10x faster each, about 100x faster overall with both. the same however can also be said of the primitives -- the same optimizations would also make them 100x faster.
Last updated: Oct 09 2024 at 00:44 UTC