00:15.50 |
Notify |
03BRL-CAD:starseeker * 67345
brlcad/trunk/src/libdm/dm-osgl.cpp: See if this will work to
properly/portably size and center things... |
00:20.24 |
Notify |
03BRL-CAD:starseeker * 67346
brlcad/trunk/src/libdm/dm-osgl.cpp: OK, the other windows bit just
flat out wasn't working... Things at least draw now. The center dot
seems to be behaving itself on Linux, but not on Windows... wonder
what the platform inconsistency is there, may have something to do
with how mouse xy coodinates are being recorded/propagated...
arrgh. |
00:25.50 |
Notify |
03BRL-CAD:starseeker * 67347
brlcad/trunk/src/libdm/dm-osgl.cpp: print some
diagnostics |
00:27.30 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
00:38.10 |
Notify |
03BRL-CAD:starseeker * 67348
brlcad/trunk/src/libdm/dm-osgl.cpp: not seeing the variation
there... |
01:15.50 |
*** join/#brlcad
Quantized_magic
(4ca5eb16@gateway/web/freenode/ip.76.165.235.22) |
01:17.02 |
Quantized_magic |
I'm trying to get in touch with the contacts
in charge of the Celestial Mechanics and Free fall GSoC
ideas |
02:09.30 |
Notify |
03BRL-CAD:starseeker * 67349
brlcad/trunk/src/libdm/dm-osgl.cpp: Can't pin down why, but the
offset between the OpenGL center (which is used to draw the point)
and the X,Y coordinates from the Tk windows seems to be different
on Windows vs Linux??? |
02:11.46 |
starseeker |
well, at least it works now... |
02:12.09 |
Stragus |
That's darn weird. Tried measuring coordinates
from screenshots? |
02:12.47 |
Stragus |
I'm more inclined to blame Tk than OpenGL
(possibly regarding window decorations or whatever else) |
02:13.35 |
starseeker |
I've got common_dm in MGED printing the actual
X,Y coordinates it's getting from clicking, then clicking over the
center dot |
02:14.11 |
starseeker |
they *should* be the XY coordinates in that
Window, and the math seems to bear that out |
02:14.20 |
*** join/#brlcad kkr_
(~kkr@14.139.160.31) |
02:14.42 |
starseeker |
I need to set up identical sized MGED windows
on both Linux and Windows and see what that does |
02:15.03 |
starseeker |
it's possible that there's some internal
OpenSceneGraph weirdness that's also platform specific |
02:15.24 |
starseeker |
ultimately, we're mating it's 2D coordinate
system with Tk's |
02:16.22 |
starseeker |
would be nice to figure that out
programmatically, but not sure if that's practical/possible with
the available APIs... |
02:16.52 |
starseeker |
"given this 0,0 opengl dot in the OSG widget,
find the corresponding coordinates in the parent tk
window..." |
02:17.38 |
starseeker |
we're trusting that the osg window and the
parent tk window are the same size, which *may* not be true
univerally across platforms... |
02:17.40 |
Stragus |
In theory, the fact that it's OSG or Tk
shouldn't matter at all. I would measure a screenshot ;) |
02:18.27 |
starseeker |
how would that help though? I need tk and osg
to agree, whatever the "right" number of pixels is... |
02:19.59 |
starseeker |
wonders if Qt would do any
better at this... I suppose conceptually these are the issues you
deal with anytime you embed windows in parents... |
02:20.05 |
Stragus |
Just a step to isolate the problem, figuring
out if Tk coordinates are what is expected |
02:20.19 |
starseeker |
nods |
03:32.43 |
Notify |
03BRL-CAD Wiki:89.234.182.58 * 9552
/wiki/ARL_Technical_Reports: |
04:41.10 |
*** join/#brlcad shubham_
(a5e1683c@gateway/web/freenode/ip.165.225.104.60) |
04:58.08 |
*** join/#brlcad nilram
(~nilram@2001:250:3c02:763:bcf1:ea29:474:7acf) |
05:23.33 |
*** join/#brlcad poxip
(~poxip@unaffiliated/mrpoxipol) |
06:12.58 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-ralnfadijsfjowtq) |
06:38.46 |
*** join/#brlcad davee_
(~davee@71-83-188-23.dhcp.lnbh.ca.charter.com) |
06:43.43 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-mxwowaqewknlrfgo) |
07:42.54 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |
08:02.01 |
*** join/#brlcad d_rossberg
(~rossberg@66-118-151-70.static.sagonet.net) |
08:15.33 |
*** join/#brlcad jasvir
(~jass@75-142-124-111.static.mtpk.ca.charter.com) |
08:48.33 |
*** join/#brlcad jasvir
(~jass@75-142-109-136.static.mtpk.ca.charter.com) |
09:02.42 |
*** join/#brlcad tandoorichick
(3d0c28b1@gateway/web/freenode/ip.61.12.40.177) |
09:03.35 |
*** join/#brlcad Gabriel_
(d5e9550e@gateway/web/freenode/ip.213.233.85.14) |
09:09.13 |
Gabriel_ |
Hi, I have one question about migrating user
interface functionality from mged/ to libged/ : does this reffer to
creating new source files and then including them both in mged and
search code? |
09:10.33 |
Gabriel_ |
So that the table mapping commands and
function calls would be a sort of low level linkage between the
mged and search? |
09:19.05 |
d_rossberg |
Gabriel_: as far as i can see from the project
ideas page this migration already happened, the next step would be
to have transactions |
09:21.15 |
Gabriel_ |
How would this help the commands passed to
exec be processed? |
09:21.55 |
Gabriel_ |
(i forgot to say i'm reffering to the "add
exec to search" project) |
09:22.51 |
Gabriel_ |
Why actually can't those commands be processed
the way other commands are actually executed? |
09:26.50 |
d_rossberg |
which commands? libged contains functions, no
commands |
09:29.09 |
Gabriel_ |
yes, meant to say that after processing the
input string it would result into possibly more commands which
would call functions |
09:30.22 |
d_rossberg |
did you read http://brlcad.org/wiki/Add_exec_option_to_search
? |
09:30.33 |
Gabriel_ |
like if we had search -name b* -exec draw {} ;
we could take the draw {} command and then call the draw
command |
09:31.23 |
Gabriel_ |
yes, I did, but I did not understand the part
related to mged very well |
09:34.58 |
d_rossberg |
ok: mged uses TCL wich has commands, which can
be seen as keywords which trigger functions from libged |
09:37.11 |
d_rossberg |
the keyword-function list is part of mged, but
the sech functionality is coded in libged's ged_search()
function |
09:38.03 |
d_rossberg |
this means that ged_search() has no knowledge
about the meaning of keawords |
09:38.17 |
d_rossberg |
(at least today) |
09:39.04 |
Gabriel_ |
so if adding the keyword functionality inside
libged we could trigger the commands by passing them the strings in
exec? |
09:40.30 |
d_rossberg |
this is one possibility, or you could put it
into another core library if there is a reason for it |
09:41.39 |
d_rossberg |
the keywords-map could be used by mged,
archer, and libged |
09:43.09 |
Gabriel_ |
i think i get it now: define the keyword table
inside a new core file which links mged, libged and archer
together? |
09:45.21 |
d_rossberg |
not really, mged and archer shouldn't be
linked together :) but they use the same core libraries, e.g.
libbn, libbu, librt, libwdb, libged, ... |
09:47.08 |
Gabriel_ |
for this project i guess that only libged
(because of search) and mged should be linked? |
09:49.33 |
d_rossberg |
they are already linked! but yes, you would
have to touch (modify) mged and libged, and maybe archer as
well |
09:51.48 |
Gabriel_ |
ok, I understand it better now, thanks for the
clarifications |
09:54.44 |
*** join/#brlcad tandoorichick
(b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
10:06.32 |
*** join/#brlcad teepee`
(bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
10:24.37 |
*** join/#brlcad Ch3ck_
(~Ch3ck@154.70.98.41) |
11:13.56 |
*** join/#brlcad gaganjyot
(~gaganjyot@122.173.79.18) |
12:24.22 |
brlcad |
notes http://brlcad.org/wiki/Online_Geometry/TODO
needs updating |
12:58.37 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
13:19.21 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
13:51.30 |
*** join/#brlcad gaganjyot
(~gaganjyot@122.173.79.18) |
14:00.24 |
*** join/#brlcad yorik
(~yorik@191.255.88.202) |
14:42.30 |
*** join/#brlcad tandoorichick
(3d0c28b1@gateway/web/freenode/ip.61.12.40.177) |
15:42.12 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
15:50.17 |
*** join/#brlcad adahp
(~adahp@c-24-20-214-39.hsd1.or.comcast.net) |
15:55.29 |
*** join/#brlcad nilram_
(~nilram@2001:250:3c02:763:bcf1:ea29:474:7acf) |
16:50.58 |
*** join/#brlcad davee_
(~davee@71-83-188-23.dhcp.lnbh.ca.charter.com) |
16:55.22 |
*** join/#brlcad shubham
(71c1893d@gateway/web/freenode/ip.113.193.137.61) |
17:20.06 |
``Erik |
314 gb drives for raspberry pi (on sale for pi
day) http://wdlabs.wd.com/products/wd-pidrive-314gb/ |
17:20.46 |
``Erik |
http://www.techweekeurope.co.uk/data-storage/raspberry-pi-hard-drive-pidrive-187871 |
17:20.54 |
``Erik |
cuz, y'know, pi pi pi pi pi pi... everything
must be pi... |
17:22.53 |
teepee` |
would have liked raspberry pi
version 3.14 with 3.14GB ram :) |
17:26.37 |
starseeker |
O.o |
17:48.44 |
*** join/#brlcad qbz
(~cLavelle@50.35.70.157) |
17:49.25 |
*** join/#brlcad jasvir
(~jass@172.56.40.194) |
17:52.14 |
*** join/#brlcad tandoorichick
(b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
18:11.02 |
*** part/#brlcad kkr_
(~kkr@14.139.160.31) |
18:11.36 |
*** join/#brlcad kkrcodes
(~kkr@14.139.160.31) |
18:14.06 |
*** join/#brlcad Ch3ck_
(~Ch3ck@154.70.111.152) |
18:25.54 |
*** join/#brlcad tandoorichick
(b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
18:39.16 |
tandoorichick |
is dynamic addition of points and faces in BoT
possible? |
18:39.46 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-aadwjcmbszxxcqen) |
18:40.57 |
tandoorichick |
is dynamic addition of points and faces in BoT
possible? |
19:32.16 |
Notify |
03BRL-CAD:brlcad * 67350
brlcad/trunk/doc/STRATEGY: expand TODO items for the website
project |
19:42.06 |
Notify |
03BRL-CAD:brlcad * 67351
brlcad/trunk/doc/STRATEGY: expand and clarify the gcv deployment
project tasks |
19:55.55 |
*** join/#brlcad teepee
(~teepee@unaffiliated/teepee) |
20:40.01 |
*** join/#brlcad gaganjyot
(~gaganjyot@122.173.79.18) |
20:40.30 |
*** join/#brlcad davee_
(~davee@172.56.41.218) |
20:50.57 |
brlcad |
fyi, server backups are underway for what will
hopefully be the last time |
20:51.06 |
brlcad |
(the last time on this sago server) |
20:51.51 |
brlcad |
tandoorichick: yes, I believe so |
20:53.32 |
brlcad |
it's not a very good interface, but it's
certainly technically possible as bots don't care about topology or
connectivity |
20:53.48 |
brlcad |
I think the edit interace in mged will let you
add and remove vertices |
20:54.06 |
brlcad |
not sure about command-line, but I'm not aware
of editing there |
20:54.31 |
tandoorichick |
brlcad: okay... |
20:55.03 |
tandoorichick |
i've sent a mail on the mailing list regarding
my ideas till now.. |
20:56.30 |
shubham |
brlcad: what is the best place to add the todo
list for online geomtery viewer in the wiki? Maybe this http://brlcad.org/wiki/Online_Geometry/TODO
! |
20:58.11 |
shubham |
maybe under a separate heading "GSoC 2016
tasks", keeping the present content as is for now |
20:58.28 |
tandoorichick |
brlcad: i wasn't able to find an LGPL software
that has healing features like gaps, overlaps, holes, etc.. i found
one that does remeshing (OpenFlipper). i'm studying some papers
that will aid me with the tasks. is that a good way? |
20:59.09 |
brlcad |
shubham: yes, I posted that link last night
when you were detatched from irc |
20:59.30 |
brlcad |
the page will need to get updated or have a
section added |
20:59.52 |
brlcad |
don't want to lose the previous thoughts and
goals without discussion |
21:00.11 |
shubham |
yes, we'll update that, but for now adding a
separate section will be fine |
21:00.47 |
brlcad |
shubham: please note where there is
duplication with existing content |
21:01.09 |
brlcad |
some marker so we know it's a shared topic
we've discussed before |
21:01.43 |
brlcad |
tandoorichick: can you back up and summarize
what you're wanting to work on? |
21:02.12 |
shubham |
I will take note of that, for now i just
wanted to dump the content from my google stylesheet to the wiki,
i'll update it once i get some more time. thanks |
21:02.21 |
tandoorichick |
yeah sure. i wanted to work on the automatic
polygonal mesh healing project |
21:04.13 |
tandoorichick |
and costa had suggested that i look at
meshlab's features for reference, and i did. i also read up a bit
and came up with a list of errors in meshes that can be corrected
as a part of the project (namely- gaps, overlaps, holes, T-joints,
singular vertices and edges, skewed elements, sliver patches, and
degeneracies with triangles) |
21:05.38 |
brlcad |
shubham: thanks -- if you don't have time to
merge them now, then I'll need to get someone else to because this
is when students will be reading it in that context |
21:06.29 |
brlcad |
students will not know the source of the
content and will see that as "the list" and that's not necessarily
representative as this has not been collectively discussed
afaik |
21:06.59 |
shubham |
i'm working on it |
21:07.50 |
tandoorichick |
and i also went through a list of softwares
that have mesh healing features which could be integrated. but most
of them turned out to be GPL softwares. OpenFlipper was one that
had remeshng capabilities and some topological control features
(like flipping or splitting edges, and adding or removing
edges) |
21:08.39 |
tandoorichick |
so, i wanted to know if implementing them on
my own would be fine? |
21:10.05 |
shubham |
brlcad: I'll need you to look at the list and
provide some feedback on it. I'll complete it in the next ~12
hours |
21:12.25 |
Notify |
03BRL-CAD Wiki:MeShubham99 * 9553
/wiki/Online_Geometry/TODO: |
21:30.29 |
Notify |
03BRL-CAD Wiki:MeShubham99 * 9554
/wiki/Template:Prettytable: |
21:41.21 |
brlcad |
tandoorichick: next you should look at what
healing facilities we already have in brl-cad (not sure about bot,
but nmg has some) |
21:42.30 |
brlcad |
you can't really propose what you're going to
suggest adding without knowing what we have ;) |
21:42.58 |
brlcad |
it'll probably take you hours to figure this
out, maybe days -- we can help point you in the right dirs, but
you'll need to read through lots of functions |
21:47.30 |
tandoorichick |
brlcad: okay, so should i start with
nmg.c? |
21:51.01 |
brlcad |
shubham: please be careful to not write their
proposal for them, e.g., telling them what they need to do at
certain points in time |
21:51.33 |
brlcad |
that is dependent upon ability, experience,
etc., and it's not our role to define that regardless |
21:52.02 |
brlcad |
we can define
objectives/features/bugs/desires/requirements/etc |
21:52.59 |
brlcad |
tandoorichick: that is a minutia question that
is yours to figure out .. there are hundreds of potential starting
points, all valid |
21:53.18 |
brlcad |
I would start with the bot code myself, then
nmg |
21:53.28 |
brlcad |
since bot is the closest data structure you're
talking about |
21:53.40 |
brlcad |
src/librt/primitives/bot code |
21:53.53 |
brlcad |
and src/libged/bot*.c code for userland
commands |
21:54.01 |
brlcad |
then src/librt/primitives/nmg code |
21:54.07 |
brlcad |
and src/libged/*nmg* code |
21:55.53 |
tandoorichick |
brlcad: thanks, i will work on this now.. one
question, is it ok to mention reading papers to understand
methodologies, as a part of the coding period? |
21:57.34 |
brlcad |
you're welcome to continue reading papers
during the coding period, but that will not count as gsoc
work |
21:57.59 |
brlcad |
and you shouldn't have tasks that rely on the
results of reading those papers (i.e., you have to have a plan
regardless) |
21:58.08 |
shubham |
brlcad: yes, thanks for pointing that out.
Although, I have limited my suggestions to the desires and
requirements for the project, that too at a very generic level.
I'll take more care. There might have been some misunderstanding at
some level. |
21:58.48 |
tandoorichick |
brlcad: okay, got it. |
22:01.17 |
Notify |
03BRL-CAD Wiki:MeShubham99 * 9555
/wiki/Online_Geometry/TODO: /* GSoC 2016 */ |
22:04.08 |
*** join/#brlcad dracarys983
(dracarys98@nat/iiit/x-evujycqomwprpeau) |
22:07.57 |
*** join/#brlcad qbz
(~cLavelle@50.35.70.157) |
22:10.11 |
Notify |
03BRL-CAD Wiki:MeShubham99 * 9556
/wiki/Online_Geometry/TODO: /* GSoC 2016 */ |
22:27.37 |
Notify |
03BRL-CAD Wiki:MeShubham99 * 9557
/wiki/Online_Geometry/TODO: /* GSoC 2016 task list*/ |
22:32.23 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
22:33.06 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |