| 00:04.35 | PrezKennedy | brlcad, the leader of project wilderness says he misses work |
| 00:36.01 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 00:47.07 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 01:54.14 | andrecastelo | brlcad & ``Erik : flat shaded http://img253.imageshack.us/img253/5120/rtmltfscastleas2.jpg :D:D |
| 01:54.34 | pacman87 | oooh, pretty! |
| 02:06.43 | andrecastelo | pacman87: thank you! :D hehehe |
| 02:06.56 | pacman87 | where'd the model come from |
| 02:06.59 | pacman87 | ? |
| 02:08.27 | andrecastelo | hmm.. brlcad/brlcadInstall/share/brlcad/7.12.1/db/ |
| 02:11.20 | CIA-60 | BRL-CAD: 03andrecastelo * r31788 10/brlcad/trunk/misc/win32-msvc9/libged/libged.vcproj: Added ae2dir.c and dir2ae.c. |
| 02:28.31 | CIA-60 | BRL-CAD: 03andrecastelo * r31789 10/brlcad/trunk/src/rt/viewmlt.c: Expanded rayhit() to output a flat shaded image. |
| 03:23.13 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.8.201) | |
| 03:36.03 | starseeker | observes his computer works much better when he has the correct IDE driver in the kernel... |
| 04:51.54 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 05:18.14 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.8.201) [NETSPLIT VICTIM] | |
| 05:28.26 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 05:29.08 | Ralith | Does there exist a more user-friendly modelling interface than mged? |
| 05:30.24 | *** join/#brlcad dtidrow_ (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 06:17.42 | homovulgaris | Raltih: not presently , mafm is working on one. http://brlcad.org/wiki/User:Mafm |
| 06:21.40 | Ralith | homovulgaris: that's good to hear. |
| 06:23.02 | homovulgaris | mged is a "little" tough to get used to .. but it is pretty functional once u start using it |
| 06:23.46 | homovulgaris | u can do things quite rapidly with the keyboard u know :) |
| 06:23.49 | Ralith | I'm sure it is; however, I'm interested in leveraging brl-cad for an audience who are wary of anything not laden in widgets. |
| 06:24.04 | homovulgaris | oh.. |
| 06:24.06 | homovulgaris | :) |
| 06:24.16 | Ralith | Personally, I prefer the keyboard; I use emacs for my generic text editor/IDE, for example. |
| 06:24.25 | Ralith | and in that respect I'm quite interested in learning mged in and of itself. |
| 06:25.19 | Ralith | however, I'm *more* interested to see if brl-cad as a whole is going to become itself accessible to people less interested in spending time learning an arcane interface than just messing around with a mouse to get some basics thrown together quickly and easily |
| 06:25.50 | Ralith | As you may be aware, other than brl-cad, there really isn't any respectable open source CAD system out there. |
| 06:26.16 | homovulgaris | yeah, i know :) |
| 06:26.21 | Ralith | the website cites a *very* impressive resume, which would seem to imply that brl-cad has finally broken that trend, but without a friendly interface, that's not very useful for my purposes. |
| 06:26.49 | Ralith | which would be a real shame, given that the user interface is probably the simplest portion of a professional-quality CAD system |
| 06:26.59 | homovulgaris | once mafm's work is done, things should be pretty smooth |
| 06:27.50 | Ralith | that's really exciting :) |
| 06:27.55 | Ralith | grabs the video |
| 06:28.13 | homovulgaris | the lack of open source CAD systems is really spooky.. I personally majored in architecture last year and had to work entirely on proprietary software tools for instance |
| 06:28.42 | Ralith | yeah |
| 06:29.20 | Ralith | especially since CAD is one of the things which would benefit most from the principles of open source |
| 06:29.20 | homovulgaris | and most of them have such high licensing fees. especially the ones with advanced features like CATIA for instance |
| 06:29.45 | Ralith | e.g. wouldn't it suck if your flagship product's designs were inaccessible because the software developer dropped support? |
| 06:30.16 | Ralith | of course, this generally moot as many CAD formats are well documented and supported. |
| 06:30.40 | Ralith | speaking as someone largely unfamiliar with CAD systems, how does brl-cad compare to something like, say, solidworks? |
| 06:30.40 | homovulgaris | :) u work in CADD sector Ralith ? |
| 06:30.43 | Ralith | nah |
| 06:30.50 | Ralith | I'm a hobbyist |
| 06:31.03 | Ralith | hoping to expand into CAD/CAM/CNC |
| 06:31.30 | Ralith | specifically, using brl-cad with home-built rapid prototyping equipment |
| 06:31.37 | homovulgaris | brl-cad has an impressive array of features. It is more useful for precision modeling and raytracing for physics simulations :) |
| 06:32.01 | homovulgaris | Ralith: rapid prototyping is really kewl. |
| 06:32.20 | Ralith | the eventual goal being the capacity to manufacture precision custom parts with few restrictions and at very low cost |
| 06:32.26 | homovulgaris | Ralith: I myself am quite interested in STL and CNC |
| 06:32.46 | Ralith | the approach I'm looking at is FDM |
| 06:32.52 | Ralith | have you heard of the reprap project? |
| 06:33.39 | homovulgaris | brl-cad has a larger array of tools around 400 and libraries.. but as u said , user friendliness is to be worked out a bit :) |
| 06:33.40 | Ralith | (FDM is neat because it proves to be pretty easy to build a rapid prototyper based on it) |
| 06:33.44 | Ralith | hehe |
| 06:33.45 | Ralith | yeah |
| 06:34.04 | Ralith | but the same goes for the rest of the reprap project, so I figure by the time it becomes userfriendly to build, perhaps brl-cad will be userfriendly to use. |
| 06:34.20 | homovulgaris | btw ;) I am just a gsoc student :D don't take these as official statements :P |
| 06:34.23 | Ralith | the project is seriously suffering from lack of powerful host software |
| 06:34.37 | Ralith | the rapid prototyper itself is moving along nicely, though |
| 06:34.45 | homovulgaris | hmm.. will check out reprap |
| 06:34.49 | Ralith | it's really cool |
| 06:35.08 | homovulgaris | what are the requirements from the host software ? |
| 06:35.17 | Ralith | long-term goal is to produce a rapid prototyper that can manufacture itself; short term goal (already achieved) is to produce one that can manufacture the only hard-to-find and thus expensive parts |
| 06:35.22 | Ralith | well, there's a few different bits |
| 06:35.25 | Ralith | first is the CAD system |
| 06:35.34 | Ralith | which I hope brl-cad will be able to provide |
| 06:35.45 | Ralith | right now a tool called Art of Illusion or something like that is being used |
| 06:35.53 | Ralith | it's some shitty java modeller that almost nobody likes :P |
| 06:36.14 | homovulgaris | :) i hope so too.. rapid prototyper building rapid prototyper sounds like an awesome project :) |
| 06:36.20 | Ralith | yeah |
| 06:36.36 | Ralith | you can build the current model for under $1000, and it's quite useful already |
| 06:36.41 | Ralith | far more than a proof of concept |
| 06:36.44 | homovulgaris | ur work is hosted on the net somewhere ? |
| 06:36.49 | Ralith | it's not my work; I'm just a fan |
| 06:36.52 | Ralith | http://reprap.org/ |
| 06:37.05 | homovulgaris | :) was just seeing reprap |
| 06:37.40 | Ralith | one of the more challenging host-side software requirements is the process of converting models to tool paths for the rapid prototyper |
| 06:37.58 | Ralith | I don't suppose you know of any existing work in that area that would be applicable to a FDM system? |
| 06:38.54 | Ralith | currently, a home-grown java system is being used (I don't get the projects' obsession with java. Perhaps it's the only language the original developers knew.) |
| 06:38.59 | Ralith | it's slow and has problems. |
| 06:39.13 | homovulgaris | nope :) I had just a 1 year span to work on my thesis. so i worked mostly with conventional proprietary stuff :) |
| 06:39.19 | Ralith | It used to (I don't know about the current state) take longer to calculate toolpaths for an object than it took to actually build it |
| 06:39.50 | homovulgaris | hm.. i am no big fan of java :| |
| 06:39.54 | Ralith | I agree. |
| 06:40.26 | Ralith | luckily, the important bit (the rapid prototyper itself and the hardware that drives it) is all done in a much more professional manner. |
| 06:40.26 | homovulgaris | i mean i understand what they say about portability etc. etc. but i always feel unnecessary overhead |
| 06:40.34 | Ralith | the funny thing is, java isn't very portable |
| 06:40.45 | homovulgaris | ;) |
| 06:40.50 | Ralith | C(++) code written using the right libraries beats it any day. |
| 06:41.18 | Ralith | for example, I doubt there's a java VM for netbsd on an ARM processor. |
| 06:42.28 | homovulgaris | hmm.. there should be i guess |
| 06:42.59 | Ralith | and the overhead itself prevents it from being used properly on an embedded platform |
| 06:43.14 | Ralith | hell, it prevents it from being used on plenty of full-on desktop computers :P |
| 06:43.21 | CIA-60 | BRL-CAD: 03d_rossberg * r31790 10/brlcad/trunk/src/libged/CMakeLists.txt: added some files to be consistent with Makefile.am |
| 06:43.47 | homovulgaris | I better go grab some food :) Ralith, i will check out reprap further .. see u on this channel sometime, u should talk with brlcad (Sean) for better info regarding brl-cad btw ;) |
| 06:43.56 | Ralith | cool |
| 06:43.59 | Ralith | seeya |
| 06:44.23 | homovulgaris | will run reprap today |
| 07:04.21 | brlcad | mehhowdy gents |
| 07:04.28 | brlcad | :) |
| 07:13.40 | *** join/#brlcad lleroy (n=chatzill@axsguard.bepco.com) | |
| 07:18.07 | Ralith | hullo |
| 07:18.20 | Ralith | I'd hang around and ask questions, but it's past midnight over here and I need some rest |
| 07:35.58 | CIA-60 | BRL-CAD: 03brlcad * r31791 10/brlcad/trunk/ (BUGS TODO): fix the primitive selection bug in mged, reported on the forums by lleroy. details in the todo file. |
| 07:40.42 | brlcad | lleroy: I replied -- the bug made it into release |
| 07:41.31 | lleroy | ok, thanks... I wondered if this was a bug or if this was due to my compilation. |
| 07:41.35 | brlcad | lleroy: there are a few trivial mods you can make that will work or you can use the command-line way as a work-around until it gets fixed -- thanks for the report, didn't know about it |
| 07:41.56 | lleroy | btw, what's in brlcad for collision detection? |
| 07:42.20 | lleroy | I mean to look into CAM toolpath generation... |
| 07:42.25 | brlcad | homovulgaris: 200 minutes is certainly not the worst I've seen for a compile :-) |
| 07:46.51 | *** join/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) | |
| 07:51.44 | brlcad | homovulgaris: (reading and responding to scrollback chatter) .. probably needs to support both binary and some scriptable form -- I can imagine some full-constrained parametric object (a full vehicle) will be horribly inefficient to have it evaluate everything as strings, but that's probably what the user will input in creating them |
| 07:54.04 | brlcad | pacman87: d_rossberg's comments about self-intersecting your sketch when connecting to the y-axis is the same that I was referring to -- probably want to connect and stop when that happens instead of going all the way to the y-axis so you don't end up with open edges and infinitely thin walls |
| 07:56.01 | brlcad | MinuteElectron: cool, and thanks :-) |
| 07:59.15 | brlcad | pacman87: fyi, dividing by zero will cause a run-time abort exception for many environments |
| 08:00.28 | brlcad | getting inf/nan results from a floating point unit is compilation and hardware dependent (relies on ieee conformance, which is a bad assumption) -- should always be using tolerance tests and other logic in order to get consistent reliable behavior |
| 08:01.20 | brlcad | PrezKennedy: heh, and the wilderness misses him too! |
| 08:04.39 | brlcad | andrecastelo: hah! awesome ... nice work, send that to erik if he doesn't see it here :) |
| 08:07.33 | brlcad | homovulgaris: how dare you say you're "just a gsoc student" .. :-) |
| 08:09.22 | brlcad | aww |
| 08:09.27 | brlcad | catches up |
| 08:12.29 | lleroy | brlcad: what support is available in brlcad for generating CAM toolpaths? |
| 08:17.04 | brlcad | lleroy: none directly -- your best bet is probably looking at your CAM hardware to see if it'll autogenerate for a given input format (like stl, which we can export) |
| 08:17.28 | lleroy | brlcad: I mean, if I were to implement CAM inside BRLCAD? |
| 08:18.30 | lleroy | brlcad: I remember reading on a forum something along the lines of "there is already support stuff implemented for CAM but...???" |
| 08:18.31 | brlcad | ah, well in that regard there is a fair bit available and quite a few things that are possible |
| 08:19.21 | brlcad | shotlining can actually give you some surprisingly accurate (sampled) collision detection, high-performance, and robust |
| 08:20.33 | brlcad | if you wanted to generate toolpaths for a layered dual-axis cnc for example, i could see setting something up where you raytrace each layer of your model and infer solidity/paths from the result |
| 08:21.14 | brlcad | similar to what rtedge is doing for 2D images, but on a slice-by-slice approach up through a model |
| 08:24.10 | brlcad | from a ray-tracing perspective, overlaps == collisions, so you could conceivably write a tool that would read in some geometry, provide tooling options (gui, cmd line, or otherwise), and then use either parametric projections or sampled slicing or some volumetric approach for generating tool paths (sort of a g-gcode converter in the end) |
| 08:26.32 | lleroy | is there something for region-querying (i.e. give me all objects that intersect an object) |
| 08:26.58 | lleroy | or where their bounding box/sphere intersects this box/sphere |
| 08:28.40 | brlcad | performing the latter would be really trivial if there's not a routine already for that |
| 08:29.11 | brlcad | there's not something to query existing overlaps that intersect, though that certainly depends on current object/viewing states |
| 08:29.19 | lleroy | yes, but doing so efficient using something along the lines of kdtree? |
| 08:29.42 | brlcad | yeah, that's what I was trying to think if there is something |
| 08:30.05 | brlcad | nothing that comes to mind that uses the spatial partitioning, but I'd have to rummage around librt a bit to be sure |
| 08:30.07 | lleroy | is there a partitioning scheme in use in librt |
| 08:31.12 | brlcad | yeah, definitely -- this question comes up a fair bit, I should really document it somewhere.. :-) |
| 08:32.30 | brlcad | it actually supports a variety of space partitioning mechanisms |
| 08:34.20 | brlcad | there's a BSP implementation and a hybrid grid-based partitioning scheme in place presently |
| 08:35.48 | brlcad | (which isn't so much like traditional gridding, it dynamicly sizes, attempts to balance objects per grid cell, etc) |
| 08:37.15 | brlcad | default though is a non-uniform binary space paritioning tree |
| 08:41.15 | brlcad | that's also, though, why I was referring to using the shot-liner since a) that uses space partitioning and is fast/robust, and b) is how you evaluate that an overlap actually exists regardless (since there is potentially unevaluated CSG and other geometry) |
| 08:51.18 | *** join/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 08:52.09 | lleroy | brlcad: something completely different: I was trying to understand the mged_ill problem, and I wonder where the code jumps to when _mged_ill is called... (i suppose it jumps from tcl to C, but I failed to find the entry point into the C code) |
| 09:38.30 | *** part/#brlcad lleroy (n=chatzill@axsguard.bepco.com) | |
| 10:10.01 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 10:16.20 | alex_joni | brlcad: seen http://code.google.com/p/wildcat-cad/ ? |
| 10:25.10 | *** join/#brlcad elite01 (n=elite01@unaffiliated/elite01) | |
| 10:27.15 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 10:28.38 | mafm | hi |
| 10:30.54 | mafm | brlcad: did you see the question about the camera yesterday? |
| 10:34.22 | *** join/#brlcad thing0 (n=ric@203-59-111-122.dyn.iinet.net.au) | |
| 11:04.29 | *** join/#brlcad homovulgaris (n=homovulg@117.196.143.199) | |
| 11:05.17 | homovulgaris | brlcad: :O more than 200 ? |
| 11:05.24 | homovulgaris | what was it on :) |
| 11:08.17 | homovulgaris | btw, 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 |
| 11:08.42 | homovulgaris | but it gives some trouble while configuring in tcl saying LDFLAGS was not set during the last run |
| 11:09.07 | homovulgaris | is there something additional i have to do other than adding the macro to m4 dir and the code to configure.ac |
| 11:09.45 | homovulgaris | and also , did u see my question about passing data about variables to C++ by strings ? |
| 11:10.15 | homovulgaris | sorry if u already replied.. is there any way to check up logs .. the ones at ibot.rikers is always one day old right ? |
| 11:15.19 | alex_joni | 10:38 <@brlcad> homovulgaris: (reading and responding to scrollback chatter) .. |
| 11:15.19 | alex_joni | <PROTECTED> |
| 11:15.19 | alex_joni | <PROTECTED> |
| 11:15.19 | alex_joni | <PROTECTED> |
| 11:15.19 | alex_joni | <PROTECTED> |
| 11:15.21 | alex_joni | <PROTECTED> |
| 11:26.59 | *** join/#brlcad andrecastelo__ (n=chatzill@189.71.25.125) | |
| 12:24.20 | *** join/#brlcad clock_ (n=clock@77-56-94-123.dclient.hispeed.ch) | |
| 12:27.51 | *** join/#brlcad sam (i=sam@poulet.zoy.org) | |
| 12:32.07 | sam | howdy |
| 12:34.06 | mafm | hi |
| 12:40.08 | *** part/#brlcad Axman6 (n=Axman6@pdpc/supporter/student/Axman6) | |
| 12:47.31 | sam | brlcad: I have two patches to suggest; one prevents "configure" from being removed upon "make distclean", and the other sets CONFIG_TS in the proper format |
| 12:47.32 | sam | http://zoy.org/~sam/patches/patch-brlcad-preserve-configure.diff |
| 12:47.32 | sam | http://zoy.org/~sam/patches/patch-brlcad-debian-friendly-date.diff |
| 12:51.50 | sam | more generally, "make distclean" renders the source tree unusable unless you run autogen again |
| 12:52.35 | sam | (which it shouldn't do) |
| 12:52.48 | sam | I suggest creating a "make maintainerclean" rule instead |
| 13:15.50 | brlcad | alex_joni: yes, I commented on the work a couple weeks ago -- and some chatter on grabowski's mailing list where it was announced |
| 13:16.53 | *** join/#brlcad vedge (n=vedge@205-237-251-204.ilesdelamadeleine.ca) | |
| 13:17.25 | brlcad | mafm: I saw the comments in the commits and your wiki update |
| 13:17.47 | brlcad | but not a specific question |
| 13:17.57 | brlcad | several camera modes would be good to have |
| 13:18.27 | mafm | examples? |
| 13:18.27 | brlcad | howdy sam! :) |
| 13:19.08 | mafm | for kbd control is not much of an issue, but I don't know for making a window to control the camera |
| 13:20.48 | brlcad | sam: for the first, understandable though it was intentional to make distclean restore the sources to a *checkout* state |
| 13:21.13 | sam | yeah, I understand the idea |
| 13:21.20 | brlcad | we could of course get that with another rule, but were intentionally avoiding having a plethora of clean rules when one goes "all the way" |
| 13:21.23 | sam | maybe it's just misc/debian which needs a makeover |
| 13:21.53 | sam | it's the first project I see where "make distclean" doesn't allow you to reconfigure though |
| 13:22.33 | brlcad | it's very bikesheddish to me -- not a big deal either way -- but there are undoubtedly other mods that would be needed to make it clean up to a dist state |
| 13:22.48 | brlcad | though I might have already started |
| 13:22.56 | brlcad | e.g. the Makefile.in files |
| 13:23.26 | brlcad | sure, I understand the tradeoff -- just saying it was indeed intentional, we distclean and run autogen.sh |
| 13:23.52 | brlcad | distclean is run prior to making a dist, so our devs have to go through the full release prep |
| 13:24.40 | brlcad | sam: curious about the second patch -- it should already be setting that with the LC_ALL=C that preceeds |
| 13:26.08 | sam | brlcad: my bad, I missed the LC_ALL=C |
| 13:26.16 | sam | but the important part is the -R flag |
| 13:26.29 | sam | debian/changelog needs to be in a very specific format |
| 13:26.46 | brlcad | i'm on a bsd atm, what does -R do? |
| 13:27.55 | sam | RFC822 format |
| 13:27.56 | brlcad | misc/debian is/was user-contributed by someone that was trying to set it up in apt, you're welcome to take it over if you like |
| 13:28.06 | brlcad | they've not continued their efforts |
| 13:28.30 | sam | I'm afraid I would make a sloppy maintainer for such a big piece of software |
| 13:28.50 | brlcad | nods |
| 13:28.59 | brlcad | and there are still integration issues to sort out |
| 13:29.35 | sam | I can provide patches during my quest to a working brlcad package though :) |
| 13:29.57 | brlcad | sure ;) |
| 13:30.10 | brlcad | want commit access to work on that or prefer patches? |
| 13:33.37 | sam | as you wish |
| 13:39.36 | CIA-60 | BRL-CAD: 03brlcad * r31792 10/brlcad/trunk/configure.ac: apply CONFIG_TS patch from sam hocevar to make the date stamp return in RFC822 format. breaks compilation timing, so might need to make sh/elapsed.sh handle 'one more' format |
| 13:40.42 | CIA-60 | BRL-CAD: 03brlcad * r31793 10/brlcad/trunk/Makefile.am: we already removed the Makefile.in clobbering for distclean, so go the extra mile and keep configure too; patch from sam (thanks) |
| 13:50.33 | CIA-60 | BRL-CAD: 03brlcad * r31794 10/brlcad/trunk/AUTHORS: special thanks to sam hocevar for his build system tweaks and debian integration testing |
| 13:52.02 | CIA-60 | BRL-CAD: 03brlcad * r31795 10/brlcad/trunk/AUTHORS: sammy is another (commit) nick |
| 13:52.46 | sam | wow, that was fast :) |
| 13:54.07 | brlcad | you have commit now, you're a fairly known quantity and all changes are pretty closely scrutinized for this project regardless |
| 13:54.47 | brlcad | but either way, thanks for the mods .. it will be really cool to finally get into apt cleanly some day |
| 13:55.24 | brlcad | trunk is unstable if you're running/testing things, there's a separate stable branch for release integration testing |
| 13:55.28 | homovulgaris | i look forward to apt-get install brlcad :) |
| 13:55.42 | brlcad | yeah, that request comes up like once a month it seems |
| 13:55.47 | sam | I was surprised brlcad wasn't in Debian |
| 13:55.58 | sam | I found packages but they're only i386 and I run amd64 |
| 13:56.24 | brlcad | that was the last time it was seriously worked on, outside of build fixes done for ubuntu |
| 13:57.39 | sam | the task is huge: unfortunately Debian still has tcl8.5 and itcl3.1 |
| 13:57.41 | brlcad | the biggest problem for integration is that brl-cad is big and with an extensive heritage .. developed since early 80's, it's more like X11 than it is like, say, gimp or even blender |
| 13:58.32 | brlcad | so it was developed to install (like many proprietary apps or X11) into an isolated root given the conflict reality |
| 13:58.38 | sam | yeah, I could see that... commit messages from 1983 :) |
| 13:59.09 | brlcad | we've got most of that fixed now, but there are still a few critical issues remaining (one being proper system incrTcl detection) |
| 13:59.30 | brlcad | and our high-conflict potential libs: librt, libbn, libbu |
| 14:00.13 | sam | are the contribs linked statically into brlcad, or installed in a separate suffix? |
| 14:00.15 | brlcad | they're our core libs and predate those we conflict, but librt is still pretty prevalent (albeit deprecated) |
| 14:00.54 | brlcad | ideally they're linked dynamic for package managers |
| 14:01.04 | brlcad | they're only compiled and linked if not detected |
| 14:01.48 | brlcad | whether we build static or dynamic is a build setting, defaults to dynamic/shared libs |
| 14:01.59 | brlcad | our install becomes several GB in side if it's static |
| 14:02.07 | brlcad | s/side/size/ |
| 14:04.07 | brlcad | so to avoid the conflicts, I think the ultimate goal is to just set up the build system so that a /usr prefix will default to /usr/lib/brlcad/VERSION etc for the libs |
| 14:04.18 | brlcad | i think i've resolved all of our bin conflicts |
| 14:17.54 | brlcad | mafm: heh |
| 14:18.02 | brlcad | (and hi) :) |
| 14:18.23 | mafm | hiya |
| 14:18.34 | brlcad | I didn't respond because it seemed more a comment than a question :) |
| 14:18.49 | mafm | I see |
| 14:19.05 | mafm | well, it's because I don't know the level of sofistication desired |
| 14:19.25 | mafm | in geometry editors you don't need "follow player" modes and things like that |
| 14:19.30 | brlcad | for clarity, you're talking about how the view responds to mouse events, yes? |
| 14:19.38 | mafm | so I figured that orbital mode (with zoom) could be enough |
| 14:20.11 | mafm | more to kbd events, but could be mouse too |
| 14:20.13 | brlcad | you need a "follow player" mode if you have animation/timeline support where there's a camera being tracked |
| 14:20.56 | mafm | are animations supported by brl-cad? |
| 14:21.10 | brlcad | crude, but yes |
| 14:21.14 | mafm | hmm |
| 14:21.30 | brlcad | I wouldn't worry so much about that right now though |
| 14:21.54 | brlcad | I see two immediate styles that are needed, one being classic "trackball" view support |
| 14:21.59 | mafm | well, the orbital idea can follow a given point, only that it follows it always from the same "orbital-stationary" position |
| 14:22.14 | brlcad | the other being our classic shift-grips |
| 14:22.41 | mafm | with "follow player" I also meant to smooth curves when following the players and so on... that's mostly needed for games with 3rd person view |
| 14:23.29 | mafm | well, I was about to create a somewhat complex and useful camera mode, with accompanying window, so I think that it would be helpful to know |
| 14:23.32 | brlcad | ah, we might be talking about two slightly different things -- I could see having an orbital mode with trackball or with shift-grips |
| 14:24.09 | mafm | ok, I describe |
| 14:24.12 | brlcad | orbital would definitely be useful to have early on, though -- imagine browsing through a geometry database, pulling up a piece of geoemtry, and your preview spins around like in a game preview panel |
| 14:24.43 | mafm | for me orbital is having a central point, and zoom in and out |
| 14:24.58 | mafm | and being able to rotate up-down and left-right |
| 14:25.26 | mafm | so the camera is always in a point of the sphere, looking to the center |
| 14:25.33 | brlcad | sure, that's basically an immobile trackball |
| 14:25.34 | mafm | being the diameter of the sphere variable |
| 14:25.51 | mafm | (and following the center, if it happens to be mobile) |
| 14:26.40 | mafm | another mode is 1st person as in doom, where basically the controls to move the kbd control the camera too, and have some additional keys to look up&down and so on |
| 14:27.10 | mafm | follwing-player is 3rd person, and would be tracking the player from a few meters behind |
| 14:27.28 | mafm | so you're in a kind of chariot, being the player the horses |
| 14:27.44 | mafm | of course lots of small variations are possible in all the modes :) |
| 14:27.52 | brlcad | nods |
| 14:28.49 | brlcad | do you intent to tie a viewing mode to input behavior, or is it merely a degrees of freedeom matter that's separately considered from input? |
| 14:28.50 | mafm | so how's trackball and shift-grips related with this? I'm not familiar with it |
| 14:29.36 | brlcad | basically, those are input control styles |
| 14:30.18 | brlcad | trackball navigation is what most modelers use by default |
| 14:30.23 | sam | by the way, I'd like to explain why I wanted to try brlcad |
| 14:30.28 | sam | maybe it isn't the right tool |
| 14:30.29 | mafm | the viewing mode would be in general tied to input behaviour I think -- keys to go left/right, up/down, zoom in/out... |
| 14:30.54 | sam | I'd like to create solids whose colour values are f(x,y,z) |
| 14:30.57 | brlcad | sam: if it gets you contributing code/patches/fixes/enhancements, then of COURSE it's the right tool ;) |
| 14:31.03 | mafm | also imagine a window: it could have 4 arrows pointing to cardinal points, and one +/- for zoom, etc |
| 14:31.05 | sam | then perform CSG operations on them |
| 14:31.54 | sam | in order to visualise what colours remain |
| 14:32.33 | brlcad | mafm: okay, if you're going to tie them together, that works -- but probably have to clarify/learn what at least is meant by shift-grips and trackball modes then -- both use the view's eye point as the manipulation point |
| 14:36.03 | mafm | is "trackball navigation" something specific about navigating with trackballs, or just an axis-based mouse? |
| 14:36.36 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 14:36.37 | mafm | or just to only have as input a trackball, instead of mouse and keyboard? |
| 14:40.09 | mafm | imagine that you have 1st person view... you can go forward, backward and turn with arrow keys; look up&down with page up&down; etc |
| 14:40.21 | mafm | but you can also assign similar actions to mouse |
| 14:41.02 | mafm | moving the mouse is looking to a particular direction, clicking some button is run, etc |
| 14:42.08 | mafm | when I speak about a camera mode is basically to have a class encompassing everything, and then you can assign kbd/mouse/trackball events to controll it, with commands similar to zoomIn, turnLeft, goToHomePosition.... |
| 14:42.49 | mafm | but you can also have several camera modes, so each time that you switch the camera mode, your buttons act also differently in the way that you move the view |
| 14:43.55 | mafm | so I'd like a bit of input in what's desired to have input on what's needed/desired if possible, so I implement something sufficiently complex to accomodate to the needs, but not overengineer it |
| 14:44.00 | brlcad | mafm: it has nothing to do with an actual trackball |
| 14:44.47 | brlcad | it's probably what you're most used to actually, started from old old code from sgi back in the 80's, and a trackball.c that most have continued to use over the years |
| 14:45.09 | brlcad | spinning around a simple model in opengl, you have basic trackball control |
| 14:46.10 | brlcad | I know entirely what you mean by the various other modes (remember that I do also code for bzflag, we have most of those modes :) |
| 14:46.51 | mafm | yes, that's what I was guessing :D |
| 14:47.07 | brlcad | you've run mged, yes? |
| 14:47.11 | mafm | yes |
| 14:47.35 | brlcad | notice how it doesn't rotate the view around if you click-drag in the graphics window? |
| 14:47.40 | brlcad | it zooms |
| 14:48.42 | mafm | yes |
| 14:49.33 | brlcad | it's a "shift-grips" interface, where you get zoom in/out with buttons and no move event actions by default, shift+clicking+dragging, though, does one set of operations (e.g. panning), control+click+dragging does another (e.g. trackball rotation), etc |
| 14:49.56 | brlcad | that's one input style that we'll definitely want to have available |
| 14:50.23 | brlcad | taking it away would probably result in me being lynched |
| 14:50.48 | brlcad | but doesn't mean it has to be default, just available ;) |
| 14:50.48 | mafm | lol |
| 14:50.56 | brlcad | there's a doc on the website that details all the bindings |
| 14:51.27 | mafm | Shift Grips Quick Reference Guide ? |
| 14:51.30 | brlcad | we only need a follower mode if/when there is an animation track to follow -- we don't have that yet so I wouldn't focus on that one now |
| 14:51.33 | brlcad | yes |
| 14:51.37 | brlcad | it's just a simple table |
| 14:52.04 | brlcad | a fly-through mode would definitely be useful/interesting |
| 14:52.22 | brlcad | and then having a trackball mode probably by default |
| 14:52.26 | mafm | ok, let me read and think about it and explain you my idea about implementing it |
| 14:52.50 | brlcad | sam: hmmm |
| 14:53.11 | brlcad | sam: that entirely depends what you expect to happen when you perform the CSG operations |
| 14:54.00 | brlcad | you can do what you suggest now, but it sounds like maybe you're wanting addition/subtraction of colors (for union/subtration ops) .. and 'something' for intersection |
| 14:56.42 | mafm | brlcad: trackball up&down&left&right just moves the center of the window, or moves the perspective looking at the same 3D point (I guess that it's the 1st, with another to zoom in&out)? |
| 14:57.35 | sam | brlcad: I just need substraction, so no colour "merging" would be involved |
| 14:59.06 | CIA-60 | BRL-CAD: 03starseeker * r31796 10/brlcad/trunk/doc/docbook/resources/README: Add basic readme explaining why the resources directory exists - this should be fleshed out later. |
| 14:59.07 | brlcad | http://brlcad.org/tmp/colors.png |
| 14:59.16 | brlcad | something like that? |
| 15:01.35 | sam | yes, exactly |
| 15:02.07 | sam | but I also want the solids to have variable colour values (using a parametric function maybe?) |
| 15:02.16 | brlcad | oof |
| 15:02.34 | brlcad | that'd be a shader |
| 15:02.57 | brlcad | certainly doable and not hard, but you'd have to write some code to support it |
| 15:03.12 | sam | and I'd need my GLX driver to understand shaders I guess |
| 15:03.18 | brlcad | no no |
| 15:03.31 | brlcad | ray-trace shader, rather different |
| 15:03.39 | sam | ah, ok. |
| 15:03.46 | brlcad | more like what pixar's renderman does for the movies |
| 15:04.45 | brlcad | when generating an image via ray-tracing, the ray hits a surface and calls upon a 'shader' to determine a color value there (for the intent of coloring a pixel image ultimately) |
| 15:05.21 | sam | would I be able to navigate in near realtime around the scene with a ~1500 vgr machine? |
| 15:05.47 | brlcad | so in that image, you're actually looking at two shaders -- one is a classic "phong" shader that shows surface curvature, specular highlights, etc .. the other is a very very simple "flat" shader that just returns the color set to the object |
| 15:05.48 | sam | the scene would have fewer than 10 cubes |
| 15:06.41 | brlcad | you could certainly navigate the wireframe in realtime.. :) |
| 15:06.45 | sam | lol |
| 15:07.01 | brlcad | those images are renderings, ray-traced |
| 15:07.55 | brlcad | ray-tracing 10 cubes in 'real-time' is certainly doable but it'd be through a different interface that doesn't use shaders |
| 15:08.19 | sam | mmmh, maybe I just need a CSG library and my own OpenGL renderer |
| 15:09.23 | brlcad | then it would be an opengl shader |
| 15:13.35 | *** part/#brlcad louipc (n=louipc@206-248-164-28.dsl.teksavvy.com) | |
| 15:17.18 | mafm | brlcad: trackball up&down&left&right just moves the center of the window, or moves the perspective looking at the same 3D point (I guess that it's the 1st, with another to zoom in&out)? |
| 15:18.10 | brlcad | the latter if I understand you correctly |
| 15:19.10 | brlcad | imagine a large bounding sphere in your 3D view, click-dragging from the center to the left rotates that sphere (and the scene it hypothetically encompasses) |
| 15:19.17 | mafm | the latter continues the object (rotates around given center), the former moves the window in a fixed Z plane |
| 15:19.42 | mafm | the latter orbits* |
| 15:20.33 | brlcad | yes |
| 15:25.44 | CIA-60 | BRL-CAD: 03sammy * r31797 10/brlcad/trunk/src/other/URToolkit/tools/rlehdr.c: * rlehdr.c: fix a potential crash in the RLE header display function. |
| 15:27.00 | mafm | I see |
| 15:27.07 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 15:27.19 | mafm | well, then I think that I'll build a bit of infrastructure for supporting different modes |
| 15:28.02 | brlcad | yeah, I figured you'd need to support at least two styles |
| 15:28.58 | mafm | nicey nicey |
| 15:29.09 | mafm | I have work for most of next week, I guess |
| 15:29.27 | brlcad | mafm: here's an example of a basic (immobile) trackball: http://www.opengl.org/resources/code/samples/glut_examples/examples/dinoshade.c |
| 15:29.46 | brlcad | simple lil glut example, gcc dinoshade.c -lglut |
| 15:30.54 | dtidrow | cls |
| 15:31.09 | dtidrow | ugh, wrong window |
| 15:31.16 | brlcad | -bash: cls: command not found |
| 15:31.32 | dtidrow | unless it's aliased ;-) |
| 15:31.43 | dtidrow | really old habits die hard |
| 15:32.06 | brlcad | shame on you for aliasing dos commands :) |
| 15:32.22 | dtidrow | see previous remark ;-) |
| 15:32.22 | CIA-60 | BRL-CAD: 03bob1961 * r31798 10/brlcad/trunk/ (11 files in 3 dirs): Added arot, eye and eye_pos functions. |
| 15:32.24 | brlcad | they die even harder when you let them keep working |
| 15:32.44 | dtidrow | fewer keystrokes too |
| 15:45.10 | mafm | I cannot compile that thing |
| 15:49.57 | brlcad | mafm: really? |
| 15:50.03 | brlcad | what's your error? |
| 15:51.27 | brlcad | all of the glut_examples are pretty simple to compile, just have to have glut installed (headers/libs) and tell gcc where |
| 15:51.41 | brlcad | maybe gcc dinoshade.c -lglut -lgl |
| 15:53.08 | mafm | the glut I already figured out |
| 15:53.23 | mafm | but there's a function from glext.h causing problems |
| 15:53.55 | mafm | dinoshade.c:(.text+0x1c25): undefined reference to `glPolygonOffsetEXT' |
| 15:59.26 | CIA-60 | BRL-CAD: 03bob1961 * r31799 10/brlcad/trunk/misc/win32-msvc8/libged/libged.vcproj: Added ae2dir, arot, dir2ae, eye and eye_pos source files. |
| 16:02.07 | brlcad | mafm: try adding the snippet suggested here: http://www2.cemr.wvu.edu/~ejb/Instructions/node10.html |
| 16:03.54 | brlcad | i.e. add the wrapper or simply remove the EXT |
| 16:03.59 | CIA-60 | BRL-CAD: 03starseeker * r31800 10/brlcad/trunk/doc/docbook/ (3 files in 2 dirs): Add appendix A of VolIII as pipes tutorial, with corresponding changes for VolIII |
| 16:04.00 | mafm | freeglut (./a.out): WARNING - Display string token not recognized: stencil>=2 |
| 16:04.00 | mafm | dinoshade: Sorry, I need at least 2 bits of stencil. |
| 16:04.02 | mafm | :D |
| 16:04.13 | *** join/#brlcad andrecastelo___ (n=chatzill@189.71.25.125) | |
| 16:04.40 | brlcad | hrm, i'll dig up a simpler example later then |
| 16:04.46 | brlcad | lunch! |
| 16:04.49 | mafm | oki |
| 16:05.00 | mafm | np anyway, I'm quite busy |
| 16:05.02 | mafm | good lunch! |
| 16:15.19 | starseeker | phooy - Apache FOP is known to have an issue (or more likely unimplemented feature) about not shrinking images to fit on a page |
| 16:15.56 | starseeker | makes note to get ahold of the FOP devs for an eta on that feature... |
| 16:20.28 | *** join/#brlcad homovulgaris (n=d@117.196.140.127) | |
| 16:24.56 | mafm | hi homovulgaris |
| 16:45.28 | poolio | Aha. My bug had to do with the fact that I fail at basic geometry. Wonderful. |
| 17:01.39 | pacman87 | brlcad: self intersecting example: https://webspace.utexas.edu/trv82/www/rev_rt13.png |
| 17:01.54 | pacman87 | 2 lines: ((1, 1); (2, 2)) and ((1, 1.5); (2, 2.5)) |
| 17:26.02 | *** join/#brlcad geocalc (n=geocalc@dyn-91-171-218-234.ppp.tiscali.fr) | |
| 17:28.17 | brlcad | starseeker: or grab their sources and try to implement it ;) |
| 17:36.43 | pacman87 | brlcad: i don't see how "open edges and infinitely thin walls" are created, unless you mean along the circle traced by the point of intersection |
| 17:37.12 | pacman87 | and that's not really different than a user-supplied self-intersecting sketch |
| 17:39.24 | MinuteElectron | brlcad: thanks? |
| 17:51.07 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 17:52.06 | starseeker | brlcad: :-P yeah, I'll just take a couple minutes here... |
| 17:52.58 | starseeker | brlcad: Thanks to the joys of binary svn diffs, I should be able to size down for now and then revert to the original size if/when fop supports it again |
| 17:54.45 | *** join/#brlcad SWPadnos_ (n=Me@dsl107.esjtvtli.sover.net) | |
| 18:29.07 | brlcad | pacman87: akin to having two segments 1,0 -> 1,1; and 2,0 -> 2,1; .. you can either make four segments that clamp the four "open" endpoints to x,0 .. or you can detect that the 2,0->2,1 segment will connect up with the other leaving you with two new segments at 2,0 -> 1,0 and 2,1 -> 1,1; |
| 18:29.47 | brlcad | MinuteElectron: for looking into the problem |
| 18:30.22 | brlcad | i was going to do the upgrade to 6 but the modules we're using weren't upgraded yet |
| 18:31.01 | mafm | I go now, have a good weekend in the case that I don't join :) |
| 18:32.52 | MinuteElectron | brlcad: really, I wonder if they still haven't been... |
| 18:33.02 | MinuteElectron | I think theres a change to the skin system too =/ |
| 18:46.16 | CIA-60 | BRL-CAD: 03starseeker * r31801 10/brlcad/trunk/doc/docbook/ (2 files in 2 dirs): Add projection shader tutorial |
| 19:07.04 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) | |
| 19:09.12 | brlcad | starseeker: reminder on https://sourceforge.net/tracker/index.php?func=detail&aid=1990961&group_id=105292&atid=640803 |
| 19:09.35 | brlcad | he's not responded, so it might just need to move to bugs, but it's one that'd be good to fix |
| 19:13.44 | starseeker | OK, thanks - i'll take a look |
| 19:14.06 | brlcad | you should be able to reproduce on your 30" |
| 19:14.11 | starseeker | :-) |
| 19:14.23 | starseeker | let me commit ebm quick |
| 19:14.34 | brlcad | doesn't have to be now/today, just a reminder |
| 19:15.06 | brlcad | like to keep support requests and patches processed with fairly high priority (contrary to bugs and feature requests that might linger for years) |
| 19:15.19 | starseeker | right |
| 19:15.27 | CIA-60 | BRL-CAD: 03starseeker * r31802 10/brlcad/trunk/doc/docbook/ (2 files in 2 dirs): Add extruded bitmap overview. |
| 19:18.20 | Ralith | brlcad: hey, you're still around! |
| 19:18.34 | Ralith | so I was told you're The Person to come to with brlcaddy questions |
| 19:19.00 | starseeker | does rtwizard not have a man page??? |
| 19:19.40 | brlcad | howdy Ralith |
| 19:19.52 | Ralith | so I've got a fairly fundemental question: is BRL-CAD an appropriate tool for designing new parts in? |
| 19:20.00 | brlcad | starseeker: niet, though it does have a fair bit of in-interface help |
| 19:20.10 | brlcad | it's meant to be a "wizard" after all, walking you through |
| 19:20.23 | brlcad | Ralith: it depends for what purpose |
| 19:20.25 | starseeker | When he's saying running it from the command line, does that mean starting it from the command line then? |
| 19:20.33 | brlcad | yes |
| 19:21.21 | Ralith | brlcad: I'm not sure how to answer that question. What I had in mind was for use as source data (which would then be converted into toolpaths) for a rapid prototyper. |
| 19:21.41 | brlcad | Ralith: conceptual design of parts is not a strong point, you tend to need a wide range of feature-based editing operations and ability to perform unknown free-form edits |
| 19:22.03 | brlcad | if it's a part that already exists, and you're just modeling it -- sure |
| 19:22.26 | brlcad | even if it's something you have drawings for already, sure |
| 19:22.52 | brlcad | if you have absolutely nothing, though, and you're trying to design the worlds latest and greatest new toaster, not good for concept design |
| 19:23.01 | Ralith | it seems like that would be the case for most serious cases; at least, when I'm designing something I usually have it all worked out on paper before I even touch a computer. |
| 19:23.15 | brlcad | then you should be golden |
| 19:23.19 | Ralith | awesome. |
| 19:24.18 | Ralith | also, on a semi-related note, I don't suppose you're aware of any freely available tools that might be adapted to create toolpaths for a fused deposition modelling rapid prototyping system? |
| 19:24.49 | Ralith | it seems like the sort of problem that should have been solved a long time ago, but is obscure enough not to have been. |
| 19:26.36 | brlcad | Ralith: here's an example of such a modeling example where someone had drafted up the dimensions and angles for an extrator part to a pistol/gun -- it was modeled up in a matter of minutes to specification |
| 19:27.27 | brlcad | the only free tool that comes to mind is one justin worked on a for a while, gcam |
| 19:27.30 | brlcad | http://gcam.js.cx/ |
| 19:27.48 | brlcad | dumps out g-code |
| 19:28.14 | starseeker | brlcad: I'm not triggering it, even at 2048x2048. Is there something special I need to be sure I do? |
| 19:28.36 | brlcad | starseeker: it'll happen right when you run the app, try starting with a .g perhaps |
| 19:28.41 | brlcad | rtwizard path/to/file.g |
| 19:28.46 | starseeker | did |
| 19:28.51 | starseeker | hmm... |
| 19:29.13 | brlcad | hm, then maybe try chaning your screen res or try making other displays the primary (under display preferences) |
| 19:29.59 | brlcad | it's certainly not been fixed, so it must just depend on some other factor(s) |
| 19:30.40 | brlcad | Ralith: oh, oops -- the example link, heh .. http://brlcad.org/gallery/s/screenshots/extractor.png.html |
| 19:31.28 | starseeker | Any chance it's 10.5 specific? |
| 19:32.29 | Ralith | brlcad: that sounds very encouraging. I hope the friendly GUI in progress will be similarily efficient; while I'm personally quite happy with steep learning curves, I'm hoping BRL-CAD might be adopted by a community which, on the whole, is not. |
| 19:32.59 | starseeker | hmm - changing resolution doesn't do it, nor does opening on another monitor |
| 19:38.51 | starseeker | tries to find out what "screen distance" means in Tk |
| 19:45.19 | starseeker | brlcad: When you wiped out rtwizard on large displays, was it an identical error message? If I'm not mistaken, the complaint is that itk is passing tk a value that is not a valid distance in pixels |
| 19:46.17 | Ralith | Does mged (and, I suppose, the BRL-CAD file format) have a way to instantiate a single object such that changes to any instance are applied to all instances? |
| 19:48.58 | prasad_ | is that shaded view in an interactive ogl context? |
| 19:49.12 | prasad_ | or is that the ray traced img |
| 20:20.05 | *** join/#brlcad cad63 (n=4f00e60e@bz.bzflag.bz) | |
| 20:38.38 | starseeker | Ralith: In a sense - if you create a primitive and then use that primitive in multiple combinations, changes to the original primitive will manifest in the combinations |
| 20:41.49 | Ralith | starseeker: that's cool and related, but I was wondering more if you can define one primitive or set of combined primitives, then define several instances of it which all share the same data, so that a change to one applies to all. |
| 20:41.58 | Ralith | perhaps I misunderstand something? |
| 20:42.33 | Ralith | the PDF on good modelling technique implies that brl-cad can do this; that is, it doesn't say how to (that I saw), but it does say that use of such a feature is a good way to do certain things. |
| 20:43.59 | starseeker | Well, not for primitives as such - what you want (I think) is to create one combination (comb1.c) with one or more primitives/combinations "inside" it |
| 20:44.08 | starseeker | then copy comb1.c to comb2.c |
| 20:44.17 | starseeker | cp comb1.c comb2.c, IIRC |
| 20:44.33 | starseeker | if you do a tree on comb1.c and comb2.c, you will notice they have the same contents |
| 20:45.32 | starseeker | so if you move a primitive (notice there is a difference between moving a primitive and moving the instance of the primitive inside comb1.c - see the OED tutoral for a discussion of this) |
| 20:45.48 | starseeker | let's get more concrete |
| 20:45.57 | starseeker | make sph1.s sph |
| 20:46.07 | starseeker | comb comb1.c u sph1.s |
| 20:46.13 | starseeker | cp comb1.c comb2.c |
| 20:47.37 | starseeker | tree comb1.c comb2.c |
| 20:47.53 | starseeker | You should see that both comb1.c and comb2.c have sph1.s in them. |
| 20:48.35 | starseeker | Now, type B sph1.s |
| 20:48.53 | starseeker | then do the following: |
| 20:48.58 | starseeker | sed sph1.s |
| 20:49.05 | starseeker | tra 0 0 -100 |
| 20:49.26 | starseeker | better make that -500 |
| 20:49.41 | starseeker | then type accept |
| 20:50.18 | starseeker | If you do B comb1.c and comb2.c, you should see no display change. This is because both comb1.c and comb2.c picked up the change to sph1.s we just made |
| 20:50.28 | starseeker | er B comb1.c comb2.c |
| 20:50.32 | starseeker | no and |
| 20:51.08 | starseeker | Now, B comb1.c |
| 20:51.38 | starseeker | no scratch that - let's leave comb2.c up |
| 20:52.03 | starseeker | Now use the oed command to work at the combination level: oed / comb1.c/sph1.s |
| 20:52.29 | starseeker | tra 0 0 500 |
| 20:52.31 | starseeker | accept |
| 20:52.42 | starseeker | you should see two spheres now |
| 20:53.03 | starseeker | because you operated at the combination level and not the primitive level, the translation was NOT shared between comb1.c and comb2.c |
| 20:53.20 | starseeker | that make any sense? |
| 20:54.01 | starseeker | Ralith: ping |
| 20:55.00 | Ralith | starseeker: I follow; this is exactly what I was hoping for. Thanks! |
| 20:56.04 | starseeker | If you now want comb1 and comb2 to each have their own primitives with the new location information, that's what xpush is all about |
| 20:57.00 | starseeker | Have you read the oed tutorial? |
| 20:59.19 | Ralith | not yet, no. |
| 20:59.41 | Ralith | I'm just getting started with all this stuff, while simultaneously trying to work out if brl-cad is entirely appropriate. So far it looks perfect. |
| 20:59.43 | starseeker | It should be at least related to this |
| 21:01.04 | starseeker | http://brlcad.org/w/images/3/36/Object_Editing_-_the_oed_Command.pdf |
| 21:05.06 | Ralith | starseeker: my installation seems to be missing an oed binary. |
| 21:05.16 | Ralith | is it a function of mged? |
| 21:06.16 | starseeker | yes, it's an mged command |
| 21:06.31 | Ralith | kk |
| 21:06.44 | Ralith | thanks! |
| 21:23.11 | brlcad | starseeker: it wasn't identical values, but the same error iirc |
| 21:23.24 | starseeker | sent a response asking for more info |
| 21:47.35 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 21:50.38 | Ralith | I have to say, I'm *very* impressed with the thoroughness of the documentation. |
| 21:51.03 | Ralith | is the source material for the pdfs available, so that it might be converted into e.g. a webpage? |
| 21:58.59 | Ralith | Also, where would I find documentation about the structure of database files? |
| 22:04.36 | Ralith | the Users group presentations wiki page seems to have docs for v5, but isn't that completely outdated? |
| 22:50.26 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 23:30.38 | *** join/#brlcad andrecastelo___ (n=chatzill@189.71.73.20) | |
| 23:32.40 | *** join/#brlcad PrezKennedy (n=Matthew@whitecalf.net) | |
| 23:46.03 | andrecastelo___ | andrecastelo: get out!! |
| 23:47.35 | andrecastelo___ | thank you |
| 23:48.06 | andrecastelo | hey brlcad, have you seen ``Erik around? |
