00:29.25 |
*** join/#brlcad adahp
(~adahp@c-24-20-214-39.hsd1.or.comcast.net) |
00:39.41 |
*** join/#brlcad maths22
(~maths22@66-118-151-70.static.sagonet.net) |
00:39.42 |
*** join/#brlcad maths22
(~maths22@unaffiliated/maths22) |
01:01.56 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |
01:34.01 |
qbz |
In regards to the gsoc idea posted here:
http://brlcad.org/wiki/Celestial_mechanics_particle_system,
What physics would this entail? Would this involve modifying the
rendering pipeline or do I just need to generate the proper data to
send to the existing pipeline? Would a more general 3d particle
system that could be used to simulate orbits make a good project or
should I only focus on tackling |
01:34.01 |
qbz |
the problem of particle orbits? These are some
of the questions I'm thinking about, I'm mostly just looking for
someone to point me in the right direction as to what an
imnplementation would roughly entail and what files I should be
looking to in order to start thinking about how I would implement
the project. |
03:38.16 |
*** join/#brlcad brlcad
(~sean@66-118-151-70.static.sagonet.net) |
03:40.13 |
brlcad |
qbz: if you are eligible to participate in
SOCIS, that may be a better fit |
05:45.24 |
*** join/#brlcad tandoorichick
(b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
05:55.25 |
qbz |
My interest is more in particle systems then
celestial bodies. |
05:55.55 |
qbz |
I just saw that project on the gsoc ideas
page |
05:56.28 |
*** join/#brlcad shubham
(a5e1683c@gateway/web/freenode/ip.165.225.104.60) |
06:17.01 |
*** join/#brlcad merzo
(~merzo@AGrenoble-653-1-574-115.w90-42.abo.wanadoo.fr) |
07:15.41 |
*** join/#brlcad davee__
(~davee@71-83-188-23.dhcp.lnbh.ca.charter.com) |
07:17.54 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |
08:02.42 |
*** join/#brlcad d_rossberg
(~rossberg@66-118-151-70.static.sagonet.net) |
08:03.15 |
*** join/#brlcad kkrcodes
(~kkr@14.139.160.31) |
08:44.28 |
*** join/#brlcad tandoorichick
(3d0c28b1@gateway/web/freenode/ip.61.12.40.177) |
09:02.45 |
*** join/#brlcad akshayjain
(67157e4f@gateway/web/freenode/ip.103.21.126.79) |
09:08.02 |
*** join/#brlcad akshayjain007
(67157e4f@gateway/web/freenode/ip.103.21.126.79) |
09:31.08 |
*** join/#brlcad tandoorichick
(b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
09:32.27 |
tandoorichick |
should degeneracies in BoTs be handled or is
it okay to let them stay? Eg: |
09:33.01 |
tandoorichick |
1. vertices that are listed but are not a part
of any triangle |
09:33.28 |
tandoorichick |
2. single vertex forming a a triangle of area
0 |
09:34.13 |
tandoorichick |
3. dangling edges- triangle made up of 2
vertices (makes a triangle of area 0 again). like va vb
vb |
09:34.52 |
tandoorichick |
should these also be healed as a part of mesh
healing? |
09:43.37 |
*** join/#brlcad kkr_
(~kkr@14.139.160.31) |
10:12.39 |
*** join/#brlcad teepee`
(bc5c2134@gateway/web/freenode/ip.188.92.33.52) |
10:39.11 |
*** join/#brlcad gaganjyot
(~gagan@122.173.79.18) |
10:39.24 |
gaganjyot |
brlcad, hi |
10:40.59 |
gaganjyot |
brlcad, I was recently placed in unisys global
services and from their wiki, I came to know unisys works with US
military :D |
10:42.01 |
gaganjyot |
so I thought you might know more about unisys.
Was wondering if I get a chance to meet you via work ;) |
12:59.54 |
*** join/#brlcad tandoorichick
(b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
13:09.16 |
*** join/#brlcad shubham
(01163f12@gateway/web/freenode/ip.1.22.63.18) |
13:42.44 |
*** join/#brlcad tandoorichick
(b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
13:49.06 |
*** join/#brlcad kkr_
(~kkr@14.139.160.31) |
14:01.06 |
*** join/#brlcad tandoorichick
(b64b2d01@gateway/web/freenode/ip.182.75.45.1) |
14:09.33 |
Notify |
03BRL-CAD:starseeker * 67340
brlcad/trunk/src/other/CMakeLists.txt: More target
folders |
14:14.04 |
*** join/#brlcad
tandoorichick_
(3d0c28b1@gateway/web/freenode/ip.61.12.40.177) |
14:15.03 |
*** join/#brlcad sofat
(~sofat@49.248.183.189) |
14:16.28 |
*** join/#brlcad sofat_
(~sofat@49.248.182.120) |
14:29.56 |
*** join/#brlcad kintel
(~kintel@unaffiliated/kintel) |
14:31.06 |
Notify |
03BRL-CAD:starseeker * 67341
(brlcad/trunk/CMakeLists.txt
brlcad/trunk/src/other/CMakeLists.txt): couple aqua tweaks - not
sure if they're needed... |
14:31.42 |
Notify |
03BRL-CAD:starseeker * 67342
brlcad/trunk/CMakeLists.txt: int, not string... |
14:40.21 |
starseeker |
brlcad: OK, OSG is definitely busted on
Windows |
14:40.44 |
starseeker |
guess that'll have to be post 7.26.0 |
15:15.30 |
*** join/#brlcad qbz
(~cLavelle@50.35.70.157) |
15:18.09 |
brlcad |
qbz: sure, particle systems ideas works for
SOCIS too -- any simulation/animation/visualization component makes
for a good socis project |
15:44.33 |
*** join/#brlcad kkr_
(~kkr@14.139.160.31) |
15:48.05 |
starseeker |
and bundled Tk doesn't like Aqua build either,
looks like (not surprised...) |
15:48.36 |
starseeker |
probably just as well - don't want to hold up
the release any longer trying for the moon... |
16:07.03 |
*** join/#brlcad yorik
(~yorik@191.255.88.202) |
16:08.46 |
Notify |
03BRL-CAD:starseeker * 67343
brlcad/trunk/src/libdm/dm-osgl.cpp: Gah. Not just a Tk dependency,
but an X11 dependency... |
16:11.32 |
Notify |
03BRL-CAD:starseeker * 67344
brlcad/trunk/src/libdm/dm-osgl.cpp: typo, copy-paste fix |
16:16.25 |
starseeker |
growl... necessary, but not
sufficient... |
16:18.13 |
*** join/#brlcad gaganjyot
(~gaganjyot@122.173.79.18) |
16:33.33 |
brlcad |
starseeker: yeah, I didn't attempt bundled
aqua Tk -- I used apple's |
16:33.44 |
brlcad |
in fact, had to force it in a few
places |
16:33.58 |
brlcad |
our opengl header inclusions were also wrong
in a few places |
16:34.16 |
brlcad |
OpenGL/gl.h vs GL/gl.h when building against
-framework OpenGL |
16:34.26 |
brlcad |
in three or so files |
16:42.31 |
*** join/#brlcad Akshay
(~Akshay@120.56.244.211) |
16:44.02 |
starseeker |
nods - IIRC that's what I
did before too - I'll want to upgrade to 8.6 before I do a lot of
fiddling to get Tk Aqua building working |
16:44.30 |
starseeker |
the windows failure is more distrubing... that
*did* work at one point... |
16:44.54 |
starseeker |
will find it eventually, but
it'll mean lots of Windows Debugging... blegh |
16:45.20 |
starseeker |
still, worth doing (along with Aqua) for
7.28.0 |
16:45.28 |
starseeker |
just now now ;-) |
16:46.26 |
*** join/#brlcad tandoorichick
(3d0c28b1@gateway/web/freenode/ip.61.12.40.177) |
17:14.29 |
*** join/#brlcad Akshay
(Akshay@120.56.244.211) |
17:49.47 |
*** join/#brlcad gaganjyot
(~gaganjyot@122.173.79.18) |
18:20.20 |
*** join/#brlcad Akshay
(Akshay@120.56.244.211) |
18:44.20 |
*** join/#brlcad tandoorichick
(b64b2de1@gateway/web/freenode/ip.182.75.45.225) |
19:01.26 |
*** join/#brlcad tandoorichick
(3d0c28b1@gateway/web/freenode/ip.61.12.40.177) |
19:06.31 |
*** join/#brlcad ickby
(~stefan@x5d84d10f.dyn.telefonica.de) |
19:15.02 |
tandoorichick |
can somebody tell me if it is necessary to
integrate some existing software's codefor mesh healing or is it
fine if i write it on my own? |
19:17.16 |
*** join/#brlcad shubham_
(71c18927@gateway/web/freenode/ip.113.193.137.39) |
19:50.52 |
*** join/#brlcad Akshay
(Akshay@120.56.244.211) |
19:56.00 |
gaganjyot |
tandoorichick, AFAIU, if you can integrate
some software |
19:56.23 |
gaganjyot |
considering it meets the licensing terms, It
would be easier for you as well as the community |
20:34.28 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |
20:37.07 |
*** join/#brlcad Gabriel_
(d5e9550e@gateway/web/freenode/ip.213.233.85.14) |
20:44.41 |
*** join/#brlcad merzo
(~merzo@AGrenoble-653-1-574-115.w90-42.abo.wanadoo.fr) |
20:48.07 |
*** join/#brlcad Akshay
(Akshay@120.56.244.211) |
21:00.24 |
tandoorichick |
gaganjyot: thanks for the advice. :) |
21:02.55 |
gaganjyot |
sure welcomed :) |
21:12.49 |
*** join/#brlcad tofu_
(~Mutter@50.242.218.129) |
21:28.35 |
*** join/#brlcad tofu__
(~Mutter@50.242.218.129) |
21:48.20 |
Gabriel_ |
Hi, can anyone tell me what does "live at a
lower level" reffers to in the "add exec option to search" GSoC
project? |
21:52.19 |
Gabriel_ |
Could it possibly mean to add the table which
maps commands to functions into another source file and then
include this source file in both the search source and
MGED? |
21:53.32 |
``Erik |
Gabriel_: I'd have to see the page to be sure,
but it might mean migrate the functionality from the mged/ user
interface into the libged/ library |
22:02.58 |
Gabriel_ |
So why commands passed to "exec" (lets say
they are already stored as individual commands) could not be
executed such as other commands are currently executed? |
22:06.16 |
Gabriel_ |
I have seen in the source code of the search
files that none includes files in mged... |
22:08.29 |
Gabriel_ |
Perhaps linking the MGED interface with the
search files through a new table mapping the commands with
functions in a new file would bring a plus to code modularity and
flexibility? |
22:11.43 |
*** join/#brlcad tofu__
(~Mutter@50.242.218.129) |
22:32.10 |
*** join/#brlcad cax
(uid152160@gateway/web/irccloud.com/x-pwjcvyxhmqrqawny) |
22:37.37 |
*** part/#brlcad Gabriel_
(d5e9550e@gateway/web/freenode/ip.213.233.85.14) |
22:37.53 |
*** join/#brlcad tofu_
(~Mutter@50.242.218.129) |
23:30.46 |
*** join/#brlcad qbz
(~cLavelle@50.35.70.157) |
23:41.44 |
*** join/#brlcad teepee_
(~teepee@unaffiliated/teepee) |