| 00:27.57 | *** join/#brlcad infobot (ibot@rikers.org) |
| 00:27.57 | *** topic/#brlcad is Welcome to BRL-CAD! || Don't ask if someone is here, ask a better question. || We're participating in GSoC 2016! Patches required. || Major release 7.26 coming any day now... :P || New website deployed, feedback welcome! || Logs: http://ibot.rikers.org/%23brlcad/ |
| 01:30.10 | *** join/#brlcad acmjnyfnoqdkrfom (~armin@dslb-088-064-033-116.088.064.pools.vodafone-ip.de) |
| 01:41.45 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 03:33.42 | boj | Hi, @starseeker, recently, I have read the manual and know some basic concepts of BRL-CAD modeling system, now I want to do somthing. As you suggested last time, creating brep_cobb and a un-closed Bot like a plane(both plate mode and ordinay BoT mode), and using *rtshot* to track the ray, I do this and get the result, It is different, I mean if the plate mode is only useful when the whole surface is not enclosed? I also try a closed sphere w |
| 03:34.28 | *** join/#brlcad boj_ (~boj@2001:250:3c02:763:8d9d:c208:fd93:9ece) |
| 03:34.54 | boj_ | That is to say, if I want to migrate the plate mode into NURBS, do I need to check if the surface is closed? Or you have done it before? |
| 04:19.18 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 04:39.38 | *** join/#brlcad softcoder32 (~djff@41.202.219.64) |
| 05:09.33 | *** join/#brlcad softcoder32 (~djff@41.202.219.66) |
| 05:46.29 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 06:49.51 | *** join/#brlcad softcoder32 (~djff@41.202.219.74) |
| 06:57.30 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 07:27.22 | *** join/#brlcad softcoder32 (~djff@41.202.219.71) |
| 07:56.03 | *** join/#brlcad softcoder32 (~djff@41.202.219.72) |
| 08:21.55 | *** join/#brlcad softcoder32 (~djff@41.202.219.78) |
| 09:09.02 | *** join/#brlcad YANICK_ (~YANICK_@41.202.219.67) |
| 09:38.46 | *** join/#brlcad YANICK_ (~YANICK_@41.202.219.69) |
| 10:05.48 | *** join/#brlcad catchchaos (6ad8b47b@gateway/web/freenode/ip.106.216.180.123) |
| 10:11.29 | *** join/#brlcad Gabriel_ (050cd591@gateway/web/freenode/ip.5.12.213.145) |
| 10:12.08 | *** join/#brlcad teepee` (bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
| 10:21.25 | Gabriel_ | Hi, I am back with some of my yesterday questions about "adding -exec to search" GSoC project. |
| 10:22.38 | Gabriel_ | I've seen that in UNIX "find -exec", the command has to determine whether the current command has to be applied to a file inside the current directory or in another directory. |
| 10:22.58 | Gabriel_ | In the latter case, the full path of the file must be determined. |
| 10:23.54 | Gabriel_ | Here, I've been told that "search" only looks for the objects inside the currently opened database. |
| 10:25.13 | Gabriel_ | I guess that there is no need to determine the path of the found object (such as UNIX does), since BRL-CAD "search" is only looking in the currently opened database, am I right? |
| 10:28.36 | *** join/#brlcad YANICK_ (~YANICK_@41.202.219.75) |
| 10:31.26 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 10:43.46 | *** join/#brlcad divamgupta (~divamgupt@103.25.231.102) |
| 11:02.33 | *** join/#brlcad 92AAAH867 (~divamgupt@103.25.231.102) |
| 11:16.43 | *** join/#brlcad Ch3ck_ (~Ch3ck@154.70.110.201) |
| 11:45.03 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 12:02.01 | *** join/#brlcad icemc (~abanda@41.202.219.79) |
| 12:05.57 | *** join/#brlcad YANICK_ (~YANICK_@41.202.219.79) |
| 12:11.47 | *** join/#brlcad divamgupta_ (~divamgupt@103.25.231.102) |
| 12:47.04 | starseeker | boj: indeed, a plate mode NURBS import will *not* check if the surface is closed |
| 12:47.27 | starseeker | boj: we check now because we only support closed shapes - the idea of plate mode NURBS is to support objects that are not closed |
| 12:47.55 | boj | sorry, I do not really get it. |
| 12:48.39 | starseeker | boj: a B-Rep is made up of mulitple surfaces, which together bound a volume in space |
| 12:49.01 | starseeker | boj: a single surface (like 1 of the 6 cobb sphere plates) does *not* bound a volume in space |
| 12:49.13 | boj | yes, I can understand |
| 12:49.43 | boj | can we say the 6 cobb sphere is closed together? |
| 12:49.49 | starseeker | yes |
| 12:50.03 | starseeker | together, those 6 surfaces are closed |
| 12:50.12 | boj | that should be fine, I have tested different case |
| 12:50.32 | boj | so we need a scheme to identify the closure? |
| 12:51.01 | starseeker | no, we need a raytracing approach that will generate in and out hit points, with a thickness, when we have a surface that is *not* closed |
| 12:51.06 | starseeker | like the plate mode bots |
| 12:51.20 | starseeker | but for NURBS |
| 12:51.34 | boj | pls allow me think for a moment..it is a little bit confusing.. |
| 12:52.03 | starseeker | boj: there is a test file in src/librt/tests called extreme_ssi_test.g |
| 12:52.16 | starseeker | in it are two non-closed NURBS surfaces |
| 12:52.31 | starseeker | currently, we cannot raytrace those surfaces, because they do not bound a closed volume |
| 12:53.35 | starseeker | a "plate mode" NURBS raytracer would take the infinitely thin surface, and from the single hit point we can get from that surface would generate in hit and out hit positions and normals that treated that surface as if it were a very thin solid in space |
| 12:53.45 | boj | I know, the *thickness* is just a kind of description(or property) of the surface, they do not really exist, when do raytracing, why we need it is just for a in/out hitting point? |
| 12:54.14 | starseeker | yes - BRL-CAD is a solid raytracing system. We need solids, and surfaces are not solids |
| 12:54.34 | starseeker | so "plate mode" raytracing "fakes" solidity by turning it into very thin solids |
| 12:54.45 | starseeker | boj: brlcad might be able to explain it better |
| 12:55.06 | boj | and the *thin solid* is described by the thickness? I think I can get it. |
| 12:55.19 | starseeker | essentially |
| 12:55.54 | boj | OK, I read the code, in bots, the thickness of each triangle is in-variable? |
| 12:55.56 | starseeker | the surface is "assigned" a thickness, and the raytracing results from the individual surface are adjusted to reflect that thickness |
| 12:56.13 | starseeker | right - the thickness is a property of the whole surface |
| 12:56.44 | boj | aha, it seems to be more clear to me. |
| 12:57.26 | starseeker | so if you raytrace just one of the six cobb surfaces, you'll get either 1 or 2 hit points depending on what direction the ray comes from. |
| 12:57.45 | starseeker | that's what a single surface reports. But for solid raytracing, we need 2 or 4 hit points |
| 12:58.21 | starseeker | So, in the 1 hit point case, we would take the reported intersection and normal and deduce two hit points from that original hit point |
| 12:59.34 | boj | you mean then, along the normal direction, we can calculate another hitting point while the surface with a *given thickness*? |
| 12:59.42 | starseeker | there are some subtle issues, like where in space the deduced points should go and what to do near the edges of the NURBS surface (or if, say, you're shooting a ray at a tangent that misses the actual NURBS surface but would hit the pseudo solid with thickness) |
| 13:00.15 | starseeker | boj: that's one scheme. another is to treat the actual hit as the midpoint and generate two new points, above and below |
| 13:00.39 | boj | above and below? how to say? |
| 13:01.39 | starseeker | so we have a hit on one of the cobb sphere surfaces. That hit has a normal. We can take our thickenss value, and generate two new points - one back in the direction the surface normal is pointing, and one in the opposite direction from that of the surface normal. |
| 13:02.08 | starseeker | or we might generate points along the ray direction, using the surface normals from the hit point |
| 13:02.38 | starseeker | Or there might be other schemes - BoTs are rather simpler in many ways since they're individually flat |
| 13:02.58 | boj | but if we trace the back direction of hit point, will it miss? |
| 13:03.02 | starseeker | as I say, brlcad may have more/better insight on how to approach this... |
| 13:03.34 | starseeker | you mean, shoot the ray from the other side of the surface? |
| 13:03.42 | starseeker | no, it should still report the hit |
| 13:04.22 | starseeker | boj: I've got to run - if brlcad comes in later he may have better ways to explain |
| 13:04.44 | boj | OK, thank you |
| 13:04.58 | boj | I need to think it and make a short plan.. |
| 13:05.22 | boj | thanks @starseeker.. :) |
| 13:09.24 | *** join/#brlcad yorik (~yorik@152.250.221.17) |
| 13:14.57 | Ch3ck_ | starseeker, I can't seem to load the GUI for MGED on the latest svn checkout |
| 13:15.00 | Ch3ck_ | I built as debug |
| 13:15.07 | Ch3ck_ | I don't know if there's something wrong I am doing? |
| 13:26.03 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:40.27 | *** join/#brlcad tafodinho (~tafodinho@154.70.98.111) |
| 14:13.06 | *** join/#brlcad Ch3ck_ (~Ch3ck@154.70.110.201) |
| 14:15.21 | ``Erik | tafodinho: tip #1, chat in the channel :) general tree walker would be useful, but would require some pretty hefty C chops, as it'd involve things like complicated recursion on possibly volatile data structures, function pointers, etc. If that sounds like something you believe you can handle, I'd recommend starting with the general recommendations for new gsoc students on the wiki |
| 14:16.16 | ``Erik | tafodinho: once you have BRL-CAD installed, maybe look at some trees in sample geometry and try doing things with the existing tree walkers to get a feeling for how they work? |
| 14:18.46 | tafodinho | ``Erik: thanks for the info |
| 14:29.18 | *** join/#brlcad softcoder32 (~djff@41.202.219.66) |
| 14:55.17 | Notify | 03BRL-CAD:starseeker * 67249 brlcad/trunk/src/tclscripts/rtwizard/main.c: checkpoint |
| 15:15.27 | *** join/#brlcad gaganjyot (~gaganjyot@122.173.190.209) |
| 15:17.55 | *** join/#brlcad Robert_Dumitru (~robert.du@2a02:2f0b:8020:102a:2c02:6771:2748:914f) |
| 15:18.05 | *** part/#brlcad Robert_Dumitru (~robert.du@2a02:2f0b:8020:102a:2c02:6771:2748:914f) |
| 15:21.40 | *** join/#brlcad YANICK_ (~YANICK_@41.202.219.64) |
| 15:22.01 | *** join/#brlcad icemc (~abanda@41.202.219.64) |
| 15:28.15 | *** join/#brlcad shubham (71c18a03@gateway/web/freenode/ip.113.193.138.3) |
| 15:29.37 | Notify | 03BRL-CAD Wiki:188.25.106.72 * 9543 /wiki/Benchmark_Performance_Database: /* References */ |
| 15:30.17 | Notify | 03BRL-CAD Wiki:188.25.106.72 * 9544 /wiki/Benchmark_Performance_Database: /* References */ |
| 15:33.12 | *** join/#brlcad anova (~robert7_@41.202.219.64) |
| 15:46.29 | *** join/#brlcad Ak7 (~Akshay@112.196.146.41) |
| 15:53.57 | *** join/#brlcad YANICK_ (~robert7_@41.202.219.70) |
| 15:53.58 | *** join/#brlcad icemc (~abanda@41.202.219.70) |
| 15:54.56 | *** join/#brlcad anova (~robert7_@41.202.219.70) |
| 16:10.52 | *** join/#brlcad ramandeep (~ramandeep@122.173.190.209) |
| 16:33.28 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:38.02 | *** join/#brlcad tafodinho (~tafodinho@154.70.98.111) |
| 17:00.39 | *** join/#brlcad anova (~robert7_@41.202.219.78) |
| 17:01.34 | *** join/#brlcad icemc (~abanda@41.202.219.78) |
| 17:01.59 | *** join/#brlcad YANICK_ (~robert7_@41.202.219.78) |
| 17:12.17 | *** join/#brlcad gaganjyot (~gaganjyot@122.173.190.209) |
| 17:16.38 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:55.12 | *** join/#brlcad softcoder32 (~djff@41.202.219.77) |
| 17:57.10 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 17:57.18 | *** join/#brlcad Gabriel_ (54e8bc31@gateway/web/freenode/ip.84.232.188.49) |
| 17:58.40 | Gabriel_ | How should the commands which are to be executed of found objects ("add exec to search command" project) be stored? |
| 17:58.52 | Gabriel_ | Would it be a good idea to store each of them in a linked list? |
| 18:21.31 | *** join/#brlcad Ak7 (~Akshay@112.196.146.41) |
| 18:34.16 | *** join/#brlcad tafodinho (~tafodinho@41.205.28.219) |
| 18:47.29 | *** join/#brlcad softcoder32 (~djff@41.202.219.75) |
| 18:56.47 | *** join/#brlcad Ch3ck_ (~Ch3ck@154.70.110.201) |
| 19:00.54 | *** join/#brlcad icemc (~abanda@41.202.219.79) |
| 19:00.56 | *** join/#brlcad YANICK_ (~robert7_@41.202.219.79) |
| 19:01.40 | *** join/#brlcad anova (~robert7_@41.202.219.79) |
| 19:24.34 | *** join/#brlcad tandoorichick (b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
| 19:39.31 | *** join/#brlcad tandoorichick (b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
| 20:02.23 | *** join/#brlcad jasvir (~jass@75-142-109-136.static.mtpk.ca.charter.com) |
| 20:14.48 | jasvir | hi all. I was trying to build brlcad. But each time I try, I ended up with an error while executing make. http://paste.ubuntu.com/15323240/ |
| 20:14.59 | jasvir | Please help me to resolve this. |
| 20:49.11 | *** join/#brlcad softcoder32 (~djff@41.202.219.70) |
| 21:00.17 | tandoorichick | to run mged you can build just that, instead of 'all'. make -j4 mged |
| 21:46.42 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 21:58.22 | *** join/#brlcad LordOfBikes (~armin@dslb-088-064-033-116.088.064.pools.vodafone-ip.de) |
| 22:31.53 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 22:42.00 | Notify | 03BRL-CAD Wiki:Semplogumbira * 0 /wiki/User:Semplogumbira: |
| 22:46.46 | *** join/#brlcad shubham (71c18b68@gateway/web/freenode/ip.113.193.139.104) |
| 23:08.21 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 23:39.21 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |