Stream: brlcad

Topic: guidance for the first contribution

Sumagna Das (Oct 14 2020 at 18:17):

@Vikram Atreya if you want there's a doxygen generated online documentation, available at brlcad.org/docs/api

Vikram Atreya (Oct 14 2020 at 18:18):

Okay, I will check it out.

Sumagna Das (Oct 14 2020 at 18:20):

if you need any other help, i will help as much as i can

Vikram Atreya (Oct 14 2020 at 18:23):

Thank you for the assurance :grinning:

Vikram Atreya (Oct 15 2020 at 18:35):

Could you give me an overview of what this struct is "rt_db_internal" and what approximately these "RT_CK_DB_INTERNAL" and "RT_BOT_CK_MAGIC" do

Sumagna Das (Oct 15 2020 at 18:37):

as far as i understand, rt_db_internal is the in-memory representation of BRL-CAD's database object.

Sumagna Das (Oct 15 2020 at 18:38):

RT_CK_DB_INTERNAL is supposed to check the rt_db_internal passed to it for corruption or something like that...

Sumagna Das (Oct 15 2020 at 18:40):

RT_BOT_CK_MAGIC is similar to RT_CK_DB_INTERNAL except it checks the magic variable of BoT for something i still dont yet understand.

Vikram Atreya (Oct 15 2020 at 18:44):

Thanks. How could I have gotten this information without asking you , like should I read the API docs in more depth or is this just general knowledge

Sumagna Das (Oct 15 2020 at 18:45):

most of it is on the page, i guess

Sumagna Das (Oct 15 2020 at 18:45):

and some of it, you get to know while exploring the codebase...

Vikram Atreya (Oct 15 2020 at 18:46):

Sumagna Das said:

most of it is on the page, i guess

In the API docs page?

Sumagna Das (Oct 15 2020 at 18:59):

yea

Vikram Atreya (Oct 15 2020 at 19:00):

Okay

Erik (Oct 15 2020 at 22:43):

all of it's thoroughly documented in https://sourceforge.net/p/brlcad/code/HEAD/tree/ , mostly in c and tcl... quite a bit of c++ these days... :D
There are a series of books, they're a bit old (might not be so very in date), but they're kinda modeled after the X docs, one of them has quite a bit of description of the guts. I imagine a pdf of scanned pages is buried in some archive somewhere that someone might know about :D

Vikram Atreya (Oct 18 2020 at 05:34):

I want to convert a .stl file to a .g file, but in the mged command window it says stl-g is an invalid command. Is there something that I should do before I use the stl-g command?

Sumagna Das (Oct 18 2020 at 07:21):

stl-g should be called from the command-line

Sumagna Das (Oct 18 2020 at 07:22):

not from the mged. Thats why it was saying invalid command as there is not command in mged called stl-g

Vikram Atreya (Oct 18 2020 at 10:03):

Cool , got it!

Vikram Atreya (Oct 19 2020 at 19:37):

Could someone explain in more detail the 2.1.1 task in Deuces page , https://brlcad.org/wiki/Deuces , I feel the bounding box function is working well enough. I tested it on a .stl file converted into a .g file and a geometry created using mged , and the bounding box was quite good.

Sumagna Das (Oct 19 2020 at 19:39):

Screenshot-from-2020-10-20-01-08-39.png

Sumagna Das (Oct 19 2020 at 19:39):

@Sean brlcad.org is down

Sumagna Das (Oct 19 2020 at 19:44):

Vikram Atreya said:

Could someone explain in more detail the 2.1.1 task in Deuces page , https://brlcad.org/wiki/Deuces , I feel the bounding box function is working well enough. I tested it on a .stl file converted into a .g file and a geometry created using mged , and the bounding box was quite good.

wait a few minutes. the site is down so i cant check what task you are talking about...

Vikram Atreya (Oct 20 2020 at 17:49):

The site is functional now, if you want I will paste the text here.

Sumagna Das (Oct 20 2020 at 17:53):

i actually dont know what to do here

Sumagna Das (Oct 20 2020 at 17:54):

can you give me your .g file?

Vikram Atreya (Oct 20 2020 at 17:54):

Yeah 1 min

Vikram Atreya (Oct 20 2020 at 17:58):

lego2.g
This is a geometry I converted from a .stl file. P.S. Im just checking the bounding box it makes for this to see if it gives any errors.

Sumagna Das (Oct 20 2020 at 17:59):

it actually wont give any errors...

Vikram Atreya (Oct 20 2020 at 18:00):

So what is the aim of the task?

Vikram Atreya (Oct 20 2020 at 18:00):

Reducing the size of the bounding box?

Sumagna Das (Oct 20 2020 at 18:01):

wait a minute...

Sumagna Das (Oct 20 2020 at 18:01):

let me see the bounding box first

Sumagna Das (Oct 20 2020 at 18:09):

i actually cant understand why it is said there that the bounding box is inaccurate.

Vikram Atreya (Oct 20 2020 at 18:10):

Is there a command to visualize the bbox, I have just been using the -e option to get the coords

Vikram Atreya (Oct 20 2020 at 18:11):

Yeah I also did not understand that
Like the other tasks also seemed to have been solved in that page

Sumagna Das (Oct 20 2020 at 18:12):

one of the tasks isnt finished

Sumagna Das (Oct 20 2020 at 18:12):

i mean solved

Sumagna Das (Oct 20 2020 at 18:12):

2.1.2 isnt solved

Vikram Atreya (Oct 20 2020 at 18:13):

It is solved I felt, i tried it

Sumagna Das (Oct 20 2020 at 18:13):

it isnt solved

Sumagna Das (Oct 20 2020 at 18:13):

to see the issue

Sumagna Das (Oct 20 2020 at 18:14):

1) call mged from the commandline

Sumagna Das (Oct 20 2020 at 18:14):

2) open any file(or dont open any file because it isnt necessary)

Sumagna Das (Oct 20 2020 at 18:14):

3) close the windows and see the terminal

Sumagna Das (Oct 20 2020 at 18:16):

close the two windows which are opened after that

Vikram Atreya (Oct 20 2020 at 18:16):

Yeah closing one doesn't take the other with it, but it does say "Segmentation fault (core dumped)"

