| 00:10.45 | Maloeran | That's kind of nice. My friend messed up completely while connecting the ends of an ethernet cable, 4 of the 8 cables are mixed up, and the ethernet cable still works!... with a packet drop rate of 15% |
| 00:11.45 | Maloeran | More specifically, it only works with the ethernet of this dual-quad-xeon, all other computers refuse to work with the cable |
| 00:14.08 | brlcad | that's messed up |
| 00:14.39 | brlcad | presumably a gigE connection? |
| 00:14.57 | brlcad | since it allows for bidirectional cross-over |
| 00:15.55 | archivist | ive had broken network cables limp along, probably helps if the switch/card can auto sense reversed cable as well |
| 00:16.31 | Maloeran | Interesting. It's vaguely amusing that the cable does work, but with a packet drop rate of 15% |
| 00:16.44 | Maloeran | I would have asumed the cable would either work or not at all |
| 00:16.57 | Maloeran | assumed* |
| 00:33.39 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) | |
| 01:24.00 | CIA-21 | BRL-CAD: 03brlcad * r31083 10/brlcad/trunk/src/mged/cmd.c: remove dead code related to savedit and get (which is in libged/wdb_obj) |
| 01:25.24 | CIA-21 | BRL-CAD: 03brlcad * r31084 10/brlcad/trunk/src/mged/cmd.h: remove comment for f_list |
| 01:27.04 | yukonbob | Maloeran: maybe the send/receive are on the same wire, but it's either poorly connected or(/and) not wired to T569-A specs, which have specfic pairs designated to be connected in a certain order... |
| 01:27.43 | yukonbob | *T568-A -- not 569 |
| 01:52.09 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 01:53.11 | PrezKennedy | hey... anyone know where i can find a compiler that compiles perfect code just from what you tell it? i hate programming |
| 01:54.20 | PrezKennedy | ah, found it |
| 01:54.23 | PrezKennedy | good night! |
| 01:55.13 | *** join/#brlcad pacman87 (n=timothy@pool-71-164-238-31.dllstx.fios.verizon.net) | |
| 01:59.15 | pacman87 | i'm back |
| 02:19.18 | CIA-21 | BRL-CAD: 03brlcad * r31085 10/brlcad/trunk/src/mged/ (cmd.c cmd.h setup.c): move the command table to setup along with cmd_setup so that it may be static. made it obvious that there were a slew of unnecessary decls that could be removed too. |
| 02:40.40 | starseeker_ | PrezKennedy: Not perfect, no - the closest known tool is called the grad student |
| 02:44.11 | Maloeran | PrezKennedy, I find that gas or any other assembler can produce fairly perfect code |
| 02:45.01 | Maloeran | Though that may also depend of the programmer |
| 02:58.57 | starseeker_ | Whoops, I lied - it looks like mged is OK with the new nirt code after all, once I rebuild it correctly *cough* |
| 02:59.51 | starseeker_ | getting double printing... |
| 02:59.53 | starseeker_ | hmm... |
| 03:01.48 | starseeker_ | Oh, good I didn't lie - it's busted in a different way |
| 03:01.49 | starseeker_ | phew |
| 03:06.07 | *** part/#brlcad pacman87 (n=timothy@pool-71-164-238-31.dllstx.fios.verizon.net) | |
| 03:07.06 | CIA-21 | BRL-CAD: 03starseeker * r31086 10/brlcad/trunk/src/nirt/if.c: Whoops - r_exit, not r_entry, should be preserved for gap |
| 03:19.35 | *** join/#brlcad pacman87 (n=Timothy@pool-71-164-238-31.dllstx.fios.verizon.net) | |
| 03:30.24 | CIA-21 | BRL-CAD: 03brlcad * r31087 10/brlcad/trunk/src/mged/cmd.c: reorder to remove need for decls |
| 03:34.14 | yukonbob | brlcad: ping |
| 03:34.33 | yukonbob | is there a way to trace the assignment of a var (in C) w/ gdb? |
| 03:35.06 | yukonbob | sees breakpoints, and "collect", but I was hoping for somethin more automagic... |
| 03:35.34 | yukonbob | *something |
| 03:41.22 | yukonbob | sees (?) breakpoints might be more powerfull than he thought... |
| 03:45.27 | CIA-21 | BRL-CAD: 03brlcad * r31088 10/brlcad/trunk/src/mged/setup.c: static -> HIDDEN |
| 03:46.56 | CIA-21 | BRL-CAD: 03brlcad * r31089 10/brlcad/trunk/src/mged/cmd.c: tighten the _WIN32 block on % so it'll at least provide help |
| 03:49.20 | yukonbob | loads up gdb into xemacs... |
| 04:28.55 | brlcad | yukonbob: pong |
| 04:28.59 | brlcad | yes, you can set a watch |
| 04:31.49 | yukonbob | brlcad: hey -- I'm trying to solve a Segment Violation -- I can see what ptr is being used uninitialized -- I need to find out when/where this is happening... |
| 04:32.27 | yukonbob | is getting a bit of ahandel w/ xemacs/gdb (read: it's awesome), but I haven't developed good gdb-fu yet ;) |
| 04:45.58 | louipc | yukonbob: woot xemacs |
| 04:54.58 | yukonbob | louipc: indeed, indeed. |
| 04:55.12 | yukonbob | w00t screen, too :) |
| 05:40.30 | CIA-21 | BRL-CAD: 03brlcad * r31090 10/brlcad/trunk/ (include/bu.h src/libbu/parse.c): make the input string of bu_shader_to_tcl_list() be const, make a copy so it can still insert the nulls as a separator but just still don't modify the original |
| 07:01.19 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 07:01.35 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 07:37.28 | *** join/#brlcad clock_ (n=clock@zux221-122-143.adsl.green.ch) | |
| 07:50.56 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 08:23.00 | CIA-21 | BRL-CAD: 03brlcad * r31091 10/brlcad/trunk/src/libbu/vls.c: move the (unused) HAVE_SHELL_ESCAPE logic from rt_split_cmd() on over into bu_argv_from_string() so that rt_split_cmd() can be marked deprecated |
| 08:25.07 | CIA-21 | BRL-CAD: 03brlcad * r31092 10/brlcad/trunk/src/libbu/getopt.c: match the header prototype, char *[] |
| 08:26.33 | CIA-21 | BRL-CAD: 03brlcad * r31093 10/brlcad/trunk/src/ (remrt/remrt.c remrt/rtsrv.c tab/tabinterp.c tab/tabsub.c): convert from rt_split_cmd to bu_argv_from_string |
| 08:28.23 | CIA-21 | BRL-CAD: 03brlcad * r31094 10/brlcad/trunk/ (doc/deprecation.txt include/raytrace.h src/librt/cmd.c): formally deprecate rt_split_cmd(), callers should now use bu_argv_from_string() instead |
| 08:55.41 | CIA-21 | BRL-CAD: 03brlcad * r31095 10/brlcad/trunk/ (8 files in 2 dirs): make the new ged functions all use const char **argv's so callers can be sure the library doesn't modify their data |
| 09:00.14 | CIA-21 | BRL-CAD: 03brlcad * r31096 10/brlcad/trunk/src/mged/ (17 files): |
| 09:00.15 | CIA-21 | BRL-CAD: major constification of all the converted commands as well as those they relate |
| 09:00.15 | CIA-21 | BRL-CAD: to or indirectly call. ended up needing to make a heck of a lot more const than |
| 09:00.15 | CIA-21 | BRL-CAD: expected. add the start of a new 'generic' mged command parser for the new ged |
| 09:00.16 | CIA-21 | BRL-CAD: commands (unused but stubbed). |
| 09:47.08 | *** join/#brlcad archivist_emc (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 11:01.30 | *** join/#brlcad thing0 (n=ric@123.208.207.48) | |
| 11:36.59 | *** join/#brlcad thing1 (n=ric@203-59-26-22.perm.iinet.net.au) | |
| 11:41.51 | *** join/#brlcad d_rossberg (n=rossberg@bz.bzflag.bz) | |
| 12:20.27 | brlcad | yawns |
| 12:21.05 | CIA-21 | BRL-CAD: 03starseeker * r31097 10/brlcad/trunk/src/nirt/ (nirt.c parse_fmt.c): Add missing break, add g to fmt options. Reading state file now works, mged still not happy. |
| 12:21.06 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 13:04.50 | CIA-21 | BRL-CAD: 03d_rossberg * r31098 10/brlcad/trunk/src/conv/3dm/3dm-g.cpp: made the code portable (using the standard string header) |
| 13:10.18 | CIA-21 | BRL-CAD: 03d_rossberg * r31099 10/brlcad/trunk/src/conv/3dm/ (CMakeLists.txt Makefile.am): MS Windows port of 3dm-g with CMake build system generator |
| 13:13.39 | CIA-21 | BRL-CAD: 03d_rossberg * r31100 10/brlcad/trunk/src/libsysv/CMakeLists.txt: we do not need neither redata.c nor regex.c too for MS Windows |
| 13:15.05 | yukonbob | !cmake |
| 13:16.55 | CIA-21 | BRL-CAD: 03d_rossberg * r31101 10/brlcad/trunk/src/other/tcl/CMakeLists.txt: revised, e.g. for CMake 2.6 |
| 13:20.46 | CIA-21 | BRL-CAD: 03d_rossberg * r31102 10/brlcad/trunk/misc/win32-msvc/CMakeLists.txt: include 3dm-g and require at least CMake 2.6 |
| 13:21.03 | *** join/#brlcad thing0 (n=ric@123.208.126.231) | |
| 13:22.56 | CIA-21 | BRL-CAD: 03d_rossberg * r31103 10/brlcad/trunk/misc/win32-msvc/Dll/brlcad.def: added some additional functions to the list (e.g. mk_brep) |
| 13:25.42 | CIA-21 | BRL-CAD: 03d_rossberg * r31104 10/brlcad/trunk/misc/win32-msvc/Dll/CMakeLists.txt: fixed a problem with dependencies and linked libraries on MS Windows |
| 13:29.27 | CIA-21 | BRL-CAD: 03d_rossberg * r31105 10/brlcad/trunk/src/ (3 files in 3 dirs): link and use openNURBS as a shared library |
| 13:36.43 | *** join/#brlcad docelic (n=docelic@78.134.193.146) | |
| 14:13.04 | *** join/#brlcad prasad_ (n=psilva@70.108.244.218) | |
| 15:06.57 | *** join/#brlcad docelic_ (n=docelic@78.134.196.19) | |
| 15:18.23 | *** join/#brlcad pacman87 (n=Timothy@pool-71-164-238-31.dllstx.fios.verizon.net) | |
| 15:54.08 | CIA-21 | BRL-CAD: 03bob1961 * r31106 10/brlcad/trunk/src/tclscripts/mged/dbfindtree.tcl: Added a -l option to dbfindtree for returning the paths in a list. |
| 16:14.03 | *** join/#brlcad Elperion (n=Bary@p54877C4C.dip.t-dialin.net) | |
| 16:30.36 | *** join/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) | |
| 17:21.37 | CIA-21 | BRL-CAD: 03starseeker * r31107 10/brlcad/trunk/src/ (5 files in 4 dirs): Add mged support for new option, set default output for gap to nil to mimic old behavior by default. |
| 17:22.00 | *** join/#brlcad homovulgaris (i=homovulg@gateway/tor/x-67bc56efc1387c0a) | |
| 17:22.18 | homovulgaris | hi everybody :) |
| 17:22.50 | prasad_ | hi dr nick |
| 17:22.52 | homovulgaris | hi Sean, I was working on rewriting the wiki page and realised i should talk to you before writing too much arbitrary stuff :P |
| 17:25.42 | homovulgaris | i have been looking at the prospect of implementing parametrics and constraints as two connected but distinct domains |
| 17:26.48 | brlcad | howdy homovulgaris |
| 17:26.51 | brlcad | wb |
| 17:29.25 | homovulgaris | constraint definition, satisfaction and associated structures required in terms of constraint network is pretty involved in itself ;) |
| 17:29.58 | homovulgaris | so i think we should look at the parametric implementation and constraint implementation quite a bit :) |
| 17:30.22 | homovulgaris | because in the end it is the constraints which are going to be more productive ( like maintaining tangency for example) |
| 17:30.51 | homovulgaris | of course parametrics is a necesary prerequisite for constraints to exist i believe |
| 17:31.46 | homovulgaris | how i was visualising the flow was 1. you ask libpg to create a parameter based geometry ( line dependent on 2 points for example ) |
| 17:32.35 | homovulgaris | 2. libpg creates this structure in memory space and produces the necessary arguments to store it in .g file and asks librt to do it |
| 17:33.43 | homovulgaris | 3. it creates a feed so that other parametric objects can subscribe to it so that they can automatically update themselves if this object changes and they are "interested" in it |
| 17:34.00 | homovulgaris | I am still thinking about how exactly to store this information in .g files |
| 17:34.59 | archivist | in any given context only x constraints are possible , let the user choose |
| 17:35.59 | homovulgaris | that is true. i mean given n objects there are various constraint possibilities between them and the user has to choose which one to use. |
| 17:36.48 | homovulgaris | basically .g has to support new data in terms of a) parameters related to each geometry and b) new non-geometric objects called constraints |
| 17:38.13 | homovulgaris | a. further breaks down into 1. numerical parameter values, 2. pointers or reference to parents or geometry which it depends on 3. data about which feeds to subscribe to which i think is basically 2 itself |
| 17:38.27 | archivist | if user attempts to over constrain, error and allow it to be driven not driving |
| 17:41.29 | homovulgaris | mathematical definition of constraints is using a 3-tuple |
| 17:41.31 | homovulgaris | basically 1. variables 2. domains and 3. relations |
| 17:41.35 | homovulgaris | in our case this would be 1. geometry and parameters 2. range for parameters and 3. constraint type definition |
| 17:41.37 | homovulgaris | what would be a good method for storage of such data in .g |
| 17:41.41 | homovulgaris | or do u think it would be functional to store them in a different file ? |
| 17:44.01 | homovulgaris | using attribute value system would obviously be a hack method as sean mentioned on the mailing list |
| 17:44.08 | homovulgaris | so we indeed need to support two new data types in .g |
| 17:44.52 | homovulgaris | one are parametric objects ( which are non-geometric but contain geometry inside them) and two constraint objects |
| 17:46.20 | homovulgaris | archivist, in other systems ( catia for example) over constraining is generally not shown as an error but the user is notified by showing those set of geometry which is overconstrained in a different colour |
| 17:46.55 | archivist | solidworks warns and says do you want this driven |
| 17:46.57 | homovulgaris | so that the user can delete some other constraint and make it ok for example. |
| 17:48.23 | homovulgaris | either ways constraint satisfaction is far away :) i am still tackling constraint definition ;) |
| 18:23.41 | brlcad | homovulgaris: I agree .. constraints are really the end-user feature, and parametric equation support is sort of the underlying feature that supports it |
| 18:45.49 | homovulgaris | hi brlcad, i mean parameters themselves can be an end-user feature like a sphere whose radius is a parameter which the user can vary.. but i think more funtional use would be in terms of constraints |
| 18:48.58 | homovulgaris | my major concern is in terms of storage in .g |
| 18:50.18 | archivist | some of my parts are driven by spreadsheets |
| 18:53.17 | archivist | I dont like the external use of a spreadsheet, but do like the functionality |
| 18:58.49 | homovulgaris | archivist: what do u use spreadsheets for ( :) i feel like a complete noob ) |
| 19:00.55 | archivist | I draw clocks, the gear parts are driven by a spredasheet to give thickness, module center hole dia and number of teeth, there are some calcs to get dimensions |
| 19:01.29 | archivist | angles, outside dia |
| 19:01.54 | archivist | and hidden construction lines |
| 19:03.46 | archivist | so the calcs represent some british clock gear cutting standard |
| 19:27.45 | homovulgaris | so how do u synchronise the data in spreadsheets and the geometry ? using scripts ? |
| 19:38.15 | *** join/#brlcad archivist_win (n=djc@host81-149-119-172.in-addr.btopenworld.com) | |
| 19:38.51 | archivist | fires up windaz and solidworks and irc.... |
| 19:40.47 | archivist_win | in a parts hierachy is a design table thats an excel spreadsheet (they use external fuctionality fom withing solidworks) |
| 19:43.08 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 19:44.03 | archivist | named columns refer to named dimensions in a part |
| 19:44.30 | archivist | named rows refer to versions of the part |
| 19:49.07 | CIA-21 | BRL-CAD: 03starseeker * r31108 10/brlcad/trunk/ (NEWS src/nirt/nirt.1 src/nirt/parse_fmt.c src/nirt/usrfmt.h): Add option to nirt that allows reporting of gaps, per request #1933724 - includes expansion of Query Ray panel in mged |
| 19:50.07 | archivist | <PROTECTED> |
| 19:50.56 | homovulgaris | archivist: hmm.. dassault.. they have something similar called design tables in catia too.. basically one design alternative per row |
| 19:51.27 | archivist | dassault own solidworks as well |
| 19:51.54 | homovulgaris | yeah. |
| 19:51.57 | homovulgaris | whats dedendum ? |
| 19:52.10 | homovulgaris | and module the single values at the bottom i mean ? |
| 19:52.10 | archivist | root of tooth |
| 19:52.29 | archivist | constants |
| 19:52.54 | homovulgaris | hmm.. k |
| 19:53.01 | archivist | leave a gap in the rows and its free space for the user |
| 19:53.44 | CIA-21 | BRL-CAD: 03starseeker * r31109 10/brlcad/trunk/src/nirt/nirt.1: Add 'g' to man page for nirt |
| 19:54.04 | archivist | I dont draw to absolute accuracy (not enough time) |
| 20:04.49 | homovulgaris | :) |
| 20:05.49 | archivist | there is a subdir there clock which has a web 3d of a design |
| 20:06.13 | archivist | if you have windows (silly restrictions) |
| 20:08.29 | homovulgaris | :( on linux .. will check it out when i am on windows ( note to self: this is why i should get my laptop repaired ) |
| 20:09.28 | archivist | I tried serving it on debian, no go, had to proxy to the winbox (wont be up 24/7) |
| 20:23.18 | *** part/#brlcad thing0 (n=ric@123.208.126.231) | |
| 20:32.06 | brlcad | homovulgaris: sorry for the sporadic input, busy day .. lots of comments pending :) |
| 20:39.05 | homovulgaris | no probs :) |
| 20:42.17 | homovulgaris | is this the final draft ? http://ftp.arl.army.mil/~mike/papers/brlcad5.0/newdb.html |
| 20:47.18 | homovulgaris | and WOW.. mike muuss wrote ping |
| 20:48.41 | homovulgaris | i guess he got that wherever he went inspite of being the architect of brl-cad ;) |
| 20:52.57 | CIA-21 | BRL-CAD: 03bob1961 * r31110 10/brlcad/trunk/ (9 files in 4 dirs): Added make_name and make commands to libged. |
| 20:55.13 | brlcad | homovulgaris: it's close to a final draft, but it's not 100% consistent with what was ultimately implemented. some minor idents are different, some features aren't implemented (like compression support) |
| 20:56.08 | brlcad | the source is the reference, of course, librt being where the db i/o layer is implemented |
| 20:56.13 | homovulgaris | k so that draft+code would be the best approach ? |
| 20:57.04 | brlcad | the draft is a good starting point just for understanding the overall structure of a .g file -- as to what pieces you care about depends on how exactly the equations are persisted/stored |
| 20:57.27 | brlcad | as attributes there is no need to modify the db format, it all happens in the library |
| 20:57.54 | brlcad | as new object types, it depends which type and how robustly the modifications are added for the new non-geom objects |
| 20:58.49 | homovulgaris | we are using machine independent .g files right ? |
| 21:00.22 | homovulgaris | the way i was seeing it.. a non geometric parametric object basically contains geometry ( example a Line which connects two points) |
| 21:00.58 | CIA-21 | BRL-CAD: 03starseeker * r31111 10/brlcad/trunk/src/nirt/nirt.c: Add logic to check for scripts in brlcad data directory (which doesn't exist yet) - may want to change this so local file with same name overrides global file? |
| 21:01.08 | brlcad | yeah, v5 .g files are machine independent |
| 21:01.30 | homovulgaris | so basically the PLIne is a non-geometric object which contains 1. the geometric object line 2. references to the two points indicating they are parents |
| 21:01.34 | brlcad | v4 .g files are not, nobody should be using those (and you don't have to worry about backwards support for them) |
| 21:02.23 | CIA-21 | BRL-CAD: 03bob1961 * r31112 10/brlcad/trunk/src/mged/qray.h: Removed extra double-quote from QRAY_FORMAT_NULL. |
| 21:02.59 | homovulgaris | when we come to constrain objects which are non-geometric again, then they have the three types of data i mentioned earlier |
| 21:03.05 | brlcad | reads the earlier comments to catch up |
| 21:04.23 | homovulgaris | basically 1. variables 2. domains and 3. relations ..in our case this would be 1. geometry and parameters 2. range for parameters and 3. constraint type definition |
| 21:05.10 | homovulgaris | the attribute system could work for storing the parameters but seems like a reverse method of storage. |
| 21:05.50 | homovulgaris | for constraint objects i have to figure out the v5 database more i guess |
| 21:06.00 | brlcad | you're not making it easy to catch up :P |
| 21:06.32 | homovulgaris | sorry :P |
| 21:09.01 | homovulgaris | basically there would be two types of new objects introduced |
| 21:09.01 | homovulgaris | 1. parametric objects |
| 21:09.02 | homovulgaris | 2. constraint objects |
| 21:09.02 | homovulgaris | both of them are non-geometric in the present sense |
| 21:11.29 | brlcad | to answer from earliery, don't think it's at all functional to store in a different file .. needs to be in the .g and the 'right way' is probably as new object types like you're suggesting |
| 21:12.31 | brlcad | instead of "containing" geometry, it can simply reference the geometry it applies to |
| 21:13.08 | homovulgaris | yeah i also felt that storing in a separate file is not exactly very functional |
| 21:13.18 | brlcad | the danger worth avoiding is layering in YAGF that isn't associated with existing geometry being created |
| 21:13.58 | homovulgaris | hmm.. |
| 21:15.08 | brlcad | the parameters are known values/objects/reference points if I'm not mistaken |
| 21:16.27 | homovulgaris | most of the times |
| 21:16.44 | homovulgaris | i mean at times they maybe some value of a property not already supported by the existing geometry representation |
| 21:17.01 | homovulgaris | like if i want a point which is at a ratio 0.6 between two points |
| 21:17.15 | homovulgaris | the value 0.6 is a parameter |
| 21:17.36 | homovulgaris | but it is not part of the point object for example. but yes it is a known value |
| 21:18.19 | homovulgaris | ok.. so in .g using a different object Header / flags we can denote the fact that it is a non-geometric object type .. |
| 21:29.21 | homovulgaris | and in terms of workflow since u create geometry at the same time as constructing parameters , writing the parametric object type will also result in writing the corresponding geometry object into .g |
| 21:29.27 | homovulgaris | while reading the .g file later we will have to take care of the association with non-existing geometry |
| 21:29.32 | homovulgaris | and what about the feed system ( i mentioned earlier :) ) well basically parametrics would imply objects depending on other objects depending on other objects and so on. |
| 21:29.37 | homovulgaris | so basically instead of keeping track of the whole chain of linkages, each parametric object basicaly starts a feed |
| 21:29.42 | homovulgaris | and all the objects which are "interested" ( in other words dependent on it directly) subscribe to this feed. |
| 21:29.47 | homovulgaris | so that if due to some reason geometry a gets updated, all its subscribers will get the news |
| 21:29.48 | homovulgaris | and can update themselves |
| 21:30.03 | brlcad | so say someone creates a sphere (sph1) with radius 10 at 0,0,0 .. then later wants to add a constraint (ct1) that the sphere remain tangent to the 0,0 XY plane -- I was thinking that the ct1 object would be a non-geom object that refers to it something akin to tangent(sph1, plane(0,0,0,0,0,1)) |
| 21:30.47 | brlcad | then resolving that tangency constraint, it'd resolve that the radius and/or position can still change, and adjust accordingly as edits to sph1 are made |
| 21:32.51 | brlcad | the subscription/feed idea sounds reasonable, I could see it working like that or as a graph in memory (it still is a graph, just an implementation detail) |
| 21:33.26 | homovulgaris | yeah basically a graph. but i think this implementation would be easier to maintain |
| 21:34.16 | homovulgaris | and regarding the sphere tangency .. yep.. the ct1 object would basically have two parents or participants ( sph1 and the plane) and the condition between them tangency |
| 21:34.34 | brlcad | one thing to think about will be how to keep the two separate yet also have an update/evaluate/resolve step |
| 21:35.20 | homovulgaris | and the fact that the sphere can change 4 parameters here ( the three coordinates and the radius ) is because sph1 is an object which has been explicitly made using those parameters |
| 21:35.27 | brlcad | where that example gets really tricky, though, is now say the object is not a sphere.. |
| 21:35.47 | brlcad | say it's a rotated elliptical toroid |
| 21:36.05 | brlcad | if I can "preserve tangency" .. that's pretty darn hard |
| 21:36.17 | brlcad | at least with the implicit representation |
| 21:36.27 | homovulgaris | on the other hand imagine a parametric sphere sph2 which has the centre ( which is defined as a point on a line) and radius as the distance between two other points |
| 21:37.01 | homovulgaris | so fundamentally the ranges over which sph2 can vary is very different from sph1 because it is defined differently |
| 21:38.42 | homovulgaris | constraint satisfaction problems alll follow similar solution techniques once they have been formulated into a constraint network |
| 21:38.50 | brlcad | I think what I'm getting at is how you can go about adding support for the 30+ existing primitives in a generalized manner |
| 21:39.58 | homovulgaris | we will have one object type for each type of primitive |
| 21:40.09 | brlcad | or if it can't really be easily generalized and libpg actually ends up needing to know about all of them |
| 21:40.26 | brlcad | which is less than ideal for many reasons |
| 21:40.39 | brlcad | have one object type for each type of primitive means what? |
| 21:40.53 | homovulgaris | but since each of these primitives can themselves be defined implicitly in different ways |
| 21:41.55 | homovulgaris | basically we will have a Point Object a Curve Object a Surface object |
| 21:42.15 | brlcad | gah, see that gets back to replicating the geometry |
| 21:43.08 | brlcad | that's really undesirable as the geometry information is already there in a compact well-behaved form |
| 21:43.36 | homovulgaris | how much does brlcad use opennurbs ? |
| 21:43.38 | homovulgaris | we wont be replicating the geometry |
| 21:44.17 | homovulgaris | the kind of information i am talking about is not what is already there |
| 21:44.35 | brlcad | it might come down to getting those pieces out of a given primitive perhaps, but those routines would have to be written |
| 21:45.07 | homovulgaris | like for example a Point parametric object would simply be a reference to a line, ratio and then the reference to the line geometry object |
| 21:45.12 | brlcad | opennurbs is presently only used for the brep object type, a new experimental/developmental primitive |
| 21:45.21 | homovulgaris | so the new information we are storing are in terms of relationship we are not storing anywhere else |
| 21:45.38 | homovulgaris | yeah i was reading about brep |
| 21:46.02 | homovulgaris | how would csg and brep work together :) |
| 21:46.29 | brlcad | and the idea that another student will be working on over the summer will be implementing a new *_brep() routine for each primitive to describe that primitive in the brep format using opennurbs |
| 21:46.52 | homovulgaris | basically the new object types for the primitives i was talking about only store the parametric data ( which we do not have support for right now and hence do not store) |
| 21:46.56 | brlcad | they work together as I can ask for the object in either format and evaluate accordingly |
| 21:47.12 | brlcad | if you're ray-tracing, you'd want to use the implicit form, for example |
| 21:47.21 | homovulgaris | k |
| 21:47.40 | brlcad | if tessellating, you want to extract the brep, perform brep-on-brep csg evaluation, and tessellate the resulting evaluated brep |
| 21:48.10 | brlcad | you have boundaries and surfaces with brep, but you don't with implicits |
| 21:48.17 | homovulgaris | ok |
| 21:48.47 | brlcad | but there are still parameterizable values with implicits that should/can/could work with this system |
| 21:49.06 | homovulgaris | hmm.. never liked surface modelers.. :) sketchup for one :P |
| 21:50.24 | homovulgaris | basically to support different primitives we would need different objects |
| 21:50.26 | brlcad | e.g. if you completely ignore the brep work for starters, and say I have a blob of unioned and intersected torii .. and I want to constrain them to be tangent to some other object, say a box |
| 21:51.18 | homovulgaris | of course brep and parametrics has nothing in common as of now :) |
| 21:51.19 | brlcad | how do you forsee that working with that example? |
| 21:52.20 | homovulgaris | hmm.. union and intersection will have to be implemented for parametrics |
| 21:52.55 | homovulgaris | implemented in the sense stored |
| 21:53.20 | archivist | one uses an axis/plane from any object for its reference in a constraint often |
| 21:53.36 | brlcad | it's already stored |
| 21:53.45 | brlcad | that is, it's available to you |
| 21:53.55 | homovulgaris | so that the parametric system or constraint system can know that it is built using that particular operation. |
| 21:53.55 | homovulgaris | how is the union / intersection currently stored in .g ? |
| 21:54.14 | brlcad | it's a combination |
| 21:54.36 | homovulgaris | if that is the case then the constraint would look something like tangency( box, torii_output) right |
| 21:54.38 | brlcad | a combination object that refers to it's contituents by name and operator |
| 21:54.58 | homovulgaris | so basically our parameters would depend on how the torii are defined |
| 21:55.57 | brlcad | e.g. make tor1 tor2 .. tor100 torii then create a combination "comb1" that is tor1 union tor2 intersect tor3 union tor4 ... etc .. union tor100 |
| 21:56.07 | homovulgaris | so that variation would be in terms of the two radii of each torii.. |
| 21:56.27 | brlcad | and then as a user, I want to say "comb1 must remain tangent to tor101" for example |
| 21:56.47 | brlcad | or box or whatever |
| 21:57.30 | homovulgaris | basically in constraint satisfaction all you have to care about is ..what can you vary and how much can you vary it. |
| 21:57.40 | homovulgaris | in this case lets say the box is fixed |
| 21:57.52 | brlcad | sure |
| 21:58.03 | homovulgaris | then you can vary the definition of each of these 100 torii |
| 21:58.28 | brlcad | not really, combinations are rigid objects for all intensive purposes |
| 21:59.16 | brlcad | you might allow scaling if it's not clamped, but otherwise we're talking even just how you align the shape and actually find the tangency point |
| 21:59.17 | homovulgaris | so how do u want them to be tangent ? |
| 21:59.26 | homovulgaris | by orientation change ? |
| 21:59.27 | brlcad | s/the/a/ |
| 22:00.34 | homovulgaris | this basically would mean a datum geometry |
| 22:01.18 | homovulgaris | by datum geometry i imply the fact that the combination is fundamentally non-parametric .. it has nothing the system can vary. so the only thing the system can do is translate/ rotate and scale |
| 22:01.20 | brlcad | yes, basically by orientation .. it's finding that orientation+position that's the (really, really) hard part when dealing with the implicit form |
| 22:02.00 | brlcad | i think i'm just convincing myself that it's really not feasible to perform that sort of constraint without a brep evaluation |
| 22:02.23 | homovulgaris | :D |
| 22:02.36 | brlcad | at best you could maybe do it for the primitives themselves |
| 22:02.38 | homovulgaris | i think it would be feasible |
| 22:02.43 | homovulgaris | this case i mean in general i am not sure |
| 22:02.45 | brlcad | i'm still not hearing how though |
| 22:02.52 | brlcad | even for this case |
| 22:02.57 | homovulgaris | true |
| 22:03.03 | brlcad | say you just have two torii |
| 22:03.21 | brlcad | where one is just slightly shifted to the left/right and is subtracted |
| 22:03.54 | brlcad | so you end up with a big "C" sliver on the outside and another on the inside facing the other way |
| 22:04.25 | brlcad | if I said "make that combination tangent" to anything .. there's no practical way to found out where the tips of that C are |
| 22:04.36 | homovulgaris | basically .. given the two torii |
| 22:04.48 | brlcad | without ray-tracing the hell out of it |
| 22:05.03 | homovulgaris | after the combination given any point on the surface i can know the tangent value |
| 22:05.11 | brlcad | that's my point |
| 22:05.18 | brlcad | you don't know any point on the surface with implicits |
| 22:05.25 | brlcad | the surface is .. implicit ;) |
| 22:05.50 | brlcad | and that just gets worse (much much higher order) when you throw in csg operations |
| 22:06.00 | homovulgaris | yeah so u need the boundary representation :P |
| 22:06.12 | brlcad | you evaluate the surface of an implicit with ray-tracing |
| 22:06.32 | brlcad | you could implement some sort of newtonian search that uses ray-tracing to find the closest point, but that'd be really nasty |
| 22:07.23 | homovulgaris | hmmm.. |
| 22:07.47 | brlcad | now what could be useful is instead of the brep form, I think you might just need "handles" and there may be a generalized way to describe that for any geometry |
| 22:08.23 | yukonbob | waves in; afternoon, gentlemen (and ladies?) |
| 22:09.12 | brlcad | e.g. for a sphere, the handles are its center point and radius; for a box, it's the 8 corner points, 12 edges, and center point |
| 22:09.38 | brlcad | so you could add routines to each primitive that amount to "what are your available handles" |
| 22:10.07 | homovulgaris | hmm.. basically entities which would help you calculate stuff ? |
| 22:10.25 | brlcad | e.g. for a brep, it's all the points, edges/curves, and surfaces that define the object and a center point |
| 22:10.32 | brlcad | yeah |
| 22:12.26 | homovulgaris | but then these routines would vary widely with respect to each primitive right ? |
| 22:12.43 | brlcad | e.g. for a right circular cylinder it's the center point, 2 curves for the circular ends, two radius values for those circles, and the length |
| 22:13.32 | brlcad | yeah, each primitive would be very different, but still only amounting to a limited set of parameterizable values that can be used in the equations/constraints |
| 22:14.52 | homovulgaris | they can be used in equations and constraints but are not themselves modifiable right |
| 22:15.17 | brlcad | why not? |
| 22:15.58 | homovulgaris | they are basically for usage in equations and not for determination and definition of geometry |
| 22:16.00 | homovulgaris | for example in the case of a sphere |
| 22:16.28 | brlcad | ah, missed the dcc, feel free to resend |
| 22:16.34 | homovulgaris | we have center and radius which are two parameters |
| 22:17.15 | homovulgaris | (it was on constraint satisfaction) |
| 22:17.57 | homovulgaris | ok.. wait.. what i have been calling parameters till now are mostly generative parameters or in other words parameters which are necessary to define or create a geometry. |
| 22:18.59 | brlcad | that's a bit of a recursive definition there ;) |
| 22:20.00 | homovulgaris | :D |
| 22:20.45 | homovulgaris | ok lets call them values and objects necessary for creation of objects |
| 22:22.40 | brlcad | i don't care so much what we call everything as it really all blends together -- the main distinction I do make, though, is that we have -- say -- a sphere that is stored a point and a radius .. and now we're adding these things that we're calling parameter objects or constraint objects or widgets whatevers where I get to specify the range/domain of valid values that sphere's position and radius can have |
| 22:23.03 | homovulgaris | so in the case of the above sphere ( we have 2 parameters ( 1. center point 2. radius ) |
| 22:23.03 | homovulgaris | ( about dcc argh.. my college firewall sucks :(( ) |
| 22:23.29 | brlcad | yeah, it announces as 127.0.0.1 |
| 22:23.46 | homovulgaris | yep |
| 22:23.50 | homovulgaris | :P |
| 22:24.28 | brlcad | so in that sphere example, there are at least two objects .. the sphere itself and this constraint/parameter/equation object |
| 22:24.44 | brlcad | wrt the .g file at least |
| 22:25.07 | brlcad | the constraint/parameter/equation object necessarily refers to the sphere object of course |
| 22:25.23 | brlcad | so you have your (as yet) one-node graph there |
| 22:25.37 | homovulgaris | ( and continuing with the spere analogy: there could be other definitions of the sphere . example a sphere with center on a line and radius as the distance between some other points A and B ) |
| 22:25.50 | homovulgaris | so we have two objects additional to the sph1 object in .g file |
| 22:26.30 | brlcad | so if I impose a constraint of radius==5 or position.x = sqrt(radius) etc |
| 22:27.09 | brlcad | dude, pick a more simple example than "center on a line and radius as the distance between some other points A and B" :) |
| 22:27.11 | homovulgaris | 1 is the parametric object which stores information relating to the fact that the center is on a line and that the radius is the distance between two points ) |
| 22:27.26 | brlcad | there are way too many prepositionals in there :) |
| 22:28.17 | homovulgaris | and 2 is the constraint object ( which is basically where u can specify situations like tangency with a plane ) |
| 22:28.38 | homovulgaris | :P |
| 22:28.38 | homovulgaris | ok see in our example of a sphere with a centre and radius |
| 22:28.41 | homovulgaris | we have sph1 in .g |
| 22:29.01 | homovulgaris | we also have a parametric object in .g specifying the fact that the sphere is built using a radius and a centre or 2 parameters |
| 22:29.18 | homovulgaris | till now we dont need to do anything about constraints |
| 22:31.19 | homovulgaris | now lets say we decide that we are going to need the sphere to be always tangent to xy plane.. that is a relation with 1. another object ( xy plane) and 2. does not affect how the sphere was originally defined **directly** |
| 22:31.23 | brlcad | I don't see the point of the parametric object, can just refer to one of the object's 'parameters' .. you can implement knowledge of valid parameters into the primitives and combinations |
| 22:31.49 | homovulgaris | that is when we need a constraint object |
| 22:32.38 | brlcad | i suppose i was only seeing them as the two combined |
| 22:33.16 | homovulgaris | basically i think csg has a limited set of ways of defining the primitives |
| 22:33.37 | homovulgaris | by using the parametric system we can define the same set of primitves in more number of ways |
| 22:33.57 | brlcad | you can have constraints that refer to nothing, effectively just become named parametric equations (e.g. my_sine_obj ==> f(x) = sin(x), which has "one parameter") |
| 22:35.33 | brlcad | i'm not saying not have "the parametric system", you just said "object" which makes me think database object .. I don't see what having two database object types gives us when the first one really is just a handle on what the primitives already have |
| 22:37.26 | homovulgaris | k |
| 22:37.32 | brlcad | am I misunderstanding something about what you just referred to as the parametric object type's purpose? how's having param1 object that provides sph1's radius and center as two parameters different than allowing named convention of obj.parameter or something similar (e.g. sph1.radius) that gets used in the constraint object |
| 22:38.28 | homovulgaris | yeah i know.. but there are different methods of defining the same primitive right ( like if i take the example of a point which is not a primitive right now i guess ? 1. a point can be defined as being on a plane and specified by two coordinates, 2. being on a line specified by a ratio 3. being a projection of another point on a line 4. being a projection of a point on a plane 5. between two points specified by a ratio .. and so o |
| 22:38.29 | homovulgaris | n ) and all these points can be represented using simply coordinates as well.. so multimple definition systems can have a common storage system |
| 22:38.30 | brlcad | on disk, it's useful to remember that everything is a named reference |
| 22:40.55 | homovulgaris | like for example considering defining a sphere as one passing through 3 points.. so parametrically it depends on three points.. on the present .g system it would be stored as sph3.. using radius and centre values and the **parametric** object would have reference to sph3 and reference to the three points |
| 22:42.00 | brlcad | okay, i see that example, but that still to me are just various formulas/equations .. so if we did have a point object, he'd have one inherint "parameter" for the xyz values, if you wanted the various 1/2/3/4/5 methods, that'd be a constraint/parameter/equation object similar to my my_sine_obj => f(x) = sin(x) example |
| 22:42.19 | homovulgaris | i hope i am not confusing u between points in space and a point actually existing as a primitive |
| 22:45.48 | brlcad | for your sphere through 3 points example, it'd be the sph object and a parameter/constraint/equation object that would describe that relationship, namely you'd need some sort of enclosure operation |
| 22:46.28 | homovulgaris | hmmm.. never thought in that direction |
| 22:47.30 | homovulgaris | basically looking at the definition of the geometry as a constraining process in itself |
| 22:47.50 | brlcad | with your 3 points example, what exactly does it contain other than the reference to sph3 and the three points? |
| 22:48.12 | brlcad | it == parametric object |
| 22:48.47 | homovulgaris | in .g file yes |
| 22:49.04 | brlcad | heh, it wasn't a yes/no question ;) |
| 22:49.13 | homovulgaris | in memory basically that'd be the object calculating the centre and radius |
| 22:49.14 | homovulgaris | from the three point coordinates |
| 22:49.39 | brlcad | how/where does it actually describe/encode that the sphere needs to encompass those three points |
| 22:51.45 | homovulgaris | well a sphere passing through three points is a standard definition of a sphere and hence would be in the code |
| 22:51.58 | homovulgaris | as in if the sphere parametric object receives three points as inputs it constructs the sphere object by taking that assumption |
| 22:52.27 | brlcad | ah |
| 22:52.29 | brlcad | yuck :) |
| 22:52.56 | brlcad | that'd basically require coding in the 1/2/3/4/5/n ways for creating any primitive |
| 22:53.13 | brlcad | i was thinking of a generalized solution that applies to any object, primitive or otherwise |
| 22:53.34 | brlcad | "make this torus encompass these three points" |
| 22:53.37 | homovulgaris | yeah the part i like the least |
| 22:53.37 | homovulgaris | :) |
| 22:54.23 | brlcad | mm.. food for thought |
| 22:54.31 | brlcad | and speaking of food.. dinner time :) |
| 22:54.54 | homovulgaris | we can try that using constraint satisfaction. |
| 22:54.56 | homovulgaris | :P |
| 22:54.56 | homovulgaris | morning jogging time here :) |
| 22:55.02 | brlcad | we can continue later if you're on ;) |
| 22:55.34 | archivist | interesting read /me goes home to bed |
| 22:56.11 | homovulgaris | basically my idea is we would have some primitives for generating geometry .. for generalized solution systems i'll have to devote lots of time over the year writing constraint satisfaction algorithms for various **interesting** cases.. like encompassing for example |
| 22:56.57 | brlcad | i really think libpg (or whatever it's called) needs to not have any lists of primitive types or specific creation criteria, it can know about different types of "parameters" (this is a point, this is a non-negative value, this is a vector, etc) |
| 22:57.17 | archivist | likes "gear" mates in solidworks |
| 22:57.30 | homovulgaris | and these primitive geometry systems would server as a basis in terms of constraint solving by variationg of parameters.. |
| 22:57.33 | homovulgaris | anyways.. lots of food for thought ;) |
| 22:59.04 | brlcad | I don't want to see this library encroach upon what librt already does -- librt manages object creation, basic validity checking, knows about each primitive that is supported etc |
| 22:59.11 | homovulgaris | :) |
| 22:59.13 | homovulgaris | i will do some more groundwork :) |
| 23:00.02 | brlcad | really don't want to "replicate" that in libpg, want to overlay existance rules .. the constraint/equation solver adjusts the values on demand per what is specified |
| 23:02.02 | homovulgaris | :) |
| 23:02.29 | homovulgaris | ok.. so that way i have to only concentrate on what sort of primitive definitions are already supported right. |
| 23:02.55 | brlcad | so if you wanted to describe a sphere with three points on the surface, you'd create a constraint akin to on_surface(point1, point2, .. pointn) and tell the solver to search for a solution |
| 23:03.06 | brlcad | sorta |
| 23:03.20 | brlcad | you shouldn't have to know or care what the primitives/object types are |
| 23:04.04 | brlcad | I'm really expecting you'll need to add a routine to each primitive that describes what data values (and their types) can be modified |
| 23:06.21 | brlcad | and that's a really limited set of things you'd need to recognize: values, non-negative values, ranged values (e.g. valid -1 to 1), points (3 values), vectors (3 ranged values), edges (2 points), and planar surfaces (point + vector) for starters |
| 23:07.02 | brlcad | so each/any object can provide a named list of those recognized knobs that can be referenced |
| 23:07.22 | brlcad | then your constraint/equation system goes to town with generalized solutions |
| 23:07.56 | brlcad | really goes to dinner now, bbl! |
| 23:08.38 | homovulgaris | k :) |
| 23:08.41 | homovulgaris | on it ;) |
| 23:08.59 | homovulgaris | :) am going to run 4 kms ;) |
| 23:10.52 | homovulgaris | and this has been a really productive day .. i would have spend another 2 days thinking arbitrary stuff :) |
| 23:20.04 | *** join/#brlcad quentusrex (n=quentusr@c-71-197-244-228.hsd1.or.comcast.net) | |