Daniel Rossberg (Nov 22 2018 at 18:56): Daniel Rossberg (Nov 22 2018 at 18:56):As you told i have started "playing" with BRL-CAD and its nice,I am doing on MGED.
I have also downloaded the BRL-CAD archer.
Actually i am a little confused about about relation of MGED and Archer, can we use same command on archer.
And what coding work is there? on Archer or MGED? I have seen some project ideas here: http://brlcad.org/wiki/Google_Summer_of_Code/Project_Ideas
And i have a good control over c/c++ and opengl so where to go?
Archer was designed as "next generation" mged application. Both are graphical user interfaces to BRL-CAD, and both are using the same core libraries as back end, including the TCL command interpreter.
Daniel Rossberg (Nov 22 2018 at 19:16):OK, I've an OpenGL issue for you:
Consider the annotation primitive in BRL-CAD: https://brlcad.org/wiki/Annot
You can create an example with the following commands:
units mm in sphere.s sph 0 0 0 1000 in annotation.s annot 0 0 0 Sphere 5 5 1 3 g all.g sphere.s annotation.s
Start mged with the X-Window backend: mged -c and then X. This shows how it should look like: The line of the annotation is always 5mm on the screen long. Zoom in and out to see the effect.
Now, start mged with the OpenGL backend: mged -c and then ogl. Here, the line is always 5mm in the model coordinate system long, which isn't correct.
The OpenGL source code for this can be found in "src/libdm/dm-ogl.c. Look for BN_VLIST_DISPLAY_MAT there, this shall toggle the used coordinate system to display scale.
Kartik kumar (Nov 23 2018 at 09:21):thank you .. Ok i m looking into it.
And yah next time i will text on public stream
Daniel Rossberg (Dec 08 2018 at 17:32):@Kartik kumar
Hello,
I was going through somes deuces workhttp://brlcad.org/wiki/Deuces#Implement_a_primitive_centroid_function
Is this code complete? i don't see any function in this?
As far as I know, not all primitives have a centroid function yet. You could do a grep -R centroid * in the src/librt/primitives directory to find out which primitives have already a rt_~_centroid() function and which do not.
Daniel Rossberg (Dec 08 2018 at 17:36):Also i see some primitives to implement here
http://brlcad.org/~sean/ideas.html
does it only require c/c++ or opencl also?
For the moment they require C only.
BTW, the implementation of some of them was already started but not finished.
Kartik kumar (Dec 09 2018 at 14:20):I am not getting the code of primitives like arb etc. what to do? I want to implement some primitives given here http://brlcad.org/~sean/ideas.html . Does it require to understand the whole code of primitive?
Daniel Rossberg (Dec 09 2018 at 17:07):Maybe not the whole code of all primitives, but which functions the primitives have and why.
Daniel Rossberg (Jan 29 2019 at 08:07):@Mayank Madan The official BRL-CAD bug tracker is https://sourceforge.net/p/brlcad/bugs/
Regarding mged: On which operating system do you run the program?
Mayank Madan (Jan 29 2019 at 10:06):I'm on Ubuntu 18.10
Mayank Madan (Jan 30 2019 at 08:23):Did the latest commit to the repository break the build? Because I cant build even after a fresh checkout
Mayank Madan (Jan 30 2019 at 08:25):It says it has no rule to make target lemper.c
Mayank Madan (Jan 30 2019 at 10:44):I'm really sorry but it seems that its building fine. Im not sure why it was happening because i did not mess with CMakeLists or Makefile(s) that were generated(the svn diff command didnt output anything so I'm pretty sure i didnt mess with anything). I decided to just start over by deleting the local copy of the repository and starting fresh and now it works. Sorry for the spam
Daniel Rossberg (Jan 30 2019 at 12:46):The BRL-CAD build needs a clean-up from time to time because of tricky changes in the CMake files which cannot be handled automatically in an existing build.
Daniel Rossberg (Jan 30 2019 at 12:48):Therefore, if a build fails and the reason isn't obvious you should try it again from scratch.
Sean (May 31 2019 at 17:48):@Chetan Shinde there's lots of ways you can get started on a project, and "what" mostly depends on your interest and abilities. If you have at least basic programming skills, something we really need is a program that creates all available objects.
Sean (May 31 2019 at 17:48):if that sounds interesting, I can give you some pointers to help you get started.
Chetan Shinde (Jun 04 2019 at 21:10):if that sounds interesting, I can give you some pointers to help you get started.
Yea, i am excited.
Chetan Shinde (Jun 04 2019 at 21:44):Chetan Shinde there's lots of ways you can get started on a project, and "what" mostly depends on your interest and abilities. If you have at least basic programming skills, something we really need is a program that creates all available objects.
Yes, i do have some basic skills.
Rajesh Kumar (Jul 15 2019 at 19:38):Hey, @Sean can you please help me with this. Thanks
CMake Error at misc/CMake/BRLCAD_Util.cmake:553 (string):
string sub-command STRIP requires two arguments.
Call Stack (most recent call first):
CMakeLists.txt:154 (set_config_time)
Sean (Jul 19 2019 at 14:41):@Rajesh Kumar my first guess would be that you're using an older or newer version of cmake. Try a newer or older version if you're not comfortable debugging CMake code.
Rajesh Kumar (Jul 21 2019 at 11:09):Thank you for your response.
I currently have a CMake version 3.13.4 on my machine (macOS), and cmakelist for BRL-CAD specifies minimum version VERSION 3.1.3, which in my case should not be an issue.
Additionally, I am trying to use a cross-compiling toolchain to generate llvm code. All goes very well until I get this error.
After a little look into it, I saw that brl-cad tries to maintain version history and ask for some variables through STRIP command, (CONFIG_DAY...).
you can find this in @ brlcad/misc/CMake/BRLCAD_Util.cmake Line: Line 553. which gets called from set_config_time.
I hope I have provided enough info about my problem. It will be really helpful if you could give me assistance on setting correct build environment.
Thanks
Sean (Jul 21 2019 at 20:04):The minimum version we currently specify may not be correct. We don't always go back to those older versions to make sure everything is working right. Similarly, we don't necessarily check the very latest cmake to see if they broke anything that was working. That said, 3.13 sounds new enough that I agree it should not be an issue. I'm using 3.14 at the moment successfully.
Sean (Jul 21 2019 at 20:06):What I suspect is happening is that "${CONFIG_DAY}" on line 553 is empty, so cmake only sees: string(STRIP CONFIG_DAY)
Sean (Jul 21 2019 at 20:06):which would happen if the preceding execute_process line fails for some reason
Sean (Jul 21 2019 at 20:08):what you can try doing is put the rfc2822_src code into a file and just try compiling and running that by hand
Sean (Jul 21 2019 at 20:09):it's this code:
/* RFC2822 timestamp and individual day, month and year files */ #include <time.h> #include <stdio.h> #include <string.h> int main(int argc, const char **argv) { time_t t = time(NULL); struct tm *currenttime = localtime(&t); if (argc <= 1) { char rfc2822[200]; strftime(rfc2822, sizeof(rfc2822), \"%a, %d %b %Y %H:%M:%S %z\", currenttime); printf(\"%s\", rfc2822); return 0; } if (strncmp(argv[1], \"day\", 4) == 0) { printf(\"%02d\", currenttime->tm_mday); } if (strncmp(argv[1], \"month\", 5) == 0) { printf(\"%02d\", currenttime->tm_mon + 1); } if (strncmp(argv[1], \"year\", 4) == 0) { printf(\"%d\", currenttime->tm_year + 1900); } return 0; }
Sean (Jul 21 2019 at 20:10):if you can compile that, try running it as "path/to/the/exe day"
Sean (Jul 21 2019 at 20:10):that should shed some light on what's going wrong.
Daniel Rossberg (Oct 29 2019 at 14:38):BRL-CAD mged tutorial: https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf
Daniel Rossberg (Oct 30 2019 at 08:35):Welcome newbies! Here an answer to the FAQ "How to start?":
mged and the more modern GUI archer.To start with programming
BTW, the posts in this Zulip chat are organized in streams and topics. Make sure that you posts are meaningfully categorized there. E.g., this post is in #general > getting started
Aniruddha Ghadge (Nov 02 2019 at 12:16):@Sean I have been got familiar with mged and rt (gone through the pdf ) what should be my further approach ?
Sean (Nov 04 2019 at 21:16):@Aniruddha Ghadge Now that you have some basics, what would you like to do or learn?
Sean (Nov 04 2019 at 21:16):If you're looking to get into code development, there is literally an endless supply of tasks small and big.
Sean (Nov 04 2019 at 21:17):If you're looking to become a more proficient 3D modeler, there's nothing quite as effective as measuring and modeling something near you in detail.
Aniruddha Ghadge (Nov 05 2019 at 10:19):@Sean I am looking to get into the code starting with small tasks and further growing step by step , I would like to gain some knowledge about API or UI design as I am interested in those two things. Can u suggest something related to these ?
Sean (Nov 05 2019 at 12:36):@Aniruddha Ghadge Sure, but it's a really big system so it'll help to focus on something really small. Looking at our TODO file, there's only a couple hundred to choose from, but I can suggest one to start with. ;)
Sean (Nov 05 2019 at 12:36):looking at the list in TODO, this one is pretty simple: overlay command needs to accept multiple file arguments
Sean (Nov 05 2019 at 16:48):To point you in the right direction, "overlay" is a command you can run in MGED on the command-line. Sources for it are in src/libged/overlay.c
Aniruddha Ghadge (Nov 05 2019 at 18:01):Yeah I was familiar with that command but I was not getting the sources ...... Thanks !
Sean (Nov 05 2019 at 18:02):nearly all mged commands are in src/libged
Aniruddha Ghadge (Nov 05 2019 at 18:06):Okayy
Jeffrey Liu (Nov 18 2019 at 04:41):Hi, I've just compiled the source code on Debian and while I believe it worked successfully, I've been having some trouble working with MGED . When I call the MGED command, my computer becomes extremely slow, and it takes around 15-20 minutes for the graphics window to open while the command window does not open at all. I don't believe that this is simply a hardware issue, so I was wondering if anyone has resolved similar issues before? Any help would be much appreciated.
Erik (Nov 18 2019 at 13:15):What kind of cpu, mem, 3d accel, etc?
Sean (Nov 18 2019 at 16:45):@Jeffrey Liu I've never heard of such an issue happening with mged before! Try running "mged -c" and try the "nu" for no-graphics mode. If that works fine, try running the "attach X" command, and then "attach ogl" command and see if both work (they should display a graphics window each).
Daniel Rossberg (Nov 18 2019 at 17:43):I'm experiencing a similar issue with rt. Also Debian, buster latest version: Mged starts normally, but when I load any geometry and run rt (even without selecting an object before), my system freezes for some minutes. After this, half of my swap space is used. A clean shut-down isn't possible either, because the swap device cant be switched off. (The laptop has 4G RAM and 8G swap space).
Same behavior with the stand alone rt command and -P 1.
Sean (Nov 18 2019 at 17:51):@Daniel Rossberg seriously?? this is definitely emergency news ... I assume it's latest trunk and not the last release? Does it happen every time? Is it using the bundled Tcl/Tk or the system Tcl/Tk?
Sean (Nov 18 2019 at 17:53):If Rt is doing it too... that implies something lower level, which is even more concerning. If it reliably has a delay, see if it goes away after: rm -rf ~/.cache/BRL-CAD
Sean (Nov 18 2019 at 17:54):If that's on Windows, it's in a different location, standard Windows user cache folder.
Sean (Nov 18 2019 at 17:57):Only other thing I can think of is (on Linux at least) library pre-binding. It might be prebinding all the libraries and that could be taking an exhaustive amount of time and memory. Maybe something we could do to pre-bind in the build system, but would need to confirm what's going on first.
Daniel Rossberg (Nov 18 2019 at 23:33):The bad news is that
But, rendering to a file works well. The difference in the output are the following two lines:
CACHE /home/rossberg/.cache/BRL-CAD/.rt WARNING: ^ Directory does not exist. Initializing.
rt_out.txt rt-to-file_out.txt
What's the ^ directory?
Another idea: Can I use X-Window instead of OpenGL for the output? Maybe with the -F command line parameter? OpenGL doesn't work well anyeway. The framebuffer window is always transparent.
Daniel Rossberg (Nov 18 2019 at 23:46):Hi, I've just compiled the source code on Debian and while I believe it worked successfully, I've been having some trouble working with MGED . When I call the MGED command, my computer becomes extremely slow, and it takes around 15-20 minutes for the graphics window to open while the command window does not open at all. I don't believe that this is simply a hardware issue, so I was wondering if anyone has resolved similar issues before? Any help would be much appreciated.
:grinning_face_with_smiling_eyes: I just reproduced this by starting mged in X-Window mode. It looks like OpenGL isn't the cause in this case :thinking:
Jeffrey Liu (Nov 19 2019 at 05:42):Hi @Sean , thank you so much for your response! Running "mged -c" seems to work fine with both "nu" as well as "X," but there doesn't seem to be a valid "ogl" option for me.
Jeffrey Liu (Nov 19 2019 at 05:51):@Erik I am using an Intel i5-6300HQ CPU with 8 GB of RAM. I do have a GTX950M with drivers installed, but I've been having some trouble enabling it so I believe that integrated graphics is being used at the moment.
Sean (Nov 21 2019 at 07:29):@Jeffrey Liu that's fine regarding no ogl. does it consistently take a long time without -c ? does it take a long time with "mged -c" and then run the "gui" command?
Sean (Nov 21 2019 at 07:36):The bad news is that
- removing the cache doesn't change anything and
That's actually really good news. It's one of the few major changes with potential to affect rt and mged, so it's good to hear it's not involved.
- configuring all libs to bundled doesn't change it either.
That helps rule out it being something from a system-installed dep on Linux, like a system Tk.
What's the
^directory?
It's pointing at the cache directory on the previous line, similar to a compiler warning marker.
Another idea: Can I use X-Window instead of OpenGL for the output? Maybe with the
-Fcommand line parameter? OpenGL doesn't work well anyeway. The framebuffer window is always transparent.
I believe this is possible, though I forget the exact mechanics. Using -F will set the default for mged -c, but I don't know if that passes through to the gui command which kicks off the Tk gui logic. I recall there being an internal command that configures the gui to using ogl or X, but I don't recall what it was. You can manually run "attach X" even in gui mode and it will create additional graphics windows using X.
Sean (Nov 21 2019 at 07:40)::grinning_face_with_smiling_eyes: I just reproduced this by starting mged in X-Window mode. It looks like OpenGL isn't the cause in this case :thinking:
That's good bad news. If you have 'perf' installed, can you run "perf record -F 99 mged" followed by "perf report" to see if there's indication of what's going on?
Daniel Rossberg (Nov 21 2019 at 15:03):I traced the malloc() and realloc() functions, with no result. Even ps and top aren't able to determine the process which consumes that much memory. I suppose therefore that the huge memory allocation is not on the heap, but maybe by the graphics unit instead.
I'll try the perf command. I just installed it.
Daniel Rossberg (Nov 22 2019 at 05:10):Unfortunately, perf didn't helped.
So, I did it the hard way and stepped trough the program until it hangs again and again, with reboots between the trials. And, I found that the rt command hangs in src/libfb/if_ogl.c line 514.
There, 4 Gig of memory is allocated and initialized, probable for no good reason. On machines with 8 Gig RAM and more this may not be an issue, on my laptop with only 4 Gig it is however. I don't know why MODE_1MALLOC isn't the default or what's the benefit of allocating always the largest possible frame buffer memory.
Jeffrey Liu (Nov 23 2019 at 00:49):Hi @Sean , the issue occurred every time I ran it without -c, but mged -c and gui took a reasonable amount of time (maybe around 2-3 seconds). I don't quite know what the issue was because everything works fine after I compiled on Windows.
Sean (Nov 23 2019 at 00:59):@Jeffrey Liu when you run "mged -c" what does it report for display modes you can attach to?
Sean (Nov 23 2019 at 00:59):and are you saying you recompiled and it worked, but the distributed binaries had the delay?
Sean (Nov 23 2019 at 01:12):@Daniel Rossberg That's a bit disconcerting. None of that code has changed, but that's still bizarre because that memset size is not very large at all ... unless .... one of the max sizes is unitialized/negative and resulting in a huge number..
Jeffrey Liu (Nov 23 2019 at 01:31):When I ran "mged -c", I believed it offered "nu|txt|X|tk." What I meant was that I was previously trying to compile on Debian Buster, so I suspect that it was most likely a driver or library issue.
Sean (Nov 23 2019 at 02:05):it offered "tk"???
Jeffrey Liu (Nov 23 2019 at 02:20):Yep, I just booted into Debian again and those options are still there. It still opens a graphics window but the top toolbar is a little messed up.
Daniel Rossberg (Nov 23 2019 at 02:42):Daniel Rossberg That's a bit disconcerting. None of that code has changed, but that's still bizarre because that memset size is not very large at all ... unless .... one of the max sizes is unitialized/negative and resulting in a huge number..
I wouldn't call 4 gigabyte of RAM "not very large". This is all this laptop has.
Sean (Nov 23 2019 at 06:59):@Daniel Rossberg it shouldn't have been 4 gigs. that sounds like a signed overflow or signed to unsigned mistake.
Sean (Nov 23 2019 at 07:09):that explains it.
looks like I made a change last year in r71760 that consolidated the max image size to consistently be 32768327684 = 4294967296 bytes (i.e., 4GB), which is obviously a major problem for 4GB systems.
Sean (Nov 23 2019 at 07:10):(to be clear, not an overflow or signed mistake, just a default memory assumption changed with implications not fully expected.
Sean (Nov 23 2019 at 07:24):applied a change that reduces the usage by more than half -- can you test?
Daniel Rossberg (Nov 23 2019 at 14:23):I'll see what I can do. I'm the most time in the air this weekend.
Daniel Rossberg (Nov 23 2019 at 14:28):The change with revision 71742 seems to have a much bigger impact.
Sean (Nov 23 2019 at 16:40):Yes, that general commit timeframe was a refactoring to support larger images. Hit limits doing large poster-size production rendering.
Sean (Nov 23 2019 at 16:44):looks like ogl went from 16k^2 to 32^2, so 1GB to 4GB minimum memory implication on context initialization
Daniel Rossberg (Nov 23 2019 at 19:04):I made some tests. In general, there were okay. I got the best results with OpenGL. With this interface, the memory doesn't need to be actually allocated in the RAM, at least not all of it. (For some reason the 4 Gig was always fully allocated/placed in the RAM.)
With the X-Window interface, always the whole 1.6 Gig was placed in the RAM, but it seems to not use shared memory either. If you are in bad luck and it starts swapping (happened to me once), it hangs.
Daniel Rossberg (Nov 23 2019 at 19:08):Hi, I've just compiled the source code on Debian and while I believe it worked successfully, I've been having some trouble working with MGED . When I call the MGED command, my computer becomes extremely slow, and it takes around 15-20 minutes for the graphics window to open while the command window does not open at all. I don't believe that this is simply a hardware issue, so I was wondering if anyone has resolved similar issues before? Any help would be much appreciated.
With the X-Window interface (for example, if you compiled BRL-CAD without OpenGL support), no extra command window will open. The command line is in the terminal were you started mged instead.
Daniel Rossberg (Nov 23 2019 at 19:10):I wonder what are the benefits of using shared memory and allocating more of it than needed :thinking:
Daniel Rossberg (Apr 30 2024 at 13:49):Hi @Grant Taylor, welcome at BRL-CAD!
You can start with BRL-CAD like you did with the other CADs you mentioned: Install the programs (installation packages can be found at https://github.com/BRL-CAD/brlcad/releases). This will install over 200 programs. Most of them are small command line tools. The most interesting for you are our old but still heavily used GUI mged and the more modern GUI archer. Try them out! You can use the tutorial https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf four guidance.
Grant Taylor (May 01 2024 at 12:00):Daniel Rossberg said:
Hi Grant Taylor, welcome at BRL-CAD!
You can start with BRL-CAD like you did with the other CADs you mentioned: Install the programs (installation packages can be found at https://github.com/BRL-CAD/brlcad/releases). This will install over 200 programs. Most of them are small command line tools. The most interesting for you are our old but still heavily used GUI mged and the more modern GUI archer. Try them out! You can use the tutorial https://brlcad.org/w/images/c/cf/Introduction_to_MGED.pdf four guidance.
Thank you very much Daniel. I think my problem is I was trying to figure out MGED more or less blind, and there was mild confusion as a result. I think I'll try using Archer for a bit. Thanks again!
Last updated: Jan 09 2025 at 00:46 UTC