| 00:06.25 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 01:13.38 | *** join/#brlcad andrecastelo (n=chatzill@189.71.73.20) | |
| 06:52.56 | *** join/#brlcad clock_ (n=clock@77-56-95-66.dclient.hispeed.ch) | |
| 08:17.49 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) [NETSPLIT VICTIM] | |
| 08:40.42 | *** join/#brlcad ``Erik (i=erik@c-68-54-174-162.hsd1.md.comcast.net) | |
| 08:54.07 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 09:53.11 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1128564908.dsl.bell.ca) | |
| 11:23.21 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 11:30.56 | *** join/#brlcad GTrax (n=a@82-69-89-195.dsl.in-addr.zen.co.uk) | |
| 11:33.11 | GTrax | ?? |
| 11:36.11 | GTrax | Ah well - it's Sunday. Maybe not too many are indoors :) |
| 11:57.27 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 11:59.09 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 12:30.06 | *** join/#brlcad homovulgaris (n=d@117.196.133.71) | |
| 12:33.41 | homovulgaris | brlcad: just read the irc logs :P "just a gsoc student" ;) |
| 12:40.40 | homovulgaris | libged breaking the build on gcc |
| 12:43.04 | homovulgaris | ged_private.h some static - nostatic trouble with ged_persp_mat function |
| 12:43.23 | homovulgaris | and Sean, did u see the boost_base doubt i had asked ? |
| 12:45.08 | homovulgaris | one more build doubt, I am including certain C headers in solver_test.cpp , it seems i have to manually specify -I../other/tcl/generic to (CPPFLAGS) for the tcl.h location |
| 12:45.25 | homovulgaris | whats the right method rather than this blind include ? |
| 13:03.02 | *** join/#brlcad thing0 (n=ric@203-59-111-122.dyn.iinet.net.au) | |
| 13:26.48 | *** join/#brlcad thing1 (n=ric@203-59-133-113.dyn.iinet.net.au) | |
| 13:50.37 | *** join/#brlcad esben (n=esben@0x573ff382.boanqu1.static.dsl.tele.dk) | |
| 14:35.51 | *** join/#brlcad homovulgaris (n=d@117.196.138.99) | |
| 14:48.56 | ``Erik | um, that may be out of sync with the, uh, actual tcl being used. There should be something like $(TCL_CPPFLAGS) in your CFLAGS or CPPFLAGS in Makefile.am |
| 14:52.14 | *** join/#brlcad starseeker_ (n=CY@c-68-33-217-173.hsd1.md.comcast.net) | |
| 15:00.51 | homovulgaris | TCL_CPPFLAGS is there in AM_CPPFLAGS but maybe i should add it to the individual binary as well ( in this case solver_test_CPPFLAGS ) .. hmm |
| 15:02.59 | homovulgaris | Erik, have u seen the bu_list example in bu.h . shouldn't there be a bu_free(my_entry) bu_free(new_entry) etc ? or does freeing the main list using bu_free free all the allocated memory ? |
| 15:06.33 | ``Erik | remove your .o file, try making it again, and look at the build line? |
| 15:07.00 | ``Erik | uhmmmm, I'd have to dig into that :/ |
| 15:08.04 | ``Erik | look at line ~510 of bu.h |
| 15:08.18 | ``Erik | does that help? |
| 15:11.14 | starseeker_ | forgot how ungodly long it takes to build VTK... |
| 15:14.24 | homovulgaris | Erik, adding TCL_CPPFLAGS to the binary_CPPFLAGS worked :) i dont like tcl |
| 15:16.08 | ``Erik | :D |
| 15:16.41 | ``Erik | tcl has some good and bad aspects to it... personally, i'd favor embedding lithp or thcheme, perhaps ruby or python these days |
| 15:22.00 | homovulgaris | lots of projects happening in python these days.. :) i still like C and C++ mostly :) |
| 15:22.15 | homovulgaris | there is something allergic about java |
| 15:25.58 | ``Erik | once java finishes going open source, it may be semi-acceptable |
| 15:26.40 | ``Erik | python and ruby seem to be the big flashy new ones, though |
| 15:27.01 | homovulgaris | bbut over the past 5 or 6 years there has been so much code base in java.. I mean lots of application software being written in it.. |
| 15:27.04 | ``Erik | seems like python is a favorite of the linux world and ruby is a favorite of the bsd world heh |
| 15:27.21 | homovulgaris | ruby rox :) |
| 15:27.33 | homovulgaris | and i am from the linux world :P |
| 15:27.37 | ``Erik | yeah, businesses like it, but it's a royal pain to install on, say, fbsd.... not wroth the hassle |
| 15:27.44 | ``Erik | worth |
| 15:27.52 | ``Erik | due to licensing issues |
| 15:27.56 | ``Erik | (java, that is) |
| 15:28.37 | homovulgaris | even in sectors like bioinformatics.. i mean gene analysis etc. is done mostly using perl but so much of their visulization and other code is in Java .. |
| 15:29.00 | homovulgaris | at least in academia and science they should stick to open source completely as a policy decision |
| 15:30.05 | ``Erik | schools here in the US used to push c++, and moved to java as I was leaving (mostly due to marketting, I believe) |
| 15:30.14 | ``Erik | a lot of the c++ was msvc and windows based, though |
| 15:30.52 | ``Erik | the notion of teaching scheme, or using a fbsd.. a lot of the wuss students thought it was stupid and irrelevant (they were looking for a vocational "programming" approach, not computer science) |
| 15:31.34 | ``Erik | and schools feel pressure to put out what the industry wants, and the industry feels pressured to move towards what the schools are pushing out, so suns JZOMFGJAVA! blitz campaigning was... highly effective :) |
| 15:31.39 | homovulgaris | In india the universities push c++, but lots of training institutes , polytechnics and so on pushing java, since it fetches jobs :) |
| 15:31.55 | homovulgaris | huge outsourcing industry in India providing technology support in Java i guess :P |
| 15:32.36 | ``Erik | yeah... *glare* :D |
| 15:32.57 | homovulgaris | at that time i guess they pushed the PORTABILITY thing so much .. and i guess in the end it is not that portable anyways :) bsd for instance |
| 15:33.43 | ``Erik | no, java is not portable at all, it runs binaries made for the java ABI, the "portable" aspect is that there are emulators for that machine available for a few OS/arch platforms |
| 15:34.11 | ``Erik | and even those tend to be fractured (even suns reference versions), so the popular snipe is "write once, debug everywhere" |
| 15:34.26 | homovulgaris | i always find the VM idea a roundabout approach to getting things done.. :P |
| 15:35.13 | homovulgaris | Sun has an ambassador in our university , trying to get students to use solaris more :) |
| 15:50.58 | CIA-60 | BRL-CAD: 03brlcad * r31804 10/brlcad/trunk/src/libged/vutil.c: static mismatch |
| 16:02.04 | *** part/#brlcad thing1 (n=ric@203-59-133-113.dyn.iinet.net.au) | |
| 16:10.49 | *** join/#brlcad docelic (n=docelic@78.134.200.43) | |
| 16:28.13 | Axman6 | homovulgaris: there's a small group at ours who put on the occasional talk. i get free solaris DVD's, so i'm happy |
| 16:40.30 | CIA-60 | BRL-CAD: 03homovulgaris * r31805 10/brlcad/trunk/src/librt/primitives/ell/ell.c: commenting out code obsolete due to pc_pc_set modification |
| 16:41.09 | CIA-60 | BRL-CAD: 03homovulgaris * r31806 10/brlcad/trunk/include/pc.h: Macros for pc_pc_set initialization, push, and free |
| 16:43.01 | CIA-60 | BRL-CAD: 03homovulgaris * r31807 10/brlcad/trunk/include/raytrace.h: modification of pc_pc_set : using bu_list in pc_param and pc_constrnt structures |
| 16:45.50 | homovulgaris | Axman6: ;) Yeah pretty much the same deal here.. ocassional talks, demonstrations etc.. :) |
| 16:50.03 | CIA-60 | BRL-CAD: 03homovulgaris * r31808 10/brlcad/trunk/src/libpc/pcParser.h: addition of pcVariable and pcConstraint grammar structs and Parser class definition |
| 16:55.56 | CIA-60 | BRL-CAD: 03homovulgaris * r31809 10/brlcad/trunk/src/libpc/ (Makefile.am solver_test.cpp): Testing pc_pc_set modifications and Parser::parse() |
| 17:24.16 | *** join/#brlcad jonored (n=jonored@c-24-34-212-39.hsd1.ma.comcast.net) | |
| 17:30.45 | jonored | Hello. I've a question: is there something in BRL-CAD that would be the equivalent of a macro in Lisp? What I mean is, is there some way of, rather than programmatically generating a shape by building an external program, writing the result to a database file, loading it in, etc. and redoing that process if something changes, of just embedding a (small) script into a model, and having the information that script is run with kept in the |
| 17:31.39 | jonored | So, for instance, I could write a macro that generates an involute gear, and would be able change the number of teeth on a gear by just modifying its definition? |
| 17:32.42 | jonored | I know that there are some features like that, but they seem like they lose information such that either the model is no longer the preferred form for editing of the design, or you have to redo work every time a definition changes. |
| 17:33.06 | archivist | shape and body of a gear is not as constant as tooth shape |
| 17:34.24 | archivist | and low number gears have differently shaped teeth |
| 17:34.59 | jonored | I'm mostly saying a gear as an example. |
| 17:36.41 | jonored | Although I'd be surprised if it weren't possible to encode the variations over a useful range - what I want would be more than a simple pattern. |
| 17:53.29 | *** join/#brlcad jonored_ (n=jonored@c-24-34-212-39.hsd1.ma.comcast.net) | |
| 17:54.07 | jonored_ | ...and the router goes away and I don't notice. did I miss replies? |
| 17:54.42 | archivist | no |
| 17:55.51 | jonored_ | ...okay. Does wanting something like that make sense, at least (even if it'd be challenging to do for that example)? |
| 17:56.31 | archivist | it does (i do it in SolodWorks) |
| 17:57.24 | archivist | parametric parts (driven by an axcel table) |
| 17:57.29 | archivist | excel |
| 17:58.15 | jonored_ | Okay. The other two questions associated with that are then whether it's there in BRL-CAD, and whether it'd be a reasonable addition (for me to work on, I mean.) |
| 18:03.22 | homovulgaris | parametric parts :) well once libpc works out well we shouldnt need solidworks |
| 18:03.38 | homovulgaris | but it is still at baby steps |
| 18:03.51 | archivist | waiting to jump ship :)) |
| 18:04.47 | jonored_ | libpc? |
| 18:05.01 | homovulgaris | parametrics and constraints library.. |
| 18:05.22 | jonored_ | facepalms. |
| 18:05.47 | jonored_ | Not in the tarball for users yet? |
| 18:05.51 | archivist | homovulgaris, will it have rotations on axis eg gearing |
| 18:06.26 | homovulgaris | jonored_: it is in the svn. but far from the actual requirements of parametric parts. |
| 18:06.54 | homovulgaris | archivist: what exactly would rotations on an axis involve ? positioning dependent on an axis ? |
| 18:07.37 | archivist | I rotate gear a and all related gears(and assemlies) rotate |
| 18:07.48 | homovulgaris | first phase of constraints would be implementations such as is_tangent or is_perpendicular and so on.. |
| 18:08.23 | homovulgaris | well i think the rotation of interconnected gears could be specified as a set of constraints |
| 18:08.37 | jonored_ | I'll check it out and take a look anyways; perhaps I can find a way to be helpful. |
| 18:08.51 | archivist | its really nice to put a mouse pointer on a gear push it and the mechanism moves as it should |
| 18:09.18 | homovulgaris | archivist: almost like physics simulation ;) |
| 18:09.24 | archivist | yesum |
| 18:09.26 | homovulgaris | and yep in the end that is pretty much the idea |
| 18:10.24 | homovulgaris | rotation of gears is basically a sort of relation between a controlling rotation of one gear and change in the orientation of the rest according to change in the orientation of the control gear right. |
| 18:10.45 | homovulgaris | It just needs to be parametrized in terms of teeth number and so on. |
| 18:11.16 | archivist | yes except some reversal and if one is fixed then the housing moves |
| 18:11.48 | archivist | but all should work out as you get the idea |
| 18:12.33 | homovulgaris | jonored_: right now i have just started writing the parser for parsing constraint expressions.. and by constraints i mean stuff like "radius<3" A "tangent to" B and so on "position of sph.centre is on the cube" and so on |
| 18:12.43 | archivist | my last job here was a sun and planet gear assembly |
| 18:13.52 | homovulgaris | archivist: hmm.. in terms of libpc , the question really would be how do we extract those relationships, i mean i cannot expect the user to specify mathematical relationship between orientation ( rotation angles) |
| 18:14.37 | homovulgaris | I will have to derive them using some simple point/teeth contact constraint between the gear parts |
| 18:15.03 | jonored_ | I seem to remember doing almost that kind of specification with Pro-E, just with selecting specific sorts of relationships. |
| 18:15.32 | archivist | that depend how the user is prompted, I add a gear mate betweent two gears ans specify the numbers and direction if the program guesses incorrectly |
| 18:16.00 | homovulgaris | and jonored_ the gear teeth number change, well theoretically , that sort of thing should be possible using libpc and sketch system |
| 18:16.36 | archivist | the mate is on the axis not the teeth in solidworks |
| 18:16.44 | homovulgaris | basically teeth angle radius etc. being interrelated |
| 18:16.53 | homovulgaris | hmm.. |
| 18:17.11 | archivist | could be pulleys and belts |
| 18:17.31 | archivist | or chain wheels |
| 18:17.51 | homovulgaris | yeah get the idea, oh.. so u set relationships between axes, |
| 18:17.59 | homovulgaris | specify rotation ratio |
| 18:18.07 | archivist | yes |
| 18:18.29 | homovulgaris | well that could be implemented .. no need for comlex derivations from teeth contact blah blah :) |
| 18:18.30 | jonored_ | *nod*. Although I'd still like a way for things like at least the invocation part of things like the wall generator/plant generator/tire generator to be kept in the model file. |
| 18:19.27 | archivist | contact type is also useful for special types of mechanical motion |
| 18:19.53 | homovulgaris | currently and as per plan, libpc will be storing the constraints in the .g file only.. u would be able to invoke it using "yet to be implemented" constraint editing commands.. |
| 18:20.06 | homovulgaris | well in this case parameter editing commands.. pretty much the same.. |
| 18:21.01 | jonored_ | Is there a programming language embedded? |
| 18:21.07 | homovulgaris | contact type would be a bit tough, computationally i mean , if you are dealing with two ranges of points.. |
| 18:21.35 | homovulgaris | jonored_: programming language ? in libpc ? |
| 18:21.55 | homovulgaris | if u mean a method of expressing relations, i am implementing a grammar using boost::spirit |
| 18:22.33 | jonored_ | Would I be able to specify an arbitrary computable shape (provided that it is definable with the primitives that BRL-CAD has) from a set of paramaters? |
| 18:24.09 | homovulgaris | with primitives that BRL-CAD has and representation of how the parameters are related to primitives and each other yes.. |
| 18:25.01 | jonored_ | ...Then I do believe that there is a programming language there in some form or another. Cool :) |
| 18:26.42 | homovulgaris | but ur idea of adding scripts to the objects is nice.. |
| 18:27.10 | homovulgaris | maybe brlcad (Sean) would have more to say about this :) |
| 18:28.22 | archivist | with a part on screen I select properties and select one of my preset configurations and the gear redraws to the new shape and no of teeth |
| 18:32.00 | homovulgaris | implementation-wise it would be an addition to the property object i guess , or if they already have something like construct_from_parameters just a call to it ? |
| 18:32.12 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 18:32.34 | homovulgaris | s/property object/object property :P |
| 18:33.19 | jonored_ | It's essentially the same thing - just an imperative language to the declarative one you're writing. |
| 18:33.54 | homovulgaris | jonored_: the present database system does not have any method of including code, it only has mostly geometric and a few non-geometric object types |
| 18:38.17 | jonored_ | i'd be surprised if there'd be much difference between adding constraints and adding imperative code, though. |
| 18:48.36 | homovulgaris | hmm.. i am still unable to visualize the workflow (implementation wise) for the imperative case |
| 18:51.34 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1128564908.dsl.bell.ca) | |
| 18:52.39 | homovulgaris | Ralith: I checked out reprap.. awesome stuff .. hoping to make my rapid prototyper soon.. maybe september :) |
| 18:52.44 | jonored_ | For defining macros it basically dumps the user straight to the assumption of being a script programmer; I don't know any way of getting as much power as you get that way without that. For the user of a script, it'd probably look a bit like using a primitive - tell it that the definition is by this macro, and that here are the parameters to the macro, and there's a shape there. I'd want to have it so that the macro can take geometry a |
| 18:54.22 | homovulgaris | yeah scripting support is provided in most applications right.. like catvba for catia , rhinoscript and so on.. ;) i worked on catvba for around 6 months last year |
| 18:54.28 | homovulgaris | i am not sure but probably we already have a tcl interface.. |
| 18:54.47 | homovulgaris | dunno what all features it supports |
| 18:57.04 | homovulgaris | jonored_: and these macros would be stored as a separate file ? |
| 18:57.46 | homovulgaris | like in catia for example , it is stored as a separate .catvba file |
| 18:58.49 | jonored_ | There are reasons to do both; on the one hand, if you send someone a model, you want it to be possible to edit the definitions of stuff in the model, on the other hand, you want it to be easy to get them from a library, because more people would be using them than writing them. |
| 19:00.56 | jonored_ | The main thing (to me) is that they'd get run when their inputs are changed, without needing the user to invoke them explicitly and redo work in the model. |
| 19:02.27 | brlcad | tunes in |
| 19:02.35 | *** join/#brlcad SlickT10 (n=9856858b@bz.bzflag.bz) | |
| 19:03.02 | homovulgaris | hmm.. so ideally they should support both insertion into file as well as independent existence.. and indeed without generated geometry life would be tough in any cad application :) |
| 19:03.11 | homovulgaris | brlcad is the man :) |
| 19:03.13 | brlcad | reads backlog |
| 19:03.36 | poolio | errr |
| 19:03.40 | SlickT10 | asdf |
| 19:03.50 | poolio | brlcad: Could you help me think through some basic dumb geometry math when you get a chance? |
| 19:04.31 | poolio | Trying to think of the best way to compute a rectangle that encloses the face given the points and the plane equation |
| 19:07.34 | jonored_ | Fills the same sort of role as the parameterization, I think, just as explicit steps rather than implicit constraints. The differences are mostly to do with speed of the code (because the constraint version needs to run a solver - which might be better or worse than what a person might write in terms of getting it done), and expressiveness - some things are easier to think of as constraints, some as steps. |
| 19:09.35 | homovulgaris | hmm.. true.. I am planning on spending quite some time optimizing the solver once i finish the basic framework that is.. and expressing step wise generation of geometry would be a bit twisted in terms of constraints.. |
| 19:09.37 | brlcad | howdy jonored_ |
| 19:10.28 | jonored_ | hullo |
| 19:10.35 | brlcad | libpc will ultimately be central to any long-term implementation of fully parametric geometry, but it's also worth noting that a fair bit of that is already possible too |
| 19:11.05 | homovulgaris | but would the macro interface look much different from using mk_* () ? like mk_sph mk_ell and so on.. basically macros could add a layer on top of them to do some additional calculation to generate their arguments from the parameters |
| 19:11.17 | brlcad | via libwdb, you can write procedural database generators (in C) that are, of course, hard-coded but entirely parametric from an input perspective |
| 19:12.01 | brlcad | this has also been done in Tcl directly in mged before, where there were tcl objects defined for a given .g such that the modeler could store the routine in the .g and invoke it as needed to create geometry |
| 19:12.37 | brlcad | what you're suggesting is also very much closely related to the last primitives idea at http://brlcad.org/~sean/ideas.html |
| 19:13.10 | brlcad | where it becomes a full-fledged new primitive with inboard or outboard script storage that gets evaluated at run-time (per constraints or whatever) |
| 19:14.11 | brlcad | poolio: possibly in a bit :) |
| 19:14.20 | Ralith | homovulgaris: cool, me too |
| 19:15.02 | brlcad | Ralith: how goes the tutorializing? |
| 19:15.21 | Ralith | brlcad: great; I'm onto #15 today |
| 19:16.13 | Ralith | libpc is that SoC project? |
| 19:16.30 | poolio | brlcad: ping me when you've got time :) |
| 19:17.05 | jonored_ | brlcad: That does sound like /exactly/ what I'm talking about. The generators in C are what I was aware of, but inconvenient - especially to a lisp programmer. |
| 19:17.34 | Ralith | jonored_: I bet you could wrap the C api in lisp |
| 19:18.47 | jonored_ | Ralith: It occurs to me that that statement has two possible meanings - I was meaning that it's inconvenient to someone who is accustomed to extending their language's compiler as he sees fit while writing his program, not as a wish to write generators in Lisp. |
| 19:18.53 | brlcad | Ralith: yeah, one of our four projects: http://brlcad.org/d/node/23 |
| 19:19.58 | Ralith | jonored_: I'm not quite sure I follow. Doesn't lisp, like most languages, have some mechanism for accessing C libraries, which can then be wrapped to make the interface more clean and lispy? |
| 19:20.33 | brlcad | jonored_: now one side effect of mged's built-in scriptability is that you can use pretty much ANY language to write "mged scripts" .. doesn't get you parameterized geometry nor a high-level api nor state management, but it does let you do just about anything you can do in mged from a given arbitrary language -- there's an example on the website .. (digs) |
| 19:21.01 | jonored_ | Ralith: Oh, easily - but I was meaning that I wanted an idea from lisp in brl-cad, not that I wanted to use lisp for brl-cad. |
| 19:21.11 | Ralith | oh, ok |
| 19:21.13 | brlcad | here's an example of mged scripted with about 3 different I/O approaches using simple posix shell scripting: http://brlcad.org/wiki/SGI_Cube |
| 19:21.25 | jonored_ | because it's essentially /the/ idea that makes lisp really powerful. |
| 19:21.39 | brlcad | generates some geometry and renders it |
| 19:22.19 | brlcad | once our new libged library is complete (which is at the heart of ALL mged commands), the plan is to swigify the whole thing so that you can access a consistent command layer from any language |
| 19:22.27 | homovulgaris | Ralith: yep libpc is a SoC project.. :) |
| 19:22.28 | brlcad | (directly, instead of indirectly) |
| 19:22.43 | Ralith | homovulgaris: yeah, brlcad provided the link |
| 19:23.04 | Ralith | (you must have a database of handy descriptive links on hand or something) |
| 19:23.06 | homovulgaris | just saw :) |
| 19:27.15 | brlcad | Ralith: not really |
| 19:27.36 | brlcad | just know where the stuff is on the website |
| 19:27.46 | brlcad | there's a heck of a lot more ;) |
| 19:27.53 | Ralith | yeah, I've been browsing |
| 19:31.12 | brlcad | and a ton of stuff not even uploaded yet |
| 19:44.12 | homovulgaris | brlcad: :) my boost_base doubt :D |
| 19:51.20 | brlcad | homovulgaris: que? |
| 19:51.35 | brlcad | oh, a question you had? |
| 19:56.55 | brlcad | homovulgaris: hmm.. you totally should not have needed to wrap the includes in extern "C" .. if there are decls in our headers that need wrapping, they should get fixed instead of adding a work-around |
| 20:02.31 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 21:32.12 | *** join/#brlcad andrecastelo (n=chatzill@189.71.40.80) | |
| 21:34.39 | andrecastelo | hey guys |
| 21:35.32 | Ralith | hullo |
| 21:36.26 | brlcad | howdy andrecastelo |
| 21:36.42 | andrecastelo | howdy brlcad |
| 21:36.49 | andrecastelo | hi ``Erik |
| 21:47.00 | brlcad | starseeker_: iqtest.dk is the site I was talking about, fun stuff ;) |
| 22:05.29 | CIA-60 | BRL-CAD: 03brlcad * r31810 10/brlcad/trunk/regress/ (9 files): regression test typo, refer to the variable instead of some invalid var expansion so that hopefully mged will find tcl/tk if we're regression testing |
| 22:20.10 | CIA-60 | BRL-CAD: 03brlcad * r31811 10/brlcad/trunk/src/librt/primitives/dsp/dsp.c: ignore dsp's with no data source a little more gracefully instead of bombing |
| 22:21.08 | CIA-60 | BRL-CAD: 03andrecastelo * r31812 10/brlcad/trunk/src/rt/viewmlt.c: Fixed point lists and path lists allocation and deallocation. Each point hit is now stored in a path list. This will be useful for path tracing. |
| 22:23.45 | homovulgaris | brlcad: checked without extern "C" .. works fine :) |
| 22:28.07 | homovulgaris | and the boost_base doubt.. |
| 22:28.11 | homovulgaris | 11:08.17homovulgarisbtw, i wanted to use the ax_boost_base.m4 macro i added using something like this addition to the configure.ac http://rafb.net/p/v3tpKU36.html |
| 22:28.11 | homovulgaris | 11:08.42homovulgarisbut it gives some trouble while configuring in tcl saying LDFLAGS was not set during the last run |
| 22:28.11 | homovulgaris | 11:09.07homovulgarisis there something additional i have to do other than adding the macro to m4 dir and the code to configure.ac |
| 22:28.22 | alex_joni | brlcad: that was quite fun (the iqtest.dk site..) |
| 22:28.47 | homovulgaris | i think i will have to modify the macro probably ? |
| 22:29.38 | poolio | alex_joni: I just took it too :P how'd you do? |
| 22:30.06 | alex_joni | 133.. but I didn't have nerve to really answer the last couple of questions |
| 22:30.34 | alex_joni | still had about 20 minutes left :) .. but it's 1am here |
| 22:30.40 | alex_joni | so I'm off to bed ;) |
| 22:31.55 | alex_joni | poolio: u? |
| 22:32.28 | poolio | alex_joni: 126, I got frustrated and didnt do the last few as well. I didn't see the pattern and went "arghhhhhhh" |
| 22:33.25 | alex_joni | haha :) |
| 22:33.28 | alex_joni | maybe one day :P |
| 22:59.22 | *** join/#brlcad thing0 (n=ric@123.208.108.119) | |
| 23:14.55 | homovulgaris | 4.44 am :) time to sleep |
| 23:15.27 | homovulgaris | will write a good grammar tomorrow |
| 23:33.21 | brlcad | homovulgaris: there's nothing additional you have to do other than blowing away the automake/autoconf caches assuming there are no problems with the m4 itself |
| 23:38.46 | brlcad | andrecastelo: something to keep in mind, at some point you'll want to optimize it so that there are no malloc/free (e.g. bu_calloc, BU_GETSTRUCT, etc) calls occurring during ray-trace (prep is fine, viewstart/viewend is fine) |
| 23:39.31 | brlcad | andrecastelo: that will generally result in a substantial performance hit .. and given you're writing a path-tracer, you'll want to keep an eye on performance very early on |
| 23:40.25 | brlcad | since you'll ultimately be shooting billions of rays (or more) per image |
| 23:45.41 | andrecastelo | hmm, i understand.. but how can I do that?? something like how scanline is treated? |
| 23:46.23 | andrecastelo | allocate a big array in the beginning.. ?? |