You can subscribe to this list here.
2004 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}
(1) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}


2005 
_{Jan}
(4) 
_{Feb}
(2) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}
(2) 
_{Jun}
(8) 
_{Jul}

_{Aug}
(4) 
_{Sep}
(3) 
_{Oct}
(10) 
_{Nov}
(1) 
_{Dec}
(10) 
2006 
_{Jan}
(6) 
_{Feb}
(2) 
_{Mar}
(4) 
_{Apr}
(6) 
_{May}
(21) 
_{Jun}
(8) 
_{Jul}
(3) 
_{Aug}
(7) 
_{Sep}
(1) 
_{Oct}
(1) 
_{Nov}
(1) 
_{Dec}

2007 
_{Jan}
(2) 
_{Feb}
(5) 
_{Mar}
(5) 
_{Apr}
(3) 
_{May}
(2) 
_{Jun}
(1) 
_{Jul}
(9) 
_{Aug}

_{Sep}
(4) 
_{Oct}
(5) 
_{Nov}

_{Dec}
(2) 
2008 
_{Jan}
(3) 
_{Feb}
(1) 
_{Mar}
(15) 
_{Apr}
(10) 
_{May}
(11) 
_{Jun}
(31) 
_{Jul}
(16) 
_{Aug}
(71) 
_{Sep}
(15) 
_{Oct}
(7) 
_{Nov}
(15) 
_{Dec}

2009 
_{Jan}
(8) 
_{Feb}
(4) 
_{Mar}
(44) 
_{Apr}
(36) 
_{May}
(14) 
_{Jun}
(30) 
_{Jul}
(19) 
_{Aug}
(1) 
_{Sep}
(5) 
_{Oct}
(2) 
_{Nov}
(5) 
_{Dec}
(10) 
2010 
_{Jan}
(19) 
_{Feb}
(21) 
_{Mar}
(1) 
_{Apr}
(38) 
_{May}
(10) 
_{Jun}
(8) 
_{Jul}
(1) 
_{Aug}
(23) 
_{Sep}
(30) 
_{Oct}
(19) 
_{Nov}
(4) 
_{Dec}
(13) 
2011 
_{Jan}
(129) 
_{Feb}
(51) 
_{Mar}
(39) 
_{Apr}
(20) 
_{May}
(12) 
_{Jun}
(30) 
_{Jul}
(38) 
_{Aug}
(24) 
_{Sep}
(164) 
_{Oct}
(92) 
_{Nov}
(33) 
_{Dec}
(27) 
2012 
_{Jan}
(77) 
_{Feb}
(29) 
_{Mar}
(251) 
_{Apr}
(159) 
_{May}
(219) 
_{Jun}
(142) 
_{Jul}
(180) 
_{Aug}
(50) 
_{Sep}
(4) 
_{Oct}
(7) 
_{Nov}
(45) 
_{Dec}
(22) 
2013 
_{Jan}
(16) 
_{Feb}
(6) 
_{Mar}
(34) 
_{Apr}
(211) 
_{May}
(97) 
_{Jun}
(95) 
_{Jul}
(219) 
_{Aug}
(170) 
_{Sep}
(175) 
_{Oct}
(191) 
_{Nov}
(78) 
_{Dec}
(90) 
2014 
_{Jan}
(77) 
_{Feb}
(84) 
_{Mar}
(232) 
_{Apr}
(56) 
_{May}
(110) 
_{Jun}
(97) 
_{Jul}
(69) 
_{Aug}
(58) 
_{Sep}
(54) 
_{Oct}
(76) 
_{Nov}
(53) 
_{Dec}
(30) 
2015 
_{Jan}
(28) 
_{Feb}
(22) 
_{Mar}
(268) 
_{Apr}
(54) 
_{May}
(66) 
_{Jun}
(90) 
_{Jul}
(75) 
_{Aug}
(61) 
_{Sep}
(4) 
_{Oct}
(5) 
_{Nov}
(41) 
_{Dec}
(3) 
2016 
_{Jan}
(5) 
_{Feb}
(40) 
_{Mar}
(422) 
_{Apr}
(33) 
_{May}
(74) 
_{Jun}
(80) 
_{Jul}
(43) 
_{Aug}
(79) 
_{Sep}
(12) 
_{Oct}
(8) 
_{Nov}
(39) 
_{Dec}

2017 
_{Jan}
(7) 
_{Feb}
(10) 
_{Mar}
(99) 
_{Apr}
(63) 
_{May}
(36) 
_{Jun}
(65) 
_{Jul}
(104) 
_{Aug}
(66) 
_{Sep}
(38) 
_{Oct}

_{Nov}

_{Dec}

From: Mario Meissner <mr.rash.boy@gm...>  20170925 11:14:05

Attached goes new code with the changes I mentioned. Only tested once on a simple case. Should give you an idea of what I meant with Saturdays mail. Feedback is as always very welcome. I will now test it more thoroughly and then move on to revamp the first step too, which is severely flawed still. I have yet to come up with a more elegant way of checking which 'tiles' our segment will cross and which not. Back with more tomorrow. Mario. On 23 September 2017 at 20:20, Mario Meissner <mr.rash.boy@...> wrote: > Hello everyone. > > I wrote this on my log a few hours ago but I thought it's a good idea to > go into more detail here since it's major change in direction. > > First, I will get rid of the projection structure, which is now just a > contribution. Its projection is now just something secondary that can be > used to predict if we need to skip the point or not. > > So, my new approach will be clearly separated into three steps: > Create a list of contributions. This stage is completely recycled from my > current code, and for now the methodology to detect points that will > contribute to our segment will remain the same. It will be the weakest part > of the implementation once this major revamp is done, and may require some > work. > Compute the boundaries between the contributions. This means computing > when each contribution starts and ends within the segment. They are stored > inside the contribution structure. > Loop through the contributions and take average density proportional to > how big each intersection is. > > Notice how much simpler the average_density computation is now. Stage two > is also simple because I have already implemented the intersection function. > > As this is a major change it will take me a few days to implement. I've > spent most of my time today to refactor step 1 to use contributions instead > of projections. I hope by tomorrow I can send an inprogress version with > some cases working. > > I really think this new version cleans up the mess quite a lot, simplifies > the concepts, makes it all more readable, and most importantly, will > support more situations than before, removing several flaws. > > Mario. > > On 23 September 2017 at 18:01, Mario Meissner <mr.rash.boy@...> > wrote: > >> I'm passing two arguments to my segment_density, which are inhit and >>> outhit points. >>> I now realize that these are pointers and could change unexpectedly >>> within the call if we run multiple threads. >>> How can I make this safe? Should I BU_GET safe heap memory to store the >>> points for the call, or pass the coordinates one by one as actual numbers? >>> >> >> I guess I should just do the same I did with intersection, since in the >> end it's the same issue. >> >> For debugging purposes I would like to set only one thread for rtweight, >> how can I do that? The fact that I get 4 or more threads running my >> segment_density at the same time makes it difficult to track down issues. >> > > 
From: Mario Meissner <mr.rash.boy@gm...>  20170923 18:21:31

Hello everyone. I wrote this on my log a few hours ago but I thought it's a good idea to go into more detail here since it's major change in direction. First, I will get rid of the projection structure, which is now just a contribution. Its projection is now just something secondary that can be used to predict if we need to skip the point or not. So, my new approach will be clearly separated into three steps: Create a list of contributions. This stage is completely recycled from my current code, and for now the methodology to detect points that will contribute to our segment will remain the same. It will be the weakest part of the implementation once this major revamp is done, and may require some work. Compute the boundaries between the contributions. This means computing when each contribution starts and ends within the segment. They are stored inside the contribution structure. Loop through the contributions and take average density proportional to how big each intersection is. Notice how much simpler the average_density computation is now. Stage two is also simple because I have already implemented the intersection function. As this is a major change it will take me a few days to implement. I've spent most of my time today to refactor step 1 to use contributions instead of projections. I hope by tomorrow I can send an inprogress version with some cases working. I really think this new version cleans up the mess quite a lot, simplifies the concepts, makes it all more readable, and most importantly, will support more situations than before, removing several flaws. Mario. On 23 September 2017 at 18:01, Mario Meissner <mr.rash.boy@...> wrote: > I'm passing two arguments to my segment_density, which are inhit and >> outhit points. >> I now realize that these are pointers and could change unexpectedly >> within the call if we run multiple threads. >> How can I make this safe? Should I BU_GET safe heap memory to store the >> points for the call, or pass the coordinates one by one as actual numbers? >> > > I guess I should just do the same I did with intersection, since in the > end it's the same issue. > > For debugging purposes I would like to set only one thread for rtweight, > how can I do that? The fact that I get 4 or more threads running my > segment_density at the same time makes it difficult to track down issues. > 
From: Mario Meissner <mr.rash.boy@gm...>  20170923 16:01:56

> > I'm passing two arguments to my segment_density, which are inhit and > outhit points. > I now realize that these are pointers and could change unexpectedly within > the call if we run multiple threads. > How can I make this safe? Should I BU_GET safe heap memory to store the > points for the call, or pass the coordinates one by one as actual numbers? > I guess I should just do the same I did with intersection, since in the end it's the same issue. For debugging purposes I would like to set only one thread for rtweight, how can I do that? The fact that I get 4 or more threads running my segment_density at the same time makes it difficult to track down issues. 
From: Mario Meissner <mr.rash.boy@gm...>  20170922 19:13:51