Sumagna Das (Oct 20 2020 at 18:18):

what?

Sumagna Das (Oct 20 2020 at 18:18):

you installed from source or from the tar.gz?

Vikram Atreya (Oct 20 2020 at 18:18):

source

Sumagna Das (Oct 20 2020 at 18:19):

you use ubuntu 18.04 right?

Vikram Atreya (Oct 20 2020 at 18:19):

Yeah

Sumagna Das (Oct 20 2020 at 18:19):

did you follow the steps i said?

Vikram Atreya (Oct 20 2020 at 18:20):

Yes I did exactly what was said in this => https://brlcad.org/wiki/Building_from_SVN

Sumagna Das (Oct 20 2020 at 18:20):

no not that

Sumagna Das (Oct 20 2020 at 18:20):

i said about opening mged

Vikram Atreya (Oct 20 2020 at 18:21):

I went to the build folder and ran "bin/mged" in the command line , is that wrong? :grimacing:

Sumagna Das (Oct 20 2020 at 18:21):

nope

Sumagna Das (Oct 20 2020 at 18:22):

nothing wrong

Sumagna Das (Oct 20 2020 at 18:22):

yet you are getting a segfault?

Vikram Atreya (Oct 20 2020 at 18:23):

Hmm yeah

Vikram Atreya (Oct 20 2020 at 18:24):

Just to clarify, I closed both the windows and after that I got segmentation fault

Sumagna Das (Oct 20 2020 at 18:25):

open mged with a file

Vikram Atreya (Oct 20 2020 at 18:26):

Yeah I opened a file in mged

Sumagna Das (Oct 20 2020 at 18:26):

now close them...

Vikram Atreya (Oct 20 2020 at 18:26):

Same thing happens

Sumagna Das (Oct 20 2020 at 18:26):

that should not happen i think

Sumagna Das (Oct 20 2020 at 18:28):

can you rebuild the whole thing right now?

Vikram Atreya (Oct 20 2020 at 18:28):

Yeah

Sumagna Das (Oct 20 2020 at 18:28):

then rebuild it and see if it is still happening

Vikram Atreya (Oct 20 2020 at 19:04):

Yeah same thing happens

Sumagna Das (Oct 20 2020 at 19:05):

ummmm...

Sumagna Das (Oct 20 2020 at 19:05):

let me see if i get the segfault

Sumagna Das (Oct 20 2020 at 19:05):

then it will be much easier for me to understand whats going on

Vikram Atreya (Oct 20 2020 at 19:05):

Okay

starseeker (Oct 20 2020 at 19:10):

Are you running on Windows?

Vikram Atreya (Oct 20 2020 at 19:10):

No, ubuntu 18.04

starseeker (Oct 20 2020 at 19:11):

Oh, I see it - MGED segfaulting on exit.

starseeker (Oct 20 2020 at 19:11):

one sec...

starseeker (Oct 20 2020 at 19:14):

See if r77518 fixes it

Sumagna Das (Oct 20 2020 at 19:23):

wait a few more minutes...it is rebuilding.

Sumagna Das (Oct 21 2020 at 14:03):

@starseeker now this happens when both the windows are closed
Screenshot-from-2020-10-21-19-32-02.png

starseeker (Oct 21 2020 at 14:45):

When both windows are closed? I'm not quite following - are you launching in classic mode?

Sumagna Das (Oct 21 2020 at 14:45):

classic mode?

starseeker (Oct 21 2020 at 14:46):

So when I type "mged", I get a command window and a dm window.

Sumagna Das (Oct 21 2020 at 14:46):

yea

starseeker (Oct 21 2020 at 14:46):

You say you're "closing both windows" - are you closing the dm and then the command window, or vice versa?

Sumagna Das (Oct 21 2020 at 14:46):

vice versa

starseeker (Oct 21 2020 at 14:46):

Ah!

starseeker (Oct 21 2020 at 14:47):

OK, let me try that.

Sumagna Das (Oct 21 2020 at 14:48):

even if i close the dm, then the command window, the same thing happens

starseeker (Oct 21 2020 at 14:49):

OK, I think I see what the immediate cause is... now where to deal with it. MGED's state management is spaghetti...

starseeker (Oct 21 2020 at 15:13):

@Sumagna Das I'm going to have to take apart the dm state management in MGED in more depth to figure out what's happening and what should be happening instead.

starseeker (Oct 21 2020 at 15:14):

In the meantime, if you quit mged with "q" on the MGED command prompt it should exit cleanly.

Sumagna Das (Oct 21 2020 at 15:15):

i wasnt actually quitting it but showing vikram what is supposed to be done in the task 2.1.2 in "Deuces" page

Vikram Atreya (Oct 21 2020 at 16:28):

Since there is some ambiguity in the tasks in the Deuces page , could anyone suggest me some issue/task to work on for my first contribution

Sean (Oct 21 2020 at 16:42):

Sumagna Das said:

Sean brlcad.org is down

Thanks @Sumagna Das -- that was the same issue as the last time. something is attacking the machine and locking up apache 100% cpu. I put a kill script in there, but it hung trying to get status. just changed it to be more forceful, so we'll have to see if it happens again.

Sean (Oct 21 2020 at 17:07):

As for the BoT bounding box ... it looks like @starseeker bb function change in c54559 may have fixed whatever was wrong, otherwise that change wouldn't have been necessary. the code was iterating over all vertices and calculating the BB. now it's apparently iterating over all faces and checking each face vertex.

Sean (Oct 21 2020 at 17:08):

That should be approximately half as fast, so I would question why iterating over vertices wasn't working. Maybe it was pulling in an errant vertex or was off-by-1 on the vertex list?

Sean (Oct 21 2020 at 17:09):

That's something that would be great to test out. Run "svn diff -c54560 src/librt/primitives/bot/bot.c" and try restoring rt_bot_bbox() to an iteration over vertices, see if there's a problem.

Sean (Oct 21 2020 at 17:10):

If there's not a problem, you will have greatly improved performance of the bbox function. If there is a problem, perhaps you can find out why. They should result in the same bbox unless there are orphaned vertices (and perhaps that's the issue, but also addressable)

Sean (Oct 21 2020 at 17:49):

