| 01:38.50 | Notify | 03BRL-CAD:brlcad * 57456 brlcad/trunk/TODO: this has come up several times recently and probably something we can predominantly automate. provide a model reduction capability. |
| 02:07.25 | Notify | 03BRL-CAD:brlcad * 57457 brlcad/trunk/TODO: simple first step for making some progress on ray bundling |
| 02:33.34 | Notify | 03BRL-CAD:brlcad * 57458 brlcad/trunk/doc/CMakeLists.txt: add some notes on the various implicit primitive constraints |
| 02:43.51 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 02:58.37 | brlcad | FLOSSrookie: how goes it? |
| 03:19.28 | FLOSSrookie | brlcad: Good. |
| 03:19.33 | FLOSSrookie | brlcad: Sorry I did not see your post earlier. I have set pidgin to log on automatically. I was just reading up on this "revelation" by the news corps of the NSA spying. And wondering why it is all so vague. They don't mention a single company that is "in bed" with the NSA and the don't mention a single encryption standard or algorithm that has been broken. |
| 03:19.33 | FLOSSrookie | If this stuff came from Snowden then he is not doing a good job of informing us. He needs to name names and tell us the facts. This all seems like fear mongering to me. |
| 03:51.56 | Notify | 03BRL-CAD:brlcad * 57459 brlcad/trunk/regress/repository.sh: if we're building in place, we also need to ignore the lexer output source files that inject system headers before our common.h header |
| 04:24.45 | Notify | 03BRL-CAD:phoenixyjll * 57460 brlcad/trunk/src/libbrep/boolean.cpp: It should be the intersection of the two merged intervals, not union. |
| 05:05.06 | Notify | 03BRL-CAD:phoenixyjll * 57461 brlcad/trunk/src/libbrep/boolean.cpp: IsPointOnLoop() and IsPointInsideLoop() may return -1. And there might be no intersections (e.g. for an innerloop) |
| 05:34.55 | Notify | 03BRL-CAD:phoenixyjll * 57462 brlcad/trunk/src/libbrep/boolean.cpp: Should use m_b for the polyline's domain... |
| 06:59.09 | *** join/#brlcad d_rossberg (~rossberg@66-118-151-70.static.sagonet.net) | |
| 07:00.26 | *** join/#brlcad kimzzzz (~AndChat31@49.249.16.85) | |
| 07:01.32 | *** join/#brlcad AndChat|317009 (~AndChat31@1.38.27.18) | |
| 07:16.14 | *** join/#brlcad kesha (~kesha@49.249.16.85) | |
| 07:43.12 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 08:03.16 | Notify | 03BRL-CAD Wiki:Phoenix * 6092 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 12 */ |
| 08:03.36 | Notify | 03BRL-CAD Wiki:Phoenix * 6093 /wiki/User:Phoenix/GSoc2013/Reports: /* Week 12 */ |
| 08:04.36 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Arb_union.png: |
| 08:04.52 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Arb_intersect.png: |
| 08:05.07 | Notify | 03BRL-CAD Wiki:Phoenix * 0 /wiki/File:Arb_diff.png: |
| 08:06.12 | Notify | 03BRL-CAD Wiki:Phoenix * 6097 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
| 08:06.47 | Notify | 03BRL-CAD Wiki:Phoenix * 6098 /wiki/User:Phoenix/GSoc2013/Reports: /* Test Results */ |
| 09:28.42 | Notify | 03BRL-CAD:indianlarry * 57463 (brlcad/branches/nurbs/TODO brlcad/branches/nurbs/doc/CMakeLists.txt and 30 others): Merging trunk into branch 'nurbs' r:57357:57462 |
| 09:33.33 | *** join/#brlcad kesha (~kesha@49.249.16.85) | |
| 09:37.58 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 10:50.01 | *** join/#brlcad Izak (~Izak@195.24.220.16) | |
| 10:58.01 | *** join/#brlcad FLOSSrookie (~brian@107-200-34-111.lightspeed.tulsok.sbcglobal.net) | |
| 11:12.47 | Notify | 03BRL-CAD:tbrowder2 * 57464 brlcad/trunk/src/util/dsp_add_t.cpp: remove commented-out code |
| 11:40.22 | *** join/#brlcad Izak (~Izak@195.24.220.16) | |
| 11:40.24 | Izak | y |
| 11:47.41 | *** join/#brlcad kimzzzz (~AndChat31@1.38.27.18) | |
| 11:58.43 | Notify | 03BRL-CAD:tbrowder2 * 57465 brlcad/trunk/src/util/dsp_add_t.cpp: change from stdout redirect to a named file as third mandatory arg (gives better opt handling) |
| 12:09.30 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) | |
| 12:09.51 | Izak__ | brlcad: Finding the sixth roots of unity did not converge |
| 12:10.34 | Izak__ | i mean did not converge in 100 iterations. I am cheking to see if the number of iterations can be increased |
| 12:53.50 | *** join/#brlcad AndChat|317009 (~AndChat31@1.38.27.18) | |
| 13:11.05 | Izak__ | brlcad: I have tested a polynomial from Kuhlkarni's paper and several others like a quintic which had to yield the 5 roots of unity and it says this http://paste.kde.org/p46239293/ |
| 13:12.10 | brlcad | Izak__: stack trace? |
| 13:12.36 | Izak__ | ok with gdb right ? |
| 13:13.17 | brlcad | in method you can manage |
| 13:13.21 | brlcad | but yeah, I'd used gdb |
| 13:14.07 | brlcad | segfault messages by themselves are rarely ever useful, just mean "something went wrong" .. and it's often something very trivially fixable |
| 13:15.44 | zero_level | brlcad : CAn you please point me to a source of generation of dpix images ? |
| 13:16.11 | zero_level | because I am afraid of the following point. |
| 13:16.39 | brlcad | zero_level: grep dpix doc/docbook/system/*/*/*.xml |
| 13:17.18 | zero_level | let say an image has values in [a,b]. 0<a<b<255 |
| 13:17.18 | brlcad | the interface hasn't been exercised in a very long time, so the tools may need dusting off (i.e. little fixes) |
| 13:18.21 | zero_level | not let say this is mapped to double values. [-MaxDouble, +MaxDouble] |
| 13:18.30 | zero_level | s/not/now |
| 13:18.54 | zero_level | So, here is my question. |
| 13:19.18 | zero_level | Do I point -MaxDouble to 0 and MinDouble to 1 |
| 13:19.22 | zero_level | or |
| 13:19.35 | zero_level | (This is while conversion) |
| 13:20.14 | zero_level | Do I find the minimum value in the Dpix i.e dpix_MIN to 0 and max value in Dpix i.e. dpix_MAX to 1 |
| 13:20.29 | zero_level | ? |
| 13:21.13 | zero_level | I believe you realize I am trying to convert dpix image to icv container and vice versa. |
| 13:21.47 | zero_level | brlcad : Also regarding the flags. |
| 13:22.14 | *** join/#brlcad PrezKennedy (~DarkCalf@173.231.40.99) | |
| 13:23.04 | zero_level | my motto of implementing them was to allow some multiplication of the form. |
| 13:23.14 | zero_level | a*5/4.9 |
| 13:23.22 | zero_level | where a is the pixel value. |
| 13:24.26 | zero_level | brlcad : Also this is a dummy example. |
| 13:32.16 | brlcad | zero_level: I don't think that question can be answered -- it depends on what the data means (and we have other tools for shifting data ranges, and can obviously write others) |
| 13:32.31 | brlcad | it's more a question of whether precision is lost and if so, how much |
| 13:32.42 | brlcad | and providing information and options to the user |
| 13:33.17 | zero_level | lets trust the existing tool and dpix-pix in util |
| 13:33.42 | Notify | 03BRL-CAD:tbrowder2 * 57466 brlcad/trunk/src/util/dsp_add_t.cpp: protect from overwriting existing files; add -f option; improve error message |
| 13:33.43 | zero_level | s/lets trust/trusting |
| 13:34.32 | zero_level | brlcad : If going by this dpix-pix uses local minima and local maxima in the dpix images. |
| 13:34.40 | zero_level | maps them to 0 and 255 respectively |
| 13:34.45 | zero_level | and converts the output. |
| 13:35.51 | zero_level | brlcad :regarding your reference to the doc rt can output the images in dpix format. |
| 13:36.05 | zero_level | and which is indeed the founding of dpix. |
| 13:36.32 | brlcad | yep |
| 13:36.49 | brlcad | but what I don't know is what range rt is capable of producing |
| 13:37.07 | zero_level | brlcad : How do we find the range ? |
| 13:37.14 | brlcad | mapping min/max to 0/255 is simply the safest thing to do, most preserving |
| 13:37.27 | brlcad | reading the code |
| 13:37.35 | zero_level | brlcad : but aboviously not the right thing |
| 13:37.45 | zero_level | also 0.0-1.0 is lot of ranges. |
| 13:37.50 | brlcad | not obviously the wrong thing either |
| 13:37.58 | brlcad | depends |
| 13:38.08 | zero_level | I think we should limit our rt in this. (If this is doable) |
| 13:38.22 | brlcad | uhm, why limit our range? |
| 13:38.33 | brlcad | the entire point is to preserve as might wavelength information as possible |
| 13:38.40 | zero_level | atleast to some values. |
| 13:38.43 | brlcad | not make something convenient for an image processing library |
| 13:38.45 | zero_level | [a,b] |
| 13:39.07 | brlcad | right now, I suspect that the range is [0,MAX_DOUBLE] |
| 13:39.17 | zero_level | alright. |
| 13:40.00 | zero_level | but than the point is if I map all these values to 0,1 (ofcourse lossy) we might not get good results. |
| 13:40.13 | zero_level | s/than/then |
| 13:40.17 | brlcad | but you would not want to just linearly map [0,MAX_DOUBLE] to [0,255] if your data was [132.13,9183.3] ... that'd all get compressed to like two color values |
| 13:40.46 | zero_level | ok. do ou suggest using gamma correlation ? |
| 13:41.10 | zero_level | c/ou/you |
| 13:41.59 | brlcad | gamma correction is for shifting values (basically a multiplier |
| 13:42.10 | brlcad | this is not a shifting issue, it's a range mapping problem |
| 13:42.47 | brlcad | there needs to be a way to map a range of values to another either on the front end or the back end |
| 13:42.49 | zero_level | I thought it has a say in mapping also. http://en.wikipedia.org/wiki/Gamma_correction |
| 13:43.50 | brlcad | but usually same range data |
| 13:43.52 | zero_level | see line 99 in encoding.c |
| 13:43.57 | brlcad | your problem is different ranges |
| 13:44.06 | brlcad | I actually have to run out for a bit |
| 13:44.06 | zero_level | libicv/encoding.c |
| 13:44.15 | zero_level | brlcad :alright. |
| 13:44.26 | zero_level | brlcad : lets continue. |
| 13:44.27 | brlcad | something to think about is simply increasing the range of icv's back-end |
| 13:44.53 | zero_level | brlcad : I am not sure if that is a good idea. |
| 13:45.50 | brlcad | you'll have to convince me of that, why limiting ourselves to a small sliver of double-precision is useful... it shouldn't matter other than for range mapping |
| 13:46.08 | brlcad | still just something to think about |
| 13:46.10 | brlcad | not act on |
| 13:46.11 | zero_level | ok. now ? |
| 13:46.56 | brlcad | the general problem is still mapping from one range to the back-end range (whatever that is), and needing function(s) to do that bidirectionally |
| 13:48.30 | brlcad | one possible way is that each format (bw, pix, dpix, png, ...) could provide a mapping routine, e.g., png_to_icv() and png_from_icv() |
| 13:49.24 | brlcad | ICV would provide plugin API for low-level data range mapping (like your chartodouble() function) for the possible C intrinsic data types |
| 13:49.26 | Notify | 03BRL-CAD:tbrowder2 * 57467 brlcad/trunk/src/util/dsp_add_t.cpp: check for zero-length files |
| 13:50.54 | brlcad | anyways, think about it .. got to run, suggest just starting with dpix as it's currently defined and mapping to current 0,1 backend, and we'll think about whether it makes sense to change it |
| 13:51.15 | brlcad | if changes are hard, something needs to change, the backend should be changeable |
| 14:29.00 | Izak__ | Huuh ! brlcad: I ran roots_example on Kuhlkarni's polynomail and it works now. You should see this http://paste.kde.org/p48c0a512/ |
| 14:30.00 | Izak__ | Erik: The real issue was that roots[] array in roots_example.c could stash only upto 4 roots. I changed that to 6 |
| 14:44.07 | Izak__ | I have changed 4 to BN_MAX_POLY_DEGREE so that 4 wouldn't look like a magic number or confuse anyone |
| 14:53.08 | Notify | 03BRL-CAD:tbrowder2 * 57468 brlcad/trunk/src/util/dsp_add_t.cpp: modify arg description for output file |
| 14:57.17 | Notify | 03BRL-CAD:iiizzzaaakkk * 57469 brlcad/trunk/src/util/roots_example.c: A roots example of a sextic equation. Changed 4 to BN_MAX_POLY_DEGREE |
| 14:59.22 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6099 /wiki/User:Izak/GSOC_2013_logs: /* September 2nd to September 7th */ |
| 14:59.31 | Notify | 03BRL-CAD:tbrowder2 * 57470 brlcad/trunk/src/util/dsp_add_t.cpp: improve help output format |
| 15:04.16 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6100 /wiki/User:Izak/GSOC_2013_logs: /* September 2nd to September 7th */ |
| 15:30.17 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) | |
| 15:30.25 | Izak__ | l |
| 15:30.34 | Izak__ | ok |
| 16:51.20 | Notify | 03BRL-CAD:tbrowder2 * 57471 brlcad/trunk/src/util/dsp_add_t.cpp: use std exit macros for portability and ease of parsing |
| 17:04.04 | *** join/#brlcad Izak (~Izak@195.24.220.16) | |
| 17:05.05 | *** join/#brlcad Izak__ (~Izak@195.24.220.16) | |
| 17:05.19 | Izak__ | looking at |
| 17:05.35 | Notify | 03BRL-CAD:tbrowder2 * 57472 brlcad/trunk/src/util/dsp_add_t.cpp: rearrange file open order; standardize format of exit messages |
| 17:06.54 | Izak__ | ``Erik: I tested roots_example on a sextic equation and it worked perfectly |
| 17:07.18 | Notify | 03BRL-CAD:tbrowder2 * 57473 brlcad/trunk/src/util/dsp_add_t.cpp: add ERROR to error exit message |
| 17:29.08 | Notify | 03BRL-CAD:tbrowder2 * 57474 brlcad/trunk/src/util/dsp_add_t.cpp: move fnames up to main scope for later use; bail on errors earlier; improve error messages |
| 17:42.24 | ``Erik | Izak__: awesome, have you wired it to your hrt shot yet? I'm eager to see either a wireframe or rt :D |
| 17:43.21 | Izak__ | I keeps saying rt_hrt_plot ont implemented yet. So it apperas the rt in mged/archer depends on plot |
| 17:44.10 | Izak__ | s/ont/Not |
| 17:44.23 | *** join/#brlcad kesha (~kesha@49.249.16.85) | |
| 17:47.09 | Izak__ | ``Erik: How can i shot rays towards the center of th hrt for example ? |
| 17:47.36 | Izak__ | Selecting the particular values to serve roots_example is hard |
| 17:50.33 | brlcad | Izak__: that's really great news |
| 17:50.46 | Izak__ | brlcad: really / |
| 17:51.06 | brlcad | why I said the first step was to just see what the solver does |
| 17:51.12 | Izak__ | I think its going to be great news when i see a heart wireframe or sth |
| 17:51.15 | brlcad | the method it uses is very general |
| 17:51.26 | brlcad | now whether it'll work for your poly is still very much in question |
| 17:51.30 | brlcad | it'd be interesting to test a sextic with non-imaginary roots (as in your case) |
| 17:51.52 | brlcad | well the heart wireframe does not involve solving any roots ;) |
| 17:52.14 | brlcad | that's code you'll have to write, basically need the parametric form of that same equation |
| 17:52.17 | brlcad | usually far simpler |
| 17:52.41 | Izak__ | ok |
| 17:52.42 | brlcad | ah, looks like mathworld just gives it to you |
| 17:52.44 | brlcad | http://mathworld.wolfram.com/HeartCurve.html |
| 17:53.49 | Izak__ | I see it. But nothing is said about z variable |
| 17:54.53 | brlcad | <PROTECTED> |
| 17:55.33 | *** join/#brlcad harmanpreet (~chatzilla@124.253.150.197) | |
| 17:55.42 | brlcad | oh nice http://www.wolframalpha.com/input/?i=heart+curve&lk=1&a=ClashPrefs_*PlaneCurveClass.Heart- |
| 17:56.01 | brlcad | wonders if our solver can do degree 8 ... |
| 17:56.39 | Izak__ | I'm optimistic since it does for arbitrary n |
| 17:57.33 | Izak__ | Thereal issue is that roots array contained 4 elements . I changed that to BN_MAX_DEGREE |
| 17:57.49 | brlcad | almost certainly unstable near the bottom point |
| 17:57.59 | brlcad | i saw |
| 17:58.10 | ``Erik | if it weren't for the static input/output vectors, ... (maybe have static buffers for up to N, then a couple pointers for n>N ?) |
| 17:59.44 | Izak__ | ``Erik: I dont understand |
| 18:00.07 | brlcad | Izak__: hate to say it, but you will probably just have to solve for x= y= z= from the implicit |
| 18:00.24 | brlcad | http://en.wikipedia.org/wiki/File:Heart3D.png |
| 18:00.39 | ``Erik | Izak__: I'm just speculating on an approach to handle arbitrary polynomials... it doesn't impact your current task, just a general musing :) |
| 18:01.35 | Izak__ | brlcad: you don't need to hate to say it :) |
| 18:01.52 | Izak__ | ``Erik: Thanks |
| 18:03.31 | ``Erik | Izak__: generating the wireframe should be fairly easy, as should the bounding box... those're probably your next two tasks (you'll need the bounding box during the prep phase, which will be called before the shot() function) |
| 18:04.43 | Izak__ | ``Erik: Thanks. Please could you llook at hrt.c code on trunk. Maybe I have done some of that bbox and prep |
| 18:05.21 | brlcad | maybe? you don't know? :) |
| 18:05.53 | Izak__ | It's just politeness brlcad: I already wrote those callbacks |
| 18:06.49 | brlcad | hm, doesn't come off as sounding polite, sounds unsure -- thx for the clarification |
| 18:07.09 | ``Erik | aha, didn't realize the bbox func has already had some meat to it... not sure it's quite right, almost looks like the center of the box is always the origin? what if the primitive is offset? |
| 18:10.36 | Izak__ | Which portion of the code indicated that the center of the box is always the origin ? ``Erik: |
| 18:11.50 | ``Erik | n/m, was reading it wrong :) brain isn't quite here today |
| 18:15.05 | kesha | 08:35.36kesha__Hello brlcad |
| 18:15.09 | kesha | 08:36.02kesha__I tried with some more geometry conversions. Still some queries .. |
| 18:15.09 | kesha | 08:37.05kesha__Many a times, when I do export, some objects are exported correctly, but it shows a message of segmentation fault(core dumped) and stops (almost 40-50% of those I tried) |
| 18:15.09 | kesha | 08:37.15kesha__The material property disappears after conversion. The mater and color related information is lost after conversion. |
| 18:15.11 | kesha | 08:37.38kesha__I tried from http://brlcad.org/private/geometry/ |
| 18:15.12 | kesha | 08:37.50kesha__http://brlcad.org/private/geometry/3dm_Geometry/ |
| 18:15.14 | kesha | 08:38.46kesha__I also installed freecad. |
| 18:15.15 | kesha | 08:39.56kesha__Whenever you are free, can you please walk me through 1 or 2 examples of *perfect 3D model importing* ? |
| 18:15.25 | kesha | brlcad: there ? |
| 18:31.23 | Izak__ | brlcad: I have solved for x = y = z from the implicit equation and it has given this http://paste.kde.org/pd52b8d11/ |
| 18:31.48 | Izak__ | thinking of trying it out in roots_example.c |
| 18:49.39 | Notify | 03BRL-CAD:starseeker * 57475 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Gah. Looks like we will need an aggregate to 'properly' define rational bspline curves. |
| 18:50.07 | Notify | 03BRL-CAD:starseeker * 57476 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Appending is taken care of elsewhere. |
| 18:50.29 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6101 /wiki/User:Izak/GSOC_2013_logs: /* September 2nd to September 7th */ |
| 18:54.18 | brlcad | kesha: I replied to all of that commentary, but you either missed it or weren't online |
| 18:54.43 | brlcad | kesha: you keep saying export |
| 18:54.49 | brlcad | what's the difference between export and import? |
| 18:56.14 | brlcad | encountering a segmentation fault message is completely useless without knowing the command you ran, what data you had, and (most importantly) obtaining a stack trace |
| 18:57.04 | brlcad | helps if it's reproducible but really it just has to be actionable information, just not "something failed and I don't know why" |
| 18:58.56 | brlcad | the color properties disappearing is not at all relevant to the task at hand |
| 19:00.08 | brlcad | Izak__: oof, I think I wrote poorly and you misunderstood what I meant |
| 19:00.40 | brlcad | Izak__: you need to end up with three equations ... x = something; y = something; and z = something; |
| 19:00.45 | Izak__ | What did you mean to say then ? |
| 19:01.14 | brlcad | usually as a function of some u,v parameterization, then u,v are iterated from 0 to 2*PI or some other range |
| 19:02.23 | brlcad | Izak__: for example, consider a sphere |
| 19:03.06 | brlcad | the implicit equation is x^2 + y^2 + z^2 - R^2 = 0 |
| 19:03.13 | brlcad | the parametric however is |
| 19:03.45 | brlcad | x = sqrt(R^2 - u^2) * cos(v) |
| 19:04.02 | brlcad | y = sqrt(R^2 - u^2) * sin(v) |
| 19:04.09 | brlcad | z = u |
| 19:04.21 | brlcad | or something really close to that ;) |
| 19:08.26 | Izak__ | brlcad: What about this http://paste.kde.org/p769e6aaa/ |
| 19:13.52 | kesha | oh, I think I missed the reply then ! My bad- export means the one we convert from our format to other and import is one we convert from other format to ours. |
| 19:14.57 | kesha | Can you walk me through an example of perfect 3D model importing ? |
| 19:23.19 | *** join/#brlcad kesha_ (~kesha@49.249.0.235) | |
| 19:24.46 | Izak__ | awaiting brlcad: 's opinion as to heart parametric equations |
| 19:26.13 | Notify | 03BRL-CAD:vladbogo * 57477 (brlcad/trunk/src/libdm/dm_obj.c brlcad/trunk/src/libtclcad/tclcad_obj.c): Default for framebuffer interface - handle unsupported display manager and framebuffer combinations by D.Rossberg |
| 19:27.42 | Notify | 03BRL-CAD:vladbogo * 57478 brlcad/trunk/src/libdm/dm-qt.cpp: Set locale to POSIX after open is called + use a single QPainter instead of creating one everytime a drawing is made. |
| 19:28.25 | brlcad | Izak__: i'm not sure what you want opinionwise :) |
| 19:28.32 | brlcad | it's either right or it's not ;) |
| 19:29.09 | Izak__ | So what exactly do i do to test hrt_shot with those parametric equations |
| 19:29.12 | brlcad | that's basically what you need to implement plot() though, so you could add it in and evaluate from 0,2PI and see what it looks like |
| 19:29.33 | brlcad | shot() is different |
| 19:29.44 | brlcad | shot() requires the implicit equation, the root solver, what you've done |
| 19:30.20 | brlcad | plot() is usually implemented using the parametric form since you want to generate polylines or polygons or points; something explicit on the surface |
| 19:30.28 | brlcad | implict vs explicit |
| 19:31.03 | brlcad | Izak__: now that you've demonstrated that the solver is *capable* of solving a sextic, you can test whether your shot() implementation is correct |
| 19:31.20 | brlcad | Izak__: run 'rt' outside of mged, feed it the name of a hrt object |
| 19:31.45 | Izak__ | Out of mged ? brlcad: how ? |
| 19:32.15 | brlcad | Izak__: then in between fits of debugging shot(), you can work on implementing plot() using your parametric equations |
| 19:33.14 | brlcad | brlman rt or just "rt" |
| 19:33.23 | brlcad | gives usage, very simple |
| 19:33.29 | brlcad | try with a sphere first |
| 19:33.40 | brlcad | mged -c test.g make sph sph |
| 19:33.42 | brlcad | rt test.g sph |
| 19:34.27 | Izak__ | in which directory ? |
| 19:35.58 | Notify | 03BRL-CAD Wiki:Vladbogolin * 6102 /wiki/User:Vladbogolin/GSoC2013/Logs: /* Week 12 */ |
| 19:37.43 | brlcad | Izak__: you should know that by now... |
| 19:37.55 | brlcad | in any directory you like |
| 19:38.05 | Izak__ | okay fine |
| 19:40.12 | brlcad | sorry, just really cannot answer that without asking you a half dozen questions |
| 19:40.28 | brlcad | you can build and run from/into anywhere, it's fully configurable and YOU decide that |
| 19:40.33 | brlcad | so only you can answer that |
| 19:41.41 | brlcad | it's like asking me which bed you should sleep in, well yours of course! (or your partner's) |
| 19:44.40 | brlcad | and at a glance, those parametric equations looks like they're probably not right, but easy enough to try (in fact you could put the equations into sage, and try them first) |
| 19:45.07 | brlcad | several apps like mathematica will graph parametric equations automatically for you |
| 19:50.14 | Notify | 03BRL-CAD Wiki:IIIzzzaaakkk * 6103 /wiki/User:Izak/GSOC_2013_logs: /* September 2nd to September 7th */ |
| 19:50.52 | Izak__ | brlcad: After trying rt on a heart object I get http://brlcad.org/~Izak/heart.png |
| 19:52.24 | brlcad | that's pretty cool actually, progress |
| 19:52.47 | brlcad | try different azimuths and elevations |
| 19:52.56 | brlcad | or create an animation to see it rotating |
| 19:53.16 | brlcad | http://brlcad.org/wiki/Animation |
| 19:55.55 | brlcad | at a glance, I'd say the equations aren't right but it's hard to say at that angle |
| 19:56.34 | brlcad | clearly lots of root solver failures too, but the basic shape should hopefully become apparent |
| 20:03.13 | Notify | 03BRL-CAD:indianlarry * 57479 brlcad/branches/nurbs/src/librt/primitives/brep/brep.cpp: playing with surf subdivision and reusing surface without malloc still WIP |
| 20:31.12 | *** join/#brlcad kesha__ (~kesha@49.249.0.235) | |
| 20:34.18 | *** join/#brlcad kesha__ (~kesha@49.249.0.235) | |
| 20:35.36 | brlcad | kesha__: the task was to *find* a few models that import correctly, so if I walk you through an example of that, I've done the task |
| 20:36.46 | brlcad | it's not uncommon for certain types of models to fail, but the point is just to find one or two that seem to import "okay" |
| 20:37.09 | brlcad | with "okay" meaning the general solid shapes import (we only care about 3D and only care about SOLID geometry) |
| 20:37.27 | brlcad | non-solid and 2D shapes will often fail horribly |
| 20:37.48 | brlcad | even 3D shapes will sometimes fail, that's why you just keep focusing on one format and find just one or two that work |
| 21:02.52 | ``Erik | https://twitter.com/DamienFahey/status/376050043720978432 @DamienFahey: Congratulations, Americans who write "Cheers" at the end of e-mails. You've found something even more pretentious than "Sent from my iPhone" |
| 21:05.44 | *** join/#brlcad kesha__ (~kesha@49.249.0.235) | |
| 22:16.42 | Notify | 03BRL-CAD:starseeker * 57480 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Add control point lists and curve types. |
| 22:28.15 | Notify | 03BRL-CAD:starseeker * 57481 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Set closed_curve and self_intersect flags |
| 22:31.02 | *** join/#brlcad mpictor (~mark@2601:d:b280:3d4:d63d:7eff:fe2d:2505) | |
| 22:42.44 | Notify | 03BRL-CAD:starseeker * 57482 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Add knots |
| 22:50.03 | Notify | 03BRL-CAD:starseeker * 57483 brlcad/trunk/src/conv/step/g-step/ON_Brep.cpp: Add the weights. Not quite correct yet, but definitely closer. |
| 22:56.37 | *** join/#brlcad caen23 (~caen23@92.81.182.233) | |
| 23:17.34 | brlcad | ``Erik: heh, Cheers! |
