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}
(25) 
_{Oct}

_{Nov}

_{Dec}

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 >>> >>> > 
From: Clifford Yapp <cliffyapp@gm...>  20170906 11:18:13

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 
From: Mario Meissner <mr.rash.boy@gm...>  20170906 09:58:09

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 Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx Call Stack (most recent call first): src/other/libpng/CMakeLists.txt:370 (add_library) CMake Error: CMake can not determine linker language for target: png CMake Error: CMake can not determine linker language for target: png_static Interestingly enough on the Ubuntu subsystem it works just fine. Mario. On Sep 4, 2017 5:13 PM, "Mario Meissner" <mr.rash.boy@...> wrote: > Interesting. May I ask in which area of Germany? >> > > In München! > > > Interesting. That looks like it is trying to execute the awk script >> in libpng's build, but that shouldn't happen on Windows normally... >> Do you have some Windows version of awk installed? > > > So apparently I do. > https://puu.sh/xrmjC/e8436e45e2.png > > It might be MinGW? I don't know what it is, can't recall having installed > anything like this so It's probably part of the MingW libraries. Shall I > try uninstalling mingw? > > For now I managed to compile on the Ubuntu subsystem for Windows. I cannot > run things like mged because the subsystem is lacking GUI libraries. > However I can run what concerns me, which is rtexample and rtweight. I can > run mged on a windows release of brlcad instead. > > Hope to be able to deliver more results tomorrow. > Mario. > 
From: Mario Meissner <mr.rash.boy@gm...>  20170905 20:53:15

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: Clifford Yapp <cliffyapp@gm...>  20170904 20:01:30

On Mon, Sep 4, 2017 at 11:13 AM, Mario Meissner <mr.rash.boy@...> wrote: > So apparently I do. > https://puu.sh/xrmjC/e8436e45e2.png > > It might be MinGW? I don't know what it is, can't recall having installed > anything like this so It's probably part of the MingW libraries. Shall I try > uninstalling mingw? See if commit r70188 avoids the problem for you. Cliff 
From: Mario Meissner <mr.rash.boy@gm...>  20170904 15:14:29

> > Interesting. May I ask in which area of Germany? > In München! Interesting. That looks like it is trying to execute the awk script > in libpng's build, but that shouldn't happen on Windows normally... > Do you have some Windows version of awk installed? So apparently I do. https://puu.sh/xrmjC/e8436e45e2.png It might be MinGW? I don't know what it is, can't recall having installed anything like this so It's probably part of the MingW libraries. Shall I try uninstalling mingw? For now I managed to compile on the Ubuntu subsystem for Windows. I cannot run things like mged because the subsystem is lacking GUI libraries. However I can run what concerns me, which is rtexample and rtweight. I can run mged on a windows release of brlcad instead. Hope to be able to deliver more results tomorrow. Mario. 
From: Clifford Yapp <cliffyapp@gm...>  20170903 22:43:34

On Sun, Sep 3, 2017 at 3:04 PM, Daniel Roßberg <danielmrossberg@...> wrote: > There is already an error in CMake: > 3>Generating pnglibconf.c 3>options.awk: bad line (10): com 3>CMake Error at > scripts/gensrc.cmake:68 (message): 3> Failed to generate pnglibconf.tf5 Interesting. That looks like it is trying to execute the awk script in libpng's build, but that shouldn't happen on Windows normally... Do you have some Windows version of awk installed? CY 
From: Daniel Roßberg <danielmrossberg@gm...>  20170903 19:04:33

Hi Mario, As you may have seen in my previous emails, I moved to Germany on the 1st of this month. Interesting. May I ask in which area of Germany? I am facing an issue with Visual Studio when I try to build the solution. For now, and since my laptop is not as quick as my desktop pc was, I want to build only the rtexample solution. I downloaded the trunk, ran cmake with VS as a target, loaded the project and hit Build > rtexample Some projects get to compile but there are 5 that throw an error. Here is the complete log: https://puu.sh/xqAwb/cf26a811c4.txt This line might contain part of the solution: LINK : fatal error LNK1181: cannot open input file '..\..\Release\lib\libfb.lib' No such file can be found in that folder. There is already an error in CMake: 3>Generating pnglibconf.c 3>options.awk: bad line (10): com 3>CMake Error at scripts/gensrc.cmake:68 (message): 3> Failed to generate pnglibconf.tf5 The other errors seem to be caused by this one. But, I can't say why because I've no computer at hand. Regards, Daniel 
From: Mario Meissner <mr.rash.boy@gm...>  20170903 16:26:26

Hello everyone. As you may have seen in my previous emails, I moved to Germany on the 1st of this month. I am finally settled in my new place and am now setting up my working environment on my laptop. I am facing an issue with Visual Studio when I try to build the solution. For now, and since my laptop is not as quick as my desktop pc was, I want to build only the rtexample solution. I downloaded the trunk, ran cmake with VS as a target, loaded the project and hit Build > rtexample Some projects get to compile but there are 5 that throw an error. Here is the complete log: https://puu.sh/xqAwb/cf26a811c4.txt This line might contain part of the solution: LINK : fatal error LNK1181: cannot open input file '..\..\Release\lib\libfb.lib' No such file can be found in that folder. I'll look for alternatives on how to compile it on windows since I'm fine with a lightweight editor. Would be nice to know the reason why this thing doesn't work though, since it worked perfectly fine on my desktop pc. Thank you. Mario. 
From: Mario Meissner <mr.rash.boy@gm...>  20170902 08:59:07

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: Shubham Rathore <shubhamrathore1947@gm...>  20170902 05:45:56

On Fri, 1 Sep 2017 at 11:03 PM, Christopher Sean Morrison <brlcad@...> wrote: > Would anyone like an additional GSoC tshirt? Or will be going/presenting > at an event or have university connection where you might want to give a > couple tshirts away? > Hi, Yes it would be great, if you could arrange for a couple of them. It would be a great way to promote open source in our university. Thanks, Shubham Rathore(:gabbar1947) > > 
From: Daniel Roßberg <danielmrossberg@gm...>  20170901 17:58:16

Tshirts size M/female are always welcome. My daughter likes them. Regards, Daniel Am 01.09.2017 7:32 nachm. schrieb "Christopher Sean Morrison" < brlcad@...>: > Would anyone like an additional GSoC tshirt? Or will be going/presenting > at an event or have university connection where you might want to give a > couple tshirts away? > > Cheers! > Sean > >  > You received this message because you are subscribed to the Google Groups > "Google Summer of CAx" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to gsocax+unsubscribe@... > To post to this group, send email to gsocax@... > To view this discussion on the web visit https://groups.google.com/d/ > msgid/gsocax/44DF9A98BFD04AE0933DC841C882336B%40mac.com. > For more options, visit https://groups.google.com/d/optout. > 
From: Christopher Sean Morrison <brlcad@ma...>  20170901 17:32:56

Would anyone like an additional GSoC tshirt? Or will be going/presenting at an event or have university connection where you might want to give a couple tshirts away? Cheers! Sean 
From: Christopher Sean Morrison <brlcad@ma...>  20170901 07:58:44

> 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 <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 