09:08.56 |
CIA-48 |
BRL-CAD: 03abhi2011 * r47014
10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp
simulate.c): |
09:08.56 |
CIA-48 |
BRL-CAD: checked to see if some subtle
positioning issues could be solved by not |
09:08.56 |
CIA-48 |
BRL-CAD: calculating the BB each iteration,
but that created large differences between |
09:08.56 |
CIA-48 |
BRL-CAD: the correct and rendered position, so
sticking with the recalculation of BB each |
09:08.56 |
CIA-48 |
BRL-CAD: iteration approach and focusing on
adding rt |
09:14.39 |
abhi2011 |
I was wondering if I can add a fix to the
primitive editor in mged to take the in focus object by default and
show its attributes, instead of having to type in the name each
time |
10:36.18 |
*** join/#brlcad jordisayol
(~jordisayo@unaffiliated/jordisayol) |
11:06.00 |
abhi2011 |
hmm there seems to be no options for an
overlap function in struct application_bundle |
11:10.53 |
abhi2011 |
hmm I ll just shoot the rays one by one at the
moment using the single ray shooting functions, translating their
position a bit across and up/down to shoot a grid |
11:23.54 |
abhi2011 |
hmm so to get the exact bounds of the overlap
I ll have to shoot at least a 100 rays in each of the x,y, z
direction |
11:23.59 |
abhi2011 |
probably more |
11:24.06 |
abhi2011 |
if the scene is large |
11:24.58 |
abhi2011 |
I ll probably get the bounding box of the
scene and shoot rays at 0.1 mm intervals in each of the 3
directions in a 3d grid |
13:19.22 |
``Erik |
that'd be an awful lot of rays... the
"marching cubes" tesselator does that kinda thing and can take gobs
of cpu time on even simple stuff |
13:20.22 |
``Erik |
um, try "g-stl -8 -a 10 /path/to/db/m35.g
component" for an idea, -8 uses marching cubes and -a is grid
spacing in mm |
13:21.29 |
``Erik |
(and it only shoots one direction until
intersections are found) |
13:23.02 |
``Erik |
conversly, raytrace the three views at
-s100000 or so, which'd ignore the book keeping and matching parts
*shrug* |
14:34.11 |
abhi2011 |
umm ok, I actually need to use librt functions
to do this, so I cant do it in the command line |
14:35.15 |
abhi2011 |
if 100 is too high will probably have to
settle for smaller scenes as of now with max about 20 rays in each
direction |
14:39.19 |
``Erik |
just noting ways to see the amount of
computation necessary, not saying how to do your certain task
:) |
14:44.44 |
abhi2011 |
:) |
14:55.37 |
abhi2011 |
hmm I need to undo a affine transformation and
I have the matrix that did the transformation |
14:55.42 |
abhi2011 |
so I need to invert the matrix |
14:55.56 |
abhi2011 |
no direct macro for that I guess |
14:56.01 |
abhi2011 |
in vmath.h |
15:47.08 |
abhi2011 |
hmm ok just transposing the upper left 3 by 3
matrix and inverting the translation vector seems to work for
inverting an affine transf. |
16:05.15 |
abhi2011 |
phew!...solved a particularly annoying
positioning issue : http://postimage.org/image/113v0wsmc/full/ |
16:06.17 |
abhi2011 |
since bullet returns world transformations,
it's important to undo the object transformation in mged, before
applying rt_matrix_transform() |
16:06.35 |
abhi2011 |
I was inverting the translation from the
previous iteration |
16:06.39 |
abhi2011 |
but not the rotation |
16:07.02 |
abhi2011 |
leading to subtle differences, like objects
outside their BB over large iterations |
16:07.59 |
CIA-48 |
BRL-CAD: 03abhi2011 * r47015
10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp
simulate.c simulate.h): Corrected positioning code and removed BB
calculation in every iteration |
16:09.07 |
abhi2011 |
Also another change is that I do not calculate
the BB every iteration, just at the first iteration, to give me
something(a cuboid) to create as a collision shape in the bullet
world |
16:11.37 |
abhi2011 |
after that bullet manages the aabb quiet well
and its best not to recalculate the AABB and insert larger cubes
into the physics world when the simulation has begun |
16:12.19 |
abhi2011 |
that tends to lock the objects into their
rotated position leading to no manifolds being generated
etc.....well all set to shoot rays now |
16:17.01 |
CIA-48 |
BRL-CAD: 03abhi2011 * r47016
10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp
simulate.c): Corrected some // comments in C code to prevent
warnings |
17:27.32 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r47017
10/brlcad/trunk/doc/docbook/resources/brlcad/book-covers-fo-template.xsl:
mod to allow unique colors file per each en book |
17:28.16 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r47018
10/brlcad/trunk/doc/docbook/resources/brlcad/brlcad-fo-stylesheet-covers.xsl:
remove old multi-book file not usable for parallel make |
17:29.18 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r47019
10/brlcad/trunk/doc/docbook/resources/brlcad/ (4 files): add unique
entry stylesheet per en book |
17:30.40 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r47020
10/brlcad/trunk/doc/docbook/BRLCAD_DOC.pm: mods for generating and
inserting unique color file per en book |
17:32.28 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r47021
10/brlcad/trunk/doc/docbook/create-book-covers.pl: mods for
generating and using unique cover and color file per en
book |
17:34.09 |
CIA-48 |
BRL-CAD: 03tbrowder2 * r47022
10/brlcad/trunk/doc/docbook/Makefile.am: mods to allow en book pdf
generation with no parallel make restrictions; some convenience
definition macros used |
18:28.20 |
abhi2011 |
hmm trying to find a simple way to draw a line
for the rays, like nirt does |
18:28.44 |
abhi2011 |
draw.c seems to do it by inventing a
solid....a bit confusing what its doing though |
18:29.03 |
abhi2011 |
_ged_invent_solid() in draw.c |
20:26.36 |
*** join/#brlcad merzo
(~merzo@237-14-132-95.pool.ukrtel.net) |
22:23.42 |
*** join/#brlcad b0ef
(~b0ef@78.58.34.95.customer.cdi.no) |
22:23.42 |
*** join/#brlcad starseeker
(~starseeke@BZ.BZFLAG.BZ) |
22:23.42 |
*** join/#brlcad dtidrow_desk
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
23:55.32 |
CIA-48 |
BRL-CAD: 03abhi2011 * r47023
10/brlcad/trunk/src/libged/simulate/ (simcollisionalgo.cpp
simphysics.cpp simulate.c simulate.h): Added manifold drawing
code |