> > What I meant was: Why has your intersection_t struct an intersect member? > You don't use it. > I wanted to use it as a surrogate for your NULL return value but what was > your reason? > I just didn't really know what that intersect member was in your example. So I just set it to 0 in the hopes that sometime later I would understand it's use xD > I wanted to show you your options because only when you know them you will > be able to make a well reasoned decision. And, Vasco showed you a third > one. Now, it's on you to decide (not on me). > In the end I decided to pass a pointer and leave all memory management to the caller. Thank you again for the help and suggestions! 
From: Daniel Roßberg <danielmrossberg@gm...>  20170922 18:28:36

Hi Mario, 20170921 18:00 GMT+02:00 Mario Meissner <mr.rash.boy@...>: > By flag you mean that I should indicate with that variable whether an > intersection occurred or not? > What I meant was: Why has your intersection_t struct an intersect member? You don't use it. I wanted to use it as a surrogate for your NULL return value but what was your reason? > Also, should I just return it without a pointer, without allocating it on > the heap? I assume this is what you wanted me to do because you suggested > my function head to be: > struct intersection_t intersection(point_t p0 .... > I wanted to show you your options because only when you know them you will be able to make a well reasoned decision. And, Vasco showed you a third one. Now, it's on you to decide (not on me). > I thought this is not possible because it would be destroyed once the > function call ends. But apparently it doesn't: https:// > stackoverflow.com/questions/22957175/howdoesfunction > actuallyreturnstructvariableinc > > The VS compiler seems to complain when I try to assign the returned struct > to another variable though. > Hmm, I tested it with MSVS 2013. Regards, Daniel 
From: Mario Meissner <mr.rash.boy@gm...>  20170922 18:19:13

Another important question. I'm passing two arguments to my segment_density, which are inhit and outhit points. I now realize that these are pointers and could change unexpectedly within the call if we run multiple threads. How can I make this safe? Should I BU_GET safe heap memory to store the points for the call, or pass the coordinates one by one as actual numbers? On 22 September 2017 at 17:07, Mario Meissner <mr.rash.boy@...> wrote: > Hello! > > Mass being 0 all the time was because the reg_los of my region was 0 for > whatever reason. Hardcoding a reg_los of 100 (and thus a 'factor' of 1) > works and I now get a mass value (however unfortunately not the value I > expect, yet). Attached goes code. Any hints on why the reg>reg_los isn't > set correctly? > > When and where is it computed? Also, what is it's meaning exactly? I know > it should be something like 'amount of the region actually filled with the > material' or something, but I don't really understand it yet. > > I'll work on figuring out why the numbers don't fit expectations. > > Mario. > > On 21 September 2017 at 18:42, Vasco Alexandre da Silva Costa < > vasco.costa@...> wrote: > >> BTW, do you have a Chinese OS version? Your diff files contain Chinese >>> comments. >>> >> >> Because Japanese uses Kanji (Chinese characters) sometimes it becomes >> hard to tell the two languages apart. But in this case you can see some >> Katakana in there so it's clearly Japanese. >> https://en.wikipedia.org/wiki/Katakana >> >>  >> Vasco Alexandre da Silva Costa >> PhD in Computer Engineering (Computer Graphics) >> Instituto Superior Técnico/University of Lisbon, Portugal >> >>  >>  >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> BRLCAD Developer mailing list >> brlcaddevel@... >> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >> >> > 
From: Mario Meissner <mr.rash.boy@gm...>  20170922 15:08:04

Hello! Mass being 0 all the time was because the reg_los of my region was 0 for whatever reason. Hardcoding a reg_los of 100 (and thus a 'factor' of 1) works and I now get a mass value (however unfortunately not the value I expect, yet). Attached goes code. Any hints on why the reg>reg_los isn't set correctly? When and where is it computed? Also, what is it's meaning exactly? I know it should be something like 'amount of the region actually filled with the material' or something, but I don't really understand it yet. I'll work on figuring out why the numbers don't fit expectations. Mario. On 21 September 2017 at 18:42, Vasco Alexandre da Silva Costa < vasco.costa@...> wrote: > BTW, do you have a Chinese OS version? Your diff files contain Chinese >> comments. >> > > Because Japanese uses Kanji (Chinese characters) sometimes it becomes hard > to tell the two languages apart. But in this case you can see some Katakana > in there so it's clearly Japanese. > https://en.wikipedia.org/wiki/Katakana > >  > Vasco Alexandre da Silva Costa > PhD in Computer Engineering (Computer Graphics) > Instituto Superior Técnico/University of Lisbon, Portugal > >  >  > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > > 
From: Vasco Alexandre da Silva Costa <vasco.costa@gm...>  20170921 16:42:20

> > BTW, do you have a Chinese OS version? Your diff files contain Chinese > comments. > Because Japanese uses Kanji (Chinese characters) sometimes it becomes hard to tell the two languages apart. But in this case you can see some Katakana in there so it's clearly Japanese. https://en.wikipedia.org/wiki/Katakana  Vasco Alexandre da Silva Costa PhD in Computer Engineering (Computer Graphics) Instituto Superior Técnico/University of Lisbon, Portugal 
From: Vasco Alexandre da Silva Costa <vasco.costa@gm...>  20170921 16:37:54