I updated the Deuces page to change the BoT bbox task.

Vikram Atreya (Oct 21 2020 at 18:00):

Cool, I will work on it

Sean (Oct 21 2020 at 19:11):

Awesome. Curious to learn what you find out.

starseeker (Oct 21 2020 at 23:25):

Just conceptually, I don't think a BoT object is required to use all of its vertices when defining faces. So it's quite possible (in a data sense) that a bbox of all vertices in the data structure will be much larger than the bbox of the actual mesh...

starseeker (Oct 21 2020 at 23:57):

Could zero-init an int array of the same size as the vertex array, iterate over the faces and set an "active" flag for every vertex used by a face, then use the flag array to only use each vertex once to expand the bbox - don't know if that would be a major benefit compared to just walking the face vertices though. Fewer math operations, but would need the memory calloc and free, not to mention the array upping the overall memory requirements...

Vikram Atreya (Oct 22 2020 at 11:57):

I made changes in the file to iterate only over vertices, I checked it using a geometry(of a lego brick) in 3 formats .g , .stl and .obj and it seemed to work fine, are there some specific geometries I have to test for?

Vikram Atreya (Oct 22 2020 at 11:58):

starseeker said:

Could zero-init an int array of the same size as the vertex array, iterate over the faces and set an "active" flag for every vertex used by a face, then use the flag array to only use each vertex once to expand the bbox - don't know if that would be a major benefit compared to just walking the face vertices though. Fewer math operations, but would need the memory calloc and free, not to mention the array upping the overall memory requirements...

I also thought of this but wont it be looping the same number of times as before, So I did not try doing it

starseeker (Oct 22 2020 at 12:01):

It would be looping the same number of times, but it would be doing less math to calculate bounding box extensions (i.e. only considering each point once, instead of multiple times.)

starseeker (Oct 22 2020 at 12:02):

I'm not sure offhand if we have a convenient exposure of a BoT with more vertices than are used in the mesh - you could construct such a bot easily enough in C for testing.

starseeker (Oct 22 2020 at 12:10):

It's what @Sean referred to as orphaned vertices - to the best of my knowledge there are no API guarantees that we won't have them in bot objects, and I know some mesh processing algorithms can produce them unless a garbage collection pass is done at the end to produce a minimal vertex set.

Vikram Atreya (Oct 22 2020 at 19:29):

How can I time both the functions, I put a printf inside the "rt_bot_bbox" , but that doesn't seem to work. I'm attaching my file if any of you wants to take a look. bot.c

Sumagna Das (Oct 22 2020 at 19:32):

you can use bu_log instead of printf.

Sean (Oct 23 2020 at 05:50):

neither is good for timing it. you'll want to use a timer outside the function, but that's premature as cliff made a good point about how we deal with unreferenced vertices.

Sean (Oct 23 2020 at 05:53):

I think we have a couple options here. We can treat them as valid BoT data i.e., an orphaned vertex is still geometric information and still part of that object's definition OR we can treat them as invalid BoT data, i.e., not relevant and that implies needing to do two passes in the bounding box function (one to determined reference vertices in a bit vector, and a second pass to bound them).

Vikram Atreya (Oct 23 2020 at 05:57):

The orphaned vertices part just flew over my head. How do I find out if a vertex is orphaned or not? By checking is its part of a face ?

Sean (Oct 23 2020 at 05:57):

I think we already have implemented a command that eliminates unused vertices (bot_simplify maybe?) so either option is viable, but I think the intrinsic nature of the primitive type implies unreferenced vertices are non-data.

Sean (Oct 23 2020 at 05:57):

Bingo, right.

Sean (Oct 23 2020 at 05:57):

Do you know what a bit-vector is?

Vikram Atreya (Oct 23 2020 at 05:57):

Ummm, No

Vikram Atreya (Oct 23 2020 at 05:58):

Im a total newbie :upside_down:

Sean (Oct 23 2020 at 05:58):

so basically we have two arrays in this triangle data structure. One is an array of faces, the other an array of vertices

Vikram Atreya (Oct 23 2020 at 05:59):

Sean said:

One is an array of faces, the other an array of vertices

Yeah, that I discovered while I was working on this

Sean (Oct 23 2020 at 05:59):

each face has three integers, and those are indicies into the vertices array

Sean (Oct 23 2020 at 05:59):

each vertex has the actual double-precision XYZ values

Vikram Atreya (Oct 23 2020 at 06:00):

Yeah

Sean (Oct 23 2020 at 06:01):

so what's needed is to iterate over all faces, and keep track of which vertices are actually used

Sean (Oct 23 2020 at 06:02):

before you switched it back to iterating over the vertices array, it was iterating over all faces

Sean (Oct 23 2020 at 06:03):

but it wasn't keeping track of anything, it just tested every vertex against the bounding box... but that means every vertex is being tested at least twice as many times as it needs to be.

that doesn't matter much for small meshes, but on something big that could be seconds or minutes of wasted computation

Sean (Oct 23 2020 at 06:04):

so the question is how do you keep track ... and the typical answer for this kind of thing is a bit vector

Vikram Atreya (Oct 23 2020 at 06:04):

Ohh Got it

Sean (Oct 23 2020 at 06:04):

a bit vector is simply an array of bits, so you'd have a bit for every vertex in the vertices array

Vikram Atreya (Oct 23 2020 at 06:04):

I knew this but did not know it was called a bit vector

Sean (Oct 23 2020 at 06:04):

and you'd iterate over the faces, and mark the bit as 'on' for that index position

Sean (Oct 23 2020 at 06:05):

then you iterate over your bit array and do the actual bounding box calculation once on the 'on' vertices

Vikram Atreya (Oct 23 2020 at 06:05):

Sean said:

and you'd iterate over the faces, and mark the bit as 'on' for that index position

Yeah got it, I will try implementing this then

Vikram Atreya (Oct 23 2020 at 06:07):

What I was thinking was instead of 2 loops , we just check for the vertex when we switch it on and later if we hit an already switched on vertex we just skip it.

Sean (Oct 23 2020 at 06:07):

we have a pretty fast bit vector data structure you should use for this since you don't have access to c++ stl containers in the bot.c file

Sean (Oct 23 2020 at 06:09):

