| 00:17.51 | Notify | 03BRL-CAD Wiki:AnkushKhandelwal * 0 /wiki/File:Polyset.png: |
| 01:43.44 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-ctihdygdkxxwcvlu) |
| 02:11.48 | *** join/#brlcad merzo_ (~merzo@193-83-63-159.adsl.highway.telekom.at) |
| 02:15.55 | starseeker | returns |
| 02:16.00 | starseeker | huzza |
| 02:32.13 | starseeker | huh: http://www.codebykevin.com/blosxom.cgi/2015/03/21#tk-cocoa-culler |
| 02:33.13 | starseeker | maybe it's time to take a serious look at Tk on Mac again |
| 02:33.27 | starseeker | (and upgrading our Tcl/Tk... urk) |
| 03:00.01 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 03:25.15 | *** join/#brlcad lemur1 (~lemur@host213-122-133-147.range213-122.btcentralplus.com) |
| 03:40.18 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 04:01.09 | *** join/#brlcad sofat (~sofat@202.164.53.117) |
| 04:01.15 | sofat | brlcad, hello |
| 04:02.23 | sofat | what is opinion regarding mediawiki or wordpress. Because I am comfortable with both. |
| 04:31.27 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 04:48.24 | *** join/#brlcad alisha (~quassel@101.60.129.47) |
| 05:03.18 | *** join/#brlcad witness (uid10044@gateway/web/irccloud.com/x-getxtkrtwrboxxhc) |
| 05:11.06 | *** join/#brlcad sofat (~sofat@202.164.53.117) |
| 05:15.48 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 05:20.46 | *** join/#brlcad cardinot (~cardinot@unaffiliated/cardinot) |
| 05:29.29 | *** join/#brlcad ignacio (~ignacio@rev-18-85-44-59.sugarlabs.org) |
| 05:49.33 | *** join/#brlcad alisha (~quassel@115.184.32.241) |
| 05:56.19 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 06:09.47 | *** join/#brlcad ignacio (~ignacio@unaffiliated/ignaciouy) |
| 07:05.58 | *** join/#brlcad seanzhu_ (86ad4e02@gateway/web/freenode/ip.134.173.78.2) |
| 07:10.28 | *** join/#brlcad albertcoder (~quassel@124.253.176.95) |
| 07:15.26 | *** join/#brlcad ujjwal (~ujjwal@1.22.29.154) |
| 07:27.55 | *** join/#brlcad alexey408_ (2ed8f586@gateway/web/freenode/ip.46.216.245.134) |
| 07:29.19 | *** part/#brlcad alexey408_ (2ed8f586@gateway/web/freenode/ip.46.216.245.134) |
| 07:31.16 | *** join/#brlcad alexey_ (2ed8f586@gateway/web/freenode/ip.46.216.245.134) |
| 07:51.03 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 08:18.18 | *** join/#brlcad alisha (~quassel@115.184.32.241) |
| 08:47.33 | *** join/#brlcad albertcoder (~quassel@124.253.140.58) |
| 09:05.31 | *** join/#brlcad alisha (~quassel@115.184.32.241) |
| 09:13.17 | *** join/#brlcad FreezingCold (~FreezingC@135.0.41.14) |
| 09:45.11 | dracarys983 | starseeker, Hey! I have been looking at B-Reps' raytrace routine which uses the newton's method to find the number of intersections. I have to implement the Plate-Mode raytracing used in BoT for B-Reps. |
| 09:46.05 | dracarys983 | I was thinking of an approach, where we assign a thickness parameter to all the vertices in the topology of the B-Rep and interpolate it for edges and faces using some smooth function |
| 09:46.51 | dracarys983 | And use this interpolated thickness while finding the BoundingBox for the B-Rep faces while building the BVH |
| 09:47.30 | dracarys983 | After prep, raytracing would be done as usual, using Newton's method |
| 09:50.31 | dracarys983 | Now, while evaluating the hits, I would have to assign a hit distance (while make a seg) to "in" and "out" points using the interpolated thickness. How would I do that for a NEAR_HIT / NEAR_MISS? |
| 09:50.40 | *** join/#brlcad alisha (~quassel@101.60.239.64) |
| 09:56.15 | *** join/#brlcad teepee-- (bc5c2133@gateway/web/freenode/ip.188.92.33.51) |
| 09:59.29 | *** join/#brlcad akshayrk95 (uid71395@gateway/web/irccloud.com/x-hlmwyociuftzlbzr) |
| 09:59.42 | dracarys983 | starseeker, I mean for a NEAR_HIT, not NEAR_MISS. That would be removed from the HitList. |
| 10:06.24 | Notify | 03BRL-CAD Wiki:Harjotkaur * 0 /wiki/User:Harjotkaur: |
| 10:08.25 | *** join/#brlcad alisha (~quassel@101.60.239.64) |
| 10:16.05 | *** join/#brlcad alisha (~quassel@101.60.239.64) |
| 10:16.28 | *** join/#brlcad konrado (~konro@41.244.243.82) |
| 10:42.09 | *** join/#brlcad Izakey (~Izakey@41.205.22.34) |
| 10:45.55 | *** join/#brlcad sofat (~sofat@202.164.53.117) |
| 10:55.24 | *** join/#brlcad piyush (0e8bf154@gateway/web/freenode/ip.14.139.241.84) |
| 11:32.27 | starseeker | dracarys983: my immediate question is what "some smoothing function" would be... |
| 11:34.22 | starseeker | dracarys983: have you considered offset surfaces? http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.360.2793&rep=rep1&type=pdf |
| 11:36.39 | starseeker | also Kumar's "Computing non-self-intersecting offsets of NURBS surfaces" |
| 11:37.02 | sofat | starseeker, hello |
| 11:37.35 | sofat | starseeker, you check my gsoc proposal ? |
| 11:37.55 | starseeker | sofat: not yet - I'm doing a lot of catch-up after being offline for a week |
| 11:38.01 | sofat | okay |
| 11:38.45 | dracarys983 | starseeker, No, I didn't consider these. I will have a quick look at these papers. Thanks :) |
| 11:38.45 | starseeker | sofat: note also I'm not one of our web guys - I know little about most aspects of web programming and design |
| 11:40.04 | dracarys983 | starseeker, One question : About problems with plate mode raytracing on NURBS - On corners and when ray grazes a surface, there will be problems right? |
| 11:41.13 | *** join/#brlcad ujjwal (~ujjwal@1.22.29.154) |
| 11:42.02 | starseeker | dracarys983: probably. You can check how our bots handle it - another possibility would be to use the offset surface edges and make "caps" using the edge curves and "birail" surface generation |
| 11:42.22 | starseeker | that would effect generate a thin "solid" from a single surface |
| 11:42.47 | starseeker | (Ayam has some birail capabilities that could be used as a guide: http://ayam.sourceforge.net/ayam.html) |
| 11:43.11 | starseeker | dracarys983: brlcad might not agree with me suggesting that approach though, as it's not really "plate mode" raytracing |
| 11:45.42 | dracarys983 | starseeker, Whoa. I'm lost. Well, I have checked up on BoTs and they use an implicit thickness to offset the surface (on both sides, +normal and -normal) while finding the bounding box in prep step. |
| 11:49.08 | dracarys983 | For bot_mode being plates, ofcourse. And then after raytracing the BoT and finding the hits, while constructing segheads, hits are taken in a FILO fashion (to be effective when ray grazes the surface) and hit distance is assigned using the implicit thicness |
| 11:54.33 | dracarys983 | What my confusion is, is that : Can we use Newton's method while doing plate-mode? Will there still be NEAR_MISS, NEAR_HIT and CLEAN_HIT types in the hits? |
| 11:58.47 | dracarys983 | starseeker, I think offset surfaces might help for the implicit thickness :D. I'll have to see the complexity involved as well, though. |
| 12:17.35 | dracarys983 | starseeker, Um, as it is an implicit thickness, wouldn't it be better if I just add a value to a point f(s, t) on the surface when needed in the direction of the normal rather than actually sample and find an offset curve? |
| 12:19.14 | *** join/#brlcad witness (uid10044@gateway/web/irccloud.com/x-pzsprmptxdxxeeec) |
| 12:32.41 | *** join/#brlcad albertcoder (~quassel@202.164.53.117) |
| 12:43.58 | Notify | 03BRL-CAD Wiki:Ngassafinjap * 8039 /wiki/User:Amalia: /* Links to some Pictures */ |
| 12:44.24 | Notify | 03BRL-CAD Wiki:Ngassafinjap * 8040 /wiki/User:Amalia: /* References */ |
| 12:45.25 | Notify | 03BRL-CAD Wiki:Ngassafinjap * 8041 /wiki/User:Amalia: /* Links to some Pictures */ |
| 12:45.49 | Notify | 03BRL-CAD Wiki:Ngassafinjap * 8042 /wiki/User:Amalia: /* Links to some Pictures */ |
| 12:46.07 | Notify | 03BRL-CAD Wiki:Ngassafinjap * 8043 /wiki/User:Amalia: /* Links to some Pictures */ |
| 12:47.30 | Notify | 03BRL-CAD Wiki:Ngassafinjap * 8044 /wiki/User:Amalia: /* Brief Project Summary */ |
| 13:11.01 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) |
| 13:12.43 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:14.21 | *** join/#brlcad amalia237 (~amalia237@41.205.22.44) |
| 13:15.21 | *** join/#brlcad alisha (~quassel@101.60.239.64) |
| 13:18.40 | *** join/#brlcad ujjwal (~ujjwal@1.22.29.154) |
| 13:28.18 | *** join/#brlcad alisha (~quassel@101.60.239.64) |
| 13:29.32 | dracarys983 | starseeker, I kind of figured out (rather that's what I think it is) that the bottleneck in the raytracing of BREPs is the very inefficient BVH built in the prep of the BREP. |
| 13:31.10 | dracarys983 | starseeker, So, if I replace it with the method used for BoTs, that is, just iterating over the face list and finding the hits and storing it - then making the segs and evaluating hits, it would be better. |
| 13:31.21 | dracarys983 | starseeker, What do you think? :) |
| 13:38.34 | brlcad | ries: yeah, you have to create a new profile every year. they don't persist. |
| 13:38.45 | *** join/#brlcad alisha (~quassel@101.60.239.64) |
| 13:39.41 | brlcad | starseeker: definitely, that was a very uplifting tk post |
| 13:39.44 | ries | brlcad: I already did create a profile this year, but may be it was removed because it was on LibreCAD only? |
| 13:40.09 | brlcad | sofat: opinion is that they're both good and they both do good things? |
| 13:41.07 | ries | I will have a new one created today and send it to you |
| 13:42.26 | brlcad | dracarys983: you'll want to check, but I believe the way bots handle plate mode on grazing situations is "technically wrong but sufficient" |
| 13:42.50 | brlcad | suggest creating a single triangle and testing out different modes and thickness settings |
| 13:43.43 | dracarys983 | brlcad: Okay. On it. |
| 13:44.07 | brlcad | wrong in the sense that you end up with a view-dependent hit -- but I haven't confirmed (or even thought about) it in a long time |
| 13:46.51 | dracarys983 | brlcad: Um, I didn't get you. |
| 13:47.52 | dracarys983 | brlcad : While playing with some geometry today I noticed that if I rotate an ars using CTRL, it doesn't get raytraced properly. |
| 13:50.04 | brlcad | dracarys983: sounds like a great patch submission |
| 13:50.39 | brlcad | note that ARS has little to do with BoT other than it uses it as a visualization method |
| 13:51.24 | *** join/#brlcad alisha (~quassel@115.184.44.143) |
| 13:51.56 | dracarys983 | brlcad: Roger that. :D |
| 13:52.07 | dracarys983 | brlcad, Did you have a look at my mail? |
| 13:53.21 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 13:55.20 | *** join/#brlcad alisha (~quassel@115.184.44.143) |
| 13:55.23 | ``Erik | sync |
| 13:57.40 | dracarys983 | brlcad, Apparently, if I use the GUI to create an ARS, it gives a problem. Command line works fine. |
| 14:01.49 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:23.43 | *** join/#brlcad infobot (ibot@rikers.org) |
| 14:23.43 | *** topic/#brlcad is BRL-CAD || http://brlcad.org || logs: http://ibot.rikers.org/%23brlcad/ || Congrats to all GCI 2014 winners Peter & Marc! || We are ACCEPTED for GSoC 2015 -- if you're a student, ask a specific question and WAIT for an answer! |
| 14:36.35 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 14:38.20 | ries | brlcad: send a request to you |
| 14:43.23 | *** join/#brlcad alisha (~quassel@115.184.44.143) |
| 14:47.02 | *** join/#brlcad ujjwal (~ujjwal@1.22.29.154) |
| 15:15.13 | brlcad | ries: done |
| 15:15.18 | ries | thanks |
| 15:16.08 | brlcad | if you don't see an "association" column at the end, you can turn it on with the columns button at the bottom of the proposals page |
| 15:17.22 | ries | brlcad: I have the overview |
| 15:25.58 | *** join/#brlcad sahil (~sahil@103.25.231.102) |
| 16:03.44 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 16:06.25 | dracarys983 | d_rossberg: Did you have a look at my proposal? :) |
| 16:21.19 | *** join/#brlcad sofat (~sofat@202.164.45.212) |
| 16:26.56 | sofat | brlcad, hello |
| 16:44.02 | *** join/#brlcad alisha (~quassel@115.184.44.143) |
| 16:51.11 | d_rossberg | dracarys983: short answer: yes, i had a look at it |
| 16:51.40 | d_rossberg | it looks reasonable but i hadn't time to go into the details yet |
| 16:52.05 | *** join/#brlcad alisha (~quassel@115.184.44.143) |
| 17:20.41 | *** join/#brlcad sofat (~sofat@202.164.45.212) |
| 17:29.06 | Notify | 03BRL-CAD:carlmoore * 64496 brlcad/trunk/src/libged/lc.c: shorten the code for lc.c, and I did do my previous test runs |
| 17:32.17 | *** join/#brlcad dracarys983 (dracarys98@nat/iiit/x-bzofwlognmghxaeh) |
| 17:38.40 | *** join/#brlcad merzo_ (~merzo@193-83-63-159.adsl.highway.telekom.at) |
| 17:42.03 | *** join/#brlcad amalia237 (~amalia237@41.205.22.10) |
| 17:50.41 | *** join/#brlcad alisha_ (~quassel@115.184.68.45) |
| 18:04.46 | *** join/#brlcad merzo__ (~merzo@62-47-218-221.adsl.highway.telekom.at) |
| 18:06.48 | Notify | 03BRL-CAD Wiki:AnkushKhandelwal * 8045 /wiki/User:AnkushKhandelwal/OpenGLRendering: |
| 18:09.57 | Notify | 03BRL-CAD Wiki:AnkushKhandelwal * 8046 /wiki/User:AnkushKhandelwal/OpenGLRendering: |
| 18:10.31 | Notify | 03BRL-CAD Wiki:AnkushKhandelwal * 8047 /wiki/User:AnkushKhandelwal/OpenGLRendering: |
| 18:11.08 | Notify | 03BRL-CAD Wiki:AnkushKhandelwal * 8048 /wiki/User:AnkushKhandelwal/OpenGLRendering: |
| 18:18.39 | *** join/#brlcad geekgrl (~geekgrl@122.170.56.87) |
| 18:28.08 | starseeker | dracarys983: the BVH is necessary for accurate NURBS raytracing |
| 18:29.14 | dracarys983 | starseeker, Just iterating over the face list would be even worse? |
| 18:29.32 | Notify | 03BRL-CAD Wiki:AnkushKhandelwal * 8049 /wiki/User:AnkushKhandelwal/OpenGLRendering: |
| 18:29.38 | starseeker | the iterative solve wouldn't always be accurate |
| 18:29.51 | starseeker | you need a "close enough" initial guess - that's what the BVH is for |
| 18:33.01 | dracarys983 | starseeker, Hm, okay. Building a better BVH would require more time, right? |
| 18:33.03 | *** join/#brlcad zenemij (~quassel@2a00:1508:1:f017:f022:47a2:d983:6f96) |
| 18:44.45 | Notify | 03BRL-CAD Wiki:AnkushKhandelwal * 8050 /wiki/User:AnkushKhandelwal/OpenGLRendering: |
| 18:50.54 | brlcad | dracarys983: in general yes, but the current bvh build is also not optimized |
| 18:51.26 | brlcad | optimized, it could probably do 10x the work in half the time it takes now (if you got a 20x improvement, for example, not unreasonable) |
| 18:51.33 | brlcad | not easy, but possible |
| 18:51.52 | brlcad | there's an RT'06 paper on fast accurate nurbs ray tracing that you should read |
| 18:51.58 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 18:52.02 | brlcad | (if working this area) |
| 18:52.48 | dracarys983 | brlcad, Does plate mode raytracing require optimization in bvh build? |
| 18:53.00 | brlcad | absolutely not |
| 18:53.43 | Stragus | brlcad, is there a pending effort to redesign the raytracer? |
| 18:53.53 | Stragus | Also with SSE/AVX, CUDA, OpenCL |
| 18:56.18 | Stragus | I don't know if there's external funding for this, but it sounds fun. You had me convinced a while ago about the value of complex primitives compared to triangles |
| 18:57.24 | brlcad | Stragus: yes, ongoing direction |
| 18:57.25 | Stragus | Rays stay a lot more coherent (which is *great* for AVX/CUDA/OpenCL), you get less memory loads in exchange for more computations |
| 18:58.07 | brlcad | two gsoc proposals to work that area this year, possibly one major funded effort next year that you might get pulled to work on |
| 18:58.24 | Stragus | Okay, cool. |
| 19:00.05 | dracarys983 | brlcad, Regarding the mail I sent you about my understanding of how to apply it to B-Reps - that won't work, right? |
| 19:00.22 | dracarys983 | I mean plate mode |
| 19:00.28 | dracarys983 | to B-Reps |
| 19:00.55 | brlcad | refresh me on the algo |
| 19:01.23 | dracarys983 | To assign an implicit thickness to the surface, I don't need to actually sample and find an offset surface - rather I can just assign that implicit thickness at a point F(s, t) of the surface whenever required, by adding an offset in the direction of (and opposite as well) the normal at (s, t). |
| 19:01.48 | dracarys983 | Instead of building the BVH (which is highly inefficient right now) from the surfaceTree, I will find the bounding boxes of all the faces in the faceList of the B-Rep and find the final Bounding Box.This will be the prep step for the plate-mode raytracing |
| 19:02.11 | dracarys983 | Once the prep is completed, the shot function will be called, and the Newton's method will be used for intersecting the ray with each face in the faceList. We now sort the hitList so that we have the nearest hit first and farthest hit last. |
| 19:02.45 | dracarys983 | Now, there can be duplicate hits in the hitList as we are simply iterating the faceList of the B-Rep rather than using a hierarchy which avoids overlap. Once we have the histList ready, we call the a function that creates segments (I will have to write a new one here!). It evaluates the hits, removes the duplicate hits, checks if a ray is grazing the surface and if so, uses the FILO approach to evaluate the hits ("in" and "out") as the |
| 19:02.45 | dracarys983 | re will be multiple entries and exits. Once done, we return the seghead filled |
| 19:03.39 | dracarys983 | And handling corners separately |
| 19:03.40 | brlcad | i meant summarize, not copy-paste but okay |
| 19:04.12 | *** join/#brlcad Shubham (6719e766@gateway/web/freenode/ip.103.25.231.102) |
| 19:05.13 | brlcad | so on the surface, that sounds like a viable direction, but some aspects are unclear |
| 19:05.43 | brlcad | for example, I think you should be able to allow the shot calculations to happen like they currently do if all you're doing is basing things off the surface hit point |
| 19:06.36 | dracarys983 | brlcad, Yes. That's why I was talking about the bvh build :) |
| 19:06.45 | brlcad | newton iteration, hit sorting, duplicate checking, etc, that all happens already |
| 19:08.09 | dracarys983 | Um, okay. I wasn't aware that the hits are getting sorted. |
| 19:08.15 | brlcad | I don't see any point in re-implementing any of that specific to plate-mode (i'm not sure if you're even suggesting that) |
| 19:08.26 | *** join/#brlcad alisha (~quassel@115.184.68.45) |
| 19:08.51 | brlcad | maybe not sorting, it was sorting at one point in the past |
| 19:09.13 | brlcad | the implementation has been overhauled and actively worked for the past 5+ years |
| 19:09.56 | brlcad | i think you first need to fully understand what bot platemode does first |
| 19:11.03 | brlcad | i believe it's very naive/simple and view dependent, which would give you bigger liberties to start with matching behavior |
| 19:11.53 | brlcad | if not, its a considerably harder problem |
| 19:14.24 | brlcad | having view-dependent behavior is by no means desirable, but having consistency with BoT would be acceptable to me (usability/consistency tradeoff) and we could focus on fixing both later |
| 19:15.18 | Stragus | You mean the thickness of the plate is dependent upon the ray's direction? Ewww |
| 19:15.22 | brlcad | create a plate-mode triangle that has a thickness greater than the longest edge (so it'll be a wedge) |
| 19:15.51 | brlcad | Stragus: I know right |
| 19:15.57 | Stragus | That's terrible |
| 19:16.17 | brlcad | it was done for air force, very thin thicknesses in general so it REALLY didn't matter |
| 19:16.35 | dracarys983 | brlcad, Hm, okay. :) I will also refine my understanding about the plate mode :) |
| 19:17.06 | brlcad | we even implemented a no-cosine mode (to match their behavior) where it reports the plate-mode thickness regardless of angle |
| 19:17.18 | brlcad | otherwise it would mess up calculations elsewhere |
| 19:17.25 | Stragus | I'm guessing RayThickness = PlateThickness / DotProduct( RayVector, SurfaceNormal ); ? |
| 19:17.50 | brlcad | that's the normal cosine version |
| 19:18.05 | Stragus | There's an even worse no-cosine mode? |
| 19:18.13 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:18.22 | dracarys983 | brlcad, What is that BITTEST() being called for? |
| 19:18.42 | brlcad | say you shoot at a thin sheet 1m x 1m that is 1mm thick |
| 19:18.57 | brlcad | shoot is square-on, and you'll get thickness=1mm |
| 19:19.05 | *** join/#brlcad lemur1 (~lemur@host213-122-133-147.range213-122.btcentralplus.com) |
| 19:20.42 | brlcad | shoot normally at a sharp angle (but hit the surface) and you're going to get some thickness > 1mm depending on the angle |
| 19:20.50 | brlcad | in no-cosine mode, you still get 1mm |
| 19:21.11 | Stragus | I can't imagine that being a good idea |
| 19:21.35 | brlcad | in general no, but it was required for a particular analysis |
| 19:21.57 | Notify | 03BRL-CAD:starseeker * 64497 brlcad/trunk/src/libbrep/shape_recognition_planar.cpp: Experiment with trying to characterize vertices to determine if they are used in a planar subvolume. |
| 19:22.13 | brlcad | big difference when you try to represent something flying as a single ray and it hits 1mm of aluminum vs 1m of aluminum |
| 19:23.02 | brlcad | anyways, we don't use it, but other folks needed it |
| 19:24.04 | *** join/#brlcad akshayrk95 (uid71395@gateway/web/irccloud.com/x-ceutnnoktqsiurnj) |
| 19:24.10 | brlcad | the bigger geometric issue is the view dependence -- shoot that sheet horizontally along it's plane and you're basically going to get a miss, or shoot just over an edge (and miss the surface) will be a miss whereas the angle might have actually met up with extruded material |
| 19:24.49 | brlcad | really only matters analytically for large thicknesses (which have never been used in practice), but technically wrong |
| 19:26.23 | *** join/#brlcad albertcoder (~quassel@1.39.33.253) |
| 19:31.16 | dracarys983 | brlcad, So the shooting-over-the-edge-miss is finally a miss because in practice, the extrusions won't have so large a thickness that it meets the ray, right? |
| 19:31.45 | brlcad | dracarys983: sorry, BITTEST is checking whether a bit is set or not |
| 19:32.01 | brlcad | usually used for book-keeping of some sort |
| 19:32.47 | brlcad | dracarys983: and no, it's not that the ray won't encounter the thickness -- it almost certainly would for pixels nearby the edge |
| 19:32.51 | brlcad | that's why I said you should test this |
| 19:33.06 | brlcad | if it's "wrong" then you'll only ever see a triangle, no matter the view you shoot from |
| 19:33.16 | brlcad | if it's right, you'll see a wedge |
| 19:34.02 | brlcad | easily fixed, but it will slow down the trace to know whether you hit within thickness of an edge |
| 19:36.42 | dracarys983 | brlcad, Okay, this looks interesting. I'll test this. Plate-mode triangle with a thickness greater than the longest edge. Cool :) |
| 19:38.45 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:38.48 | dracarys983 | brlcad, I will also try to understand plate-mode in BoTs better. Will get back ASAP. |
| 19:38.49 | brlcad | share screenshots |
| 19:39.12 | dracarys983 | brlcad, Yeah, will do. |
| 19:39.16 | brlcad | and if you find a crash or bug, fix it ;) |
| 19:39.26 | brlcad | don't often test with just one triangle :) |
| 19:40.10 | dracarys983 | brlcad, Yes, yes. Understood :) |
| 19:42.26 | dracarys983 | brlcad, BITTEST is being used for assigning thickness to faces in BoT prep, based on whether the test passes or not. What does that mean? http://pastebin.com/RD5zvK8d |
| 19:44.00 | *** join/#brlcad kintel (~kintel@unaffiliated/kintel) |
| 19:45.45 | brlcad | can't get to pastebin.com |
| 19:45.54 | brlcad | didn't I tell you that already? :) |
| 19:46.23 | brlcad | really should stop using them .. they're just .. there are so many other better options :) |
| 19:46.35 | dracarys983 | brlcad, Yeah you did. I thought it was temporary. :/ |
| 19:47.10 | Notify | 03BRL-CAD:starseeker * 64498 brlcad/trunk/src/libbrep/shape_recognition.cpp: Put the filters back - their absence causes other problems. |
| 19:48.27 | dracarys983 | Sorry. Here : http://hastebin.com/ogevaposun.coffee |
| 20:00.58 | *** join/#brlcad andrei_il (~andrei@109.100.128.78) |
| 20:01.22 | sofat | brlcad, hello |
| 20:01.36 | sofat | i needed you help regarding the technology which technology you prefer me for project(mediawiki or wordpress) |
| 20:05.49 | sofat | <PROTECTED> |
| 20:05.50 | sofat | what is your requirement right now? |
| 20:05.51 | sofat | mediawiki or wordpress ? |
| 20:10.58 | *** join/#brlcad ozzy1 (~tomek@host-81-190-233-203.wroclaw.mm.pl) |
| 20:18.34 | *** join/#brlcad teepee (~teepee@unaffiliated/teepee) |
| 20:21.10 | *** join/#brlcad ih8sum3r (~chatzilla@122.173.186.133) |
| 20:56.47 | *** join/#brlcad sofat (~sofat@202.164.45.212) |
| 21:24.45 | Notify | 03BRL-CAD:n_reed * 64499 brlcad/trunk/src/librt/primitives/joint/joint.c: need to reverse the transformations above the target object to put the rotation vector in the correct position realative to the untransformed object |
| 21:32.36 | *** part/#brlcad ozzy1 (~tomek@host-81-190-233-203.wroclaw.mm.pl) |
| 21:36.25 | dracarys983 | brlcad, there? |
| 21:43.31 | Notify | 03BRL-CAD:carlmoore * 64500 brlcad/trunk/doc/docbook/system/mann/en/lc.xml: describe use of -0, -1 |
| 21:48.59 | brlcad | ~ask |
| 21:48.59 | infobot | Questions in the channel should be specific, informative, complete, concise, and on-topic. Don't ask if you can ask a question first. Don't ask if a person is there; just ask what you intended to ask them. Better questions more frequently yield better answers. We are all here voluntarily or against our will. |
| 21:49.31 | brlcad | dracarys983: so that BITTEST is looking to see what type of facemode should be used |
| 21:49.54 | dracarys983 | brlcad, Yeah I got that when I tried to make a bot right now :D |
| 21:50.10 | dracarys983 | 2 seconds. I'll share the screenshots |
| 21:50.19 | brlcad | in addition to offsetting a surface, extruding it some distance from 0.0 to 1.0, you can extrude it -0.5 to 0.5 (centered |
| 21:51.04 | *** join/#brlcad alisha_ (~quassel@115.184.34.98) |
| 21:52.05 | dracarys983 | Right. So the facemode defines the type of extrusion :) |
| 21:53.01 | brlcad | facemode is a type id, and surfno is a surface number corresponding to that triangle |
| 21:53.54 | brlcad | it's sort of like indexing into a bool array |
| 21:54.53 | dracarys983 | brlcad, Hm, I get it now. |
| 21:55.06 | brlcad | can sort of think of that if/else logic like: bool extruded_face = surfaces[surfno].attributes.facemode; if (extruded_face) ... else /* centered */ |
| 21:56.17 | dracarys983 | Yes, you're right. Yes :D |
| 21:56.18 | brlcad | what it's really doing is creating a massive bit-vector, jumping to the bit set for that surface, and looking at the bit corresponding to facemode which is either set or unset |
| 21:56.35 | dracarys983 | I have uploaded the screenshots on Google Drive. Should I post the link here? (It's too long :P) |
| 21:56.49 | brlcad | can't get to google drive until later |
| 21:56.56 | brlcad | so go ahead, will check it then |
| 21:57.18 | dracarys983 | https://drive.google.com/drive/#folders/0B12fowx3-NjTflBBcXd6NFBQQXlRT2NONUZhUGVTQlJjUExYT2F6MUk0cjZybzE2WnlnNTg/0B12fowx3-NjTfnJ1SGxaMEg0cExBRlR5V2JzSnlybmhwWF9vRjlqeEk3QXpoSFpERV9Sd1k |
| 21:59.50 | dracarys983 | brlcad, It performs this test while filling in the seg structure as well. I get it now :) |
| 22:02.10 | dracarys983 | brlcad, I haven't started writing the proposal for plate mode NURBS raytracing yet. I'll have to rethink the algo, so. |
| 22:02.25 | dracarys983 | I will send it by tonight most probably :) |
| 22:03.26 | brlcad | have you made a patch submission yet? |
| 22:04.49 | brlcad | a useful patch can be far more important than what is written in a proposal |
| 22:05.27 | brlcad | all patches to be considered during proposal evaluation must be received before Monday |
| 22:05.49 | brlcad | anyone without a patch or with a useless or non-functional patch will be at a huge disadvantage |
| 22:07.05 | dracarys983 | I worked on reviewing the unit tests written by GCi students and have written 3 final test files (.cpp) |
| 22:07.15 | dracarys983 | I haven't submitted them as patches yet |
| 22:08.27 | dracarys983 | brlcad, They're good enough. But they relate to the core interface of GE |
| 22:08.27 | brlcad | whatever you do, you'll want to try and demonstrate your ability to understand and modify existing code, not just write code |
| 22:09.13 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |
| 22:10.09 | brlcad | let me know if you need some suggestions, there's a few bot-related items in our TODO that should be doable in a day |
| 22:10.36 | dracarys983 | brlcad, I'll take the suggestions :) |
| 22:12.52 | brlcad | a) our bot_split command seems to have O(n^3) performance or some other massive performance issue, b) there's a bin sort optimization crash that needs to be re-enabled, debuged, and fixed, and c) add an option to bot_dump to output surface normals |
| 22:13.51 | brlcad | code for (a) and (c) are in src/libged, code for (b) is in src/librt/primitives/bot (I think) |
| 22:14.01 | dracarys983 | brlcad, I'll try to have a look at the raytracing problem of ARS in MGED (when created from GUI) after I do one from the suggestions :) |
| 22:14.16 | brlcad | ARS would be perfect |
| 22:14.36 | brlcad | really anything like that which involves debugging, code inspection, understanding |
| 22:15.03 | dracarys983 | brlcad, Okay, great. I'm on it :D |
| 22:15.36 | brlcad | i'm frankly not nearly as concerned about a plate-mode algorithm as that can be sorted out in the bonding phase if you were selected, and plans / technical directions often do change |
| 22:16.21 | brlcad | just the scope of a project ideally shouldn't change -- so you could submit something quick that covers the scope/objectives with rough timeline, then back to patch(es), then back to as much detail as you can fit |
| 22:16.33 | brlcad | one day each and then times up |
| 22:18.18 | dracarys983 | brlcad, Yeah, I get it. :) |
| 22:19.46 | dracarys983 | brlcad, There's one problem with me. I tend to get over excited sometimes and lose sight of the small important details. This is a great chance for me to learn :) |
| 22:20.05 | dracarys983 | brlcad, Well, first things first. I'll work on my patch. |
| 22:20.24 | brlcad | I tend to not get excited and obsess over unimportant details, so it's all good |
| 22:20.45 | brlcad | ;) |
| 22:21.06 | dracarys983 | :D |
| 22:58.59 | *** join/#brlcad merzo__ (~merzo@62-47-218-221.adsl.highway.telekom.at) |
| 23:41.50 | *** join/#brlcad teepee_ (~teepee@unaffiliated/teepee) |