| 00:41.15 | *** join/#brlcad aodzalkgykrzrriw (~armin@dslb-088-066-131-231.088.066.pools.vodafone-ip.de) |
| 03:00.17 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 03:58.39 | *** join/#brlcad amarjeet (~Amarjeet@101.211.218.19) |
| 04:10.36 | *** join/#brlcad amarjeet (~Amarjeet@101.211.218.19) |
| 04:37.44 | *** join/#brlcad amarjeet (~Amarjeet@101.211.218.19) |
| 04:53.21 | *** join/#brlcad merzo (~merzo@62-51-133-95.pool.ukrtel.net) |
| 05:09.03 | Notify | 03BRL-CAD Wiki:Mandeeps708 * 9829 /wiki/User:Mandeeps708/GSoC16/logs: /* logs*/ |
| 05:19.16 | *** join/#brlcad amarjeet (~Amarjeet@101.211.218.19) |
| 05:33.05 | Notify | 03BRL-CAD Wiki:Mandeeps708 * 9830 /wiki/User:Mandeeps708/GSoC16/logs: /* Project Details */ |
| 05:34.24 | nmz787_ | brlcad: hmm, well I don't think the slicing is terribly slow... I mean, for the speed and ease of Python coding, the speed was fine for slicing. NIRT seems like it doesn't benefit from parallel jobs, at least on my machine. I thought about whether it was some kind of file lock... but I haven't tried copying the g-file a few times and running a job on each file in parallel. |
| 05:37.15 | nmz787_ | brlcad: what is more interesting and concerning from your response is actually "or at least 0.0005mm for computational stability"... why is 5 microns the limit for computational stability??? I mean, have I been mislead by front-page advertising i.e. last sentence here: http://brlcad.org/wiki/Overview#What_is_BRL-CAD.3F |
| 05:37.57 | nmz787_ | brlcad: I have been banking on "BRL-CAD users can accurately model objects on scales ranging from the subatomic through the galactic and get "all the details, all the time."" for a few years |
| 06:42.00 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 07:06.55 | *** join/#brlcad maths22 (~maths22@unaffiliated/maths22) |
| 07:15.18 | *** join/#brlcad tandoorichick (b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
| 07:38.53 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 07:56.03 | *** join/#brlcad teepee] (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 08:25.55 | *** join/#brlcad Caterpillar (~caterpill@unaffiliated/caterpillar) |
| 08:27.08 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 08:32.06 | *** join/#brlcad merzo (~merzo@user-94-45-58-141.skif.com.ua) |
| 08:49.12 | *** join/#brlcad d_rossberg (~rossberg@104.225.5.10) |
| 09:12.30 | tandoorichick | d_rossberg: could you please give suggestions on my final work product? |
| 10:27.08 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 10:35.19 | d_rossberg | tandoorichick: okay, i assumed that you already completed your evaluation for Google |
| 10:37.00 | tandoorichick | d_rossberg: i've made a blog post here: https://tandoorichickblog.wordpress.com/2016/08/23/gsoc16workproduct/ |
| 10:40.02 | d_rossberg | is this essentially the same as the google doc from your e-mail? |
| 10:40.11 | tandoorichick | Yes it is |
| 10:40.33 | tandoorichick | Since they had mentioned it needed to be at a stable location, i published it in a blog.. |
| 10:42.16 | tandoorichick | also, could you advise me on the intersection of lines issue i had mailed you about? |
| 10:43.35 | tandoorichick | when there are thin triangles, no feature pairs are identified sometimes because wrong intersection of lines is detected |
| 10:49.28 | d_rossberg | regarding your blog post: the only thing i would recommend to add is to emphasize your final patch (with a direkt link to it) |
| 10:52.46 | d_rossberg | regarding the thin triables: the first thing which came into my mind when you talked about triangles with a thickness on the edge of the precision was: remove them! |
| 10:53.16 | d_rossberg | is this feasible? |
| 10:55.37 | tandoorichick | i will add a direct link to my patch, maybe put it up on g drive? |
| 10:55.46 | tandoorichick | i dont understand your comment about the thin triangles.. |
| 10:57.16 | d_rossberg | you get numerical/precision issues with the thin triangles, right? |
| 10:58.40 | tandoorichick | yeah.. |
| 10:59.41 | d_rossberg | so, they must be very thin, with a thickness close to the numerical precision? |
| 11:00.14 | tandoorichick | yeah |
| 11:01.15 | d_rossberg | with almost no area => remove them? |
| 11:02.08 | d_rossberg | maybe with moving its point in the middle on the long edge |
| 11:02.29 | tandoorichick | yes i am doing that.. |
| 11:03.05 | tandoorichick | when it is a quadrilateral, or has more vertices what do we do then? |
| 11:03.43 | tandoorichick | essentially all the vertices in the gap need to be healed in one go, because they wont be visited again. |
| 11:04.13 | tandoorichick | so with gaps with more number of vertices itm ight tricky |
| 11:04.36 | tandoorichick | because we wouldnt know which vertex to choose to heal first such that the whole mesh gets healed |
| 11:05.23 | tandoorichick | is what i am saying true? |
| 11:06.00 | tandoorichick | (also, i have included my final patch in the blog) |
| 11:15.40 | d_rossberg | what i once did in a (maybe?) similar case was a kind of preprocessing: i unified nearby vertices; this could be extended by a test for vertices on (or near) edges |
| 11:16.02 | d_rossberg | this should give us a mesh with "wide open" holes |
| 11:16.13 | tandoorichick | oh okay.. |
| 11:16.19 | tandoorichick | yes that seems fair enough |
| 11:16.57 | tandoorichick | but then again until when would be unify the vertices? |
| 11:17.07 | tandoorichick | until it is a thin triangle or until it is a whide hole? |
| 11:17.15 | tandoorichick | wide* |
| 11:17.34 | tandoorichick | because both are possible right? |
| 11:19.58 | d_rossberg | there shouldn't be any thin triangle any more after this procedure: there are no two vertices closer to each othes as <precision> and no vertex is closer to any edge than <precision> |
| 11:21.22 | tandoorichick | so essentially one unification would be enough? |
| 11:25.03 | *** join/#brlcad merzo (~merzo@92.60.189.225) |
| 11:28.48 | d_rossberg | one unification of vertices, one moving of vertices onto nearby edges, and maybe an additional unification of vertices (plus fixing affected edges and faces) |
| 11:34.12 | tandoorichick | the thing is then, the heal command might have to be called multiple times as the algo does not revisit vertices.. |
| 11:36.09 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 11:36.38 | d_rossberg | the filtering i described here is something which would be done before the creation of the DCEL |
| 11:37.52 | tandoorichick | oh.. |
| 11:38.24 | tandoorichick | but the thin triangles that i described arise after one round of healing.. |
| 11:42.09 | d_rossberg | but in this case: don't create thin triangles? if the triangle you would create is thin something is wrong |
| 11:42.59 | *** join/#brlcad amarjeet (~Amarjeet@101.211.244.81) |
| 11:45.46 | tandoorichick | the thing is, with the broken sphere: say a vertex contraction happens. after this, for the vertex next to the vertex just healed, the feature edge becomes the edge that has been newly added, whose dist measure is just slightly lesser than that of the previous feature (which was a vertex). this is what results in thin triangles.. |
| 12:26.20 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 12:37.36 | *** join/#brlcad amarjeet (~Amarjeet@101.211.244.81) |
| 12:39.03 | d_rossberg | when do you know that the triangle is thin? |
| 12:56.23 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 13:19.34 | *** join/#brlcad amarjeet (~Amarjeet@101.211.244.81) |
| 13:22.23 | tandoorichick | d_rossberg: algorithmically i'm not sure, i just saw from the return value of the orientation function, and from the visualization |
| 13:29.32 | *** join/#brlcad amarjeet (~Amarjeet@101.211.244.81) |
| 13:29.37 | d_rossberg | maybe there is a (small) consistency check necesary after each healing step to make it watertight |
| 13:30.35 | tandoorichick | okay, yeah that seems plausible.. |
| 13:32.34 | tandoorichick | this step would involve the unification of the close vertices? |
| 13:33.20 | tandoorichick | and what do i take as the tolerance for that |
| 13:36.57 | d_rossberg | i would recommend a machine or double dependent value |
| 13:37.20 | d_rossberg | i'm using 5.3e-11 for 3d points |
| 13:37.34 | tandoorichick | hmmm okay cool.. |
| 13:37.42 | tandoorichick | i will try to finish this.. |
| 13:38.02 | d_rossberg | this is (3. * std::numeric_limits<double>::epsilon()^2)^1/3 |
| 13:38.44 | tandoorichick | ok cool |
| 13:39.08 | d_rossberg | and with absMax = std::max(std::max(fabs(value1), fabs(value2)), 1.) |
| 13:39.37 | d_rossberg | test for fabs(value1 - value2) < (absMax * tolerance) |
| 13:43.05 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:50.19 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 13:51.21 | tandoorichick | d_rossberg: actually the vertices of the triangular hole are v1: (-12.976259378703389, 1.4414630845285288, 995.78376342420256), v2: (587.78601884841919, 65.293997526168823, 809.01700258255005) and v3: (0, 0, 1000) |
| 13:51.39 | tandoorichick | v3 is to be projected onto the edge v1v2 |
| 13:51.49 | tandoorichick | the vertices are not that close enough right? |
| 13:54.09 | *** join/#brlcad amarjeet (~Amarjeet@101.211.244.81) |
| 13:58.48 | tandoorichick | also what are value1 and value2 wrt the 3d points? |
| 14:03.43 | *** join/#brlcad amarjeet (~Amarjeet@101.211.244.81) |
| 14:15.09 | *** join/#brlcad yorik (~yorik@187.35.8.25) |
| 14:16.06 | *** join/#brlcad amarjeet (~Amarjeet@101.211.212.162) |
| 14:17.49 | d_rossberg | replace fabs(value1 - value2) with the distance of the two points |
| 14:19.15 | d_rossberg | your points really aren't so close ... |
| 14:19.33 | tandoorichick | yeah... |
| 14:19.53 | tandoorichick | basically the error pops up in the orientation function |
| 14:20.32 | tandoorichick | when the the two points v1, v2 and the orthogonal projection of v3 onto v1v2 are passed for orientation check, |
| 14:20.37 | tandoorichick | collinearity isnot returned |
| 14:20.41 | tandoorichick | im not sure why.. |
| 14:21.08 | tandoorichick | this is the basis of all error pertaining to thin triangles.. |
| 14:21.24 | tandoorichick | any opinions as to why this might be happening? |
| 14:27.20 | *** join/#brlcad amarjeet_ (~Amarjeet@101.211.233.74) |
| 14:42.01 | tandoorichick | d_rossberg: alternatively, i could try this. im currently ignoreing edges that are incident on a vertex for the candidate of closest edge. if this were not the case, with thin triangles, the two closest vertices would be unified. this could work. but im not sure i can complete it before the gsoc deadline. but definitely before the showcase.. |
| 14:43.57 | d_rossberg | your tolerance is very low |
| 14:44.15 | d_rossberg | try 5.3e-11 ? |
| 14:45.22 | d_rossberg | keep in mind what std::numeric_limits<double>::epsilon() means |
| 14:47.04 | d_rossberg | i.e. "< absMax * tolerance" |
| 14:49.39 | tandoorichick | i dont exactly get what absMax is |
| 14:53.27 | tandoorichick | i set my tolerance to the value you suggested |
| 14:53.30 | d_rossberg | okay, you can ignore this if one value is 0 |
| 14:54.12 | d_rossberg | i.e. if you test for "value = 0?" |
| 14:54.58 | tandoorichick | i set it to 5.3e-11 and tried.. the issue persists.. |
| 15:01.32 | d_rossberg | there seams to be a more general issue with the orientation function: if the 3 points are in the x=0 plane it returns collinear ... |
| 15:03.02 | tandoorichick | right... |
| 15:04.49 | tandoorichick | id been very confused as to how to implement the orientation function, guess i didn't think it through.. |
| 15:04.58 | tandoorichick | what may be the right implementation of it? |
| 15:05.02 | d_rossberg | so: two points define a vector, when is the third one clockwise and when counterclockwise? |
| 15:05.47 | tandoorichick | clockwise if the point is to the "right" of it and CCw if left? |
| 15:06.48 | d_rossberg | you mean in the projection to the xy plane? |
| 15:07.29 | tandoorichick | not quite |
| 15:08.22 | tandoorichick | i mean to say if i was at point 1, and im looking towards point 2, if to the right of my line of sight, then CW, if left ccw |
| 15:08.50 | tandoorichick | if point 3 is to the right of my line of sight* |
| 15:10.57 | tandoorichick | how about finding the cross product of the vectors AB, AC when the three points in order are A, B, C? |
| 15:11.36 | d_rossberg | "right" and "left" devide the space in two parts, the partition plane is described by the vector from 1 to 2 and a third point: which? |
| 15:13.10 | tandoorichick | ok yeah it is the projection in the xy plane.. |
| 15:14.18 | d_rossberg | the cross product gives you a vector orthogonal to your triangle |
| 15:15.11 | tandoorichick | hmmmm |
| 15:15.23 | d_rossberg | i'll rethink it when i review your code |
| 15:15.32 | tandoorichick | how do we determine the orientation? |
| 15:15.40 | tandoorichick | okay.. |
| 15:15.52 | tandoorichick | so do i submit off this code? |
| 15:16.41 | tandoorichick | i would like to finish fixing the orientation code.. |
| 15:16.47 | tandoorichick | any suggestions? |
| 15:20.01 | d_rossberg | with your understanding of orientation you will likely go into trouble if you go around something, the right and left will flip, e.g. with a sphere |
| 15:20.37 | tandoorichick | hmmmm |
| 15:21.08 | tandoorichick | what could i do then? |
| 15:22.56 | d_rossberg | the question is: for what do you need it? only for checkIfIntersectsInterior() and checkIfCollinear()? |
| 15:24.42 | tandoorichick | as of now, the init functions also use it.. |
| 15:26.41 | tandoorichick | setting the start edge for a face, and the incident face ref for an edge.. |
| 15:27.34 | tandoorichick | and also at one point if the square is a hole, to check if it is indeed a hole and not the external boundary |
| 15:27.41 | *** join/#brlcad amarjeet (~Amarjeet@101.211.249.120) |
| 15:30.19 | d_rossberg | as i already mentioned: determine the orientation from the nearby triangles |
| 15:31.20 | d_rossberg | what is really inside and outside isn't important, but it has to be consistent for the whole mesh |
| 15:31.32 | tandoorichick | yeah i got that.. |
| 15:32.05 | tandoorichick | thought i will look into this more pressing issue of line intersections before i looked into that bigger issue.. |
| 15:34.20 | d_rossberg | okay :) |
| 15:53.10 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 15:54.20 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 16:13.07 | *** join/#brlcad ickby (~stefan@x5d847777.dyn.telefonica.de) |
| 16:36.16 | *** join/#brlcad ickby (~stefan@x5d847777.dyn.telefonica.de) |
| 16:37.10 | *** join/#brlcad sniok (~sniok@89.252.2.135) |
| 17:16.26 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 18:02.49 | *** join/#brlcad amarjeet_ (~Amarjeet@101.211.209.239) |
| 18:31.10 | *** join/#brlcad ickby_ (~stefan@x5d847777.dyn.telefonica.de) |
| 18:39.27 | *** join/#brlcad tandoorichick (b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
| 19:47.29 | *** join/#brlcad merzo (~merzo@80-118-132-95.pool.ukrtel.net) |
| 19:47.43 | Notify | 03BRL-CAD:starseeker * 68743 brlcad/trunk/src/librt/primitives/bot/g_bot_include.c: Revert commits 61337 and r61598. The former broke some BoT raytracing situations, and the latter is causing more subtle issues with an isolated bot region reporting one raytracing result and the same region below another comb reporting a different result. |
| 20:51.29 | *** join/#brlcad ickby (~stefan@x5d847777.dyn.telefonica.de) |
| 20:54.48 | *** join/#brlcad ickby (~stefan@x5d847777.dyn.telefonica.de) |
| 21:21.53 | *** join/#brlcad asad_ (~asad00@host10-2.natpool.mwn.de) |
| 21:58.47 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 22:14.33 | *** join/#brlcad merzo (~merzo@80-118-132-95.pool.ukrtel.net) |