| 09:01.02 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) |
| 09:19.28 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) |
| 10:24.09 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 10:38.15 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) |
| 10:38.15 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) |
| 10:38.51 | *** join/#brlcad CIA-62 (~CIA@cia.atheme.org) |
| 10:39.08 | *** join/#brlcad plaes (~plaes@gn237.zone.eu) |
| 10:39.43 | *** join/#brlcad betta_y_omega (~betta_y_o@90.166.231.220) |
| 10:39.43 | *** join/#brlcad kanzure (~kanzure@131.252.130.248) |
| 10:40.33 | *** join/#brlcad DarkCalfz (DC@173.231.40.98) |
| 10:40.33 | *** join/#brlcad kunigami2 (~kunigami@loco-gw.ic.unicamp.br) |
| 10:40.33 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 10:40.38 | *** join/#brlcad merzo (~merzo@12-152-132-95.pool.ukrtel.net) |
| 10:41.58 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) |
| 10:41.58 | *** join/#brlcad packrat (~packrator@99-67-225-40.lightspeed.livnmi.sbcglobal.net) |
| 10:41.58 | *** join/#brlcad starseeker (~starseeke@BZ.BZFLAG.BZ) |
| 10:45.33 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) |
| 10:45.33 | *** join/#brlcad brlcad (~sean@BZ.BZFLAG.BZ) |
| 13:45.10 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 13:46.37 | abhi2011 | is there a way to calculate a transformation matrix to convert between co-ordinate systems |
| 13:47.17 | abhi2011 | bullet's co-ordinate system assumes the y axis as up, but is right handed, just like mged |
| 13:48.09 | abhi2011 | so objects fall towards the xz plane when gravity is applied |
| 13:48.45 | abhi2011 | the transformation matrix has to map the translations and rotations to mged's co-ordinate system correctly |
| 13:57.08 | abhi2011 | i ll try a simple rotation about the x-axis |
| 14:55.21 | abhi2011 | trying to reset some primtives to the origin before the simulation starts |
| 14:55.47 | abhi2011 | apparently rt_matrix_transform() applies a translation/rotation to the existing transform |
| 14:56.22 | abhi2011 | there does not seem to be a functions that can directly set the absolute world transform of a comb/primitive |
| 15:29.17 | *** join/#brlcad ``Erik (Here@c-69-140-109-104.hsd1.md.comcast.net) |
| 17:19.42 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
| 17:29.05 | *** join/#brlcad merzo (~merzo@77-191-133-95.pool.ukrtel.net) |
| 18:28.00 | brlcad | abhi2011: perhaps there's a way to specify the coordinate system to bullet |
| 18:29.37 | brlcad | otherwise, you can just apply the rotation before you feed values to bullet and the reverse when you read values and apply them back on geometry |
| 18:32.40 | abhi2011 | brlcad: ok |
| 18:33.57 | abhi2011 | about the bounding box function, I have been trying with combp = (struct rt_comb_internal *)ip->idb_ptr; and rt_bound_tree(combp->tree, tree_min, tree_max) |
| 18:34.32 | abhi2011 | however rt_bound_tree() does not implement the OP_DB_LEAF case which causes the traversal of the tree to get stuck |
| 18:35.50 | abhi2011 | so I was considering adding that case, but even if I rt_bound_tree() does get me to the leaf, it seems the leaf only had information about a primtive's name |
| 18:36.22 | abhi2011 | not its shape information such as a pointer to its ft_bbox() method etc, or any geometry info |
| 18:49.29 | brlcad | abhi2011: so it sounds like there's some disconnect, that you're not setting up something correctly |
| 18:50.59 | brlcad | if I recall correctly, you had it working earlier, when you were mimicking what the bb command does (ala _ged_get_obj_bounds) |
| 18:51.13 | brlcad | now you're basically saying that method doesn't work |
| 18:51.22 | brlcad | but you had it working for combs, so what's changed? |
| 18:55.53 | brlcad | IF ip is a comb (which you have to check), then you still have to call rt_gettree() to "load" the members of that comb and calculate the primitive bb's (and THEN you can call rt_bound_tree() to get the overall comb bb) |
| 18:56.57 | brlcad | read src/libged/get_obj_bounds.c again -- it does what you're trying to do |
| 18:57.12 | brlcad | it just starts with a char*name instead of an rt_db_internal |
| 18:58.39 | brlcad | when your function is done and working, it should drop right into _ged_get_obj_bounds() and _ged_get_obj_bounds2() |
| 18:58.58 | brlcad | (or better still, into the callers of those functions so they can be eliminated) |
| 19:30.08 | abhi2011 | brlcad: yes I just found that out, that I need to call rt_gettree() for combs, otherwise the members are not loaded |
| 19:30.24 | abhi2011 | well now I ll get it working |
| 19:35.28 | abhi2011 | ok I got the reason why I had said rt_bound_tree() was working before |
| 19:36.15 | abhi2011 | it was with a standalone program which obtained a struct rt_i *rtip directly from the the database file , using rtip = rt_dirbuild(argv[1], title, sizeof(title)); |
| 19:36.54 | abhi2011 | this trip does have the primtives and can be safely passed to rt_gettree(rtip, argv[2]), to load all the primtives for a combination |
| 19:37.19 | abhi2011 | but in the bb box function, I create an in-mem rtip |
| 19:37.40 | abhi2011 | which does not know anything about the primitives |
| 19:37.59 | abhi2011 | as it was not made from the original file |
| 19:39.09 | abhi2011 | so calling rt_gettree() as follows : ( when I am trying to find the bb for a comb of course), would lead to the members of that comb still not getting loaded |
| 19:40.52 | abhi2011 | if (rt_gettree(rtip, "dummy") < 0){... |
| 19:42.36 | abhi2011 | the only thing thats changed is the rtip between the 2 cases (the one where I build rtip using rt_dirbuild() and the bb function case which uses an in-mem rtip ) |
| 19:46.44 | abhi2011 | brlcad: thats why the original rtip that was made from the database file would be needed to get to the primtives, because rt_gettree() needs to get the original rtip |
| 20:14.34 | brlcad | I'm not sure much of that made sense to me :) |
| 20:16.05 | brlcad | recounting what you did to me isn't necessary, I know what you did :) it was a question to ask yourself to hopefully help you figure out what you now need to do to get things working |
| 20:18.14 | abhi2011 | yes ok :) , I am certain now that the original dbip needs to be passed and I ll get the bb using it and wrap up the function |
| 20:18.29 | abhi2011 | perhaps in the near future i ll be able to remove it |
| 20:19.02 | brlcad | if it's a comb, your job is really easy |
| 20:19.58 | brlcad | the only real work remaining is/was supposed to be figuring out how to calculate the bb for a primitive |
| 20:20.14 | brlcad | you had *A* solution, just not the ideal solution |
| 20:20.55 | brlcad | so you could go with what you had (using the inmem) ... or figure out how to build an rt_comb_internal by hand with just that one primitive |
| 20:22.31 | brlcad | I'd suggest getting it to work for both comb and prims using the two methods you already know work, then trying to build the rt_comb_internal as a replacement method for prims |
| 20:22.56 | brlcad | that way, the code will be at least functional and can be tested for any object type |
| 20:43.09 | *** join/#brlcad merzo (~merzo@194-13-133-95.pool.ukrtel.net) |
| 21:02.24 | abhi2011 | brlcad: yes, I will be building a rt_comb_internal for finding the bb of both prims and combs |
| 21:03.46 | abhi2011 | the only other thing I will be doing is adding an extra paramter to rt_bound_internal() |
| 21:04.42 | abhi2011 | will make it like : rt_i rt_bound_internal(struct rt_i *rtip, struct rt_db_internal *ip, point_t rpp_min, point_t rpp_max) |
| 21:05.06 | brlcad | why? you shouldn't need to do that |
| 21:05.14 | abhi2011 | ah ha...:) |
| 21:05.20 | abhi2011 | so that is because |
| 21:05.39 | abhi2011 | the rtip that I pass to rt_gettree() should be the original rtip |
| 21:05.53 | abhi2011 | not one created from an in-mem dbip |
| 21:07.19 | brlcad | it feels like we're talking in circles :) |
| 21:07.53 | abhi2011 | the in-mem dbip has no geometry information about the primtives in the model, and consequently neither does the struct rt_i* made from it |
| 21:08.25 | abhi2011 | well, yeah I know it feels that way, and its my fault really |
| 21:09.09 | abhi2011 | the rt_bound_tree(combp->tree, tree_min, tree_max) method never worked before actually |
| 21:09.13 | brlcad | sure, that you found out last week -- you'd have to add all of the comb's members (that's why you were researching db_functree()) |
| 21:09.22 | abhi2011 | yes exactly |
| 21:09.35 | abhi2011 | and db_functree() runs against the same problem see |
| 21:09.45 | abhi2011 | its unable to add the primtives |
| 21:10.03 | brlcad | because? |
| 21:10.04 | abhi2011 | because it uses db_lookup() on the in-mem db_i |
| 21:10.24 | abhi2011 | the one I create and pass to it inside the rt_bound_internal() function |
| 21:10.24 | brlcad | you don't run functree on the inmem |
| 21:11.11 | brlcad | youd run functree on the original dbi to add them to the inmem |
| 21:11.11 | abhi2011 | yes, I should run it on the original struct db_i |
| 21:11.31 | abhi2011 | yes, but the original db_i is not passed |
| 21:11.34 | abhi2011 | to the function |
| 21:11.43 | abhi2011 | so I would need to pass it |
| 21:12.30 | brlcad | that would be better than passing an rtip, but still seems unnecessary.. |
| 21:12.39 | abhi2011 | yes, umm why |
| 21:12.51 | abhi2011 | there is no other way to add the primitives |
| 21:13.14 | abhi2011 | other than picking them form the original struct db_i and putting them in the in-mem struct db_i |
| 21:16.27 | brlcad | the why would be because the rt_comb_internal should already have a union tree * filled out |
| 21:16.46 | brlcad | the inmem one you were trying didn't, but that's obvious why .. you only added the comb |
| 21:18.25 | brlcad | the caller will be passing you an rt_db_internal that should be filled out, that tree should be passable to rt_bound_tree() as-is .. no? |
| 21:18.42 | brlcad | if it's not, it sounds like a problem in the caller code |
| 21:19.24 | brlcad | (like not calling dirbuild or gettrees or something .. don't think it matters which) |
| 21:19.24 | abhi2011 | yes it should be passable to rt_bound_tree(), however the structure of the tree is wrong |
| 21:20.09 | abhi2011 | the tree leads to the primtive node , but that node has just the primtive name |
| 21:20.49 | abhi2011 | it does not have any geometry information and the tr_op is not OP_SOLID |
| 21:20.55 | abhi2011 | its OP_DB_LEAF |
| 21:20.59 | abhi2011 | which is not correct |
| 21:21.18 | brlcad | so why is that, sounds like something not getting set up right |
| 21:21.30 | abhi2011 | yes so let me explain :) |
| 21:21.39 | brlcad | like I said -- "it sounds like a problem in the caller code" |
| 21:22.21 | abhi2011 | hmm yeah |
| 21:22.33 | abhi2011 | the rt_db_internal() should have a complete tree |
| 21:23.56 | abhi2011 | but the caller code is very straight forward : http://bin.cakephp.org/view/1978180787 |
| 21:24.36 | brlcad | rt_bound_tree() is clearly used by src/libged/bb.c (via get_obj_bounds.c()) so if they can do the setup, you should be able to too (even if it requires the caller to do something first) |
| 21:25.23 | abhi2011 | ok |
| 21:25.28 | brlcad | so if that caller code isn't working right, there's something else you need to have it do |
| 21:26.35 | brlcad | maybe see what rt_gettree() does since that's what get_obj_bounds.c calls before calling librt |
| 21:26.45 | abhi2011 | ah! |
| 21:26.46 | brlcad | you may need to do some subportion of what it's doing |
| 21:27.00 | abhi2011 | so its called before |
| 21:27.11 | abhi2011 | yes I ll check it |
| 21:27.13 | brlcad | there's no point in calling rt_gettree in the caller code because you don't have an rtip |
| 21:27.33 | brlcad | but maybe there is some other rt function that sets up and initializes the rt_comb_internal properly |
| 21:27.40 | brlcad | very likely :) |
| 21:27.44 | abhi2011 | ok |
| 21:28.00 | brlcad | something related to loading a union tree * |
| 21:29.48 | abhi2011 | yeah the first thing get_obj_bounds() does it /* Make a new rt_i instance from the existing db_i sructure */ and finally calls rt_gettree() on it |
| 21:31.05 | abhi2011 | which I could do in my caller code too :P, but lets see if there some other way |
| 21:34.47 | brlcad | yeah, if the caller had to do all of that, it would defeat the simplicity we're going for |
| 21:35.13 | brlcad | if you find out that you have to add a dbip parameter, that's fine -- but you should make sure first |
| 21:37.25 | abhi2011 | well yes, there is no way to intialize the tree of an rt_comb_internal() for a regions without doing walk on the database instance tree using the original db_i |
| 21:38.09 | brlcad | how do you know that? |
| 21:39.14 | abhi2011 | because only the original db_i would have the information about the geometry of the primitives |
| 21:40.02 | abhi2011 | and that db_i would need to be used to look up any primitive names that we encounter while traversing the tree for a comb |
| 21:40.21 | brlcad | right, okay -- I misread what you were saying |
| 21:40.50 | brlcad | the question is whether there is already a routine or simple method that will initialize it for you |
| 21:41.02 | brlcad | other than rt_gettree() |
| 21:46.16 | brlcad | if something doesn't exist, that actually might be a good case for adding a function that creates a non op_db_leaf union tree suitable for your function (which calling code would then be required to call beforehand) |
| 21:47.31 | brlcad | basically something like rt_gettree() but specifically for combs, like maybe a new rt_comb_tree() function |
| 21:48.15 | abhi2011 | ok |
| 21:48.58 | abhi2011 | i did come across |
| 21:48.59 | abhi2011 | db_comb_describe |
| 21:49.07 | abhi2011 | and rt_comb_describe() |
| 21:52.32 | abhi2011 | ok yeah, adding a function that creates a non op_db_leaf union tree would still require passing the original db_i to it, so all the geometry info about the model is available |
| 21:53.00 | brlcad | yes, something like: union tree *rt_comb_tree(const struct db_i *dbip, const struct rt_db_internal *ip) |
| 21:55.41 | abhi2011 | ok |
| 21:55.45 | brlcad | I hate to say it, because that's probably the way to go, but I think we're getting out of scope |
| 21:55.51 | brlcad | a bit at least |
| 21:56.27 | brlcad | figuring out how to implement that function properly would probably take a few days at best, a couple weeks at worst |
| 21:56.33 | abhi2011 | yeah I dont see any other function in raytrace.h that could make a rt_comb_internal |
| 21:57.10 | brlcad | plus figuring out the important parts from rt_gettree() is probably a little bit out of depth |
| 21:57.26 | brlcad | that's relatively complex code so it'd be a challenge |
| 21:57.44 | abhi2011 | yah that would really go deep into 3D geometry I think :P |
| 21:57.59 | brlcad | not really |
| 21:58.06 | brlcad | it gets deep into librt structures is all |
| 21:58.13 | abhi2011 | ok |
| 21:58.15 | brlcad | at lot of recursion and complex data structures |
| 21:58.41 | brlcad | doable, but not immediately relevant for the goals of this project |
| 21:59.07 | brlcad | so pass the dbip, but add a FIXME note to the comment header with the details we've talked about |
| 21:59.31 | abhi2011 | ok |
| 21:59.34 | brlcad | stating the need for something like rt_comb_tree to get a portion of the rt_gettree() initialization |
| 21:59.54 | abhi2011 | right |