You have typically 3 choices to solve an allocation problem like that. 1) allocate a chunk of memory and return it, with the caller becoming responsible for the free later. (like Daniel Said) 2) changing the function signature so that the caller has to pass to the function a pointer to the memory chunk that will be used to store the results (usually this is the best option of the three as it means the caller becomes responsible for all memory management). 3) return a struct with the data inside. On Thu, Sep 21, 2017 at 5:00 PM, Mario Meissner <mr.rash.boy@...> wrote: > By flag you mean that I should indicate with that variable whether an > intersection occurred or not? > > Also, should I just return it without a pointer, without allocating it on > the heap? I assume this is what you wanted me to do because you suggested > my function head to be: > struct intersection_t intersection(point_t p0 .... > I thought this is not possible because it would be destroyed once the > function call ends. But apparently it doesn't: https:// > stackoverflow.com/questions/22957175/howdoesfunction > actuallyreturnstructvariableinc > > The VS compiler seems to complain when I try to assign the returned struct > to another variable though. > > As far as svn printing Japanese comments, that is due to the fact that > some of my locale settings in my OS are set to Japanese (not the language). > No clue why svn decided to use Japanese comments now though. I hope it > isn't too annoying ^^' > > Thank you for the quick feedback! Very much appreciated. > > Mario. > > On 21 September 2017 at 17:16, Daniel Roßberg <danielmrossberg@...> > wrote: > >> Hi Mario, >> >> Hmm, it looks like you haven't really understood what I wrote you. You >> use the struct but allocate it with BU_GET() on the heap and don't use its >> intersect flag. But what is really bad is that you don't free it if it >> won't be used any more. >> >> BTW, do you have a Chinese OS version? Your diff files contain Chinese >> comments. >> >> >> Regards, >> Daniel >> >> >> 20170921 14:13 GMT+02:00 Mario Meissner <mr.rash.boy@...>: >> >>> Hi Daniel. >>> >>> Thank you for your response. Negative values may have been only due to >>> using the wrong formatting tag while printing values. I have cleaned up >>> some unused variables and fixed the intersection by using your suggestion. >>> >>> Mass is 0 in the total_weight variable, as if the code wasn't really >>> adding up my segment_density values correctly. I might have deleted some >>> important code related to the storing or reading of the values. I will >>> double check on that now. >>> Attached goes current version of my code. >>> >>> Mario. >>> >>> On 21 September 2017 at 13:03, Daniel Roßberg <danielmrossberg@... >>> > wrote: >>> >>>> Hi Mario, >>>> >>>> I have been trying to track down the reason why some densities are >>>>> negative. A few questions I have ended up asking myself: >>>>> >>>>>  Is it possible for MAGNITUDE() to return a negative number? It would >>>>> make no sense to me, but I suspect it's happening. >>>>> >>>> >>>> No, MAGNITUDE() is the square root of a (necessarily) positive value. >>>> You can safely assume it to be not negative. >>>> >>>>  In my little function intersection I noticed that I am returning a >>>>> pointer to a local variable, that could be destroyed in any moment after >>>>> the call ends. Instead of that, I want to return a safe variable. How do I >>>>> do that in this case? >>>>> >>>>> I don't understand why it doesn't let me return directly the variable >>>>> point_t. It's a pointer, because it's an array, right? As it didn't let me >>>>> return the point, I decided to return a pointer to the point instead, >>>>> however as I mentioned this is not safe, so I have to change it now. Any >>>>> explanation on why I can't return the point, and what I should do to make >>>>> it safe? >>>>> >>>> >>>> Well, there is a standard solution for this kind of issue: Putting the >>>> data on the heap, e.g. >>>> point_t *intersect = (point_t *) bu_malloc(sizeof(point_t), >>>> "intersection"); >>>> with the disadvantage that the caller has explicitly to free the memory >>>> with bu_free(). >>>> >>>> It's true that C functions can't return arrays (because of historic >>>> reason). But, returning an array wouldn't help you here as you are using >>>> the function's return as a flag for intersection too. On the other hand, >>>> structs can be returned: >>>> struct intersection_t { >>>> int intersect; >>>> point_t intersection_point; >>>> }; >>>> >>>> struct intersection_t intersection(point_t p0, point_t p1, >>>> point_t p_co, vect_t p_no) { >>>> .... >>>> should work. >>>> >>>> >>>>> Finally, I think I could need some help regarding the negative values >>>>> issue, at least once I'm sure the two points above aren't the cause. >>>>> >>>> >>>> Feel free to ask ;) >>>> >>>> >>>> Regards, >>>> Daniel >>>> >>>>  >>>>  >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> BRLCAD Developer mailing list >>>> brlcaddevel@... >>>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>>> >>>> >>> >>>  >>>  >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> BRLCAD Developer mailing list >>> brlcaddevel@... >>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>> >>> >> >>  >>  >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> BRLCAD Developer mailing list >> brlcaddevel@... >> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >> >> > >  >  > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > >  Vasco Alexandre da Silva Costa PhD in Computer Engineering (Computer Graphics) Instituto Superior Técnico/University of Lisbon, Portugal 
From: Mario Meissner <mr.rash.boy@gm...>  20170921 16:01:18

By flag you mean that I should indicate with that variable whether an intersection occurred or not? Also, should I just return it without a pointer, without allocating it on the heap? I assume this is what you wanted me to do because you suggested my function head to be: struct intersection_t intersection(point_t p0 .... I thought this is not possible because it would be destroyed once the function call ends. But apparently it doesn't: https://stackoverflow.com/questions/22957175/howdoesfunctionactuallyreturnstructvariableinc The VS compiler seems to complain when I try to assign the returned struct to another variable though. As far as svn printing Japanese comments, that is due to the fact that some of my locale settings in my OS are set to Japanese (not the language). No clue why svn decided to use Japanese comments now though. I hope it isn't too annoying ^^' Thank you for the quick feedback! Very much appreciated. Mario. On 21 September 2017 at 17:16, Daniel Roßberg <danielmrossberg@...> wrote: > Hi Mario, > > Hmm, it looks like you haven't really understood what I wrote you. You > use the struct but allocate it with BU_GET() on the heap and don't use its > intersect flag. But what is really bad is that you don't free it if it > won't be used any more. > > BTW, do you have a Chinese OS version? Your diff files contain Chinese > comments. > > > Regards, > Daniel > > > 20170921 14:13 GMT+02:00 Mario Meissner <mr.rash.boy@...>: > >> Hi Daniel. >> >> Thank you for your response. Negative values may have been only due to >> using the wrong formatting tag while printing values. I have cleaned up >> some unused variables and fixed the intersection by using your suggestion. >> >> Mass is 0 in the total_weight variable, as if the code wasn't really >> adding up my segment_density values correctly. I might have deleted some >> important code related to the storing or reading of the values. I will >> double check on that now. >> Attached goes current version of my code. >> >> Mario. >> >> On 21 September 2017 at 13:03, Daniel Roßberg <danielmrossberg@...> >> wrote: >> >>> Hi Mario, >>> >>> I have been trying to track down the reason why some densities are >>>> negative. A few questions I have ended up asking myself: >>>> >>>>  Is it possible for MAGNITUDE() to return a negative number? It would >>>> make no sense to me, but I suspect it's happening. >>>> >>> >>> No, MAGNITUDE() is the square root of a (necessarily) positive value. >>> You can safely assume it to be not negative. >>> >>>  In my little function intersection I noticed that I am returning a >>>> pointer to a local variable, that could be destroyed in any moment after >>>> the call ends. Instead of that, I want to return a safe variable. How do I >>>> do that in this case? >>>> >>>> I don't understand why it doesn't let me return directly the variable >>>> point_t. It's a pointer, because it's an array, right? As it didn't let me >>>> return the point, I decided to return a pointer to the point instead, >>>> however as I mentioned this is not safe, so I have to change it now. Any >>>> explanation on why I can't return the point, and what I should do to make >>>> it safe? >>>> >>> >>> Well, there is a standard solution for this kind of issue: Putting the >>> data on the heap, e.g. >>> point_t *intersect = (point_t *) bu_malloc(sizeof(point_t), >>> "intersection"); >>> with the disadvantage that the caller has explicitly to free the memory >>> with bu_free(). >>> >>> It's true that C functions can't return arrays (because of historic >>> reason). But, returning an array wouldn't help you here as you are using >>> the function's return as a flag for intersection too. On the other hand, >>> structs can be returned: >>> struct intersection_t { >>> int intersect; >>> point_t intersection_point; >>> }; >>> >>> struct intersection_t intersection(point_t p0, point_t p1, point_t >>> p_co, vect_t p_no) { >>> .... >>> should work. >>> >>> >>>> Finally, I think I could need some help regarding the negative values >>>> issue, at least once I'm sure the two points above aren't the cause. >>>> >>> >>> Feel free to ask ;) >>> >>> >>> Regards, >>> Daniel >>> >>>  >>>  >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> BRLCAD Developer mailing list >>> brlcaddevel@... >>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>> >>> >> >>  >>  >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> BRLCAD Developer mailing list >> brlcaddevel@... >> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >> >> > >  >  > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > > 
From: Daniel Roßberg <danielmrossberg@gm...>  20170921 15:16:20

Hi Mario, Hmm, it looks like you haven't really understood what I wrote you. You use the struct but allocate it with BU_GET() on the heap and don't use its intersect flag. But what is really bad is that you don't free it if it won't be used any more. BTW, do you have a Chinese OS version? Your diff files contain Chinese comments. Regards, Daniel 20170921 14:13 GMT+02:00 Mario Meissner <mr.rash.boy@...>: > Hi Daniel. > > Thank you for your response. Negative values may have been only due to > using the wrong formatting tag while printing values. I have cleaned up > some unused variables and fixed the intersection by using your suggestion. > > Mass is 0 in the total_weight variable, as if the code wasn't really > adding up my segment_density values correctly. I might have deleted some > important code related to the storing or reading of the values. I will > double check on that now. > Attached goes current version of my code. > > Mario. > > On 21 September 2017 at 13:03, Daniel Roßberg <danielmrossberg@...> > wrote: > >> Hi Mario, >> >> I have been trying to track down the reason why some densities are >>> negative. A few questions I have ended up asking myself: >>> >>>  Is it possible for MAGNITUDE() to return a negative number? It would >>> make no sense to me, but I suspect it's happening. >>> >> >> No, MAGNITUDE() is the square root of a (necessarily) positive value. >> You can safely assume it to be not negative. >> >>  In my little function intersection I noticed that I am returning a >>> pointer to a local variable, that could be destroyed in any moment after >>> the call ends. Instead of that, I want to return a safe variable. How do I >>> do that in this case? >>> >>> I don't understand why it doesn't let me return directly the variable >>> point_t. It's a pointer, because it's an array, right? As it didn't let me >>> return the point, I decided to return a pointer to the point instead, >>> however as I mentioned this is not safe, so I have to change it now. Any >>> explanation on why I can't return the point, and what I should do to make >>> it safe? >>> >> >> Well, there is a standard solution for this kind of issue: Putting the >> data on the heap, e.g. >> point_t *intersect = (point_t *) bu_malloc(sizeof(point_t), >> "intersection"); >> with the disadvantage that the caller has explicitly to free the memory >> with bu_free(). >> >> It's true that C functions can't return arrays (because of historic >> reason). But, returning an array wouldn't help you here as you are using >> the function's return as a flag for intersection too. On the other hand, >> structs can be returned: >> struct intersection_t { >> int intersect; >> point_t intersection_point; >> }; >> >> struct intersection_t intersection(point_t p0, point_t p1, point_t >> p_co, vect_t p_no) { >> .... >> should work. >> >> >>> Finally, I think I could need some help regarding the negative values >>> issue, at least once I'm sure the two points above aren't the cause. >>> >> >> Feel free to ask ;) >> >> >> Regards, >> Daniel >> >>  >>  >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> BRLCAD Developer mailing list >> brlcaddevel@... >> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >> >> > >  >  > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > > 
From: Mario Meissner <mr.rash.boy@gm...>  20170921 12:14:24

Hi Daniel. Thank you for your response. Negative values may have been only due to using the wrong formatting tag while printing values. I have cleaned up some unused variables and fixed the intersection by using your suggestion. Mass is 0 in the total_weight variable, as if the code wasn't really adding up my segment_density values correctly. I might have deleted some important code related to the storing or reading of the values. I will double check on that now. Attached goes current version of my code. Mario. On 21 September 2017 at 13:03, Daniel Roßberg <danielmrossberg@...> wrote: > Hi Mario, > > I have been trying to track down the reason why some densities are >> negative. A few questions I have ended up asking myself: >> >>  Is it possible for MAGNITUDE() to return a negative number? It would >> make no sense to me, but I suspect it's happening. >> > > No, MAGNITUDE() is the square root of a (necessarily) positive value. > You can safely assume it to be not negative. > >  In my little function intersection I noticed that I am returning a >> pointer to a local variable, that could be destroyed in any moment after >> the call ends. Instead of that, I want to return a safe variable. How do I >> do that in this case? >> >> I don't understand why it doesn't let me return directly the variable >> point_t. It's a pointer, because it's an array, right? As it didn't let me >> return the point, I decided to return a pointer to the point instead, >> however as I mentioned this is not safe, so I have to change it now. Any >> explanation on why I can't return the point, and what I should do to make >> it safe? >> > > Well, there is a standard solution for this kind of issue: Putting the > data on the heap, e.g. > point_t *intersect = (point_t *) bu_malloc(sizeof(point_t), > "intersection"); > with the disadvantage that the caller has explicitly to free the memory > with bu_free(). > > It's true that C functions can't return arrays (because of historic > reason). But, returning an array wouldn't help you here as you are using > the function's return as a flag for intersection too. On the other hand, > structs can be returned: > struct intersection_t { > int intersect; > point_t intersection_point; > }; > > struct intersection_t intersection(point_t p0, point_t p1, point_t > p_co, vect_t p_no) { > .... > should work. > > >> Finally, I think I could need some help regarding the negative values >> issue, at least once I'm sure the two points above aren't the cause. >> > > Feel free to ask ;) > > > Regards, > Daniel > >  >  > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > > 
From: Daniel Roßberg <danielmrossberg@gm...>  20170921 11:03:46

Hi Mario, I have been trying to track down the reason why some densities are > negative. A few questions I have ended up asking myself: > >  Is it possible for MAGNITUDE() to return a negative number? It would > make no sense to me, but I suspect it's happening. > No, MAGNITUDE() is the square root of a (necessarily) positive value. You can safely assume it to be not negative.  In my little function intersection I noticed that I am returning a > pointer to a local variable, that could be destroyed in any moment after > the call ends. Instead of that, I want to return a safe variable. How do I > do that in this case? > > I don't understand why it doesn't let me return directly the variable > point_t. It's a pointer, because it's an array, right? As it didn't let me > return the point, I decided to return a pointer to the point instead, > however as I mentioned this is not safe, so I have to change it now. Any > explanation on why I can't return the point, and what I should do to make > it safe? > Well, there is a standard solution for this kind of issue: Putting the data on the heap, e.g. point_t *intersect = (point_t *) bu_malloc(sizeof(point_t), "intersection"); with the disadvantage that the caller has explicitly to free the memory with bu_free(). It's true that C functions can't return arrays (because of historic reason). But, returning an array wouldn't help you here as you are using the function's return as a flag for intersection too. On the other hand, structs can be returned: struct intersection_t { int intersect; point_t intersection_point; }; struct intersection_t intersection(point_t p0, point_t p1, point_t p_co, vect_t p_no) { .... should work. > Finally, I think I could need some help regarding the negative values > issue, at least once I'm sure the two points above aren't the cause. > Feel free to ask ;) Regards, Daniel 
From: Mario Meissner <mr.rash.boy@gm...>  20170921 08:02:42

Hi again. I have been trying to track down the reason why some densities are negative. A few questions I have ended up asking myself:  Is it possible for MAGNITUDE() to return a negative number? It would make no sense to me, but I suspect it's happening.  In my little function intersection I noticed that I am returning a pointer to a local variable, that could be destroyed in any moment after the call ends. Instead of that, I want to return a safe variable. How do I do that in this case? I don't understand why it doesn't let me return directly the variable point_t. It's a pointer, because it's an array, right? As it didn't let me return the point, I decided to return a pointer to the point instead, however as I mentioned this is not safe, so I have to change it now. Any explanation on why I can't return the point, and what I should do to make it safe? Finally, I think I could need some help regarding the negative values issue, at least once I'm sure the two points above aren't the cause. Mario. On 17 September 2017 at 21:16, Mario Meissner <mr.rash.boy@...> wrote: > After my linux build decided to not compile anymore (and haven't been able > to fix it since) I switched back to VStudio and I have been able to run > rtweight with the density file. Attached goes current state of the code for > both rtexample (to see how segment_density works) and rtweight. > > Doesn't work yet, I'm investigating the cause, but I'll detail what's > happening here. If I put a point with density 3 inside my 1000x1000x1000mm > box, it sometimes adds 3 to the datapoint, but then sometimes 1 or 2, and > in the end the accumulation of all the datapoints evaluates as 0. So > something in my code segment_density code is allowing for negative values > and it somehow happens to result in a symmetrical set of positive and > negative values, adding up to 0. > > I'll keep working on this tomorrow, but for now it would be nice to hear > some more feedback overall. > > Mario. > > On 15 September 2017 at 16:23, Mario Meissner <mr.rash.boy@...> > wrote: > >> I'm working on integrating the code into viewweight. >> As a first step I thought it would be a good idea to not touch the >> existing code (and let it read from the .density file) and just override >> the hit() function to call my segment_density instead of taking the file >> data. However I'm getting segmentation faults whenever I try to run the >> code. This happened to me before and I managed to solve it by changing the >> codification of the .density file, however this time I don't seem to be >> able to fix it. >> >> Here is result screencap, and I also attach the modified viewweight and >> the density file. >> https://puu.sh/xAmiE/b5fa0dfab8.png >> >> Mario. >> >> On 8 September 2017 at 21:04, Mario Meissner <mr.rash.boy@...> >> wrote: >> >>> Peopleee! >>> >>> Here goes today's work. I'm proud to announce the example I modeled a >>> few days ago now works correctly!! >>> Code still contains my debug prints and lots of random 'puts' to know >>> where and why stuff crashes. I feel I will need it in the future so for now >>> it remains. >>> I probably should keep looking for flaws by setting up other examples, >>> and while doing so I should also clean it up a bit since the code grew over >>> 600 lines now, quite difficult to read and understand. >>> >>> Screenshot: >>> https://puu.sh/xuIXk/9626ce2fb6.png >>> >>> Mario. >>> >>> On 8 September 2017 at 19:56, Mario Meissner <mr.rash.boy@...> >>> wrote: >>> >>>> Hi Daniel! >>>> >>>> Thank you a lot for your reply. I was focused on generating the >>>> bisector to intersect two lines, but intersecting the actual plane is much >>>> simpler. I made a little function to intersect a plane with a line >>>> (partially taken from this stackoverflow post >>>> <https://stackoverflow.com/questions/5666222/3dlineplaneintersection>;, >>>> so credits to user ideasman42 >>>> <https://stackoverflow.com/users/432509/ideasman42>;). I am now >>>> finishing of the 'patch' to my code that is supposed to now correctly skip >>>> unnecessary points and create a list with those who's regions we will >>>> actually cross. Code probably tomorrow. >>>> >>>> Mario. >>>> >>>> On 8 September 2017 at 09:35, Daniel Roßberg <danielmrossberg@... >>>> > wrote: >>>> >>>>> Hi Mario, >>>>> >>>>> In 3D space, rectangular to a vector you have a plane and the vector >>>>> is a normal vector of this plane. In this plane are all vectors which are >>>>> perpendicular to your first vector, i.e. the vectors which products with >>>>> your first vector are 0. This gives you a first equation with two >>>>> variables. >>>>> >>>>> Next, you want to intersect the plane with a ray. I.e., one vector >>>>> from your plan has to be a multiple of the ray which gives you another >>>>> equation. >>>>> >>>>> However, there should be examples in the BRLCAD source code for >>>>> this. E.g., the raytrace of the half primitive is very similar to your >>>>> problem. There, the intersection of a plane, given by a normal vector and >>>>> a point in it, and a ray, given by a start point and a direction, will be >>>>> computed. >>>>> >>>>> I hope this helps. >>>>> >>>>> >>>>> Regards, >>>>> Daniel >>>>> >>>>> >>>>> >>>>> I'm facing a wall. I need to find a perpendicular vector with the >>>>> condition that it will intersect a third vector. >>>>> Basically, I have the ray and a vector drawn from my current point to >>>>> the previous point. >>>>> I want the perpendicular bisector of that vector to cross my ray, so >>>>> that I can obtain the intersection between the bisector and the ray. >>>>> >>>>> For that I need two things: >>>>> 1) Obtain the perpendicular vector. in 3D there are infinite options, >>>>> but only one will cross the ray. How do I get the one I need? >>>>> 2) Obtain the intersection point. >>>>> >>>>> I browsed through vmath.h but I didn't find anything that could help >>>>> me. Do you know any macro that could be useful here? >>>>> Otherwise I will need to make some of my own for this! If so, any >>>>> ideas on how to approach it? >>>>> >>>>> Mario. >>>>> >>>>> >>>>>  >>>>>  >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> BRLCAD Developer mailing list >>>>> brlcaddevel@... >>>>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>>>> >>>>> >>>> >>> >> > 
From: Mario Meissner <mr.rash.boy@gm...>  20170917 19:17:16

After my linux build decided to not compile anymore (and haven't been able to fix it since) I switched back to VStudio and I have been able to run rtweight with the density file. Attached goes current state of the code for both rtexample (to see how segment_density works) and rtweight. Doesn't work yet, I'm investigating the cause, but I'll detail what's happening here. If I put a point with density 3 inside my 1000x1000x1000mm box, it sometimes adds 3 to the datapoint, but then sometimes 1 or 2, and in the end the accumulation of all the datapoints evaluates as 0. So something in my code segment_density code is allowing for negative values and it somehow happens to result in a symmetrical set of positive and negative values, adding up to 0. I'll keep working on this tomorrow, but for now it would be nice to hear some more feedback overall. Mario. On 15 September 2017 at 16:23, Mario Meissner <mr.rash.boy@...> wrote: > I'm working on integrating the code into viewweight. > As a first step I thought it would be a good idea to not touch the > existing code (and let it read from the .density file) and just override > the hit() function to call my segment_density instead of taking the file > data. However I'm getting segmentation faults whenever I try to run the > code. This happened to me before and I managed to solve it by changing the > codification of the .density file, however this time I don't seem to be > able to fix it. > > Here is result screencap, and I also attach the modified viewweight and > the density file. > https://puu.sh/xAmiE/b5fa0dfab8.png > > Mario. > > On 8 September 2017 at 21:04, Mario Meissner <mr.rash.boy@...> > wrote: > >> Peopleee! >> >> Here goes today's work. I'm proud to announce the example I modeled a few >> days ago now works correctly!! >> Code still contains my debug prints and lots of random 'puts' to know >> where and why stuff crashes. I feel I will need it in the future so for now >> it remains. >> I probably should keep looking for flaws by setting up other examples, >> and while doing so I should also clean it up a bit since the code grew over >> 600 lines now, quite difficult to read and understand. >> >> Screenshot: >> https://puu.sh/xuIXk/9626ce2fb6.png >> >> Mario. >> >> On 8 September 2017 at 19:56, Mario Meissner <mr.rash.boy@...> >> wrote: >> >>> Hi Daniel! >>> >>> Thank you a lot for your reply. I was focused on generating the bisector >>> to intersect two lines, but intersecting the actual plane is much simpler. >>> I made a little function to intersect a plane with a line (partially taken >>> from this stackoverflow post >>> <https://stackoverflow.com/questions/5666222/3dlineplaneintersection>;, >>> so credits to user ideasman42 >>> <https://stackoverflow.com/users/432509/ideasman42>;). I am now >>> finishing of the 'patch' to my code that is supposed to now correctly skip >>> unnecessary points and create a list with those who's regions we will >>> actually cross. Code probably tomorrow. >>> >>> Mario. >>> >>> On 8 September 2017 at 09:35, Daniel Roßberg <danielmrossberg@...> >>> wrote: >>> >>>> Hi Mario, >>>> >>>> In 3D space, rectangular to a vector you have a plane and the vector is >>>> a normal vector of this plane. In this plane are all vectors which are >>>> perpendicular to your first vector, i.e. the vectors which products with >>>> your first vector are 0. This gives you a first equation with two >>>> variables. >>>> >>>> Next, you want to intersect the plane with a ray. I.e., one vector >>>> from your plan has to be a multiple of the ray which gives you another >>>> equation. >>>> >>>> However, there should be examples in the BRLCAD source code for this. >>>> E.g., the raytrace of the half primitive is very similar to your problem. >>>> There, the intersection of a plane, given by a normal vector and a point in >>>> it, and a ray, given by a start point and a direction, will be computed. >>>> >>>> I hope this helps. >>>> >>>> >>>> Regards, >>>> Daniel >>>> >>>> >>>> >>>> I'm facing a wall. I need to find a perpendicular vector with the >>>> condition that it will intersect a third vector. >>>> Basically, I have the ray and a vector drawn from my current point to >>>> the previous point. >>>> I want the perpendicular bisector of that vector to cross my ray, so >>>> that I can obtain the intersection between the bisector and the ray. >>>> >>>> For that I need two things: >>>> 1) Obtain the perpendicular vector. in 3D there are infinite options, >>>> but only one will cross the ray. How do I get the one I need? >>>> 2) Obtain the intersection point. >>>> >>>> I browsed through vmath.h but I didn't find anything that could help >>>> me. Do you know any macro that could be useful here? >>>> Otherwise I will need to make some of my own for this! If so, any ideas >>>> on how to approach it? >>>> >>>> Mario. >>>> >>>> >>>>  >>>>  >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> BRLCAD Developer mailing list >>>> brlcaddevel@... >>>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>>> >>>> >>> >> > 
From: Mario Meissner <mr.rash.boy@gm...>  20170915 14:24:19

I'm working on integrating the code into viewweight. As a first step I thought it would be a good idea to not touch the existing code (and let it read from the .density file) and just override the hit() function to call my segment_density instead of taking the file data. However I'm getting segmentation faults whenever I try to run the code. This happened to me before and I managed to solve it by changing the codification of the .density file, however this time I don't seem to be able to fix it. Here is result screencap, and I also attach the modified viewweight and the density file. https://puu.sh/xAmiE/b5fa0dfab8.png Mario. On 8 September 2017 at 21:04, Mario Meissner <mr.rash.boy@...> wrote: > Peopleee! > > Here goes today's work. I'm proud to announce the example I modeled a few > days ago now works correctly!! > Code still contains my debug prints and lots of random 'puts' to know > where and why stuff crashes. I feel I will need it in the future so for now > it remains. > I probably should keep looking for flaws by setting up other examples, and > while doing so I should also clean it up a bit since the code grew over 600 > lines now, quite difficult to read and understand. > > Screenshot: > https://puu.sh/xuIXk/9626ce2fb6.png > > Mario. > > On 8 September 2017 at 19:56, Mario Meissner <mr.rash.boy@...> > wrote: > >> Hi Daniel! >> >> Thank you a lot for your reply. I was focused on generating the bisector >> to intersect two lines, but intersecting the actual plane is much simpler. >> I made a little function to intersect a plane with a line (partially taken >> from this stackoverflow post >> <https://stackoverflow.com/questions/5666222/3dlineplaneintersection>;, >> so credits to user ideasman42 >> <https://stackoverflow.com/users/432509/ideasman42>;). I am now finishing >> of the 'patch' to my code that is supposed to now correctly skip >> unnecessary points and create a list with those who's regions we will >> actually cross. Code probably tomorrow. >> >> Mario. >> >> On 8 September 2017 at 09:35, Daniel Roßberg <danielmrossberg@...> >> wrote: >> >>> Hi Mario, >>> >>> In 3D space, rectangular to a vector you have a plane and the vector is >>> a normal vector of this plane. In this plane are all vectors which are >>> perpendicular to your first vector, i.e. the vectors which products with >>> your first vector are 0. This gives you a first equation with two >>> variables. >>> >>> Next, you want to intersect the plane with a ray. I.e., one vector from >>> your plan has to be a multiple of the ray which gives you another equation. >>> >>> However, there should be examples in the BRLCAD source code for this. >>> E.g., the raytrace of the half primitive is very similar to your problem. >>> There, the intersection of a plane, given by a normal vector and a point in >>> it, and a ray, given by a start point and a direction, will be computed. >>> >>> I hope this helps. >>> >>> >>> Regards, >>> Daniel >>> >>> >>> >>> I'm facing a wall. I need to find a perpendicular vector with the >>> condition that it will intersect a third vector. >>> Basically, I have the ray and a vector drawn from my current point to >>> the previous point. >>> I want the perpendicular bisector of that vector to cross my ray, so >>> that I can obtain the intersection between the bisector and the ray. >>> >>> For that I need two things: >>> 1) Obtain the perpendicular vector. in 3D there are infinite options, >>> but only one will cross the ray. How do I get the one I need? >>> 2) Obtain the intersection point. >>> >>> I browsed through vmath.h but I didn't find anything that could help me. >>> Do you know any macro that could be useful here? >>> Otherwise I will need to make some of my own for this! If so, any ideas >>> on how to approach it? >>> >>> Mario. >>> >>> >>>  >>>  >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> BRLCAD Developer mailing list >>> brlcaddevel@... >>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>> >>> >> > 
From: Daniel Roßberg <danielmrossberg@gm...>  20170913 08:41:42

Hmm, the error seems to be in librtuif which is on your computer only. This lib depends e.g. on libbu but this isn't probably mentioned in librtuif's CMake configuration. Regards, Daniel 20170912 23:39 GMT+02:00 Mario Meissner <mr.rash.boy@...>: > Hello again. > I'm afraid I ran into more problems while compiling. > Rtexample works well but not so for rtweight. > Attached goes my error log. > > I ran svn up and build clean before this. > > Mario. > > On 8 September 2017 at 17:53, Mario Meissner <mr.rash.boy@...> > wrote: > >> I forgot to reply to this yesterday. >> >> r70209 fixed all my problems. >> Build successful on all platforms (with mingw still installed). >> Thank you a lot! >> >> Mario. >> >> On 6 September 2017 at 13:18, Clifford Yapp <cliffyapp@...> wrote: >> >>> On Wed, Sep 6, 2017 at 5:58 AM, Mario Meissner <mr.rash.boy@...> >>> wrote: >>> > I noticed that cmake actually links the AWK entry to my mingw >>> 'gawk.exe' >>> > file, so I was right with my guess. >>> > >>> > After updating to the latest commit available (which is 70194 at the >>> time of >>> > writing) i get this cmake error on windows: >>> > >>> > CMake Error at CMakeLists.txt:369 (_add_library): >>> > Cannot find source file: >>> > >>> > C:/Users/MEISSNERBLANCOJOHANN/Desktop/brlcad/build/src/other >>> /libpng/pngprefix.h >>> >>> Give r70209 a shot. >>> >>> CY >>> >>>  >>>  >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> BRLCAD Developer mailing list >>> brlcaddevel@... >>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>> >> >> > >  >  > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > > 
From: Mario Meissner <mr.rash.boy@gm...>  20170912 21:40:10

Hello again. I'm afraid I ran into more problems while compiling. Rtexample works well but not so for rtweight. Attached goes my error log. I ran svn up and build clean before this. Mario. On 8 September 2017 at 17:53, Mario Meissner <mr.rash.boy@...> wrote: > I forgot to reply to this yesterday. > > r70209 fixed all my problems. > Build successful on all platforms (with mingw still installed). > Thank you a lot! > > Mario. > > On 6 September 2017 at 13:18, Clifford Yapp <cliffyapp@...> wrote: > >> On Wed, Sep 6, 2017 at 5:58 AM, Mario Meissner <mr.rash.boy@...> >> wrote: >> > I noticed that cmake actually links the AWK entry to my mingw 'gawk.exe' >> > file, so I was right with my guess. >> > >> > After updating to the latest commit available (which is 70194 at the >> time of >> > writing) i get this cmake error on windows: >> > >> > CMake Error at CMakeLists.txt:369 (_add_library): >> > Cannot find source file: >> > >> > C:/Users/MEISSNERBLANCOJOHANN/Desktop/brlcad/build/src/other >> /libpng/pngprefix.h >> >> Give r70209 a shot. >> >> CY >> >>  >>  >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> BRLCAD Developer mailing list >> brlcaddevel@... >> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >> > > 
From: Mario Meissner <mr.rash.boy@gm...>  20170908 19:05:13

Peopleee! Here goes today's work. I'm proud to announce the example I modeled a few days ago now works correctly!! Code still contains my debug prints and lots of random 'puts' to know where and why stuff crashes. I feel I will need it in the future so for now it remains. I probably should keep looking for flaws by setting up other examples, and while doing so I should also clean it up a bit since the code grew over 600 lines now, quite difficult to read and understand. Screenshot: https://puu.sh/xuIXk/9626ce2fb6.png Mario. On 8 September 2017 at 19:56, Mario Meissner <mr.rash.boy@...> wrote: > Hi Daniel! > > Thank you a lot for your reply. I was focused on generating the bisector > to intersect two lines, but intersecting the actual plane is much simpler. > I made a little function to intersect a plane with a line (partially taken > from this stackoverflow post > <https://stackoverflow.com/questions/5666222/3dlineplaneintersection>;, > so credits to user ideasman42 > <https://stackoverflow.com/users/432509/ideasman42>;). I am now finishing > of the 'patch' to my code that is supposed to now correctly skip > unnecessary points and create a list with those who's regions we will > actually cross. Code probably tomorrow. > > Mario. > > On 8 September 2017 at 09:35, Daniel Roßberg <danielmrossberg@...> > wrote: > >> Hi Mario, >> >> In 3D space, rectangular to a vector you have a plane and the vector is a >> normal vector of this plane. In this plane are all vectors which are >> perpendicular to your first vector, i.e. the vectors which products with >> your first vector are 0. This gives you a first equation with two >> variables. >> >> Next, you want to intersect the plane with a ray. I.e., one vector from >> your plan has to be a multiple of the ray which gives you another equation. >> >> However, there should be examples in the BRLCAD source code for this. >> E.g., the raytrace of the half primitive is very similar to your problem. >> There, the intersection of a plane, given by a normal vector and a point in >> it, and a ray, given by a start point and a direction, will be computed. >> >> I hope this helps. >> >> >> Regards, >> Daniel >> >> >> >> I'm facing a wall. I need to find a perpendicular vector with the >> condition that it will intersect a third vector. >> Basically, I have the ray and a vector drawn from my current point to the >> previous point. >> I want the perpendicular bisector of that vector to cross my ray, so that >> I can obtain the intersection between the bisector and the ray. >> >> For that I need two things: >> 1) Obtain the perpendicular vector. in 3D there are infinite options, but >> only one will cross the ray. How do I get the one I need? >> 2) Obtain the intersection point. >> >> I browsed through vmath.h but I didn't find anything that could help me. >> Do you know any macro that could be useful here? >> Otherwise I will need to make some of my own for this! If so, any ideas >> on how to approach it? >> >> Mario. >> >> >>  >>  >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> BRLCAD Developer mailing list >> brlcaddevel@... >> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >> >> > 
From: Mario Meissner <mr.rash.boy@gm...>  20170908 17:57:34

Hi Daniel! Thank you a lot for your reply. I was focused on generating the bisector to intersect two lines, but intersecting the actual plane is much simpler. I made a little function to intersect a plane with a line (partially taken from this stackoverflow post <https://stackoverflow.com/questions/5666222/3dlineplaneintersection>;, so credits to user ideasman42 <https://stackoverflow.com/users/432509/ideasman42>;). I am now finishing of the 'patch' to my code that is supposed to now correctly skip unnecessary points and create a list with those who's regions we will actually cross. Code probably tomorrow. Mario. On 8 September 2017 at 09:35, Daniel Roßberg <danielmrossberg@...> wrote: > Hi Mario, > > In 3D space, rectangular to a vector you have a plane and the vector is a > normal vector of this plane. In this plane are all vectors which are > perpendicular to your first vector, i.e. the vectors which products with > your first vector are 0. This gives you a first equation with two > variables. > > Next, you want to intersect the plane with a ray. I.e., one vector from > your plan has to be a multiple of the ray which gives you another equation. > > However, there should be examples in the BRLCAD source code for this. > E.g., the raytrace of the half primitive is very similar to your problem. > There, the intersection of a plane, given by a normal vector and a point in > it, and a ray, given by a start point and a direction, will be computed. > > I hope this helps. > > > Regards, > Daniel > > > > I'm facing a wall. I need to find a perpendicular vector with the > condition that it will intersect a third vector. > Basically, I have the ray and a vector drawn from my current point to the > previous point. > I want the perpendicular bisector of that vector to cross my ray, so that > I can obtain the intersection between the bisector and the ray. > > For that I need two things: > 1) Obtain the perpendicular vector. in 3D there are infinite options, but > only one will cross the ray. How do I get the one I need? > 2) Obtain the intersection point. > > I browsed through vmath.h but I didn't find anything that could help me. > Do you know any macro that could be useful here? > Otherwise I will need to make some of my own for this! If so, any ideas on > how to approach it? > > Mario. > > >  >  > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > > 
From: Mario Meissner <mr.rash.boy@gm...>  20170908 15:54:05

I forgot to reply to this yesterday. r70209 fixed all my problems. Build successful on all platforms (with mingw still installed). Thank you a lot! Mario. On 6 September 2017 at 13:18, Clifford Yapp <cliffyapp@...> wrote: > On Wed, Sep 6, 2017 at 5:58 AM, Mario Meissner <mr.rash.boy@...> > wrote: > > I noticed that cmake actually links the AWK entry to my mingw 'gawk.exe' > > file, so I was right with my guess. > > > > After updating to the latest commit available (which is 70194 at the > time of > > writing) i get this cmake error on windows: > > > > CMake Error at CMakeLists.txt:369 (_add_library): > > Cannot find source file: > > > > C:/Users/MEISSNERBLANCOJOHANN/Desktop/brlcad/build/src/ > other/libpng/pngprefix.h > > Give r70209 a shot. > > CY > >  >  > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > BRLCAD Developer mailing list > brlcaddevel@... > https://lists.sourceforge.net/lists/listinfo/brlcaddevel > 
From: Daniel Roßberg <danielmrossberg@gm...>  20170908 07:35:25

Hi Mario, In 3D space, rectangular to a vector you have a plane and the vector is a normal vector of this plane. In this plane are all vectors which are perpendicular to your first vector, i.e. the vectors which products with your first vector are 0. This gives you a first equation with two variables. Next, you want to intersect the plane with a ray. I.e., one vector from your plan has to be a multiple of the ray which gives you another equation. However, there should be examples in the BRLCAD source code for this. E.g., the raytrace of the half primitive is very similar to your problem. There, the intersection of a plane, given by a normal vector and a point in it, and a ray, given by a start point and a direction, will be computed. I hope this helps. Regards, Daniel I'm facing a wall. I need to find a perpendicular vector with the condition that it will intersect a third vector. Basically, I have the ray and a vector drawn from my current point to the previous point. I want the perpendicular bisector of that vector to cross my ray, so that I can obtain the intersection between the bisector and the ray. For that I need two things: 1) Obtain the perpendicular vector. in 3D there are infinite options, but only one will cross the ray. How do I get the one I need? 2) Obtain the intersection point. I browsed through vmath.h but I didn't find anything that could help me. Do you know any macro that could be useful here? Otherwise I will need to make some of my own for this! If so, any ideas on how to approach it? Mario. 
From: Mario Meissner <mr.rash.boy@gm...>  20170907 16:28:36

Hello everyone! I'm facing a wall. I need to find a perpendicular vector with the condition that it will intersect a third vector. Basically, I have the ray and a vector drawn from my current point to the previous point. I want the perpendicular bisector of that vector to cross my ray, so that I can obtain the intersection between the bisector and the ray. For that I need two things: 1) Obtain the perpendicular vector. in 3D there are infinite options, but only one will cross the ray. How do I get the one I need? 2) Obtain the intersection point. I browsed through vmath.h but I didn't find anything that could help me. Do you know any macro that could be useful here? Otherwise I will need to make some of my own for this! If so, any ideas on how to approach it? Mario. On 6 September 2017 at 18:39, Mario Meissner <mr.rash.boy@...> wrote: > After considering a dozen of different options, I think I may have found > one solution that doesn't involve too much rewriting. However I have this > bugging feeling that it might still not cover 100% of the cases and we will > just continue on and on adding 'fix' code that ends up cluttering up > everything. I seriously hope this is not the case. If it keeps happening we > will need to step back and take a different path. > > Anyway, my thought was that, if we find a skip candidate, we do the > following to check if its a false positive or not: > > Take the current user_point and the previous one, and connect them. Now > draw the perpendicular bisector, and find the intersection with our ray. If > this intersection point has a user_point closer to it than our current > user_point, then it means we will never cross the region of our current > point (because both at the projection point and at this other intersection > point we find closer points than this one). If there is no closer point, so > this means that our current user_point AND the previous user_point are the > closest to the intersection. Thus, once the ray crosses the intersection > point, it will inevitably enter the region of our current user_point. > > Of course, we will also need to check that the intersection lays inside > the limits of the segment, otherwise the region may actually exist but is > too far away (farther than in or out points) and thus we will not reach it. > > We could also make use of these intersections and actually save them to > use them for the boundary calculation phase, replacing my current equation. > We can think about it later. > > I will start working on this unless you think there is a superior approach > to this. > > Mario. > > > > On 6 September 2017 at 17:33, Mario Meissner <mr.rash.boy@...> > wrote: > >> Hey Sean! >> >> I identified the reason why the first projection was skipped when it >> shouldn't have. >> The first projection that my code works on is the last one (with value 9) >> in my diagram because of the nature of the bu_list stack nature. >> >> I approached skipping projections with the following procedure: If we >> find a point that is closer to our projection than its original is, then >> the projection does not need to be made. This seemed logical in our little >> color diagram I made a few weeks back. However if we look at my new test >> case, projection of point 9 happens to fall inside the region 8 (point 8 is >> closer to it than the actual point 9). We DO however need point 9 to be >> projected because we are going to cross the region 9. >> I believe that if we correctly project 9 onto the segment then the result >> will be correct since 9 is heavier and its the last 0.20 we need to reach >> 7.25. These cases should be correctly handled by my later boundary >> calculation formula, so it should suffice to find a better projection >> skipping method. I'm however struggling to find one. >> Do you have any suggestions? >> >> Mario. >> >> On 5 September 2017 at 22:52, Mario Meissner <mr.rash.boy@...> >> wrote: >> >>> Hello again! >>> Now that things are working on the Ubuntu subsystem, I could start with >>> the tests. >>> I came up with this one test that is supposed to cover some of the >>> complicated scenarios, and calculated the result by hand, then threw the >>> points into my voronoi code. >>> >>> We have five points, values 5 to 9, from left to right. Some are 100mm >>> away from the ray, some are 250mm away. Cell regions have been drawn as >>> well, to see how much of each cell the ray sees. >>> We agree that the result should be 7.25, right? >>> >>> Code returns 7.05. Which is off. Not TOO off, but still not accurate. I >>> will need to track this issue down. In fact I already suspect that the >>> problem is the line between 8 and 9. It cuts our ray to the right of point >>> 9, but I don't think I properly took care of this case in my code yet. >>> It also said its skipping two projections when it should only be >>> skipping one. >>> >>> Mario. >>> >>> On 2 September 2017 at 10:58, Mario Meissner <mr.rash.boy@...> >>> wrote: >>> >>>> Hi Sean. >>>> It's the same test as in my third email from this thread. I added one >>>> extra point that should be more far away and thus be ignored. >>>> I'll perform more thorough tests once I'm set up here, but I have no >>>> scanner to make diagrams. I'll do my best to represent it through text. >>>> Mario. >>>> >>>> On Sep 1, 2017 09:58, "Christopher Sean Morrison" <brlcad@...> >>>> wrote: >>>> >>>>> >>>>> On Aug 30, 2017, at 6:38 AM, Mario Meissner <mr.rash.boy@...> >>>>> wrote: >>>>> >>>>> Implemented the mentioned changes and fixed projections not being >>>>> skipped correctly when they should. Unless my next tests fail, I think this >>>>> version is quite stable. >>>>> >>>>> Code attached. >>>>> >>>>> In this test: >>>>> https://puu.sh/xn8Hh/0d5c617dfe.png >>>>> >>>>> >>>>> Can you diagram out what that test is supposed to look like? Not sure >>>>> I can quickly follow what the debug print statements line up with without >>>>> some tedious reconstruction. >>>>> >>>>> The reason why I worked on projections is because you told me to do so: >>>>>>>> >>>>>>>> >>>>>>> >>>>> The devil is always in the details is it not? :) Projections >>>>> are/were fine for 2 points but then it simply didn’t generalize without >>>>> needing additional consideration. I think it still holds for any 2 points >>>>> piecewise. The issue is the Npoint generalization, which you did find an >>>>> interesting case that required adjustment. That’s a good thing! >>>>> >>>>> >>>>> Not the distance between points, but distance to their transition >>>>>>>>> vectors. From the prior email, the way this should fully generalize can >>>>>>>>> be handled by projecting points onto the ray, and projecting any transition >>>>>>>>> vectors onto the ray. Then for a given ray, it can fully handle just about >>>>>>>>> any transition type. >>>>>>>>> >>>>>>>>> To see how this will work, it will likely be necessary to redo >>>>>>>>> rtexample and get 2points working without any vectors. You project each >>>>>>>>> point onto the ray. >>>>>>>>> >>>>>>>>> ptA ptB >>>>>>>>>   >>>>>>>>> IN v v OUT >>>>>>>>> ray optA'ptB'o >>>>>>>>> >>>>>>>>> Density from IN to ptA’ is density(ptA). >>>>>>>>> Density from ptB’ to OUT is density(ptB). >>>>>>>>> Density from ptA’ to ptB’ is density(ptA) until the midpoint >>>>>>>>> between ptA’ and ptB’. Thus the section’s average density would be >>>>>>>>> density(ptA)/2 + density(ptB)/2But >>>>>>>>> >>>>>>>> >>>>>>>> But I now realize as well that taking the midpoint between >>>>>>>> projections does not give us the actual boundary between the polygons. >>>>>>>> >>>>>>> >>>>> The midpoint was specific to the ptA/ptB case setup, for >>>>> understanding, not to suggest it always works out that way as the midpoint. >>>>> >>>>> >>>>> We could work with the mesh like you mention, or we could do a slight >>>>>>>> modification to the current code to compute the actual boundaries while >>>>>>>> walking through the points (probably our already available projections, >>>>>>>> we'll see). It's probably a simple trigonometry problem, and I'll try to >>>>>>>> come up with the operation we need to do to obtain the boundaries in a >>>>>>>> segment. >>>>>>>> >>>>>>> >>>>> If you do/did sort this out, I absolutely agree that it’d be a >>>>> superior solution. >>>>> >>>>> Cheers! >>>>> Sean >>>>> >>>>> >>>>> >>>>> >>>>>  >>>>>  >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> BRLCAD Developer mailing list >>>>> brlcaddevel@... >>>>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>>>> >>>>> >>> >> > 
From: Mario Meissner <mr.rash.boy@gm...>  20170906 16:40:11

After considering a dozen of different options, I think I may have found one solution that doesn't involve too much rewriting. However I have this bugging feeling that it might still not cover 100% of the cases and we will just continue on and on adding 'fix' code that ends up cluttering up everything. I seriously hope this is not the case. If it keeps happening we will need to step back and take a different path. Anyway, my thought was that, if we find a skip candidate, we do the following to check if its a false positive or not: Take the current user_point and the previous one, and connect them. Now draw the perpendicular bisector, and find the intersection with our ray. If this intersection point has a user_point closer to it than our current user_point, then it means we will never cross the region of our current point (because both at the projection point and at this other intersection point we find closer points than this one). If there is no closer point, so this means that our current user_point AND the previous user_point are the closest to the intersection. Thus, once the ray crosses the intersection point, it will inevitably enter the region of our current user_point. Of course, we will also need to check that the intersection lays inside the limits of the segment, otherwise the region may actually exist but is too far away (farther than in or out points) and thus we will not reach it. We could also make use of these intersections and actually save them to use them for the boundary calculation phase, replacing my current equation. We can think about it later. I will start working on this unless you think there is a superior approach to this. Mario. On 6 September 2017 at 17:33, Mario Meissner <mr.rash.boy@...> wrote: > Hey Sean! > > I identified the reason why the first projection was skipped when it > shouldn't have. > The first projection that my code works on is the last one (with value 9) > in my diagram because of the nature of the bu_list stack nature. > > I approached skipping projections with the following procedure: If we find > a point that is closer to our projection than its original is, then the > projection does not need to be made. This seemed logical in our little > color diagram I made a few weeks back. However if we look at my new test > case, projection of point 9 happens to fall inside the region 8 (point 8 is > closer to it than the actual point 9). We DO however need point 9 to be > projected because we are going to cross the region 9. > I believe that if we correctly project 9 onto the segment then the result > will be correct since 9 is heavier and its the last 0.20 we need to reach > 7.25. These cases should be correctly handled by my later boundary > calculation formula, so it should suffice to find a better projection > skipping method. I'm however struggling to find one. > Do you have any suggestions? > > Mario. > > On 5 September 2017 at 22:52, Mario Meissner <mr.rash.boy@...> > wrote: > >> Hello again! >> Now that things are working on the Ubuntu subsystem, I could start with >> the tests. >> I came up with this one test that is supposed to cover some of the >> complicated scenarios, and calculated the result by hand, then threw the >> points into my voronoi code. >> >> We have five points, values 5 to 9, from left to right. Some are 100mm >> away from the ray, some are 250mm away. Cell regions have been drawn as >> well, to see how much of each cell the ray sees. >> We agree that the result should be 7.25, right? >> >> Code returns 7.05. Which is off. Not TOO off, but still not accurate. I >> will need to track this issue down. In fact I already suspect that the >> problem is the line between 8 and 9. It cuts our ray to the right of point >> 9, but I don't think I properly took care of this case in my code yet. >> It also said its skipping two projections when it should only be skipping >> one. >> >> Mario. >> >> On 2 September 2017 at 10:58, Mario Meissner <mr.rash.boy@...> >> wrote: >> >>> Hi Sean. >>> It's the same test as in my third email from this thread. I added one >>> extra point that should be more far away and thus be ignored. >>> I'll perform more thorough tests once I'm set up here, but I have no >>> scanner to make diagrams. I'll do my best to represent it through text. >>> Mario. >>> >>> On Sep 1, 2017 09:58, "Christopher Sean Morrison" <brlcad@...> >>> wrote: >>> >>>> >>>> On Aug 30, 2017, at 6:38 AM, Mario Meissner <mr.rash.boy@...> >>>> wrote: >>>> >>>> Implemented the mentioned changes and fixed projections not being >>>> skipped correctly when they should. Unless my next tests fail, I think this >>>> version is quite stable. >>>> >>>> Code attached. >>>> >>>> In this test: >>>> https://puu.sh/xn8Hh/0d5c617dfe.png >>>> >>>> >>>> Can you diagram out what that test is supposed to look like? Not sure >>>> I can quickly follow what the debug print statements line up with without >>>> some tedious reconstruction. >>>> >>>> The reason why I worked on projections is because you told me to do so: >>>>>>> >>>>>>> >>>>>> >>>> The devil is always in the details is it not? :) Projections are/were >>>> fine for 2 points but then it simply didn’t generalize without needing >>>> additional consideration. I think it still holds for any 2 points >>>> piecewise. The issue is the Npoint generalization, which you did find an >>>> interesting case that required adjustment. That’s a good thing! >>>> >>>> >>>> Not the distance between points, but distance to their transition >>>>>>>> vectors. From the prior email, the way this should fully generalize can >>>>>>>> be handled by projecting points onto the ray, and projecting any transition >>>>>>>> vectors onto the ray. Then for a given ray, it can fully handle just about >>>>>>>> any transition type. >>>>>>>> >>>>>>>> To see how this will work, it will likely be necessary to redo >>>>>>>> rtexample and get 2points working without any vectors. You project each >>>>>>>> point onto the ray. >>>>>>>> >>>>>>>> ptA ptB >>>>>>>>   >>>>>>>> IN v v OUT >>>>>>>> ray optA'ptB'o >>>>>>>> >>>>>>>> Density from IN to ptA’ is density(ptA). >>>>>>>> Density from ptB’ to OUT is density(ptB). >>>>>>>> Density from ptA’ to ptB’ is density(ptA) until the midpoint >>>>>>>> between ptA’ and ptB’. Thus the section’s average density would be >>>>>>>> density(ptA)/2 + density(ptB)/2But >>>>>>>> >>>>>>> >>>>>>> But I now realize as well that taking the midpoint between >>>>>>> projections does not give us the actual boundary between the polygons. >>>>>>> >>>>>> >>>> The midpoint was specific to the ptA/ptB case setup, for understanding, >>>> not to suggest it always works out that way as the midpoint. >>>> >>>> >>>> We could work with the mesh like you mention, or we could do a slight >>>>>>> modification to the current code to compute the actual boundaries while >>>>>>> walking through the points (probably our already available projections, >>>>>>> we'll see). It's probably a simple trigonometry problem, and I'll try to >>>>>>> come up with the operation we need to do to obtain the boundaries in a >>>>>>> segment. >>>>>>> >>>>>> >>>> If you do/did sort this out, I absolutely agree that it’d be a superior >>>> solution. >>>> >>>> Cheers! >>>> Sean >>>> >>>> >>>> >>>> >>>>  >>>>  >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> BRLCAD Developer mailing list >>>> brlcaddevel@... >>>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>>> >>>> >> > 
From: Mario Meissner <mr.rash.boy@gm...>  20170906 15:33:54

Hey Sean! I identified the reason why the first projection was skipped when it shouldn't have. The first projection that my code works on is the last one (with value 9) in my diagram because of the nature of the bu_list stack nature. I approached skipping projections with the following procedure: If we find a point that is closer to our projection than its original is, then the projection does not need to be made. This seemed logical in our little color diagram I made a few weeks back. However if we look at my new test case, projection of point 9 happens to fall inside the region 8 (point 8 is closer to it than the actual point 9). We DO however need point 9 to be projected because we are going to cross the region 9. I believe that if we correctly project 9 onto the segment then the result will be correct since 9 is heavier and its the last 0.20 we need to reach 7.25. These cases should be correctly handled by my later boundary calculation formula, so it should suffice to find a better projection skipping method. I'm however struggling to find one. Do you have any suggestions? Mario. On 5 September 2017 at 22:52, Mario Meissner <mr.rash.boy@...> wrote: > Hello again! > Now that things are working on the Ubuntu subsystem, I could start with > the tests. > I came up with this one test that is supposed to cover some of the > complicated scenarios, and calculated the result by hand, then threw the > points into my voronoi code. > > We have five points, values 5 to 9, from left to right. Some are 100mm > away from the ray, some are 250mm away. Cell regions have been drawn as > well, to see how much of each cell the ray sees. > We agree that the result should be 7.25, right? > > Code returns 7.05. Which is off. Not TOO off, but still not accurate. I > will need to track this issue down. In fact I already suspect that the > problem is the line between 8 and 9. It cuts our ray to the right of point > 9, but I don't think I properly took care of this case in my code yet. > It also said its skipping two projections when it should only be skipping > one. > > Mario. > > On 2 September 2017 at 10:58, Mario Meissner <mr.rash.boy@...> > wrote: > >> Hi Sean. >> It's the same test as in my third email from this thread. I added one >> extra point that should be more far away and thus be ignored. >> I'll perform more thorough tests once I'm set up here, but I have no >> scanner to make diagrams. I'll do my best to represent it through text. >> Mario. >> >> On Sep 1, 2017 09:58, "Christopher Sean Morrison" <brlcad@...> wrote: >> >>> >>> On Aug 30, 2017, at 6:38 AM, Mario Meissner <mr.rash.boy@...> >>> wrote: >>> >>> Implemented the mentioned changes and fixed projections not being >>> skipped correctly when they should. Unless my next tests fail, I think this >>> version is quite stable. >>> >>> Code attached. >>> >>> In this test: >>> https://puu.sh/xn8Hh/0d5c617dfe.png >>> >>> >>> Can you diagram out what that test is supposed to look like? Not sure I >>> can quickly follow what the debug print statements line up with without >>> some tedious reconstruction. >>> >>> The reason why I worked on projections is because you told me to do so: >>>>>> >>>>> >>> The devil is always in the details is it not? :) Projections are/were >>> fine for 2 points but then it simply didn’t generalize without needing >>> additional consideration. I think it still holds for any 2 points >>> piecewise. The issue is the Npoint generalization, which you did find an >>> interesting case that required adjustment. That’s a good thing! >>> >>> >>> Not the distance between points, but distance to their transition >>>>>>> vectors. From the prior email, the way this should fully generalize can >>>>>>> be handled by projecting points onto the ray, and projecting any transition >>>>>>> vectors onto the ray. Then for a given ray, it can fully handle just about >>>>>>> any transition type. >>>>>>> >>>>>>> To see how this will work, it will likely be necessary to redo >>>>>>> rtexample and get 2points working without any vectors. You project each >>>>>>> point onto the ray. >>>>>>> >>>>>>> ptA ptB >>>>>>>   >>>>>>> IN v v OUT >>>>>>> ray optA'ptB'o >>>>>>> >>>>>>> Density from IN to ptA’ is density(ptA). >>>>>>> Density from ptB’ to OUT is density(ptB). >>>>>>> Density from ptA’ to ptB’ is density(ptA) until the midpoint between >>>>>>> ptA’ and ptB’. Thus the section’s average density would be density(ptA)/2 >>>>>>> + density(ptB)/2But >>>>>>> >>>>>> >>>>>> But I now realize as well that taking the midpoint between >>>>>> projections does not give us the actual boundary between the polygons. >>>>>> >>>>> >>> The midpoint was specific to the ptA/ptB case setup, for understanding, >>> not to suggest it always works out that way as the midpoint. >>> >>> >>> We could work with the mesh like you mention, or we could do a slight >>>>>> modification to the current code to compute the actual boundaries while >>>>>> walking through the points (probably our already available projections, >>>>>> we'll see). It's probably a simple trigonometry problem, and I'll try to >>>>>> come up with the operation we need to do to obtain the boundaries in a >>>>>> segment. >>>>>> >>>>> >>> If you do/did sort this out, I absolutely agree that it’d be a superior >>> solution. >>> >>> Cheers! >>> Sean >>> >>> >>> >>> >>>  >>>  >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> BRLCAD Developer mailing list >>> brlcaddevel@... >>> https://lists.sourceforge.net/lists/listinfo/brlcaddevel >>> >>> > 