| 00:02.09 | *** join/#brlcad madant_ (n=d@117.196.130.205) |
| 02:37.46 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) |
| 03:15.34 | brlcad | starseeker: hehe, cool |
| 03:42.22 | CIA-28 | BRL-CAD: 03brlcad * r34437 10/brlcad/trunk/src/librt/primitives/pipe/pipe.c: ws indent style cleanup plus consistently wrap all of the (*nh) to be encased consistently in wraps. |
| 04:52.40 | *** join/#brlcad madant (n=d@117.196.134.144) |
| 05:12.29 | *** join/#brlcad elena (n=elena@92.86.0.28) |
| 05:24.25 | elena | ~log |
| 05:24.26 | ibot | methinks log is http://ibot.rikers.org/%23wowhead/ |
| 05:55.53 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 06:04.19 | *** join/#brlcad madant (n=d@117.196.129.202) |
| 07:09.50 | *** join/#brlcad _clock_ (n=_sushi_@zux221-122-143.adsl.green.ch) |
| 08:54.27 | *** join/#brlcad Elrohir (n=kvirc@91.20.251.16) |
| 10:34.12 | *** join/#brlcad madant_ (n=d@117.196.131.200) |
| 10:46.39 | *** join/#brlcad Mouette (n=chatzill@122-116-39-75.HINET-IP.hinet.net) |
| 10:51.38 | *** join/#brlcad CIA-28 (n=CIA@208.69.182.149.simpli.biz) |
| 11:30.32 | d-lo | brlcad & ``Erik: something as small as that lotus, doing 0-120mph in 7 seconds, is frightening to say the least... |
| 11:31.25 | d-lo | Ralith: FORTRAN is good, just make sure the GUI is scriptable with VBA. |
| 11:40.51 | *** join/#brlcad elite01 (n=omg@unaffiliated/elite01) |
| 11:40.59 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 11:48.55 | CIA-28 | BRL-CAD: 03indianlarry * r34438 10/brlcad/trunk/src/conv/step/Makefile.am: fixing step-g build |
| 12:25.09 | brlcad | notes that apparently broke the build (possibly just distcheck) |
| 12:30.05 | d-lo | brlcad: are you talking about r34438? |
| 12:30.55 | brlcad | yep |
| 12:31.46 | brlcad | can you take a look, https://pawl.arl.army.mil/cruisecontrol/builds/brlcad-trunk/34438 |
| 12:32.30 | brlcad | should be able to expand the log, get details at the bottom |
| 12:33.59 | d-lo | ...the only thing I see is a warning. No errors. Additionally, is it a bad sign that it builds fine on my machine? ;) |
| 12:34.44 | brlcad | what's the warning? |
| 12:35.01 | d-lo | "config.status: WARNING: Makefile.in seems to ignore the --datarootdir setting " |
| 12:35.10 | brlcad | it's not a bad sign, you're not testing nearly as much as the regression test is |
| 12:35.58 | brlcad | could be a cruisecontrol hiccup -- look at the latest log (take off /34438 from the url) |
| 12:36.15 | brlcad | looks like it may have been interrupted and restarted as there is a .1 |
| 12:37.46 | brlcad | build is fine here too, so it could be a false positive .. the full tests take a half hour though so won't know for a bit |
| 12:38.02 | d-lo | strange. I am no expert (duh) but it lookes like once the ./configure is complete, it fires off a distclean and then stops in the middle of it. |
| 12:39.11 | brlcad | ehm, are you looking at the full log? |
| 12:40.04 | d-lo | strangeness. interweb hiccup. F5 for the win. |
| 12:41.38 | d-lo | is the regression testing using Automake v1.10 on purpose? Seems a bit old. |
| 12:42.48 | brlcad | no, it's just using the system default |
| 12:42.50 | brlcad | 1.10 is fine |
| 12:43.06 | brlcad | in fact, ours should even work all the way through 1.6 |
| 12:43.27 | brlcad | autogen has version validation checks |
| 12:43.36 | d-lo | well this machine has 1.9.6 installed and it seems to be working just fine. |
| 12:44.13 | brlcad | eh |
| 12:44.15 | brlcad | missing something |
| 12:44.20 | brlcad | what did the cc log say? |
| 12:44.46 | brlcad | it's what's saying it failed, that's all that really matters to check |
| 12:45.17 | brlcad | repost it to pastebin |
| 12:47.28 | d-lo | http://pastebin.bzflag.bz/m1ed56600 |
| 12:48.15 | brlcad | make[3]: ../../../src/other/step/src/fedex_plus/fedex_plus: Command not found |
| 12:48.28 | brlcad | thats the error |
| 12:48.35 | d-lo | right, I figured :) |
| 12:50.33 | brlcad | trying to build the fedex sources, yours probably skips that build rule on a regular build, but those sources are needed for a distcheck |
| 12:51.03 | brlcad | s/probably skips/is skipping/ |
| 12:54.06 | brlcad | he needs to try a distcheck |
| 12:54.39 | d-lo | to be clear: make distcheck should recreate the same error that cc is reporting? |
| 12:55.22 | brlcad | I believe so, think the problem is just that built_sources is in extra_dist |
| 12:56.18 | brlcad | ah, he added them to SOURCES, so yeah that means they need to be in the dist |
| 13:00.36 | CIA-28 | BRL-CAD: 03brlcad * r34439 10/brlcad/trunk/src/conv/step/Makefile.am: annotate three FIXME's in this file that should help with the distchecking and build cleanup |
| 13:12.09 | *** join/#brlcad madant (n=d@117.196.130.64) |
| 13:28.45 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 13:29.17 | *** join/#brlcad phyTurtle (n=turtle@pooh.korea.ac.kr) |
| 13:33.12 | *** join/#brlcad Mouette (n=chatzill@122-116-39-75.HINET-IP.hinet.net) [NETSPLIT VICTIM] |
| 13:33.12 | *** join/#brlcad _clock_ (n=_sushi_@zux221-122-143.adsl.green.ch) [NETSPLIT VICTIM] |
| 13:45.13 | CIA-28 | BRL-CAD: 03starseeker * r34440 10/brlcad/branches/STABLE/src/librt/primitives/pipe/pipe.c: Add the key pipe fix to stable - looks like trunk has some of the ifree tweaks in it so wait for a proper merge to sync pipe.c with the trunk pipe.c |
| 13:58.04 | *** join/#brlcad mafm (n=mafm@223.Red-83-49-86.dynamicIP.rima-tde.net) |
| 13:58.40 | mafm | hi |
| 14:17.05 | phyTurtle | Hi, I'm a newcomer of using brlcad |
| 14:17.28 | elena | hi |
| 14:17.45 | phyTurtle | nowadays, I'm learning using brlcad following tutorial. |
| 14:18.54 | phyTurtle | Also, I read some source code to see what I can contribute to code. |
| 14:19.54 | phyTurtle | However, I couldn't where I can start. |
| 14:20.21 | elena | you could try to fix a small bug |
| 14:20.37 | phyTurtle | So, dose anybody tell me a starring point? |
| 14:20.44 | phyTurtle | bugs? |
| 14:21.03 | elena | if you want to contribute. |
| 14:21.22 | elena | if you want to learn how to use it, the tutorial is a great place to start. |
| 14:21.55 | phyTurtle | then how about learing the mechanism of the program? |
| 14:22.18 | phyTurtle | is bug fixing still good way to learing it? |
| 14:22.35 | elena | I can't answer that. |
| 14:22.47 | elena | but I guess it depends on you. |
| 14:23.12 | elena | do you feel you're learning by tracking bugs. |
| 14:23.14 | elena | ? |
| 14:23.53 | phyTurtle | well.... |
| 14:24.02 | ``Erik | there're ~400 executables, many libraries... it's a big package, you'd have to figure out which part you're interested in before really jumping in... :) |
| 14:24.03 | phyTurtle | Yes.. Many times.. |
| 14:24.31 | phyTurtle | Actually, I am a physicist. |
| 14:24.43 | elena | waves ``Erik |
| 14:24.44 | phyTurtle | So, I'm not good at programming.. |
| 14:24.50 | starseeker | howdy elena |
| 14:24.51 | ``Erik | *wave* |
| 14:24.57 | elena | hi starseeker. |
| 14:25.15 | ``Erik | c'mon, starseeker, stand up and sit down, we're doing the wave here :D |
| 14:25.25 | elena | than jumping right to bugs might not be a good idea. |
| 14:25.31 | elena | than => then |
| 14:25.44 | starseeker | crushes chairs doing that |
| 14:25.46 | phyTurtle | hmm.. |
| 14:26.32 | elena | did you managed to checkout and build brlcad? |
| 14:27.08 | elena | btw, fyi, i'm a brlcad user, not programmer. |
| 14:27.54 | phyTurtle | sorry, pardon? I can't follow you.. what is fyi? |
| 14:28.03 | ``Erik | "for your information" |
| 14:28.05 | elena | for your information |
| 14:29.02 | elena | btw = by the way. |
| 14:30.54 | phyTurtle | do you mean that I installed on my system with source code? |
| 14:31.06 | elena | yes. |
| 14:31.09 | phyTurtle | yes |
| 14:31.20 | elena | what's your system, btw. just curious. |
| 14:31.25 | phyTurtle | I used source code and built on my linux system |
| 14:31.31 | phyTurtle | ubuntu 8.04 |
| 14:31.39 | elena | ok. that's a good start. |
| 14:31.51 | phyTurtle | thanks |
| 14:32.03 | starseeker | phyTurtle: what are your interests? CAD is a big field, do you have specific subject areas in mind? |
| 14:32.09 | phyTurtle | yes |
| 14:32.23 | phyTurtle | I am developing FDTD library |
| 14:32.39 | brlcad | howdy phyTurtle |
| 14:32.45 | brlcad | and welcome! |
| 14:32.54 | phyTurtle | Finite Difference Time domain method which is a Electromagnetic simulation algorithm |
| 14:32.55 | d-lo | hai phyTurtle! |
| 14:33.03 | phyTurtle | hello. |
| 14:33.07 | d-lo | regular party up in here. |
| 14:33.40 | starseeker | phyTurtle: Is your interest to integrate that method with the physical geometry abilities of a CAD system? |
| 14:33.51 | phyTurtle | In the FDTD Library, inserting structure is horrible task. |
| 14:34.14 | phyTurtle | especially 3D structure simulation. |
| 14:34.49 | phyTurtle | So I seek some software which could modle solid structure |
| 14:35.07 | phyTurtle | modle->model |
| 14:35.09 | starseeker | what sort of structural information do you need for a FDTD analysis? surfaces, volumes, triangles... |
| 14:35.39 | phyTurtle | Just the info of mesh point |
| 14:36.07 | starseeker | ok, so the geometry problem is merging meshes? |
| 14:36.09 | phyTurtle | FDTD use rectangular mesh to model electric field and magnetic field |
| 14:36.13 | phyTurtle | yes |
| 14:36.16 | brlcad | phyTurtle: are you at all interested in data processing (like wavelets, FFTs, etc) or mostly modeling and/or geometry? |
| 14:36.27 | phyTurtle | mostly geometry |
| 14:37.00 | phyTurtle | I need info of points which intersect with solid objects |
| 14:37.03 | brlcad | cool, then a great starting point (on the programming side) is our procedural modeling facilities |
| 14:37.14 | brlcad | maybe starting out with a little program that "makes something" |
| 14:37.23 | phyTurtle | ok.. |
| 14:37.34 | brlcad | there are lots of examples to get you started, but that's one area that's pretty well defined and easy to get into |
| 14:37.56 | phyTurtle | well I have found that 'NIRT' do the task I need |
| 14:38.16 | brlcad | are you specifically interested in programming or are you looking for how you can "get things done" for whatever your end goals are? |
| 14:38.31 | brlcad | like the difference between writing an app or writing a script that does the same thing |
| 14:38.46 | phyTurtle | Well shot goal is find the points which intersect the objedts.. |
| 14:39.12 | brlcad | scripting nirt is a great way to sample geometry, get in/out hit points along a given line as it intersects geometry |
| 14:39.20 | phyTurtle | and the great goal is joining the brlcad programming.. |
| 14:39.26 | brlcad | :) |
| 14:39.41 | brlcad | but then to shoot nirt .. you need to have geometry to shoot at |
| 14:39.44 | brlcad | what is your data now? |
| 14:39.59 | brlcad | in your head? design specs? models in other cad formats? |
| 14:39.59 | starseeker | wait... do you have pre-existing meshes you need to intersect rays with, or do you actually need to merge two distinct meshes into a single mesh? |
| 14:41.29 | phyTurtle | my plan is using brlcad, modelling simulation structure first |
| 14:42.11 | phyTurtle | second, defining mesh (ray) which I want know intersection points |
| 14:42.36 | phyTurtle | third, saving intersecting points for each mesh grid. |
| 14:42.59 | brlcad | so you have some running simulation code, then, and from that simulation you already have geometry or you will need to derive geometry? |
| 14:43.19 | phyTurtle | brfore the simulation. |
| 14:43.49 | phyTurtle | I should define the geometry. |
| 14:43.51 | brlcad | so you're going to model something and put it into a simulation |
| 14:43.54 | brlcad | okay |
| 14:43.56 | phyTurtle | yes |
| 14:44.08 | phyTurtle | It is not time running modeling. |
| 14:45.18 | phyTurtle | I just skimed the nirt tutorial. |
| 14:45.19 | brlcad | so some sort of way to represent an electric field and a magnetic field |
| 14:45.43 | phyTurtle | well.. |
| 14:45.53 | phyTurtle | for example. |
| 14:46.15 | phyTurtle | I put the dielectric sphere ball in the space. |
| 14:46.46 | phyTurtle | and insert incident wave(initial condition) |
| 14:47.14 | phyTurtle | later, by the dielectric sphere, electric field and magnetic field is changed. |
| 14:47.25 | phyTurtle | I need to model the dielectric sphere. |
| 14:47.32 | phyTurtle | not the field info. |
| 14:49.58 | phyTurtle | Some of FDTD developer used AutoCad or ACIS to model the dielectric sphere. |
| 14:50.24 | phyTurtle | So, I searched similar library and I found brlcad. |
| 14:54.03 | elena | have to go. bye |
| 14:54.09 | d-lo | bye! |
| 14:54.10 | brlcad | cya elena! |
| 14:54.25 | elena | good luck, phy. let me know how it goes. |
| 14:54.29 | phyTurtle | bye! |
| 14:54.31 | phyTurtle | yes |
| 14:54.51 | brlcad | phyTurtle: ever worked with metaballs? |
| 14:55.05 | phyTurtle | no |
| 14:55.07 | brlcad | http://brlcad.org/gallery/s/renderings/primitives/niceballs.png.html |
| 14:55.29 | brlcad | promises that it's safe for work :) |
| 14:55.31 | CIA-28 | BRL-CAD: 03davidloman * r34441 10/brlcad/trunk/src/other/step/src/clstepcore/ (sdaiSelect.cc sdaiSelect.h): Changed a return type from int to long in order to support building on 64bit hardware. |
| 14:56.43 | phyTurtle | what is metaball? |
| 14:57.20 | phyTurtle | now I'm looking the image.. but I can't figure out what it is.. |
| 14:59.40 | brlcad | another example: http://www.math.sunysb.edu/%7Esorin/online-docs/blender/html/x2708.html |
| 15:00.08 | brlcad | basically they are points with a 'weight' .. that then cause volumes and field effects |
| 15:01.23 | brlcad | so that you get blended volume between your field points |
| 15:02.02 | brlcad | ah, here we go.. some nice examples: http://sayinghai.com/metaballs3d.html |
| 15:06.28 | phyTurtle | is metaball using raytracing too? |
| 15:09.01 | phyTurtle | I need the info that if a ray intersect a solid, what the intersection point is, on rectangular coordinate. |
| 15:09.53 | phyTurtle | I think I need to study elimentary computational geometry and ray tracing. |
| 15:10.36 | phyTurtle | so, could you recommand me some reference? book or paper..? |
| 15:25.05 | brlcad | yes, you can shoot a nirt ray at a metaball too |
| 15:25.27 | brlcad | it does represent a solid with defined inside/outside characterization |
| 15:28.30 | brlcad | really don't think studying computational geometry or ray tracing is going to help you get up to speed, but there are lots of great books and papers (thousands really) .. |
| 15:29.11 | phyTurtle | ok. thanks^^ |
| 15:29.24 | phyTurtle | now I should go. |
| 15:29.35 | phyTurtle | here is 24:30 now. |
| 15:29.57 | phyTurtle | see you later . bye! |
| 15:29.58 | brlcad | okay, good talking to you |
| 15:30.07 | brlcad | someone's generally always here ;) |
| 15:30.08 | brlcad | cya |
| 15:30.20 | phyTurtle | thanks. bye |
| 15:32.47 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) |
| 15:34.24 | starseeker | was thinking mesh intersections would be a good excuse to integrate GTS |
| 15:35.50 | starseeker | It's not a problem with the pipe solid data - it's a problem with how the pipe code was handling one particular case in the shot results. If you raytrace from a slightly different view you might avoid the problematic case, but odds are equally good you'll still run into it. |
| 15:35.54 | starseeker | I'll push the fix into the STABLE branch this morning, but I don't think there's anything you can do to the pipe itself to avoid the bug. |
| 15:36.00 | starseeker | whoops |
| 15:36.01 | starseeker | sorry |
| 15:37.27 | starseeker | mutters under his breath about text selection integration on Mac between X11 and normal apps... |
| 15:37.52 | starseeker | Anyway, http://gts.sourceforge.net/gallery.html shows some examples of mesh intersections, unions, subtractions, etc |
| 15:46.37 | CIA-28 | BRL-CAD: 03bob1961 * r34442 10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added scale_ell.c and scale_tor.c to the libged build file for windows. |
| 15:51.33 | CIA-28 | BRL-CAD: 03bob1961 * r34443 10/brlcad/trunk/misc/win32-msvc8/librt/librt.vcproj: Modified the windows build file for librt (i.e. mirror.c and table.c have moved). |
| 17:07.37 | *** join/#brlcad Mouette (n=chatzill@fw1.phys.sinica.edu.tw) |
| 17:23.22 | CIA-28 | BRL-CAD: 03bob1961 * r34444 10/brlcad/trunk/misc/win32-msvc8/ (19 files in 19 dirs): Mods to accommodate new files, moved files and deleted files. |
| 17:29.26 | CIA-28 | BRL-CAD: 03bob1961 * r34445 10/brlcad/trunk/src/ (archer/archer.bat mged/mged.bat util/rtwizard.bat): Update to 7.14.7 |
| 17:30.52 | CIA-28 | BRL-CAD: 03bob1961 * r34446 10/brlcad/trunk/ (7 files in 5 dirs): Added code to edit torus attributes in Archer via the mouse. |
| 18:19.52 | *** join/#brlcad _sushi_ (n=_sushi_@77-58-230-110.dclient.hispeed.ch) |
| 18:33.22 | CIA-28 | BRL-CAD: 03bob1961 * r34447 10/brlcad/trunk/src/librt/primitives/metaball/metaball.c: Have rt_metaball_point_value_metaball return something to make the compiler happy. |
| 18:35.22 | CIA-28 | BRL-CAD: 03bob1961 * r34448 10/brlcad/trunk/include/raytrace.h: Put back declarations for rt_pipept_print and rt_metaballpt_print. |
| 18:37.48 | CIA-28 | BRL-CAD: 03bob1961 * r34449 10/brlcad/trunk/src/fb/fbfade.c: Do an #ifndef drand48 before defining a drand48 function. |
| 19:06.45 | CIA-28 | BRL-CAD: 03bob1961 * r34450 10/brlcad/trunk/src/proc-db/ (terrain.c vegitation.c): Do an #ifndef drand48 before defining a drand48 function. |
| 19:21.47 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-199.sbndin.btas.verizon.net) |
| 19:23.18 | CIA-28 | BRL-CAD: 03brlcad * r34451 10/brlcad/trunk/NEWS: |
| 19:23.18 | CIA-28 | BRL-CAD: this one is borderline user-visible but does impact the style/appearance of mged |
| 19:23.18 | CIA-28 | BRL-CAD: and archer so go ahead and mention it. bob worked on converting several/many of |
| 19:23.18 | CIA-28 | BRL-CAD: the widgets in archer and a couple in mged over to using the new tk 'ttk' |
| 19:23.18 | CIA-28 | BRL-CAD: widgets. ttk is a new modular themable widget system developed for tcl/tk 8.5. |
| 19:23.20 | CIA-28 | BRL-CAD: these new widgets even further make BLT unnecessary. |
| 20:15.58 | CIA-28 | BRL-CAD: 03brlcad * r34452 10/brlcad/trunk/src/fb/fbfade.c: consistency cleanup, remove ancient irrelevant docs |
| 20:17.39 | CIA-28 | BRL-CAD: 03brlcad * r34453 10/brlcad/trunk/src/fb/fbfade.c: it's already wrapped, kinda silly to double-wrap it |
| 20:18.21 | CIA-28 | BRL-CAD: 03brlcad * r34454 10/brlcad/trunk/include/config_win.h: it's provided as a define for windows, so define HAVE_DRAND48 to true |
| 20:19.17 | CIA-28 | BRL-CAD: 03bob1961 * r34455 10/brlcad/trunk/include/ (common.h opennurbs_ext.h): Mods for building on Windows. |
| 20:33.17 | CIA-28 | BRL-CAD: 03brlcad * r34456 10/brlcad/trunk/src/proc-db/ (terrain.c vegitation.c): ya killin' me bob. revert r34450. HAVE_DRAND48 is now defined per config_win.h so shouldn't need all that hackery and code duplication. if you need the same code in more than one place, it's the wrong way. |
| 20:35.57 | CIA-28 | BRL-CAD: 03indianlarry * r34457 10/brlcad/trunk/src/conv/step/Makefile.am: reverting back to revision 34408 to fix distcheck on cruisecontrol will clean up monday |
| 20:36.12 | CIA-28 | BRL-CAD: 03brlcad * r34458 10/brlcad/trunk/src/proc-db/terrain.c: should be the other way around. rand_s() is very windowsy. some minor ws cleanup too. |
| 20:48.27 | ``Erik | ah, dave applied the fix to src/other/step that I was about to dig into (I think it's treating it like a boolean, so the extra precision is unnecessary) |
| 21:04.29 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) |
| 21:53.34 | *** join/#brlcad rincon (n=alvaro@190.77.167.45) |
| 21:53.44 | *** join/#brlcad BxCx (n=BxCx@189.182.244.112) |
| 21:55.15 | rincon | does brl cad has dimensioning facilities, distance measuring tools, and precision enough to make engineering 2d drawings |
| 21:58.26 | *** part/#brlcad BxCx (n=BxCx@189.182.244.112) |
| 22:00.01 | brlcad | rincon: there are very limited dimensioning facilities (at least for producing 2d drawings), nothing automatic |
| 22:00.12 | brlcad | there are various measuring tools, though, very good ones at that |
| 22:00.37 | brlcad | there's also automatic drawing generation, just unannotated |
| 22:00.49 | brlcad | e.g., http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html |
| 22:01.24 | brlcad | if you wanted to add annotations for dimensions, though, you'd have to calculate them and add them to the image manually |
| 22:01.38 | brlcad | would be a great addition for someone to make, but to date hasn't happened |
| 22:01.50 | rincon | verical horizontal and radial are enough dimensioning facilities for me, does it has it? |
| 22:02.11 | brlcad | ``Erik: you should fix that better .. that pointer->int/long cast seems wrong |
| 22:02.22 | brlcad | make it return a bool if it's a bool |
| 22:02.52 | brlcad | rincon: yeah, those are easy to calculate -- you can create a bounding box around any arbitrary object and get the dimensions of that box |
| 22:03.27 | brlcad | could even probably script them together so it's a one step operation if you really needed to call it a lot |
| 22:03.42 | rincon | brlcad: what i mean is to draw dimensioning symbols |
| 22:04.30 | rincon | like basic dimensioning autocad facilities does? |--------| ...... |
| 22:05.29 | brlcad | starseeker: for those particular cases, gts provides nothing that nmg doesn't already do |
| 22:05.48 | brlcad | and even better, our nmg routines should do much better to preserve solidity (gts doesn't care) |
| 22:06.29 | *** join/#brlcad Elrohir (n=kvirc@p5B14FB10.dip.t-dialin.net) |
| 22:06.51 | brlcad | rincon: i know what you mean -- that's what I was referring to with "you'd have to calculate them and add them to the image manually" |
| 22:07.13 | brlcad | calculating the dimension is done fairly easily, but not automatic, and not graphically |
| 22:07.36 | brlcad | you'd have to add whatever dimensions you want to the image manually |
| 22:08.10 | brlcad | that's more a drafting feature, so we just haven't had a lot of demand/priority for it compared to other issues |
| 22:08.30 | rincon | does brl cad has the capability of drawing a circle of radius 0.0000001 ? |
| 22:08.38 | brlcad | sure |
| 22:09.41 | brlcad | have to keep absolute units into account, though |
| 22:09.58 | brlcad | all values are stored as mm, so you'd have to be working in a larger scale |
| 22:10.49 | rincon | brlcad: can you draw in m in brlcad? |
| 22:10.51 | brlcad | you can shift the scale by setting a much larger working scale to the model |
| 22:10.57 | brlcad | sure |
| 22:10.58 | rincon | meters? |
| 22:11.01 | brlcad | "units m" |
| 22:11.13 | brlcad | you can arbitrarily change your units as needed |
| 22:11.24 | rincon | that is good |
| 22:12.16 | brlcad | it's common that a modeler will have part data for one object in meters, another in feet, yet another part in mm .. you just set units while you work and everything is seamless |
| 22:12.44 | rincon | brlcad: in that particular is better than autocad |
| 22:13.25 | brlcad | we're better than autocad in *many* ways under the hood .. |
| 22:13.35 | brlcad | we're just a lot worse with regards to GUI and usability :) |
| 22:13.49 | rincon | brlcad: the dimensioning part needs more collaboration |
| 22:13.59 | brlcad | sure, you going to work on it? :) |
| 22:14.34 | rincon | brlcad: i do not have enough time, by now by i'd like to |
| 22:14.43 | rincon | by=but |
| 22:14.54 | brlcad | common problem |
| 22:15.00 | brlcad | which is why it's not implemented ;) |
| 22:15.25 | rincon | brlcad: yes i will collaborate some of these days |
| 22:15.32 | rincon | give me time |
| 22:19.04 | rincon | brlcad: does brlcad use layers , and groups objects into compound block entiities? |
| 22:19.59 | brlcad | layers can be achieved through combinations, but they aren't specific/separate entities |
| 22:20.07 | brlcad | they are generalized object groupings |
| 22:20.43 | brlcad | so 'yes', but not exactly the same way as autocad -- can achieve the exact same end-result though |
| 22:21.44 | rincon | but can you group automatically as you draw, or you have to add objects one by one? |
| 22:23.17 | brlcad | latter, nearly everything is explicit (intentionally) |
| 22:24.58 | rincon | brlcad: for example to tell cad all things i will draw today will be on group "A"? |
| 22:26.43 | rincon | is it possible?, or you have to draw first and group later...? |
| 22:27.04 | brlcad | like I said, nothing is automatic |
| 22:27.16 | brlcad | so you'd have to create the objects, then add them to groups |
| 22:27.40 | brlcad | if you had three objects, a b c, and wanted to group them: g mygroup a b c |
| 22:28.28 | brlcad | if you gave them a consistent naming convention, a.r b.r c.r, you could use globbing: g mygroup *.r |
| 22:28.50 | rincon | i will not call that automatic, it is just to put a flag in the object that identifies the group by default.....seems to be easy to program |
| 22:29.31 | brlcad | it's not a matter of difficulty |
| 22:29.40 | brlcad | hence the (intentionally) comment |
| 22:30.13 | brlcad | it's something that would be happening potentially unbeknownst to you, and certainly not explicit at the minimum |
| 22:30.52 | brlcad | or if your specific example, that'd be very stateful, something you'd have to "turn on / turn off" .. and how do you introspect to know when that behavior is on/off |
| 22:34.31 | rincon | i know it is a matter of collaboration, but thinking about the solution is the first step, objects are complex entities that has many aspects if you set all of the aspects to a default value the group must be one of them and a default group can be the group "0" for exampl |
| 22:36.33 | rincon | and you can set a enviroment variable with the current group |
| 22:38.19 | brlcad | therein is one of the differences -- it does make sense for all objects to exist on some 'layer' as an entity type, but not on a generalized group |
| 22:38.34 | brlcad | there are plenty of objects/models that exist without any group |
| 22:38.38 | ``Erik | *readreadread* autocad is more of a computer aided drafting program, BRL-CAD is more of a computer aided engineering/analysis package |
| 22:39.33 | brlcad | I think it would be useful to add a concept of layers as specific entities (as they have very different behaviors and semantics from groups, distinct subset) |
| 22:39.42 | rincon | Erik: you can not analyze nothing if do not draw it first |
| 22:40.01 | ``Erik | was looking into changing that method to bool, was researching how it was used to make sure his assumption is correct |
| 22:40.14 | brlcad | 'draw' is very much a drafting term.. you don't draw objects, you model them :) |
| 22:40.29 | brlcad | 2d vs 3d terminology ;) |
| 22:40.59 | ``Erik | BRL-CAD grew up modeling existing objects to do things to/with them, so the whole path to generate a blueprint really wasn't a factor :D |
| 22:41.30 | brlcad | and brl-cad has it's own terminology where 'draw' specifically means to display the object up on the screen, not modify or create |
| 22:41.59 | rincon | brlcad: drawing is basic, you have to start by basic to move forward |
| 22:42.19 | ``Erik | that depends on how you define "draw" |
| 22:42.55 | brlcad | rincon: *drafting* is basic, and no you don't have to start with drafting |
| 22:42.55 | rincon | draw: is to draw a building for example |
| 22:43.23 | brlcad | the act of modeling may or may not be basic |
| 22:43.24 | ``Erik | the only thing you can define recursively is recursion. |
| 22:44.48 | rincon | Erik: is brlcad the most close i can find to autocad in free software? |
| 22:45.14 | ``Erik | um, I think things like 'qcad' might be fundamentally closer, but not nearly as mature |
| 22:45.26 | brlcad | rincon: we're by far the most feature complete, but qcad focuses on 2D |
| 22:46.05 | ``Erik | I don't think wings3d or ac3d are close to either, they're more like 3dmax |
| 22:46.35 | brlcad | rincon: not to misunderstand -- I don't disagree entirely with what you're saying, other than the specific meaning of those terms, or even disagree that we shouldn't have some feature such as you suggest |
| 22:46.43 | ``Erik | I think steve abandoned ppe |
| 22:47.14 | ``Erik | d'no the scene 'nuff to say much, though |
| 22:47.20 | brlcad | rincon: it's more a matter of there are 10000 things we can be working on, and that's simply not a priority at the moment, but could be if you were working on it ;) |
| 22:47.36 | ``Erik | hehehehe patches welcome! :D |
| 22:48.14 | ``Erik | brlcad: what was that trivial patch you guys were discussing earlier? |
| 22:48.26 | brlcad | dunno |
| 22:48.34 | rincon | brlcad: is it more practical draw engineering plans in qcad than doing it in brlcad? |
| 22:48.44 | ``Erik | also; what're some good search keywords for that video you mentioned on the way back from lunch? :D |
| 22:48.57 | brlcad | rincon: if your end-goal is drafting diagrams and your okay not having a 3D model, sure |
| 22:49.24 | rincon | i mean plans of civil engineering for example |
| 22:49.29 | brlcad | they have a lot more 2D drafting features than brl-cad has, we focus a LOT more on 3D and solid modeling |
| 22:49.40 | ``Erik | rincon: you mean blueprints, yes? |
| 22:50.10 | brlcad | civil engineering plans ARE drafting diagrams |
| 22:50.11 | rincon | i mean the design of a concrete structure for example? |
| 22:50.31 | brlcad | just a specific domain subset |
| 22:50.45 | ``Erik | http://brlcad.org/gallery/s/renderings/havoc_rtedge.png.html this is the closest we get atm |
| 22:51.13 | brlcad | rincon: I'm getting the sense that you don't seem to understand the distinction between the drafting and non-drafting approaches to modeling -- they are very very different |
| 22:51.36 | brlcad | autocad is from the ground up predominantly a drafting system, but that's not the only way by a long shot |
| 22:51.37 | ``Erik | but we can do things like photorealistic rendering, stress/strain analysis, solving mass of structures, etc. that your drafting programs won't do |
| 22:52.26 | brlcad | systems like catia, unigraphics, and pro/engineer are not predominantly drafting systems (yet still CAD), they're 3D solid modeling systems that utilize a non-drafting approach at their core |
| 22:53.00 | brlcad | important to understand that distinction as it affects the outputs that you're talking about, your goals and products |
| 22:53.12 | ``Erik | http://brlcad.org/gallery/s/diagrams/Industry_Diagram.png.html might be good to consider and study :) |
| 22:56.26 | rincon | brlcad: do you think is better to make a draw qcad? |
| 22:56.45 | rincon | brlcad: do you think is better to make a 2D draw with qcad? |
| 22:56.46 | brlcad | rincon: absolutely not, but then I'm very biased :) |
| 22:57.17 | brlcad | I think you will find it a lot easier to generating 2D annotated drawings with qcad, sure ;) |
| 22:57.31 | brlcad | but 'better', hell no ;) |
| 22:58.43 | ``Erik | if all you want to do is make a blueprint and stop, qcad might be sufficient... but once you want to go past that point, we can do that where they cannot :) |
| 22:59.42 | rincon | Erik: qcad needs a lot of collaboration.... |
| 23:00.17 | ``Erik | http://www.qcad.org/qcad.html if you read their pimp lit, they outright say they just do 2d line (technical) drawings, we do 3d solid geometry :) |
| 23:00.55 | brlcad | rincon: it does, we do a lot more by far, but we also need a lot of 'collaboration' as you put it |
| 23:01.39 | brlcad | so if you want to help, just let someone know and they can help you get familiarized with the source code or writing docs or isolating bugs, etc |
| 23:02.00 | brlcad | otherwise, it is what it is and we're working on making it better in the meantime |
| 23:02.44 | rincon | Erik: brlcad: isolating bugs sounds good to me but i am not sure if i like qcad more than brlcad |
| 23:03.23 | ``Erik | they're different beasts with different purposes, dude... there's a bit of overlap, but apples and oranges are both fruit *shrug* |
| 23:04.48 | brlcad | passive contributions aren't nearly as useful as active contributions (i.e. things that take time) .. we can all come up with 100 ways to make brl-cad better, some new feature minor or major |
| 23:04.53 | brlcad | ideas are cheap, time is not ;) |
| 23:04.53 | ``Erik | if your intent coincides with BRL-CAD, please, grab a bug or something off the todo list, we'll help you where we can :) but we can't decide which is more appropriate for you, you have to understand what your goal is and make that choice yourself :) |
| 23:06.17 | ``Erik | (I don't mean to be rude, but *shrug* that's what it all boils down to) |
| 23:06.38 | rincon | i think is better to help brlcad because it is more advanced but , i think 2D blueprints can improve more the humanity level than a deep engineering capability |
| 23:07.52 | rincon | the monopoly of autocad must be finished |
| 23:08.04 | ``Erik | ok, I would recommend that you play with the system a bit, make some models, render then in various ways... then think of some ideas for how you can make it better for you and talk to us then :) we can help steer you towards the lower hanging fruit and where to dig in at that time |
| 23:08.16 | ``Erik | but that's just my personal view here :) *shrug* |
| 23:09.34 | ``Erik | there are tutorials on the website that have been honed over a decade or two of classes and use, that'd be a good approach to learning what BRL-CAD is and is not at this time :) |
| 23:10.12 | ``Erik | sound good? |
| 23:11.14 | CIA-28 | BRL-CAD: 03brlcad * r34459 10/brlcad/trunk/src/proc-db/terrain.c: massive cleanup and refactor of the nurbs terrain example. fix a memory corruption and eliminate all globals. |
| 23:12.52 | rincon | Erik: brlcad is not on the fedora repos, why? |
| 23:13.10 | ``Erik | um, because no one has taken the time to generate the binaries |
| 23:13.30 | ``Erik | we have an rpm spec file, but *shrug* I don't use linux myself |
| 23:13.43 | ``Erik | (even though I think I was the one who made the spec file... and the deb directory) |
| 23:13.52 | brlcad | rincon: perhaps a place you could help, work on getting it added to fedora |
| 23:14.17 | rincon | Erik: i prefer to isolate bugs |
| 23:14.22 | ``Erik | has been remiss on support the FreeBSD port lately :/ |
| 23:14.57 | brlcad | the answer is 99% of the time, because there are 100 other things we *are* working on that were determined to be more important (out of the 10000 things we could be working on) |
| 23:15.55 | brlcad | just about anyone could help get brl-cad into fedora -- I can probably count on one hand how many people could add a new annotation primitive to BRL-CAD :) |
| 23:17.05 | rincon | can brlcad be installed in fedora? |
| 23:17.09 | brlcad | sure |
| 23:17.31 | rincon | let me see i am going to install it first |
| 23:17.36 | ``Erik | one of our primary "paid for" targets is redhat enterprise, fedora isn't too different |
| 23:18.01 | brlcad | someone was working on it at one point, and supposedly had it done, but don't know where it ended up |
| 23:23.42 | ``Erik | *asplode*! |
| 23:23.51 | CIA-28 | BRL-CAD: 03erikgreenwald * r34460 10/brlcad/trunk/src/other/step/src/clstepcore/ (sdaiSelect.cc sdaiSelect.h): |
| 23:23.51 | CIA-28 | BRL-CAD: Change the exists() method to return a bool. This only seems to be |
| 23:23.51 | CIA-28 | BRL-CAD: used in that capacity and causes 32/64b issues by using the address |
| 23:23.51 | CIA-28 | BRL-CAD: as "true" and NULL as "false". |
| 23:24.27 | ``Erik | indianlarry can take it up with me on tuesday if I broke it |
| 23:24.32 | ``Erik | :D |
| 23:24.58 | rincon | my processor is an athlon which brlcad should i use |
| 23:25.16 | brlcad | notes NULL is not necessarily 0 ? :) |
| 23:25.17 | ``Erik | the one you build from source? |
| 23:25.35 | ``Erik | no, but the c++ makes that assumption |
| 23:25.36 | brlcad | athlon is x86_64 |
| 23:25.56 | ``Erik | it sets the internal val to NULL, then acts like it's 0 when not set elsewhere |
| 23:26.01 | rincon | http://sourceforge.net/project/showfiles.php?group_id=105292&package_id=113559 |
| 23:26.34 | brlcad | rincon: yes? |
| 23:26.58 | CIA-28 | BRL-CAD: 03erikgreenwald * r34461 10/brlcad/trunk/src/other/step/src/clstepcore/sdaiSelect.cc: ok, ok, NULL is not necessarily 0. |
| 23:27.00 | ``Erik | now stfu |
| 23:27.02 | ``Erik | :D |
| 23:27.19 | brlcad | rincon: care to redesign the website? :) |
| 23:27.26 | brlcad | wants a redesign badly for some reason |
| 23:28.06 | rincon | brlcad: i just want to experiment the reality of brlcad |
| 23:28.21 | ``Erik | redesign as in heirarchal redesign, or a new css face? |
| 23:28.24 | brlcad | rincon: fair enough |
| 23:28.28 | brlcad | new facelift |
| 23:28.46 | brlcad | needs to have a lot more of our information uploaded and organized too, but that's a separate task altogether |
| 23:28.50 | brlcad | the appearance |
| 23:29.02 | brlcad | actually have a hierarchical organization all sorted out |
| 23:29.13 | ``Erik | I don't quite understand why people continue to build css by hand when there're some quite nice css compilers out there |
| 23:29.14 | brlcad | worked on that for hours a long time ago |
| 23:29.34 | *** part/#brlcad rincon (n=alvaro@190.77.167.45) |
| 23:29.45 | ``Erik | it's like coding in assembly... yeah, it's good to learn how to do it, but you simply don't do that in real life |
| 23:30.03 | ``Erik | more than a few hours to make it work on the various IE's iirc |
| 23:30.23 | ``Erik | catch ya later, rincon, nice meeting you O.o |
| 23:30.34 | brlcad | I mean I worked for hours just on the hierarchical organization |
| 23:30.38 | ``Erik | hopes he wasn't too dickish to the dude |
| 23:30.39 | brlcad | lot of thought went in |
| 23:31.35 | brlcad | highly suspects that was an NNPP conversation |
| 23:31.48 | ``Erik | yeah, |
| 23:31.57 | ``Erik | thus my "here's what you do, now shut up and go do it" attitude |
| 23:32.31 | ``Erik | (nnpp?) |
| 23:33.43 | brlcad | net negative producing (person) .. conversation |
| 23:34.11 | brlcad | but it's still good to say if only to have logged and reiterated |
| 23:34.20 | ``Erik | *shrug* everyone can bring a positive effect if steered and utilized effectively |
| 23:34.27 | ``Erik | there are tasks for all levels of ability |
| 23:35.41 | ``Erik | btw, that other/step patch... that's totally "it compiles, ship it" :D hopefully it's trivial enough that I didn't bung something |
| 23:36.05 | ``Erik | got his books today, huzzah, *read* |
| 23:37.00 | ``Erik | "practical common lisp" and "lisp in small pieces" |
| 23:37.35 | brlcad | sounds like a hack'n'slash horror thriller |
| 23:37.55 | brlcad | small pieces... bloody curlies everywhere! |
| 23:38.09 | ``Erik | these... are your fathers parenthesis |
| 23:38.15 | ``Erik | from a more civil time |
| 23:38.43 | ``Erik | the ToC of the small pieces book is... terrifyingly impressive |
| 23:39.19 | ``Erik | chapter 2 has greek in the name, chapter three is hitting continuations |
| 23:39.36 | ``Erik | chapter 1 is how to write an evaluator and compiler for the language |
| 23:39.55 | ``Erik | "macros: their use & abuse" |
| 23:40.31 | CIA-28 | BRL-CAD: 03brlcad * r34462 10/brlcad/trunk/src/proc-db/vegitation.c: cleanup |
| 23:40.35 | ``Erik | an awfully complete working of OO that stomps c++/java in 30 pages |
| 23:40.54 | ``Erik | I think there's a lot in this book, it's gonna hurt and take a while to digest :) |
| 23:42.14 | brlcad | thinks ``Erik should work on a 'led' tool that binds lisp to libged as an expression evaluator as he works his way through his books |
| 23:42.34 | ``Erik | supposedly, it's the seminal text to move one from a basic 'hello world' grub to a guru grade user |
| 23:42.38 | brlcad | cackles and evil laugh |
| 23:42.40 | ``Erik | "led"? |
| 23:42.49 | brlcad | lisp geometry editor, lge? :) |
| 23:42.54 | ``Erik | heh |
| 23:43.06 | ``Erik | cffi is pretty clean |
| 23:43.10 | ``Erik | so is uffi |
| 23:43.18 | ``Erik | both far less painful than jni |
| 23:43.30 | brlcad | (opendb 'moss.g (make sph sph)) |
| 23:43.45 | ``Erik | 'cept that'd get one flamed up one side and down the other |
| 23:43.58 | ``Erik | (with-db "moss.g" (make sph sph)) |
| 23:43.59 | ``Erik | :) |
| 23:44.25 | ``Erik | (make "sph" 'sph) perhaps? |
| 23:44.49 | ``Erik | and #P"moss.g" |
| 23:44.56 | ``Erik | ack.. brain... exploding... |
| 23:44.57 | brlcad | probably (make "sph" "sph"), all gets passed as literals to libged |
| 23:45.22 | brlcad | could get fancy, but really no need |
| 23:45.31 | brlcad | just need a binding layer |
| 23:45.32 | ``Erik | is it right to refer to the data type as a string? that requires string comparison and eliminates compile time error checking |
| 23:46.22 | ``Erik | *shrug* these books are pure lithp, interface would be using one of the ffi layers, different scope |
| 23:46.25 | brlcad | there's not yet any means for libged to declare expected args so that you could do anything other than strings atm |
| 23:46.35 | ``Erik | that's cuz tcl sucks |
| 23:46.43 | brlcad | has nothing to do with tcl |
| 23:46.44 | ``Erik | I mean, tcl thinks of everything a string |
| 23:46.47 | brlcad | talking about libged |
| 23:47.11 | brlcad | they approach it from an argc/argv command interface |
| 23:47.16 | ``Erik | which is the transport of mged C functions, which exist as the support cast to the tcl layer |
| 23:47.27 | brlcad | which is irrelevant :) |
| 23:47.37 | ``Erik | the API in mged shows its tcl heredity quite readily :) |
| 23:47.41 | ``Erik | libged, rather |
| 23:47.52 | brlcad | I don't see it like that |
| 23:48.00 | ``Erik | *shrug* ok |
| 23:48.00 | brlcad | it's pretty simple and clean as it is |
| 23:48.16 | brlcad | each one of those commands could be trivially turned into it's own program |
| 23:48.33 | brlcad | and probably should at least for testing purposes |
| 23:48.38 | ``Erik | ok, it shows adaptation from a language that understand nothing other than strings |
| 23:48.41 | brlcad | would be kinda neat |
| 23:48.43 | ``Erik | be it tcl, shell, ... |
| 23:48.50 | brlcad | sure |
| 23:49.49 | brlcad | not that it'd be different even outside that context, though -- it's meant to be high-level like that so the api is untyped by design |
| 23:49.56 | brlcad | not just a side effect |
| 23:50.52 | brlcad | could have gone a vararg approach as well, but that was a later thought and has a LOT of implications |
| 23:51.46 | ``Erik | hm, is lowest common denominator the best approach? opposed to explicit typing in the weakly typed hooks? |
| 23:51.55 | ``Erik | yeah, that'd be a lot of weird custom parsing :/ lcd is probably better |
| 23:52.07 | brlcad | plus rewriting getopt parsing for 400+ commands/functions would really suck :) |
| 23:52.09 | ``Erik | shouldn't be too terrible of a perforance hit |
| 23:52.24 | brlcad | I was thinking of some hybrid |
| 23:52.39 | brlcad | as there are some typed objects in the ged object that is passed to them all |
| 23:52.55 | brlcad | for view(s) and geometry object(s) |
| 23:53.12 | ``Erik | but suppose you flop the typing in your script |
| 23:53.24 | ``Erik | instead of handling in the "native" language format |
| 23:53.29 | brlcad | so if you have a named object as an argv element, it's looked up against the geometry object has that was passed in or looked up in the db provided |
| 23:53.32 | ``Erik | ... O.o it'd have to be explicitely handled? |
| 23:53.48 | brlcad | the commands should handle their own type 'too' at least |
| 23:54.14 | brlcad | but I was thinking of having something more like a registration interface for each command where they could report their expected arglist format/types |
| 23:54.18 | ``Erik | so (parse-integer x :junk-allowed t) all over the lisp? or whatever ruby or python do to parse a string to an int? or float? or symbol? |
| 23:54.42 | ``Erik | ok, but different languages have different types |
| 23:54.46 | brlcad | so if you had a typed language, you could have your wrapper command pull the information so it can do type checks |
| 23:54.48 | ``Erik | how does swag deal with that? |
| 23:55.02 | ``Erik | wouldn't be surprised if they punted |
| 23:55.18 | brlcad | dunno |
| 23:55.29 | ``Erik | this is all brainpuke *shrug* I'm just thinkin' noisly |
| 23:55.30 | brlcad | packs it up |
| 23:55.32 | ``Erik | noisily |
| 23:55.37 | ``Erik | aight, drive careful, dude |
| 23:55.39 | brlcad | code that shtiff up |
| 23:56.06 | brlcad | could find a way to bind typing up to libged -- that'd be cool |
| 23:57.21 | ``Erik | has a few more pressing tasks first :( |
| 23:57.45 | ``Erik | and only some of them software development hhe |