Vikram Atreya said:

What I was thinking was instead of 2 loops , we just check for the vertex when we switch it on and later if we hit an already switched on vertex we just skip it.

You totally could, but two loops will almost certainly be faster due to data coherency and branch prediction misses

Sean (Oct 23 2020 at 06:11):

with two loops, there's no data dependency, so it can literally scream through the array, prefetch data, and just set bits without any stalling.

Vikram Atreya (Oct 23 2020 at 06:12):

Okay , I will implement it with 2 loops :+1:

Sean (Oct 23 2020 at 06:14):

if this were a performance bottleneck, it'd be interesting to profile

Sean (Oct 23 2020 at 06:18):

would you like an example on using our bit vector data structure?

Vikram Atreya (Oct 23 2020 at 06:19):

Yeah sure

Sean (Oct 23 2020 at 06:26):

It's simply:

struct bu_bitv *bv = bu_bitv_new(bot->num_vertices);
...
for (i = 0; i < bot->num_faces; i++) {
    BU_BITSET(bv, bot->faces[(i*3)+X]); BU_BITSET(bv, bot->faces[(i*3)+Y]); BU_BITSET(bv, bot->faces[(i*3)+Z]);
}
for (i = 0; i < bot->num_vertices; i++) {
    if (BU_BITTEST(bv, i)) {
        ... do BB test...
    }
}

at least something like that. that's pseudocode off the cuff, but hopefully enough to go on for figuring it out

Sean (Oct 23 2020 at 06:27):

oh, right and a final call to bu_bitv_free() when you're done of course.

Vikram Atreya (Oct 23 2020 at 11:28):

starseeker said:

you could construct such a bot easily enough in C for testing.

Done implementing and testing with some basic models. But how do I do this?

starseeker (Oct 23 2020 at 12:59):

There is a file in src/proc-db called bottest.c - you can look at that for how to create BoTs, and then deliberately create one with an extra vertex off in space somewhere.

Vikram Atreya (Oct 23 2020 at 13:48):

Ohh Thanks!

Sean (Oct 23 2020 at 17:25):

I think you can also do a bot adjust and just provide it additional vertices

Sean (Oct 23 2020 at 17:31):

yeah, that worked. here's a simple bot with 2 extra vertices @Vikram Atreya
test.g

Sean (Oct 23 2020 at 17:31):

"bot" has no extra, "bot.bad" has 2 extra

Sean (Oct 23 2020 at 17:32):

see if you get a different bounding box for them both

Vikram Atreya (Oct 23 2020 at 17:32):

Sean said:

yeah, that worked. here's a simple bot with 2 extra vertices Vikram Atreya
test.g

Wow! Thank you for taking so much effort :grinning_face_with_smiling_eyes:

Sean (Oct 23 2020 at 17:42):

no problem, that's not something you'd have been able to discover and it just took a second.

Sean (Oct 23 2020 at 17:43):

for what it's worth to reproduce what I did, I created an object, an arb6 I think
make arb6 arb6

Sean (Oct 23 2020 at 17:43):

then turned it into a bot:
facetize arb6 bot

Sean (Oct 23 2020 at 17:44):

then extracted a version of the bot in text form:
get bot

Vikram Atreya (Oct 23 2020 at 17:45):

Sean said:

see if you get a different bounding box for them both

I get the same bounding box for both

Sean (Oct 23 2020 at 17:45):

made a copy:
cp bot bot.bad
then adjusted the copy with a vertex list that had two more added:
adjust bot.bad V { { 0 0 0 } { -500 500 -1000 } { -500 -500 -1000 } { 500 500 -1000 } {1000 1000 1000} {-1000 -1000 -1000} }

Sean (Oct 23 2020 at 17:47):

Vikram Atreya said:

I get the same bounding box for both

You do? and that's iterating over the vertices array or over the faces array?

Sean (Oct 23 2020 at 17:47):

the latest code will produce the same bounding box.

Sean (Oct 23 2020 at 17:48):

iterating over the vertices array only without consulting the faces array should result in a different box

Sean (Oct 23 2020 at 17:48):

if it doesn't, something's wrong :)

Vikram Atreya (Oct 23 2020 at 17:48):

Iterating over the faces first , switching on the vertices in the bit vector and then iterating over the vertices

Vikram Atreya (Oct 23 2020 at 17:48):

This is what I implemented

Sean (Oct 23 2020 at 17:49):

oh, haha, well then that's great -- didn't know you'd gotten that far!

starseeker (Oct 23 2020 at 17:49):

You may want to do the control test though, and make sure you do get a different box if you iterate over all of them.

Vikram Atreya (Oct 23 2020 at 17:50):

Sure, I just have that code commented

Sean (Oct 23 2020 at 17:50):

yeah, set the bit vector to all on, see if you get a different box

Vikram Atreya (Oct 23 2020 at 17:50):

Sean said:

yeah, set the bit vector to all on, see if you get a different box

Nice , even easier

Sean (Oct 23 2020 at 17:51):

that'll be a good indication that it's definitely doing what it needs to be doing

Vikram Atreya (Oct 24 2020 at 04:11):

I got the desired results , when I normally run my code it gives the same bounding box for both ,bot and bot.bad, whereas if I run it with all bits switched on in the bit vector I get different bounding boxes.

Sean (Oct 24 2020 at 05:48):

excellent @Vikram Atreya ! sounds like you have a viable patch them. do you know how to submit a patch?

Vikram Atreya (Oct 24 2020 at 05:54):

I know how to use git, but no idea about svn. But...
"svn co https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad.edit
cd brlcad.edit

make changes

svn diff > ~/my.patch

read ~/my.patch file with text editor

cd ..
svn co https://brlcad.svn.sourceforge.net/svnroot/brlcad/brlcad/trunk brlcad.fresh
cd brlcad.fresh
patch -p0 < ~/my.patch"

submit your patch file to our patches tracker

I found this on the website

Sean (Oct 24 2020 at 05:55):

it's very similar to git without github, you just get a diff and save that diff to a file

Sean (Oct 24 2020 at 05:55):

check it over to make sure it only includes what you intended, and then submit it

Sean (Oct 24 2020 at 05:57):

