| 00:19.38 | *** join/#brlcad kanzure_ (~kanzure@131.252.130.248) |
| 00:59.51 | CIA-62 | BRL-CAD: 03starseeker * r46316 10/brlcad/trunk/ (41 files in 39 dirs): (log message trimmed) |
| 00:59.51 | CIA-62 | BRL-CAD: Stub in a way for view information to be passed to plot routines. Inactive at |
| 00:59.51 | CIA-62 | BRL-CAD: the moment, and the struct being passed in just has a single token value - this |
| 00:59.51 | CIA-62 | BRL-CAD: is setting up the path through which information can be passed, not actually |
| 00:59.51 | CIA-62 | BRL-CAD: doing it (yet). This will introduce a binary compatibility, so it may need to |
| 00:59.52 | CIA-62 | BRL-CAD: be reverted, but I'm committing it at this time to preserve the information for |
| 00:59.53 | CIA-62 | BRL-CAD: future use; the commit diff is a good starting point when determing what |
| 02:04.48 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 02:13.51 | starseeker | crud s/compatibility/incompatibility |
| 02:15.47 | abhi2011 | ok I have modified the cmake logic and put the simulation files in libged/simulation |
| 02:16.30 | abhi2011 | added 1 symbol to indicate bullet was found or not |
| 02:27.45 | abhi2011 | here is the diff of the 3 cmake files, 2 existing, 1 added : http://bin.cakephp.org/view/295759995 |
| 02:29.39 | abhi2011 | minimal changes to the top level file |
| 02:30.36 | starseeker | abhi2011: you don't need the MESSAGE line for the Bullet find pakage |
| 02:30.38 | starseeker | package even |
| 02:31.56 | brlcad | starseeker: hm |
| 02:31.57 | starseeker | also, I would expect the BRLCAD_ADDLIB line to use "${BULLET_LIBRARIES}" instead of individually listing them - does that not work? |
| 02:32.03 | brlcad | isn't scale sufficient? |
| 02:32.29 | starseeker | brlcad: not for what I'm experimenting with at the moment |
| 02:32.38 | starseeker | if that doesn't pan out, then possibly |
| 02:32.44 | abhi2011 | starseeker: ok I will remove the message line |
| 02:33.09 | brlcad | I'd had similar thoughts to add view information to the plot callback for levels-of-detail, but data-wise the callback still only needs a single scaling factor |
| 02:33.41 | abhi2011 | well ${BULLET_LIBRARIES} contains the static libraries with the .a extensions as thats what applications normally use |
| 02:34.06 | abhi2011 | however when I tried linking against the static libraries I was getting an error related to the -fPIC flag |
| 02:34.12 | starseeker | brlcad: I'm experimenting with some view-dependent logic at the moment - too early to know if it's viable or not |
| 02:34.37 | abhi2011 | I ll try it once more, though I think -static needs to be specified when compiling mged |
| 02:34.48 | abhi2011 | to alllow bullet to link to it statically |
| 02:35.04 | brlcad | starseeker: er, like rtedge-style plotting? |
| 02:35.27 | starseeker | brlcad: no, some level-of-detail stuff for bots |
| 02:35.48 | abhi2011 | starseeker: therefore I compiled the dynamic libs for bullet with .so extensions and use those which requires individually specifiying the libs |
| 02:35.59 | starseeker | brlcad: I can revert that commit if it's a problem - it's way too early to know if what I'm thinking will work or not |
| 02:36.10 | brlcad | er, but how is it view-dependent (beyond scale) |
| 02:36.37 | starseeker | view direction and matrix |
| 02:36.55 | starseeker | window size, etc |
| 02:37.06 | brlcad | but how? :) |
| 02:37.25 | brlcad | window size I can see easily, but that is encompassed by scale |
| 02:37.27 | starseeker | sigh... OK, fine: http://vdslib.virginia.edu/ |
| 02:38.22 | starseeker | knew he shouldn't have committed that... |
| 02:38.33 | brlcad | i'm not looking for a bunny out of a hat, I'm really just curious how |
| 02:38.48 | brlcad | LoD doesn't need view dir |
| 02:39.27 | starseeker | this isn't a standard "decimate the mesh" approach - http://www.cs.virginia.edu/~luebke/publications/pdf/vds.cad.pdf |
| 02:41.00 | starseeker | the 1.0 code apparently isn't around anymore, but thanks to debian an earlier version is: http://bzflag.bz/~starseeker/vdslib-0.9-6.1.tar.gz |
| 02:41.28 | starseeker | is looking at the polyview example app they have in there, and intending to do what they're doing with bots and vlists |
| 02:42.22 | abhi2011 | ok I have modified libged/simulation/CMakeLists.txt to link to the static libs but I get an error : http://bin.cakephp.org/view/372893931 |
| 02:42.27 | abhi2011 | same one as before |
| 02:43.01 | starseeker | got libvds, libstdvds and polyview compiling today, and polyview kinda worked |
| 02:43.02 | abhi2011 | something to with 32 bit libraries on 64 bit platforms |
| 02:43.57 | starseeker | abhi2011: urm. what does the file command tell you about your bullet libraries? |
| 02:45.36 | starseeker | brlcad: it may be that once I fully understand what vds is doing scale will turn out to be sufficient for our needs, but I was going to first verify in the most straightforward way I could that I could duplicate what polyview is doing inside MGED |
| 02:46.56 | abhi2011 | libBulletCollision.a gives : libBulletCollision.a: current ar archive |
| 02:47.10 | starseeker | hmm |
| 02:47.19 | abhi2011 | libBulletCollision.so.2.78: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, not stripped |
| 02:47.36 | abhi2011 | those are the static and dynamic counterparts of the same basic library |
| 02:47.42 | brlcad | starseeker: interesting approach, I hadn't seen that paper before (or at least not that I remember) |
| 02:47.45 | starseeker | OK, but the bullet find_package isn't returning the dynamic lib? |
| 02:48.13 | abhi2011 | no , the stock FindBullet.cmake does not |
| 02:48.25 | brlcad | a quick read through the paper, there are several issues it claims that are somewhat non-issues these days (e.g., memory use for the lod) |
| 02:48.55 | abhi2011 | I could make a FindBullet.cmake specifically for returning dynamic libs |
| 02:49.01 | brlcad | and issues caused by his approach (distant object popping, trouble with the folding) |
| 02:49.01 | starseeker | brlcad: I got triggered by a comment from Bob when he was working with one of the big BoT models about how the interactivity sucked so bad, so I went hunting this weekend for something that might be viable (since it's for sure anybody dealing with a big BoT model would have the same issue) |
| 02:49.16 | starseeker | abhi2011: that might be worth doing |
| 02:49.36 | starseeker | abhi2011: we do custom Find*.cmake files when the stock ones don't suffice - there are several in misc/CMake |
| 02:50.19 | starseeker | brlcad: yeah, the mesh probably won't be perfect, but if it's "close enough" and interactive it will beat the heck out of one refresh every 30 sec. when zooming |
| 02:50.27 | abhi2011 | ok yes I can make a custom one, I wonder whats up with the compiler though, it should have allowed static linking |
| 02:50.48 | starseeker | abhi2011: are you compiling 32 or 64 bit? (-m32 or -m64?) |
| 02:51.06 | abhi2011 | maybe bullet builds the 32 bit version by default |
| 02:51.06 | brlcad | abhi2011: the subdir should match the command name |
| 02:51.14 | starseeker | brlcad: apparently it was a SIGGRAPH thing back in the late 1990s |
| 02:51.21 | starseeker | s/thing/paper |
| 02:51.31 | abhi2011 | starseeker: i avent checked that , will check now |
| 02:51.37 | brlcad | starseeker: I noticed |
| 02:51.46 | abhi2011 | brlcad: ok I ll change it |
| 02:51.51 | starseeker | was hoping to try it before he got told why it wouldn't be a good idea :-P |
| 02:51.58 | brlcad | heh |
| 02:52.48 | brlcad | it's not evidently a bad idea, just odd -- not many folks did research on view-dependent LoD |
| 02:52.48 | starseeker | it took a little time to propagate the rt_*_plot change, and I didn't want to leave it uncommitted, so I figured do it in one fell swoop that could be easily undone |
| 02:53.13 | brlcad | and from my quick read, it's still not entirely clear that it is exactly view-dependent from our plot-perspective |
| 02:53.48 | starseeker | it might not be - I was going on what the polyview app was feeding via vds functions |
| 02:53.49 | brlcad | you feed an initial mesh at a given LoD along with the view params, then it generates a quadree simplification based on the current view |
| 02:55.22 | starseeker | right - but since our plotting routines call the functab for each primitive to get the lines to draw, I was assuming that the simplification output (in vlist form) was what would need to come back from rt_bot_plot |
| 02:55.29 | brlcad | you could still keep plot view agnostic, returning a plot at some predetermined scale, then have a function churn through the view-dependent simplification |
| 02:56.10 | starseeker | maybe, but that starts to get deep into the tangle of code that is the draw logic |
| 02:56.25 | starseeker | was trying to stay below that rats nest, at least for the first trial |
| 02:56.53 | brlcad | that's where injecting view-dependent information is going to be a mess ... plot() for some of the prims is already a nightmare |
| 02:57.10 | brlcad | but yeah, that seems to be the way the algorithm wants it anyways |
| 02:57.16 | brlcad | you got to have the mesh to start with |
| 02:57.17 | starseeker | brlcad: but we don't have to use it unless we want to |
| 02:57.31 | brlcad | hm? |
| 02:57.36 | starseeker | for now, every primitive except BoT will totally ignore the view info |
| 02:58.37 | brlcad | that's my point, though -- the algorithm doesn't know or care about object types, and shouldn't need to |
| 02:58.44 | starseeker | the main problem I was looking at was caching the vds tree |
| 02:58.55 | brlcad | the same logic that'd let you simplify a bot will simplify any plot() data set |
| 02:58.56 | starseeker | uh... which algorithm? |
| 02:59.04 | brlcad | this view-dep lod paper |
| 02:59.07 | starseeker | oh - not sure about that, actually |
| 02:59.14 | starseeker | it may need face data as well as edges |
| 02:59.29 | brlcad | sure, it wants manifold surfaces |
| 02:59.39 | brlcad | several of the plot impls go through nmg anyways |
| 02:59.56 | starseeker | sure, so for those it might be viable - but (say) ell or eto won't care |
| 03:00.12 | starseeker | wasn't going to tangle with nmg in the first round |
| 03:01.47 | brlcad | that's actually a good point |
| 03:01.55 | brlcad | the paper did require topology |
| 03:02.45 | brlcad | which .. BoTs ain't got |
| 03:03.01 | brlcad | tess() would be more appropriate than plot() |
| 03:04.04 | brlcad | then it is back to being agnostic to entity type |
| 03:04.40 | brlcad | that said..... |
| 03:04.58 | brlcad | bob's problem is fixed with a *very* simple scale-based LoD reduction :) |
| 03:05.34 | starseeker | except how do we know how to draw the bots at various scales? |
| 03:05.45 | starseeker | this seemed like a systematic way to address that cleanly |
| 03:07.13 | brlcad | easy, you pass the scale you want to the bot |
| 03:07.27 | starseeker | and then the bot does... what? |
| 03:07.38 | brlcad | if the super-detailed bot is being drawn tiny, the scale factor will be tiny |
| 03:08.11 | starseeker | right, but that still begs the question of which subset of edges from the BoT to draw at that scale |
| 03:08.21 | brlcad | the scale factor is basically used to collapse edges or introduce new edges |
| 03:08.44 | brlcad | so at scale near zero, it's a point or a single tiny vlist segment |
| 03:09.00 | brlcad | at near one, it's whatever "full detail" means |
| 03:09.04 | starseeker | right, but the details of that collapsing are the difficulty |
| 03:09.18 | starseeker | that problem is probably a subset of what vds is doing, actually |
| 03:09.21 | brlcad | you have that info directly from the scale value |
| 03:09.28 | brlcad | that scale is in relation to the model size |
| 03:09.50 | brlcad | so tessellating as we do now, we make ton's of segments that are effectively all overlapping |
| 03:10.11 | brlcad | detecting that next_point == curr_point within tolerance is easy |
| 03:10.27 | brlcad | we just don't/didn't even have the scale to even know that |
| 03:11.45 | starseeker | isn't sure next_point == curr_point is enough, but I suppose I don't understand enough about how plot is doing its drawing |
| 03:12.13 | starseeker | bbiab |
| 03:12.14 | brlcad | it's not really == .. it's within tolerance given the current scale |
| 03:12.56 | brlcad | NEAR_EQUAL(curr_point, next_point, collapse_distance) |
| 03:15.30 | brlcad | the only thing you don't explictly know with just a scale size is the number of pixels since that's really what (should) drives the edge collapse |
| 03:16.33 | brlcad | so you encode that implicitly in the scale (e.g., 1.0 immplies 1024x1024 spacing of edges scaled to that object's bbox) |
| 03:16.56 | brlcad | or you pass the interpixel spacing (i.e., the collapse_distance) instead of scale |
| 03:19.57 | brlcad | OR you pass both and you get arbitrary on-demand LoD :) |
| 03:20.22 | brlcad | abhi2011: ../../../src/libged/simulate.c:63:1: error: C++ style comments are not allowed in ISO C90 |
| 03:28.31 | abhi2011 | brlcad: yes I removing those comments |
| 03:30.06 | brlcad | starseeker: another thought -- you could get a boost within libdm itself, agnostic to any primitive plot() implementation |
| 03:32.31 | brlcad | libdm knows the view size and pixel size so there are several optimizations that could be made right off the bat -- like not even calling plot if object is smaller than a pixel, and reducing the plot vlist eliminating edges that are less than half a pixel distance in length |
| 03:33.52 | brlcad | that's probably a couple hours effort in an afternoon to get something that simple working .. hmm! |
| 03:38.54 | brlcad | looks like drawH_part2() is where the action is at |
| 04:03.46 | CIA-62 | BRL-CAD: 03brlcad * r46317 10/brlcad/trunk/doc/docbook/system/mann/en/Makefile.am: file was renamed to edit_translate.xml |
| 04:26.24 | CIA-62 | BRL-CAD: 03brlcad * r46318 10/brlcad/trunk/include/ (bu.h magic.h raytrace.h): if NO_BOMBING_MACROS is enabled, then it will leave empty if-statements throughout the code making the compiler unhappy. sacrifice a no-opish ((void)0) to keep the compilation gods happy. |
| 05:15.35 | CIA-62 | BRL-CAD: 03brlcad * r46319 10/brlcad/trunk/src/libged/Makefile.am: update Makefile.am at the same time as CMakeLists.txt, add simulate.c and simphysics.cpp to unbreak autotools build. |
| 05:16.08 | CIA-62 | BRL-CAD: 03brlcad * r46320 10/brlcad/trunk/src/tclscripts/mged/CMakeLists.txt: no packages presently exist in mged dir |
| 05:26.04 | plaes | hum.. how do I "exit" from oed back to the viewing state? |
| 05:26.30 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
| 05:30.13 | plaes | aha.. reject |
| 05:33.52 | CIA-62 | BRL-CAD: 03brlcad * r46321 10/brlcad/tags/zlib_1_0_4/: there is no reason for keeping a tag of zlib 1.0.4 |
| 05:45.58 | brlcad | pressing escape in the graphics window will do it too |
| 05:57.59 | CIA-62 | BRL-CAD: 03brlcad * r46322 10/brlcad/tags/ (12 files in 12 dirs): similarly no reason to keep around the old cvs branch tags that were useful for tracking branch start points, end points, and branch termination. relegated the legacy into svn history. |
| 06:23.48 | plaes | hmm.. rtwizard doesn't set the path properly |
| 07:15.20 | *** join/#brlcad merzo (~merzo@193.254.217.44) |
| 07:25.09 | CIA-62 | BRL-CAD: 03d_rossberg * r46323 10/brlcad/trunk/CMakeLists.txt: |
| 07:25.09 | CIA-62 | BRL-CAD: quell cmake warning |
| 07:25.09 | CIA-62 | BRL-CAD: and apparently trimmed trailing spaces |
| 07:25.18 | *** join/#brlcad d_rossberg (~rossberg@BZ.BZFLAG.BZ) |
| 07:57.09 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) |
| 08:20.48 | *** join/#brlcad Unknown_Monkey (~max@netblock-208-127-49-10.dslextreme.com) |
| 08:22.38 | Unknown_Monkey | hey I installed brlcad on my ubuntu machine and when i run mged and I draw a cone or anything It doesnt show up the screen is blank and when I click on the window the cone drawing shows up but then it disappers |
| 08:24.37 | *** join/#brlcad DarkCalf (DC@2002:ade7:2862::ade7:2862) |
| 08:27.30 | Unknown_Monkey | DarkCalf: can you help me |
| 12:19.46 | CIA-62 | BRL-CAD: 03brlcad * r46324 10/brlcad/tags/ (itcl3-2/ libpng_1_0_2/ tcl8-3/ tk8-3/): revmoed additional 3rd party dependencies that don't really belong amongst our other tags |
| 13:09.05 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:35.15 | CIA-62 | BRL-CAD: 03abhi2011 * r46325 10/brlcad/trunk/src/libged/simulate.c: Removed C++ style comments in C file to conform to C90 |
| 13:37.36 | CIA-62 | BRL-CAD: 03abhi2011 * r46326 10/brlcad/trunk/src/libged/simphysics.cpp: Changed mode to C++ in the file style section at the bottom |
| 13:41.17 | CIA-62 | BRL-CAD: 03n_reed * r46327 10/brlcad/trunk/src/conv/obj-g_new.c: Fixed missing header and implicit return statement that g++ complained about. |
| 13:42.43 | CIA-62 | BRL-CAD: 03brlcad * r46328 10/brlcad/tags/ (10 files in 10 dirs): more removal of cvs branching artifacts where it was necessary to tag before and after merging, pushed into the depths of svn history |
| 14:07.26 | CIA-62 | BRL-CAD: 03n_reed * r46329 10/brlcad/trunk/src/libgcv/wfobj/ (10 files): Replaced flex scanner with re2c equivalent. |
| 14:12.51 | starseeker | woot! |
| 14:13.17 | starseeker | ditches view stuff and hits the re2c/lemon logic |
| 14:16.07 | CIA-62 | BRL-CAD: 03starseeker * r46330 10/brlcad/trunk/src/other/ (CMakeLists.txt byacc/ flex/ m4/): We're not using them right now, re2c/lemon work is progressing, and svn has our back if we have to return to this route - clear out m4/byacc/flex |
| 14:31.24 | CIA-62 | BRL-CAD: 03starseeker * r46331 10/brlcad/trunk/src/other/ (450 files in 13 dirs): Check in vanilla copies of re2c-0.13.5 and the latest lemon from sqlite.org. No build system logic yet, baselining with the vanilla sources. |
| 14:40.27 | CIA-62 | BRL-CAD: 03starseeker * r46332 10/brlcad/trunk/src/other/ (20 files in 3 dirs): Add first stages of CMake logic for re2c and lemon building |
| 14:59.43 | CIA-62 | BRL-CAD: 03starseeker * r46333 10/brlcad/trunk/ (4 files in 2 dirs): Add more CMake logic for re2c/lemon, this time relating to deciding whether or not to build local copies - this is Not Done, particularly the FindRE2C and FindLEMON files, but checkpointing. |
| 15:18.34 | *** join/#brlcad b0ef (~b0ef@226.27.202.84.customer.cdi.no) |
| 15:30.48 | CIA-62 | BRL-CAD: 03bob1961 * r46334 10/brlcad/trunk/src/tclscripts/lib/Ged.tcl: Updated Ged::pane_mouse_ray to calculate the mLastMouseRayStart point (i.e. the point from which to fire a ray) so that all displayed geometry is in front of the ray firing point. |
| 15:36.28 | abhi2011 | ok I have modified the cmake logic to detect bullet dynamic libs |
| 15:36.37 | abhi2011 | all I had to do was remove the static libs |
| 15:36.44 | abhi2011 | time for a whoosh! commit |
| 15:37.06 | brlcad | abhi2011: try to commit incrementally if you can without breaking the build |
| 15:37.15 | abhi2011 | brlcad: ok :P |
| 15:37.20 | brlcad | like one commit moves the files into a subdir, another fixes the bullet rules, etc |
| 15:37.45 | brlcad | you shouldn't move modified files, for example |
| 15:38.17 | brlcad | edit, commit, then move, commit OR move, commit, then edit, commit |
| 15:40.03 | abhi2011 | ok I have deleted 2 files : simulate.c and simphysics.cpp in libged however |
| 15:40.20 | abhi2011 | moved them to libged/simulate directory |
| 15:40.50 | abhi2011 | ok for those 2, I ll commit last |
| 15:40.54 | brlcad | that's wrong |
| 15:41.10 | brlcad | svn will handle the move for you, and is preferred because it will preserve the commit history |
| 15:43.04 | brlcad | cd src/libged && svn revert simulate.c simphysics.cpp && mv simulate simulate.backup && mkdir simulate && svn add simulate && svn commit -m "stub in simulate dir" simulate && svn mv simulate.c simulate/simulate.c && svn mv simphysics.cpp simulate/simphysics.cpp && .... etc |
| 15:43.42 | abhi2011 | ok |
| 15:44.26 | CIA-62 | BRL-CAD: 03brlcad * r46335 10/brlcad/tags/ (merge-to-head-20051223/ stable-branch/): move cvs branch tagging artifact removal |
| 15:45.07 | abhi2011 | ok then I ll checkout fresh again , and do the changes one by one |
| 15:47.42 | abhi2011 | hmm, no i think just deleting the simulate directory and recreating through the commands you gave should be enough, ok will do that |
| 15:47.57 | CIA-62 | BRL-CAD: 03brlcad * r46336 10/brlcad/tags/temp_tag/: remove what looks like a tag related to the merging of the bobWinPort work, some artifact tag that was retained through conversion from cvs. |
| 15:52.03 | CIA-62 | BRL-CAD: 03brlcad * r46337 10/brlcad/tags/CMD/: nice.. remove very old version of remrt that was tagged in the early 90's. nice and easy to read. |
| 15:56.45 | CIA-62 | BRL-CAD: 03brlcad * r46338 10/brlcad/tags/help/: remove mysterious 'help' tag from 7.8, no apparent purpose and certainly no need to keep it around now |
| 16:03.56 | CIA-62 | BRL-CAD: 03abhi2011 * r46339 10/brlcad/trunk/src/libged/simulate/: stub in simulate dir |
| 16:10.08 | CIA-62 | BRL-CAD: 03abhi2011 * r46340 10/brlcad/trunk/src/libged/ (5 files in 2 dirs): stub for 2 files moved to simulate dir |
| 16:13.20 | CIA-62 | BRL-CAD: 03abhi2011 * r46341 10/brlcad/trunk/src/mged/cmd.c: stub for simulate cmd wrapper modification |
| 16:23.12 | CIA-62 | BRL-CAD: 03brlcad * r46342 10/brlcad/tags/Original/: remove '98 tagging of the html docs |
| 16:27.27 | CIA-62 | BRL-CAD: 03brlcad * r46343 10/brlcad/tags/release-7-0/: clearly not actually release 7.0 .. remove the cvs tag relic that was made on a few files just before the project was converted to open source. |
| 16:30.44 | CIA-62 | BRL-CAD: 03brlcad * r46344 10/brlcad/tags/rel-5-0beta/: remove the rel-5-0beta cvs-to-svn relic as it's not actually the 5.0 beta release. the rel-5-0-beta tag has that so this one that just has tcl/tk can get gone. |
| 16:31.29 | brlcad | and with that, our tags should now be all in order, each representing some snapshot in time for a given production |
| 16:40.40 | CIA-62 | BRL-CAD: 03abhi2011 * r46345 10/brlcad/trunk/CMakeLists.txt: Added detection of bullet dynamic libraries using the stock CMAKE FindCMake.cmake module |
| 16:42.59 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) |
| 16:45.01 | CIA-62 | BRL-CAD: 03abhi2011 * r46346 10/brlcad/trunk/src/libged/ (4 files in 2 dirs): Changes in the CMake build logic and source files to allow the simulate command to link to bullet |
| 16:45.22 | abhi2011 | and that completes the changes to link to bullet for the mged simulate command |
| 16:46.37 | abhi2011 | hope I didnt break anything |
| 16:52.26 | abhi2011 | so if anyone installs bullet (has to be told to specifically compile shared libs) and tries out the simulate command then let me know :) |
| 17:02.36 | CIA-62 | BRL-CAD: 03n_reed * r46347 10/brlcad/trunk/src/libgcv/wfobj/Makefile.sample: Adding local makefile to demonstrate necessary build steps. |
| 17:42.33 | *** join/#brlcad molto_crescendo (~molto_cre@BZ.BZFLAG.BZ) |
| 17:42.57 | brlcad | I wonder |
| 17:43.45 | molto_crescendo | okay |
| 17:49.48 | starseeker | brlcad: wonder... what? |
| 17:50.10 | brlcad | starseeker: never mind :) |
| 17:51.13 | starseeker | heh - k |
| 18:00.25 | starseeker | wheee - that was fun! |
| 18:10.02 | CIA-62 | BRL-CAD: 03starseeker * r46348 10/brlcad/trunk/src/other/lemon/CMakeLists.txt: need lempar.c in the same directory as the lemon binary |
| 18:10.48 | molto_crescendo | yep, same directory |
| 18:11.18 | CIA-62 | BRL-CAD: 03brlcad * r46349 10/brlcad/trunk/src/other/Makefile.am: bison/flex/m4 removed, stay in sync with CMakeLists.txt |
| 18:12.27 | CIA-62 | BRL-CAD: 03brlcad * r46350 10/brlcad/trunk/src/other/Makefile.am: add lemon and re2c dirs |
| 18:16.59 | brlcad | abhi2011: nice work regardless, hopefully get a chance to test it later this wek |
| 18:17.03 | brlcad | s/wek/week/ |
| 18:23.35 | ``Erik | weeeee, earthquakes |
| 18:23.36 | brlcad | abhi2011: one cleanup, the " |
| 18:24.27 | brlcad | abhi2011: the simulate "library" can just be named simulate (not libgedsim) since it's not intended to be installed/used as a standalone library but as a module to libged |
| 18:25.01 | abhi2011 | brlcad: ok |
| 18:49.39 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 19:28.50 | CIA-62 | BRL-CAD: 03starseeker * r46351 10/brlcad/trunk/ (391 files in 59 dirs): Get the new obj-g building as part of BRL-CAD. |
| 19:29.20 | CIA-62 | BRL-CAD: 03brlcad * r46352 10/brlcad/trunk/TODO: |
| 19:29.21 | CIA-62 | BRL-CAD: primitive testing has uncovered off-by-one raytrace errors during identical |
| 19:29.21 | CIA-62 | BRL-CAD: subsequent invocations of rt due to some floating point issue during parallel |
| 19:29.21 | CIA-62 | BRL-CAD: processing. single processor results in zero errors yet parallel gives subtle |
| 19:29.21 | CIA-62 | BRL-CAD: changes. should investigate to see if there's a code issue though the problem |
| 19:29.21 | CIA-62 | BRL-CAD: persists back as far as at least 7.8 (on 64-bit Linux). |
| 19:38.03 | brlcad | starseeker: I presume you put boost there because of conflicts or uncertainty with src/other/boost ? |
| 19:41.13 | starseeker | yep |
| 20:58.45 | *** join/#brlcad Elrohir (~kvirc@p5B14AEDB.dip.t-dialin.net) |
| 20:59.49 | CIA-62 | BRL-CAD: 03starseeker * r46353 10/brlcad/trunk/src/other/boost/ (88 files in 30 dirs): Clear old boost libs |
| 21:22.25 | CIA-62 | BRL-CAD: 03n_reed * r46354 10/brlcad/trunk/src/libged/ (CMakeLists.txt simulate/CMakeLists.txt): get the build working - probably not the 'right' fix (starseeker) |
| 21:40.51 | CIA-62 | BRL-CAD: 03n_reed * r46355 10/brlcad/trunk/src/mged/setup.c: Need to use HAVE_BULLET in mged too - no ged_simulate, no simulate command. |
| 21:52.46 | CIA-62 | BRL-CAD: 03n_reed * r46356 10/brlcad/trunk/src/conv/obj-g_new.c: Removed obsolete debug output. |
| 22:00.40 | CIA-62 | BRL-CAD: 03n_reed * r46357 10/brlcad/trunk/src/libgcv/wfobj/obj_rules.re: Removed obsolete debug output. |
| 22:30.31 | CIA-62 | BRL-CAD: 03starseeker * r46358 10/brlcad/trunk/src/other/boost/ (1467 files in 127 dirs): add the bcp reported subset of boost 1.47 needed for spirit.hpp. Made a quick stab at CMakeLists.txt build logic for the libs, not sure if it's right. |
| 22:33.30 | CIA-62 | BRL-CAD: 03starseeker * r46359 10/brlcad/trunk/src/libpc/CMakeLists.txt: because we have both boost and libs dirs now, include src/other/boost not src/other |
| 22:36.31 | molto_crescendo | exit |
| 22:38.30 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) |
| 22:39.37 | *** join/#brlcad abhi2011_ (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 22:45.28 | bhinesley | hmm... playing around with Blender. There is a setting to "manipulate object centers only". I didn't think of allowing translations based on angles (without actually rotating the object being translated). |
| 22:46.08 | brlcad | bhinesley: not sure I follow |
| 22:46.30 | brlcad | a translation based on an angle means what exactly? |
| 22:47.34 | brlcad | like only translating against an object's local coordinate system instead of global? |
| 22:48.15 | brlcad | so a box tilted 45 degrees and translated "by x" would go "up" at a 45 degree translation? |
| 22:48.20 | bhinesley | brlcad: hard to explain. In Blender, you can set your 3d cursor where you would like the center of a rotation to take place. Then you enable "manipulate object centers only". When you "rotate", you're not really rotating. You're just moving the object to some other point. |
| 22:48.52 | bhinesley | brlcad: no, it does local vs. global translations too, but that's not what I'm refering to. |
| 22:49.27 | brlcad | yeah .. okay .. confused then :) |
| 22:51.30 | bhinesley | brlcad: say you place a box at 1,0,0 and the center of rotation at 0,0,0. If you rotate the box 90 degrees on the z-axis, you'll end up at 0,1,0 with the cube still facing the same directions. |
| 22:51.40 | brlcad | finds http://blenderunderground.com/blender-3d-faq/#mi_centers to be unhelpful |
| 22:52.24 | brlcad | ahh, good example |
| 22:53.40 | brlcad | sounds like a flag to the rotate command ;) |
| 22:53.57 | brlcad | or a different "pivot" command |
| 22:54.29 | brlcad | since you're really pivoting around a point, seems apropos |
| 22:55.17 | bhinesley | nods |
| 22:55.36 | bhinesley | rotate is already too complex |
| 22:57.03 | bhinesley | to the user it would "feel" like a special type of rotation, but under cover a pivot command would just call translate. |
| 22:57.41 | brlcad | or call rotate twice |
| 22:57.58 | bhinesley | hmm, not a bad idea. |
| 23:02.13 | bhinesley | could be used to create polar arrays (i.e. lugnuts on a wheel) |
| 23:02.38 | brlcad | the existing pattern tool already does that albeit manually in the implementation |
| 23:03.06 | brlcad | spherical and cylindrical |
| 23:03.14 | bhinesley | ah, nice |
| 23:04.25 | bhinesley | brlcad: what is it called? is it in Archer? |
| 23:04.26 | CIA-62 | BRL-CAD: 03brlcad * r46360 10/brlcad/trunk/TODO: potential lead, -B works with parallel enabled so something fishy is going on. possibly conversion from float to double ... but random numbers should not be involved! |
| 23:04.45 | brlcad | bhinesley: the interface is just atrocious |
| 23:04.49 | brlcad | so it's in mged ;) |
| 23:05.22 | brlcad | Pattern tool under the Tools menu |
| 23:05.27 | bhinesley | ah, I see, thanks |
| 23:07.16 | CIA-62 | BRL-CAD: 03starseeker * r46361 10/brlcad/trunk/src/ (CMakeLists.txt util/CMakeLists.txt): libpc ain't happy about the boost change - turn it off for now. |
| 23:14.07 | CIA-62 | BRL-CAD: 03starseeker * r46362 10/brlcad/trunk/src/libgcv/wfobj/ (CMakeLists.txt boost_shared_ptr/): Well, can now use src/other/boost for obj-g anyway... |
| 23:23.57 | CIA-62 | BRL-CAD: 03starseeker * r46363 10/brlcad/trunk/src/other/boost/boost/spirit/ (32 files in 11 dirs): hmm - may not have gotten everything. bcp --scan of the libpc headers resulted in a few more boost files. |