00:17.33 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
02:48.53 |
starseeker |
kunigami: is it building tcl? |
02:49.17 |
starseeker |
if that's a CMake build, can you post again
with make VERBOSE=1 ? |
02:50.20 |
kunigami |
starseeker: right, I'll do that in a minute. I
went back to r45780 and it seems fine (r5797 gives a compile error
too) |
02:50.45 |
starseeker |
kunigami: it's very probably the tweaks I made
to the tcl/tk build system |
02:51.07 |
starseeker |
kunigami: you're on a mac? which version of
OSX? |
02:51.39 |
kunigami |
I'm on on mac 10.6 |
02:51.44 |
starseeker |
huh |
02:52.00 |
starseeker |
what's your cmake configure line? |
02:52.18 |
kunigami |
starseeker: cmake ../brlcad
-DBRLCAD-ENABLE_OPENGL=OFF -DBRLCAD-ENABLE_COMPILER_WARNINGS=OFF
-DBRLCAD-ENABLE_ALL_LOCAL_LIBS=ON -DBRLCAD-ENABLE_OSL=ON
-DCMAKE_INSTALL_PREFIX=/Users/kunigami/dev/brlcad-bin/
-DBRLCAD-ENABLE_STRICT=OFF |
02:53.42 |
starseeker |
huh. yeah, if you can post the whole thing
(that plus make VERBOSE=1 ) that should help |
02:54.47 |
kunigami |
here it is: http://paste.ubuntu.com/660214/ |
02:59.24 |
starseeker |
kunigami: um. can you try it again from a
clean build directory? |
02:59.50 |
starseeker |
eg cmake <options> && make
VERBOSE=1 |
03:00.02 |
kunigami |
oh, sure! |
03:04.49 |
starseeker |
gah, wait a sec... |
03:05.58 |
CIA-62 |
BRL-CAD: 03starseeker * r45807
10/brlcad/trunk/src/other/tk/CMakeLists.txt: Whoops. Helps to spell
things correctly. |
03:06.21 |
starseeker |
kunigami: see if that fixes things |
03:14.40 |
kunigami |
starseeker: seems it did! thank you! |
04:03.30 |
starseeker |
O.o http://nova-docdb.fnal.gov/cgi-bin/ShowDocument?docid=6090 |
04:09.54 |
starseeker |
hmm - can at least partially import this but
it raytraces funny
http://acquisition.jpl.nasa.gov/rfp/JC-2663-595218/GantryCADfile(STPformat).stp |
04:58.12 |
*** join/#brlcad kunigami1
(~kunigami@loco-gw.ic.unicamp.br) |
08:50.49 |
CIA-62 |
BRL-CAD: 03Abhi2011 07http://brlcad.org * r3052
10/wiki/User:Abhijit: /* Logs */ |
08:56.05 |
CIA-62 |
BRL-CAD: 03Abhi2011 07http://brlcad.org * r3053
10/wiki/User:Abhijit: /* Log */ |
12:15.45 |
abhi2011 |
brlcad : I have written the runphysics command
to translate an input object using the rt_matrix_transform()
function : http://bin.cakephp.org/view/1932154726 |
12:17.31 |
abhi2011 |
A new combination which is a copy of the
input, is created at the translated position (later I will make it
work on the input combination itself) |
12:19.13 |
abhi2011 |
I added the new translated combination to the
db tree, but it seems to not respond to draw commands, this is the
error I get in Mged : http://bin.cakephp.org/view/1614988156 |
13:15.10 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
13:48.44 |
*** join/#brlcad Stattrav
(~Stattrav@unaffiliated/stattrav) |
14:15.05 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
14:46.43 |
brlcad |
abhi2011: looking good ... does it
work? |
14:49.12 |
brlcad |
one change I'd like to request .. "runphysics"
sounds too quirky, too ambiguous |
14:49.12 |
abhi2011 |
umm no brlcad :( |
14:49.19 |
brlcad |
almost like "do science" |
14:49.24 |
abhi2011 |
haha :) |
14:49.38 |
abhi2011 |
"simulate" |
14:49.42 |
``Erik |
"teh winz: |
14:50.01 |
brlcad |
that's exactly what I was going to suggest,
"simulate" is better and extends to other operations in the
future |
14:50.11 |
abhi2011 |
right |
14:50.18 |
abhi2011 |
so regarding the code |
14:50.43 |
abhi2011 |
its seems that rt_matrix_transform() takes an
input combination and returns an output combination |
14:50.59 |
brlcad |
okay |
14:51.00 |
abhi2011 |
but what would be better is to directly act on
the input |
14:51.03 |
``Erik |
sips his irish coffee in
celebration of a successful oil change and tire rotation (next
time, imma just pay someone to do it) |
14:51.16 |
abhi2011 |
change its attributes so it gets drawn in the
new position |
14:51.49 |
brlcad |
abhi2011: are you saying that the output
combination is not the same as the input combination? |
14:51.58 |
``Erik |
thought rt_matrix_transform() just called the
f_xform() field for the primitive, it did NOT operate at the comb
level... but I may misrecall |
14:52.17 |
abhi2011 |
brlcad : well I think so |
14:52.39 |
abhi2011 |
because when I add it to the db then it shows
an error |
14:52.59 |
abhi2011 |
http://bin.cakephp.org/view/1614988156 |
14:53.24 |
brlcad |
``Erik: it calls into the object
functab |
14:53.29 |
abhi2011 |
I call the output combination as
translated_solid |
14:53.32 |
brlcad |
(combs are registered as objects) |
14:53.39 |
``Erik |
ah, did not know that |
14:53.49 |
``Erik |
do combs recursively pass the xform? |
14:54.10 |
``Erik |
xpush style? |
14:54.35 |
brlcad |
I don't recall, but I don't think so |
14:54.54 |
brlcad |
just calls the generic transform |
14:55.10 |
``Erik |
sets the comb matrix and returns, ok |
14:55.19 |
``Erik |
might be a pertinent detail to abhi's
stuff |
14:55.25 |
brlcad |
which does an import with a matrix
applied |
14:55.59 |
brlcad |
abhi2011: what is translated_solid? |
14:56.03 |
brlcad |
"l translated solid" |
14:56.11 |
brlcad |
er, "l translated_solid" |
14:56.23 |
abhi2011 |
its the output of
rt_matrix_transform() |
14:56.36 |
brlcad |
no |
14:56.38 |
abhi2011 |
i add the output of rt_matrix_transform() to
the database |
14:56.40 |
brlcad |
run that command in mged |
14:57.15 |
abhi2011 |
yes the command adds it to the
database |
14:57.24 |
brlcad |
*sigh* |
14:57.25 |
brlcad |
no |
14:57.33 |
brlcad |
run ... "l translated_solid" ... in
mged |
14:57.39 |
abhi2011 |
oh ok |
14:58.04 |
``Erik |
most mged commands are simple wrappers to the
C library |
14:58.35 |
``Erik |
so "what does this mean" can be easily
experimented with by doing mged cmds |
15:00.19 |
brlcad |
from that pastebin listing, it looks like
translated_solid is wrong -- it's not recognized as a comb yet
giving a subtree failure |
15:00.57 |
abhi2011 |
ya seems that way |
15:00.59 |
abhi2011 |
http://bin.cakephp.org/view/1112923952 |
15:01.02 |
brlcad |
I wouldn't worry about making a copy just yet
-- try updating the original object |
15:01.36 |
brlcad |
interesting |
15:01.37 |
abhi2011 |
ok , then rt_matrix_transform() output should
be copied into the original object |
15:01.55 |
brlcad |
rt_matrix_transform applied the change to the
original object |
15:01.59 |
brlcad |
you just have to write it out to
disk |
15:02.16 |
brlcad |
look at the other places where
rt_matrix_transform() is called, see what else they're
doing |
15:02.39 |
abhi2011 |
yes |
15:03.02 |
abhi2011 |
the translate and rotate commands apply vector
math to do their thing |
15:03.40 |
abhi2011 |
I was looking at chgmodel.c for how these
commands work |
15:04.22 |
brlcad |
I believe you just feed rt_matrix_transform()
the same rt_db_internal pointer for both input and output |
15:05.11 |
brlcad |
then it'll either be written to disk, or
you'll call an export function (e.g., rt_db_put_internal()) to
write it |
15:05.26 |
abhi2011 |
oh its that simple....:P |
15:05.46 |
brlcad |
it's something close to that simple |
15:07.15 |
abhi2011 |
yes after getting the output from
rt_matrix_transform() , I call db_diradd() to get the directory
pointer and then rt_db_put_internal() to put the internal format of
the combination to the disk |
15:08.33 |
``Erik |
brlcad: I think I have the new machine cleaned
up and about ready to look at migration again, the hiccup with the
weird dep thrashing everything is fixed |
15:09.44 |
``Erik |
(if not zomfg migration, I'd appreciate the
crit. name being moved so'z I don't have to remember #'s :D
) |
15:14.04 |
brlcad |
nods |
15:19.34 |
abhi2011 |
YES!!!! :) |
15:19.40 |
abhi2011 |
just moved it |
15:19.52 |
abhi2011 |
brlcad: thanks ! |
15:21.13 |
abhi2011 |
here is the modified code , have to clean up
though : http://bin.cakephp.org/view/1932154726 |
15:36.50 |
*** join/#brlcad splineman
(~splineman@155.Red-88-21-190.staticIP.rima-tde.net) |
15:36.56 |
*** join/#brlcad emagdalenag
(~splineman@155.Red-88-21-190.staticIP.rima-tde.net) |
15:38.35 |
*** join/#brlcad splineman
(~splineman@155.Red-88-21-190.staticIP.rima-tde.net) |
15:38.57 |
*** join/#brlcad emagdalena
(~emagdalen@155.Red-88-21-190.staticIP.rima-tde.net) |
15:53.26 |
abhi2011 |
I am trying to do arbitrary rotations now for
the simulate command |
16:08.26 |
*** join/#brlcad emagdalenag
(~emagdalen@3.Red-83-56-124.dynamicIP.rima-tde.net) |
17:13.41 |
brlcad |
excellent |
18:24.04 |
*** join/#brlcad abhi2011
(~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) |
18:32.00 |
CIA-62 |
BRL-CAD: 03Abhi2011 07http://brlcad.org * r3054
10/wiki/User:Abhijit: /* Log */ |
18:54.23 |
CIA-62 |
BRL-CAD: 03Abhi2011 07http://brlcad.org * r3055
10/wiki/User:Abhijit: /* Log */ |
20:46.54 |
abhi2011 |
ok I get a strange behavior when I link the
simulate command with a command wrapper |
20:47.28 |
abhi2011 |
so I have modified cmd.c to include a new
command wrapper for the new mged command "simulate" |
20:48.05 |
abhi2011 |
cmd.c now has the implementation for
cmd_ged_simulate_wrapper(ClientData clientData, Tcl_Interp
*interpreter, int argc, const char *argv[]) |
20:48.18 |
abhi2011 |
its very similar to the
cmd_ged_edit_wrapper() |
20:49.11 |
abhi2011 |
http://bin.cakephp.org/view/1859715979 |
20:49.48 |
abhi2011 |
in the command wrapper I call the libged
function which actually implements the simulate function :
ged_simulate(struct ged *gedp, int argc, const char
*argv[]) |
20:50.24 |
abhi2011 |
i call ged_simulate() 100 times from the
command wrapper with an artificial delay inserted of 1/10th of a
second |
20:51.51 |
abhi2011 |
ged_simulate() is called inside a for loop and
I draw the object at the new position as well at the end of each
iteration, so it should appear to move every 1/10th of a second in
mged |
20:52.36 |
abhi2011 |
but the object is moved only at the end of all
the iterations when the command wrapper returns |
20:53.10 |
abhi2011 |
I would have expected mged to draw the object
immediately after the cmd_draw() is called to draw the
object |
20:58.41 |
abhi2011 |
so the way the simulate command should work is
, the user gives the number of steps to simulate as : simulate
10 |
20:59.17 |
abhi2011 |
and then the physics takes over and simulates
with the command wrapper for simulate called the libged simulate
implementation 10 times |
21:00.14 |
abhi2011 |
but after each call to the libged simulate
function ged_simulate(), the position of the dynamic object should
be redrawn in mged and not after all the iterations are
complete |
21:00.14 |
``Erik |
command sounds about right, I believe there is
a "flush" type command that has to be passed to force
display |
21:00.25 |
abhi2011 |
aoh |
21:00.35 |
abhi2011 |
right i ll check it |
21:31.23 |
abhi2011 |
there is a update_views = 1; probably that
one |
21:54.48 |
``Erik |
I tend to avoid gui code, but that sounds
familiar. I think there was maybe discussion about an explicit
"block until" flush cmd? I'm not sure :/ |
21:55.17 |
``Erik |
(the discussion being about if we should
implement one, or if the variable is adequate) |
22:09.59 |
abhi2011 |
any way to grep the irc logs :P |
22:16.34 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
22:18.02 |
louipc |
abhi2011: the one's stored on your
computer? |
22:21.59 |
abhi2011 |
no the logs for the last few months |
22:22.46 |
abhi2011 |
louipc: maybe I can find the discussion
regarding the 'block until' flush command that Erik was speaking
about |
22:28.36 |
abhi2011 |
basically if a command is taking too long to
process, there must be a way to send updates to the user as it
progresses |
22:58.53 |
louipc |
abhi2011: you can try using google to search
maybe |
22:59.44 |
louipc |
abhi2011: search "site:http://ibot.rikers.org/%23brlcad/
abhi2011" for example |
23:20.18 |
abhi2011 |
louipc: ah yes that works quite well |
23:20.34 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |
23:37.04 |
*** join/#brlcad dtidrow
(~dtidrow@c-68-84-167-135.hsd1.mi.comcast.net) |