the steps on the website will work, but they're more rigorous having you make sure your patch will apply and compile cleanly, which is how you can prove to yourself that the patch is good. probably not needed for a patch this small.

Vikram Atreya (Oct 24 2020 at 05:59):

Okay cool

Vikram Atreya (Oct 24 2020 at 06:28):

I created my first ticket :grinning_face_with_smiling_eyes:

Sean (Oct 24 2020 at 06:35):

Looks spot on, well done!

Sean (Oct 24 2020 at 06:37):

you know, it'd be really great if you could test performance before and after on something significant. what platform are you on?

Sean (Oct 24 2020 at 06:38):

I've uploaded a detailed canonical test case you can try it on to https://brlcad.org/~sean/tmp/hairball.g

Vikram Atreya (Oct 24 2020 at 06:39):

Sean said:

you know, it'd be really great if you could test performance before and after on something significant. what platform are you on?

Ubuntu 18.04

Sean (Oct 24 2020 at 06:39):

if you're on linux/mac/bsd, a real quick way to test is using mged's command mode.

Sean (Oct 24 2020 at 06:39):

okay, yeah, ubuntu will work well, something like:

Sean (Oct 24 2020 at 06:40):

time mged -c hairball.c bb hairball

Sean (Oct 24 2020 at 06:40):

run that 3 times or so, note the average time. then do it again without your patch, 3 times or so.

Vikram Atreya (Oct 24 2020 at 06:41):

Sure , will do

Sean (Oct 24 2020 at 06:43):

oh, and we should eliminate the file I/O time. for that, can run something like: time mged -c hairball.c tops

Vikram Atreya (Oct 24 2020 at 08:01):

In terms of real time there is a 0.5% improvement whereas in sys time it has 5% improvement time-stamps-bbox

Erik (Oct 24 2020 at 11:54):

if you're on linux, /usr/bin/time -v has a lil more info

Erik (Oct 24 2020 at 11:55):

(use the path or it might grab the shell builtin which might not have the -v flag)

Sean (Oct 24 2020 at 14:36):

@Vikram Atreya hm, these numbers don't add up... You compiled BRL-CAD yourself right? Do you know if you compiled with optimizations enabled?

Sean (Oct 24 2020 at 14:39):

if you didn't enable optimization, that would account for why the times are the same as there's not really any difference with the old or new without optimization.

Sean (Oct 24 2020 at 15:12):

just crunching some numbers, there are:

  1470000 vertices
  8640000 face vertex indices
  2940000 unique vertex indices

Sean (Oct 24 2020 at 15:14):

barring coherency factors, we should expect a 1/3 reduction in time on this model

Sean (Oct 24 2020 at 15:17):

If you're recompiling, you could wrap the function in a better timer:

int64_t start = bu_gettime();
 .... do the bb calc ...
double elapsed = bu_gettime() - start;
double seconds = elapsed / 1000000.0;
bu_log("time: %.2f\n", seconds);

Vikram Atreya (Oct 24 2020 at 15:52):

Sean said:

Vikram Atreya hm, these numbers don't add up... You compiled BRL-CAD yourself right? Do you know if you compiled with optimizations enabled?

I felt the same. By optimizations you mean compiling the new code I hope, Yes I did enable it. Let me check again

Vikram Atreya (Oct 24 2020 at 15:53):

Sean said:

If you're recompiling, you could wrap the function in a better timer:

Yeah I'll do this

Vikram Atreya (Oct 24 2020 at 16:30):

I get:

 error: implicit declaration of function ‘bu_gettime’; did you mean ‘rt_get_timer’?

when I try to use bu_gettime() when I try to compile it
I tried including time.h but its still the same happens

Sean (Oct 24 2020 at 16:59):

@Vikram Atreya you need to #include "bu/time.h"

Sean (Oct 24 2020 at 17:00):

and by optimized build, that's a cmake flag -- did you specify any cmake flags?

Sean (Oct 24 2020 at 17:00):

specify cmake -DCMAKE_BUILD_TYPE=Release

Vikram Atreya (Oct 24 2020 at 17:01):

No I haven't specified any flags , I just used cmake ..

Sean (Oct 24 2020 at 17:01):

okay, so that's why

Sean (Oct 24 2020 at 17:01):

huge difference. default compile is designed for debugging, it's a completely unoptimized build.

Sean (Oct 24 2020 at 17:02):

an optimized build will typically be about twice as fast, depending on what's being measured

Vikram Atreya (Oct 24 2020 at 17:08):

Using the bu_gettime, I get 0.07 sec for the old bounding box code and 0.04 sec for the new code. So 42% improvement :grinning:

Sean (Oct 24 2020 at 17:15):

I bet it's more than that on something more significant with 10's of millions of polygons

Sean (Oct 24 2020 at 17:16):

either way, that's really great vikram! you cut the time in half on a routine that's used for ray tracing, collisions, bounding volumes, and more...

Sean (Oct 24 2020 at 17:19):

try an svn up and test performance again -- I made a minor adjustment to eliminate the intermediate variables

Sean (Oct 24 2020 at 17:27):

this is a colossal example why memory coherency is so important. without i/o interrupts, memory allocations, file activity... it can process over 2.8M triangles in 4/100's of a second. that's about 70M triangles per second.

Vikram Atreya (Oct 24 2020 at 17:28):

Sean said:

try an svn up and test performance again -- I made a minor adjustment to eliminate the intermediate variables

Will do

Sean (Oct 24 2020 at 17:28):

I'll note that processing could also be vectorized and parallelized, which would raise the number to 2B triangles/sec if we did both.

Sean (Oct 24 2020 at 17:29):

(4-way simd, 8-way parallel)

Sean (Oct 24 2020 at 17:38):

@Vikram Atreya would you mind deleting that deuces task since you knocked it out so well?

Vikram Atreya (Oct 24 2020 at 17:39):

Sure...(lol)

Vikram Atreya (Oct 24 2020 at 19:36):

Sean said:

try an svn up and test performance again -- I made a minor adjustment to eliminate the intermediate variables

The performance is the same

Sean (Oct 25 2020 at 05:38):

k, thanks for testing it. Knew there was a chance the optimizer would've taken care of it automatically, but good to know it did (or at least it'd need to be a much much bigger mesh to notice). What version compiler are you using?

