| 00:14.10 | *** join/#brlcad stas (~stas@109.48.62.192) | |
| 00:41.36 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 00:56.18 | *** join/#brlcad Stattrav (~Stattrav@61.12.114.82) | |
| 00:56.19 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:12.18 | *** join/#brlcad elf_ (~elf@213.233.85.7) | |
| 10:19.54 | *** join/#brlcad Stattrav (~Stattrav@ns.cmi.ac.in) | |
| 10:19.55 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 10:27.09 | *** join/#brlcad Al_Da_Best (Al_Da_Best@cpc2-shep12-2-0-cust21.8-3.cable.virginmedia.com) | |
| 11:07.12 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 11:07.12 | *** mode/#brlcad [+o ChanServ] by kornbluth.freenode.net | |
| 11:31.34 | starseeker | hmm... CIA really got clobbered this time |
| 11:36.38 | *** join/#brlcad stas (~stas@109.48.62.192) | |
| 12:26.34 | *** join/#brlcad elf_ (~elf@p5.eregie.pub.ro) | |
| 13:17.16 | *** join/#brlcad abhi2011 (~chatzilla@122.167.3.180) | |
| 15:23.24 | *** join/#brlcad Stattrav (~Stattrav@ns.cmi.ac.in) | |
| 15:23.25 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:25.40 | brlcad | starseeker: yeah, critical fail |
| 15:26.16 | brlcad | been working with the previous maintainer to see if he has access to his mirror from a couple years ago when we were working on sf.net integration |
| 15:26.40 | brlcad | there are a half-dozen distinct efforts under way to get notifications back online |
| 15:27.15 | brlcad | one guy got the current code updated for modern django, but still leaves a lot starting from scratch without a dump |
| 15:31.15 | brlcad | ``Erik: bug is probably that stdint.h isn't included |
| 15:32.10 | brlcad | looks like other platforms are getting lucky with sys headers that ended up including it |
| 15:48.15 | *** join/#brlcad Stattrav (~Stattrav@ns.cmi.ac.in) | |
| 15:48.15 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 15:55.05 | *** join/#brlcad DarkCalf (~DarkCalf@2002:ade7:2862::ade7:2862) | |
| 16:01.13 | ``Erik | brlcad: put #include <stdint.h> in the .h and it still failed, wrapped it in an extern "C" {} and it still failed *shrug* both fbsd and linux failed the same way |
| 16:01.29 | ``Erik | prods brlcad.org and sago |
| 16:03.10 | brlcad | o.O |
| 16:03.34 | brlcad | found https://issues.apache.org/ooo/show_bug.cgi?id=64762 |
| 16:04.07 | brlcad | testing a clean netbsd and vanilla system at the moment to see if I can reproduce |
| 16:07.10 | brlcad | I mean, that symbol shouldn't even be conditional as far as I know -- SIZE_MAX is what c99 defines |
| 16:07.21 | brlcad | found a comment thread indicating freebsd4 even had it |
| 16:07.38 | ``Erik | if we have a stray stdc=c89, that might force it off? |
| 16:07.57 | brlcad | hm, yeah, that's possible |
| 16:08.07 | brlcad | especially in that src/other subdir |
| 16:08.22 | ``Erik | ah, fbsd's headers explicitely turn it off in c++ |
| 16:08.58 | brlcad | woot, just got it to reproduce |
| 16:09.07 | brlcad | ahh |
| 16:09.48 | ``Erik | cstddef has the right stuff, according to this post |
| 16:10.21 | brlcad | tests |
| 16:11.24 | brlcad | nfg here, I'll dig some |
| 16:13.19 | brlcad | looks like c++ doesn't define that c99 symbol (bleh) |
| 16:13.56 | brlcad | got it, cplusplusy |
| 16:15.39 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:16.27 | brlcad | CIA: BRL-CAD: brlcad * r52608 /brlcad/trunk/src/other/step: turns out, c++ doesn't define the SIZE_MAX c99 constant. instead of adding a (size_t)-1 define manually, do it the c++y-way. use numeric_limits. |
| 16:22.17 | *** join/#brlcad Stattrav (~Stattrav@ns.cmi.ac.in) | |
| 16:22.17 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:23.37 | ``Erik | http://paste.lisp.org/display/132283 alter is screwey |
| 16:27.26 | brlcad | that verizon's backbone? |
| 16:27.50 | *** join/#brlcad Stattrav (~Stattrav@ns.cmi.ac.in) | |
| 16:27.51 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:28.13 | brlcad | brl-cad tutorial in portuguese: http://www.scribd.com/doc/107130136/Trabalho-Desenho-Tecnico-aplicado-BRLCAD-1%C2%BA-Bimestre |
| 16:29.02 | brlcad | notes that carl has fixed no less than 50 spelling mistakes in docs |
| 16:31.10 | elf_ | Hello, brlcad |
| 16:31.12 | ``Erik | it's a backbone, verizon and uunet both use it to get to sago... *shrug* |
| 16:31.14 | brlcad | hi elf_ |
| 16:31.42 | brlcad | ``Erik: going to alter.net jumps to verizon, so looks like it's backbone that they own |
| 16:32.01 | ``Erik | could be, traceroute from the office fails, too |
| 16:32.03 | ``Erik | in alter |
| 16:32.27 | elf_ | Added another patch right now, it fixes the meter/mm problem that I've got when transferring the units from brlcad to bullet, also added that README file with the simulate command workings explained |
| 16:32.34 | ``Erik | comcrap can still hit sago? O.o |
| 16:32.57 | elf_ | the mass of the objects is being calculated in the right way now, meaning it doesn't grow during the simulation |
| 16:33.34 | ``Erik | (yeh, alter.net whois lists verizon contacts) |
| 16:34.43 | brlcad | ``Erik: yeah, no problems |
| 16:34.58 | *** join/#brlcad Stattrav (~Stattrav@ns.cmi.ac.in) | |
| 16:34.59 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 16:35.08 | elf_ | right now I am working on the ray-tracing part of the simulate command, the rt part is not working properly yet, it is done only for the box-box collision, talked with Abhi and he suggested I do a standalone bullet demo, where I will add the custom algorithm for simulation using his implementation just as reference since it hasn't been tested extensively |
| 16:58.00 | brlcad | elf_: okay -- it'd be good to have a specific goal identified for that |
| 17:00.17 | brlcad | i'm a bit concerned over how progress has slowed over the past week -- given there's only a few weeks remaining now |
| 17:01.58 | brlcad | need to plan effort going forward so that we don't end up with you having finally understood what you need to do with bullet and the raytracing portion, yet no useful code written |
| 17:02.23 | elf_ | brlcad, yes I do have a specific goal for that one, actually there(in the simrt.c file and the registered custom collision algorithm) is where the collision detection for objects it happens, so doing the standalone bullet project and seeing what it works and what doesn't for box-box and spheres then changing the existing code, I hope it will fix the physics for those 2 shapes |
| 17:03.13 | elf_ | and I am sorry for the slow progress over the last week, I moved a little around, but I totally understand your concerns |
| 17:05.01 | brlcad | "doing the standalone bullet project and seeing what it works and what doesn't for box-box and spheres then changing the existing code" is not a goal... that's a plan of action, and it sounds rather vague at that |
| 17:05.26 | brlcad | fixing the physics for "those 2 shapes" might be a goal, but that's not very specific |
| 17:05.40 | brlcad | what's the goal? |
| 17:08.14 | elf_ | the standalone bullet it is actually related to the simrt.c file, everything that takes place in that standalone demo file should take place in the brlcad world too, the nearphase, broadphase callbacks for bullet should be integrated in both brlcad and the standalone bullet world |
| 17:08.38 | elf_ | the goal is to be able to detect and resolve more than just box-box collision |
| 17:09.20 | elf_ | the current custom algorithm registered with bullet it's for box-box but it can be extended to more than that, sphere collision for example |
| 17:10.11 | elf_ | for box-box there are 4 rays shoot to detect collision, for sphere-box it will only have to be one ray to shoot to detect the collision, it will be like one contact point between the 2 geometry shapes |
| 17:10.20 | *** join/#brlcad merzo (~merzo@204-150-132-95.pool.ukrtel.net) | |
| 17:21.48 | *** join/#brlcad dtidrow_desk (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 17:44.19 | brlcad | elf_: that still sounds ill-defined to me |
| 17:44.32 | brlcad | to be able to detect and resolve more than just box-box collision is a great high-level goal |
| 17:45.12 | brlcad | it's more of an objective even |
| 17:45.16 | brlcad | I'm looking for smaller measurable goals that get you towards that high-level objective |
| 17:45.42 | brlcad | implementing a nearphase callback in brl-cad and demonstrating it would be two near-term goals |
| 17:46.00 | brlcad | what's the difference between a nearphase and broadphase callback? |
| 17:47.05 | elf_ | for bullet the broadphase callback is there when objects can collide, like they are really close to each other, the AABB are almost intersecting or they will intersect in the next few iterations |
| 17:47.17 | elf_ | after that the nearphase callback it takes place |
| 17:47.25 | elf_ | when the AABB actually collide |
| 17:47.49 | elf_ | and the code it is actually there, brlcad, for both of them, it is just ill-working |
| 17:48.02 | *** join/#brlcad merzo (~merzo@106-59-133-95.pool.ukrtel.net) | |
| 17:48.02 | elf_ | for the moment it is all commented out |
| 17:49.13 | brlcad | I was aware of a "preliminary" collision detection using the aabb's to tell you when two objects are "close" and a secondary more precise collision detection that should tell the exact points |
| 17:49.46 | brlcad | is that your broad/nearphase callbacks or is that something else, because it doesn't match your description of a callback prior to the AABBs even overlapping (the broadphase) |
| 17:50.10 | elf_ | that's it, the broadphase - when objects are close and there's the possibility of them to collide and the nearphase when they actually collide, the nearphase returns the actual collision points |
| 17:50.32 | elf_ | the callback is not working as it is supposed to |
| 17:50.46 | brlcad | which, the broad or near? |
| 17:51.23 | brlcad | by general understanding was that broad has been working for some time |
| 17:54.46 | elf_ | it has yes, for box-box, the nearphase is not |
| 17:55.42 | brlcad | so that gets back to my previous point about needing a specific goal |
| 17:56.13 | elf_ | okay, then the specific goal it is to make the nearphase work |
| 17:56.40 | brlcad | for what inputs? |
| 17:56.51 | brlcad | and what does work mean? |
| 17:57.13 | brlcad | what's your output -- how will you demonstrate the goal being achieved? |
| 17:58.05 | elf_ | box-box for now, then test the broadphase for box-sphere and adding nearphase for box-spere too |
| 17:58.37 | elf_ | work = collision points should be detected, that should be verified with shooting rays |
| 17:59.27 | brlcad | woah, so hold on again |
| 17:59.38 | brlcad | broadphase is either working for all object or it's not, no? |
| 17:59.56 | brlcad | if it's not working, that should be the focus of attention before getting into nearphase work |
| 18:00.12 | elf_ | right, but it hasn't been tested, it should be working, at least in theory, abhi hasn't tested it |
| 18:00.38 | brlcad | testing that should take all of a few minutes, no? |
| 18:00.54 | brlcad | you just wrote up a tutorial, replace the box with a sphere |
| 18:01.22 | brlcad | that is central to planning your next course of action |
| 18:02.45 | brlcad | in fact, you should be able to also test something complex, like the m35 truck model, to tell you if broadphase is working |
| 18:03.02 | elf_ | yes, testing it shouldn't take more than a few minutes, so that's why I didn't dwell on it |
| 18:03.26 | elf_ | okay, about the m35 truck model how do one gets those models inside mged? |
| 18:03.42 | brlcad | except your plan of action involved testing broadphase for box-sphere later |
| 18:03.58 | brlcad | the point of testing it is that there's a chance it doesn't work, you don't know |
| 18:04.06 | elf_ | you are right |
| 18:04.08 | brlcad | IF it doesn't work, that completely changes your plan |
| 18:04.18 | brlcad | that's not a minor detail |
| 18:04.29 | elf_ | true |
| 18:04.48 | brlcad | that's something you could spend a week investigating and fixing, so it has to come before any nearphase work |
| 18:05.30 | brlcad | so there's a specific goal |
| 18:06.30 | elf_ | okay, so for now the goal is to test and make sure the broadphase it is working for all kinds of arbitrary shapes |
| 18:06.37 | brlcad | TEST broadphase AABB collision detection with aa-box (done), rotated box (not done), ellipsoid (not done), combination (not done) |
| 18:06.55 | brlcad | not arbitrary, a carefully selected set that gives you confidence it's working |
| 18:07.22 | brlcad | testing shouldn't take more than an hour or two, but is a good goal |
| 18:07.39 | elf_ | okay, so rotated box, ellipsoid and combination |
| 18:07.47 | brlcad | on a related note, I presume with the tolerance work that you were able to get a better animation of the box falling down to the ground in your tutorial? |
| 18:09.29 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 18:09.41 | elf_ | right now the box is not penetrating the plane anymore, ran it for 300 steps and it stopped on the ground plane |
| 18:09.49 | elf_ | there is a pic on the log page |
| 18:10.20 | elf_ | http://imageshack.us/a/img18/2438/simulate300.png |
| 18:10.24 | brlcad | I believe your tutorial created a really small box, right, like 1-2mm big? |
| 18:10.43 | elf_ | same simulation, geometry in meters this time |
| 18:11.13 | brlcad | okay, so if it's 1-2mm then it still sinks into the ground? |
| 18:11.23 | elf_ | yeah, that is not possible 1-2mm big, bullet has the 0.04m tolerance and it can be set lower, but it will have unexpected behaviour |
| 18:11.45 | elf_ | yes, for geometry that small it is not working |
| 18:12.39 | brlcad | you should mention that in the tutorial... :) |
| 18:12.42 | brlcad | after the If you want to see when the cube touches the ground plane then you only have to increase the simulate step numbers to 190. You should see something like the image to the right : |
| 18:13.16 | *** join/#brlcad abhi2011 (~chatzilla@122.167.3.180) | |
| 18:13.29 | elf_ | okay will do |
| 18:13.43 | brlcad | after that image, you can say something like "notice how the box goes into the ground and rolls over .. it's too small! we can scale it up simply with this: ... and the re-simulate/re-render looks like this: ... |
| 18:15.29 | elf_ | will modify it :) |
| 18:16.03 | brlcad | it's likely to be a common point of confusion, so it's good to say something about the limitation |
| 18:18.48 | brlcad | quick scale instructions: e cube gp ; sed cube ; sca 1000 ; accept ; sed gp ; sca 1000 ; accept ; d cube gp |
| 18:19.11 | brlcad | or something like that, test it yourself |
| 18:19.45 | brlcad | use 'draw' instead of 'e' to be consistent |
| 18:28.59 | abhi2011 | hallo brlcad :) |
| 18:29.31 | brlcad | howdy abhi |
| 18:31.20 | abhi2011 | is BRL-CAD moving to use Qt for the Archer GUI ? |
| 18:31.56 | abhi2011 | I saw some mails related to DisplayManager |
| 19:15.26 | brlcad | abhi2011: it might not make it into archer, but Qt is on the mid-term development roadmap |
| 19:15.35 | brlcad | which is cool, used to be long-term |
| 19:20.11 | *** join/#brlcad stas (~stas@109.48.62.192) | |
| 19:20.18 | abhi2011 | yeah and Qt is awesome, I think even Maya uses Qt now :) |
| 20:50.42 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 21:13.54 | *** join/#brlcad KimK (~Kim__@wsip-184-176-200-171.ks.ks.cox.net) | |
| 21:21.23 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 21:59.07 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 22:22.03 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
| 22:48.00 | *** join/#brlcad dtidrow (~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) | |