Vikram Atreya (Oct 25 2020 at 06:10):

After I did an svn up was I supposed to test it as it is, coz i replaced the code in bot.c with my code and then tested it :P

Vikram Atreya (Oct 25 2020 at 06:12):

Sean said:

What version compiler are you using?

Cmake 3.12.1

starseeker (Oct 25 2020 at 14:14):

I think @Sean was looking for you to test the committed patch, which means not switching the bot.c code. Also, for version I think he was wanting to know your compiler version (gcc -v or clang --version)

Sean (Oct 25 2020 at 14:26):

Vikram Atreya said:

After I did an svn up was I supposed to test it as it is, coz i replaced the code in bot.c with my code and then tested it :P

Your patch was applied, and then a few more changes were made. So by "I replaced the code" mean you undid the changes and then tested? :) Because, yeah -- what starseeker said -- the intent was just to update and try the latest code. If you run "svn diff", what changes have you made? (there shouldn't be a diff for the final test)

Vikram Atreya (Oct 25 2020 at 16:47):

Wrong choice of words I guess, by replaced I meant I added the bu_gettime() parts to it and then checked, coz that was what I was using to check the performance. So the function was the same.

Vikram Atreya (Oct 25 2020 at 16:57):

gcc version is 8.4.0

Vikram Atreya (Oct 25 2020 at 18:55):

And if Im done with this should I pickup another Deuces task or could anyone guide me to some task that I could do?

Sean (Oct 26 2020 at 17:55):

yeah, I think that task is knocked out of the park, well done @Vikram Atreya

Sean (Oct 26 2020 at 18:08):

@Vikram Atreya since you have some decent coding skills, I suggest another coding task from our TODO file. how about either 1) create a simple unit test for our rt_boolweave() function or 2) implement simple ray tracing support for points (the rt_pnts_prep() and rt_pnts_shot() function for pnts objects that have a radius).

Vikram Atreya (Oct 26 2020 at 18:10):

Which one is tougher? :P

Sean (Oct 26 2020 at 18:11):

they're similar difficulty, both actually fairly simple from a quantity-of-code perspective (probably less than 50 lines to do either)

Vikram Atreya (Oct 26 2020 at 18:11):

Okay then I will do 1) first

Sean (Oct 26 2020 at 18:12):

Basically #1 requires looking at the definition of that function (rt_boolweave), figuring out what the arguments mean, creating a small main() program like hello world, and make your program call rt_boolweave with some meaningful input.

Sean (Oct 26 2020 at 18:13):

now that I type it out and think about potential issues, #2 is probably slightly easier, but still #1 is doable if you think you understand how structs and data in C work

Vikram Atreya (Oct 26 2020 at 18:15):

Anyways I wanted to do the tougher one

Sean (Oct 26 2020 at 18:15):

with rt_boolweave, the difficulty is going to be understanding what a struct seg and struct partition are so you can construct one by hand, so you can call rt_boolweave()

Sean (Oct 26 2020 at 18:16):

include/rt/boolweave.h has rt_boolweave's definition. struct seg is in include/rt/seg.h and struct partition is annoyingly in include/rt/ray_partition.h

Sean (Oct 26 2020 at 18:17):

so first step would probably be to create a struct seg by hand and then calling rt_pr_seg() to print it

Vikram Atreya (Oct 26 2020 at 18:17):

Sean said:

so first step would probably be to create a struct seg by hand and then calling rt_pr_seg() to print it

Okay

Sean (Oct 26 2020 at 18:18):

if you're not familiar with ray tracing, you might want to try using the 'nirt' tool in mged on some geometry -- there's a whole detailed guide at https://brlcad.org/~nouhrasofat/articles/en/nirt.php that visualizes segments and partitions

Vikram Atreya (Oct 26 2020 at 18:19):

I know the principles but not the code

Sean (Oct 26 2020 at 18:19):

basically, they're the pieces of geometry along a line

Vikram Atreya (Oct 26 2020 at 18:19):

Sean said:

if you're not familiar with ray tracing, you might want to try using the 'nirt' tool in mged on some geometry -- there's a whole detailed guide at https://brlcad.org/~nouhrasofat/articles/en/nirt.php that visualizes segments and partitions

i will check this out

Sean (Oct 26 2020 at 18:21):

here's a visual depiction on something less abstract: https://brlcad.org/~nouhrasofat/books/en/images/tutorial_series_volIII_fig18.png

Sean (Oct 26 2020 at 18:22):

in that oversimplified example, each of those labeled things is the evaluated partitions and segments you get after boolweave

Vikram Atreya (Oct 26 2020 at 18:24):

Ohhkay, Let me explore it first then maybe I can ask you doubts if I have

Sean (Oct 26 2020 at 18:24):

yeah, sure -- check out the comments in the header that might help explain some of the terms. Some may become more clear as you create one and try to use it in code.

Vikram Atreya (Oct 29 2020 at 08:06):

In the seg structure , there is another structure bu_list, I'mnt able to understand what it is, Is it sort of a vector in c++ and what is it representing?

Sean (Oct 29 2020 at 16:12):

@Vikram Atreya excellent question. yes, that's a generic list structure, and understandable how it will appear confusing as it relies on a really old feature of C (type aliasing).

Sean (Oct 29 2020 at 16:14):

bu_list is a doubly linked list structure that can be used as a simple list, a stack, or a queue. with it, you can turn ANY existing structure into a list by simply putting the bu_list structure into that existing structure as the first element.

Sean (Oct 29 2020 at 16:14):

for example, say I have a simple:
struct point {
int x, y, z;
};

Sean (Oct 29 2020 at 16:15):

I can make a linked list of points by making that:
struct point {
struct bu_list *l;
int x, y, z;
};

Vikram Atreya (Oct 29 2020 at 16:16):

Sean said:

bu_list is a doubly linked list structure that can be used as a simple list, a stack, or a queue

Yeah I was just figuring it out , like how you represent trees with pointers to the left and right node

Sean (Oct 29 2020 at 16:16):

struct point *my_list_of_pnts = malloc(sizeof(struct point) * 100);

Vikram Atreya (Oct 29 2020 at 16:17):

Got it!

Sean (Oct 29 2020 at 16:17):

I can of course access, my_list_of_pnts[#] if we allocated that way, but what's more common is to just allocate one and then allocate another and then another, and doing that we can chain them all together

Sean (Oct 29 2020 at 16:19):

the BIG DIFFERENCE is what we can do with a struct point pointer

Sean (Oct 29 2020 at 16:19):

it can be simply cast to a bu_list

Sean (Oct 29 2020 at 16:20):

and we can then iterate over all list members using the forw and back pointers of the bu_list structure, and cast back to struct point to get at the parent structure

Vikram Atreya (Oct 29 2020 at 16:26):

Yeah got how the struct works :grinning: , so is what is it representing, lengths of the ray where medium is changing?

Vikram Atreya (Oct 29 2020 at 16:26):

or the segs themselves as a list

Sean (Oct 29 2020 at 16:33):

segs themselves as a list

Sean (Oct 29 2020 at 16:34):

each segment does represent a section of geometry where the ray intersected the geometry

Sean (Oct 29 2020 at 16:39):

               ________
     ___       \      /
----|---|-------\----/------>
    `---´        \  /
                  \/

So a ray going through two objects will result in either two partitions with one segment each OR one partition with two segments. Which depends how it was modeled and organized, if the objects were part of the same region or separate regions.

Vikram Atreya (Oct 29 2020 at 17:11):

Nice, thanks!

Vikram Atreya (Oct 29 2020 at 18:19):

To create hits, xrays, etc do we already have some functions to initialize them or do I give assign everything on my own, one by one?

Vikram Atreya (Oct 29 2020 at 18:24):

Even soltab, how can i create an soltab variable, since it has so many things inside it

Sean (Oct 29 2020 at 18:28):

there are functions that do that, but I don't think you should use them

Sean (Oct 29 2020 at 18:28):

the goal is to test just rt_boolweave behavior as isolated as possible

Sean (Oct 29 2020 at 18:29):

if you call rt_shootray() for example, that will generate segments and partitions, but they'll already be evaluated via boolweave too and they'll only be a particular organization of segments and partitions that it's used to creating, which doesn't explore robustness of rt_boolweave.

Sean (Oct 29 2020 at 18:30):

I suggest starting with just passing a single segment to boolweave and see what it does.
They maybe try passing an empty segment list. Then two segments that don't overlap, then two that do, etc.

Sean (Oct 29 2020 at 18:31):

If it crashes, report it and we can figure out if it something can/should be done about it.

Vikram Atreya (Oct 29 2020 at 18:32):

Yeah , Im talking about creating the segment, can i assign any random values to the member variables?

Sean (Oct 29 2020 at 18:32):

I don't know :)

Sean (Oct 29 2020 at 18:33):

probably not, maybe

Sean (Oct 29 2020 at 18:33):

it depeds

Vikram Atreya (Oct 29 2020 at 18:33):

Okay :joy:

Sean (Oct 29 2020 at 18:34):

could start with a NULL soltab and just see what it does

Sean (Oct 29 2020 at 18:36):

just as a general rule of thumb, you can probably start with everything zero-initialized and work your way filling things out as you go.
part of the task is figure out just what exactly is required to get a useful result.

Sean (Oct 29 2020 at 18:37):

conceptually, boolweave is deciding whether to merge or split line segments

Vikram Atreya (Oct 29 2020 at 18:38):

Where do I find the actual code, https://brlcad.org/docs/api/de/d4d/boolweave_8h_source.html, it isn't here

Sean (Oct 29 2020 at 18:40):

so if you have

          |----------|  seg1
|---------------|       seg2

    if they are seg1 - seg2 then the result should be:
                |----|
    if they are seg2 - seg1 then the result should be:
|---------|
    if they are seg1 U seg2, then the result could be:
|--------------------|
    or it could be an overlap condition:
|---------|-----|----|

Sean (Oct 29 2020 at 18:41):

At least, I think. it may be doing more or less than that too as some processing is delegated to rt_boolfinal() and I don't recall where the responsibilities start/end.

Sean (Oct 29 2020 at 18:44):

so from an input perspective, do you see how the seg_in and seg_out fields can describe either seg1 and/or seg2 above as a "struct hit"?

Vikram Atreya (Oct 29 2020 at 18:45):

Sean said:

so from an input perspective, do you see how the seg_in and seg_out fields can describe either seg1 and/or seg2 above as a "struct hit"?

yeah

Sean (Oct 29 2020 at 18:46):

maybe start with a struct hit seg1hit = RT_HIT_INIT_ZERO; seg1hit.hit_dist = 1.0;

Sean (Oct 29 2020 at 18:46):

then make an out with hit_dist = 10.0;

Vikram Atreya (Oct 29 2020 at 18:47):

Sean said:

struct hit seg1hit = RT_HIT_INIT_ZERO;

This was the function I was asking for, to initialize it, thanks

Sean (Oct 29 2020 at 18:47):

you'll have to read the source code of rt_boolweave() to see if it reads any other fields of the seg_in/seg_out hit struct fields.

Sean (Oct 29 2020 at 18:48):

nearly all the complex structs have an *_INIT_ZERO macro.

Vikram Atreya (Oct 29 2020 at 18:48):

Sean said:

you'll have to read the source code of rt_boolweave() to see if it reads any other fields of the seg_in/seg_out hit struct fields.

im not able to find this . Its not there in boolweave,h

Sean (Oct 29 2020 at 18:48):

to find what?

Vikram Atreya (Oct 29 2020 at 18:49):

the source code :stuck_out_tongue: :stuck_out_tongue: :stuck_out_tongue:

Vikram Atreya (Oct 29 2020 at 18:49):

Its just the declaration given there

Sean (Oct 29 2020 at 18:50):

well the header would only have declaration and types
"grep -r rt_boolweave src" will show all the places it's used and where it's defined.

Sean (Oct 29 2020 at 18:50):

grep will tell you it lives in src/librt

Vikram Atreya (Oct 29 2020 at 18:52):

Vikram Atreya said:

im not able to find this . Its not there in boolweave,h

Ooooh, the struggles of being a beginner :joy:

Sean (Oct 29 2020 at 18:56):

this is a fairly advanced beginner task :)

Vikram Atreya (Oct 29 2020 at 19:01):

Lol

Vikram Atreya (Nov 07 2020 at 18:43):

Its been a while ig, Nov is going to be quite busy for me due to end semester exams coming up :grimacing:

Vikram Atreya (Nov 07 2020 at 18:43):

How I do I call rt_boolweave in a separate file, I included "bool.c" and wrote a program, but that dint work out :stuck_out_tongue: ?

Sean (Nov 10 2020 at 15:19):

@Vikram Atreya heh, you will not want to include bool.c - that's compiled into a library (librt). you will want to create your own whatever.c, include the interface for librt (#include <rt/boolweave.h> in your file), and compile it making sure to link with -I include dirs and linking against librt.

Sean (Nov 10 2020 at 15:20):

It's probably best if you start with https://brlcad.org/wiki/Example_Application and get that working first.

Sean (Nov 10 2020 at 15:20):

it's a single file example that has includes and links against libraries

Vikram Atreya (Dec 04 2020 at 09:22):

Finally my exams are over and I hope to contribute as much as I can as we have vacation whole of December!

Vikram Atreya (Dec 04 2020 at 09:23):

Sean said:

It's probably best if you start with https://brlcad.org/wiki/Example_Application and get that working first.

I was trying to get this working
but when I run "cc -I/usr/brlcad/include/brlcad -L/usr/brlcad/lib -o rtexample rtexample.c -lbu -lrt -lm", it says "fatal error: common.h: No such file or directory"

starseeker (Dec 04 2020 at 12:33):

You need to tell the compiler to include the directory with the common.h header in it.

starseeker (Dec 04 2020 at 12:34):

Does /usr/brlcad/include/brlcad have common.h?

Vikram Atreya (Dec 04 2020 at 17:31):

starseeker said:

Does /usr/brlcad/include/brlcad have common.h?

There is no "brlcad" folder in "/usr/brlcad/include/" :sweat_smile:

Vikram Atreya (Dec 04 2020 at 17:36):

The common.h file is in /usr/brlcad/include/

Sean (Dec 06 2020 at 06:14):

@Vikram Atreya Then that's the folder you need to put on the -I option ... -I/usr/brlcad/include

Vikram Atreya (Dec 06 2020 at 06:29):

Yeah tried that but still I get:- "fatal error: common.h: No such file or directory"
The address of my brlcad folder is: ~/brlcad , I tried with this -> ( -I/brlcad/include ) as well but still dint work

Sean (Dec 06 2020 at 06:35):

you compiled and installed or just compiled?

Vikram Atreya (Dec 06 2020 at 06:36):

I didnt get you

Sean (Dec 06 2020 at 06:44):

Vikram Atreya said:

I didnt get you

You're compiling against BRL-CAD. Where did the BRL-CAD that you're going to be compiling against come from? Did you compile it? Did you install it?

Vikram Atreya (Dec 06 2020 at 06:50):

https://brlcad.org/wiki/Building_from_SVN
I had followed this when i installed BRL-CAD,So I think I compiled it
Im not fully clear about terms like compiling and installing, but ill get it slowly I hope

Sean (Dec 06 2020 at 06:51):

What was the last command from those instructions that you did?

Vikram Atreya (Dec 06 2020 at 06:54):

make test

Sean (Dec 06 2020 at 06:55):

So note those are under the "compile" instructions. You've only compiled, not installed, which is an optional step later.

Sean (Dec 06 2020 at 06:55):

so you need to specify the path to your build folder

Vikram Atreya (Dec 06 2020 at 06:56):

Sean said:

So note those are under the "compile" instructions. You've only compiled, not installed, which is an optional step later.

Got it

Sean (Dec 06 2020 at 06:56):

that will be wherever you are running make, there is an include folder and an include/brlcad folder there. That's what you need to specify to the -I include directory option

Vikram Atreya (Dec 06 2020 at 06:58):

Yeah, now I see the brlcad folder in include
I was looking in the wrong include folder before

Vikram Atreya (Aug 23 2021 at 18:34):

Hello everyone!
Today is the last day of GSoC and I wanted to express my gratitude to all of you for helping me reach here. When I was planning to start contributing to an organization last October, I had very little knowledge of development and just knew the basics of C++. I tried to reach out to a few organizations before I came to know about BRL-CAD and failed to even compile their code. I was just throwing a stone when I messaged in the new members channel here. The response I received was very helpful and @Sumagna Das @starseeker literally guided me at every step to get the code compiled. It was the first time in my life that I had compiled a codebase. Even after that everyone was so helpful when I was overwhelmed when I saw the code for the first time, everything was greek and Latin, and I was scared that open source was too tough for me. The guidance I received was so warm, that it really encouraged me to put in more effort and seriously contribute. I was so happy after I submitted my the patch to increase speed of the bounding box algorithm, also the first PR in my life that I decided I would like to apply for GSoC in BRL-CAD. From there on there were a few breaks and tough challenges, compiling with OpenCL enabled and the raytrace tests, and was pretty scared if I could do GSoC. Finally, I found the perfect task for me to do in GSoC after I implemented the overwrite functionality for dbconcat.
Getting selected for GSoC was a great feeling and achievement for me, pursuing mechanical engineering as my major, this was validation that I knew how to code and from there on it was a wonderful journey for all the 10 weeks. I really enjoyed solving problems, finding better methods, implementing them and debugging them. Finally a special thanks to @Sean for helping me and guiding me all the way through right from the beginning, with so much patience, I still remember asking what the difference was between compiling and installing, it embarasses me now but all of it was part of the journey. I will take a small break and then surely contribute again. I'll also try to participate in GSoC next year and do something even more exciting.
Thank you everyone for all the kindness

Sean (Aug 24 2021 at 05:24):

@Vikram Atreya You've been amazing. Thank you for all your efforts this GSoC. Excellent progress on the project and your development learning and developing the infrastructure has been impressive. It's been a wonderful exemplary journey and hopefully a rewarding one that you'll carry with you. Open source is something you can do, whether with BRL-CAD or other projects, for years to come personally and professionally, taking on projects you find interesting, rewarding.

Last updated: Jan 09 2025 at 00:46 UTC