00:29.54 |
CIA-5 |
BRL-CAD: 03brlcad * 10brlcad/autogen.sh: (log
message trimmed) |
00:29.55 |
CIA-5 |
BRL-CAD: don't buy into the philosophy of
requiring a minimum version so strictly. add |
00:29.55 |
CIA-5 |
BRL-CAD: extra failure support for
configure.ac files that are actually using autoconf |
00:29.55 |
CIA-5 |
BRL-CAD: macros newer than the stated minimum
requirement on the half-presumption that |
00:29.55 |
CIA-5 |
BRL-CAD: they are perhaps not strictly
necessary for the build. warn verbosely about any |
00:29.55 |
CIA-5 |
BRL-CAD: edits iff it helps autoconf succeed.
this helps everything 'just work' even for |
00:29.57 |
CIA-5 |
BRL-CAD: the maintainers without requiring
tools to be updated for potentially |
03:01.19 |
*** join/#brlcad learner
(n=brlcad@pcp0011649376pcs.aberdn01.md.comcast.net) |
03:01.20 |
*** mode/#brlcad [+o learner]
by ChanServ |
07:12.28 |
*** join/#brlcad DTRemenak
(n=DTRemena@DHCP-170-143.caltech.edu) |
07:17.33 |
*** join/#brlcad ibot
(i=ibot@pdpc/supporter/active/TimRiker/bot/apt) |
07:17.33 |
*** topic/#brlcad is http://brlcad.org/ || BRL-CAD is now Open
Source! || Release 7.6.0 is now being prepared |
13:38.41 |
AchiestDragon |
hi |
14:21.44 |
learner |
hello |
14:22.14 |
AchiestDragon |
ha life :) |
14:40.53 |
learner |
:) |
14:43.32 |
AchiestDragon |
grrr , been generating a gui to show an idea ,
done it twice now , but qt designer crashed on me both times ,
another 2 hrs down the drain |
14:44.41 |
learner |
ahh, yes .. gotta save often with that
sucker |
14:46.14 |
AchiestDragon |
had almost finished it as well |
14:46.48 |
learner |
i'm sure it was wonderful ;) |
14:50.38 |
AchiestDragon |
trying to show an idea for an ( auto parts
generator ) , so objects such as box, tube , I beems etc can be
easaly generated |
14:52.36 |
AchiestDragon |
by selecting from the standard end profiles (
or a custom profile ) specifying the lenth or a bend profile file
and it should generate the main part , then you may have to do
object add/ subtract to put holes in it |
14:53.16 |
learner |
sort of like basic feature-based
editing |
14:53.29 |
AchiestDragon |
yes |
14:57.24 |
AchiestDragon |
so for a paperclip it would be round bar 1mm
dia folowing say a dxf of a paperclip bend path |
15:01.34 |
AchiestDragon |
component libs would be usefull so you could
have std nuts bolts screws or whatever |
15:05.21 |
brlcad |
yeah, that would be useful |
15:07.05 |
AchiestDragon |
question that i find odd it that brlcad was a
us gov program , so why are dimementions in mm |
15:07.43 |
brlcad |
:) |
15:08.08 |
brlcad |
actually, you can set to units to whatever you
like, it's just the default that's mm ;) |
15:08.20 |
AchiestDragon |
k |
15:08.22 |
AchiestDragon |
:) |
15:08.26 |
brlcad |
units command |
15:09.21 |
AchiestDragon |
is fine for me in mm , just seemed odd that
it was by default |
15:10.27 |
brlcad |
brl-cad's always had an international
community of users, 'some' default unit of measurement was
needed |
15:11.16 |
brlcad |
just because most of the rest of the country
has difficulty adopting metric doesn't mean we can't :) |
15:11.47 |
*** join/#brlcad docelic
(n=docelic@195.246.23.200) |
15:13.19 |
AchiestDragon |
ive been using metric and imperial units for
some time , since the uk went metric in the 70's , its still a case
of some odd things like 1"*1" steel bar comes in 6m lenths
now |
15:15.51 |
AchiestDragon |
finding imperial spanners and tools like drill
bits , all seem to be metric here now so its hard to get imperial
tools |
15:16.00 |
brlcad |
yeah, that's what makes the unit command
useful.. you can change units on the fly for each object if you
wanted |
15:17.49 |
AchiestDragon |
at least you dont need 12 fingers when
calculating metric mesurement |
15:17.57 |
AchiestDragon |
s |
15:20.13 |
AchiestDragon |
cool, so i can have a 1" cube with a 20mm hole
though it for example , |
15:21.14 |
*** join/#brlcad learner
(n=brlcad@pcp0011649376pcs.aberdn01.md.comcast.net) |
15:21.14 |
*** mode/#brlcad [+o learner]
by ChanServ |
15:21.30 |
AchiestDragon |
wb learner |
15:24.44 |
AchiestDragon |
what's the time scaile for archer for linux (
well even for a working alpha version ) |
15:29.03 |
brlcad |
hopefully by the end of this month |
15:29.25 |
AchiestDragon |
:) |
15:33.19 |
AchiestDragon |
will need to sort cvs out so i can test
it |
15:36.31 |
learner |
that would be cool |
15:38.59 |
AchiestDragon |
now cvs is working ok this time , not changed
anything so must of been sourcefourge's end |
15:39.20 |
brlcad |
usually is |
15:39.39 |
brlcad |
usually just a matter of waiting for sf.net
guys to get in to work the next day.. |
15:47.50 |
AchiestDragon |
any ./configure options you recomend other
than --enable-optimized debug ones for example |
15:53.01 |
*** join/#brlcad Twingy
(n=justin@pcp0011647505pcs.aberdn01.md.comcast.net) |
16:09.47 |
brlcad |
AchiestDragon: debug is default, regardless of
optimization --enable-optimized is all I'd suggest |
16:10.07 |
brlcad |
the rest is all auto-detect and will build
everything it can |
16:10.28 |
AchiestDragon |
k , is on make at moment , did ./configure
--enable-optimized --prefix=$HOME |
16:16.25 |
brlcad |
that'll work, though it's going to toss a
bunch of dirs into $HOME |
16:16.40 |
brlcad |
bin, share, lib, include, man |
16:18.21 |
AchiestDragon |
should of done $HOME/brlcad but bit late
now |
16:19.26 |
AchiestDragon |
well guess not , have'nt done make install
yet |
16:19.53 |
brlcad |
it does matter ;) |
16:20.12 |
brlcad |
the libraries and resource utilities keep
track of where they will install at configure time |
16:20.56 |
AchiestDragon |
stoped it and started with ./configure
--enable-optimized --prefix=$HOME/brlcad this time |
17:00.59 |
AchiestDragon |
:) well cvs version compiles ok and seems to
be running ok |
17:01.58 |
AchiestDragon |
see that wire frame overlay seems to be
working in perspective mode now |
17:10.31 |
brlcad |
shouldn't have ever stopped working
.. |
17:11.09 |
brlcad |
except for shaded_mode where there's a
bug |
17:12.26 |
AchiestDragon |
ha , well when i have overlay selected and
whenever i enabled perspective the wire frame vanished , making it
hard to position the image , had to do a quick render and guess
when repositioning the image |
17:14.09 |
AchiestDragon |
since doing this render its now not showing ,
hopes it comes back , half way though a trace so will wait for it
to finish first |
17:17.05 |
brlcad |
you do know about underlay/overlay,
yes? |
17:17.32 |
brlcad |
if you're rendering to the framebuffer in the
graphics window, the wireframe can be on top or below the
framebuffer |
17:19.03 |
AchiestDragon |
yes underlay draws it underneath and overlay
draws it over the top , so overlay should desplay it
regardles |
17:20.25 |
AchiestDragon |
but depends on what bit is beeing layed over
the top layer will be the prominent image , |
17:21.18 |
AchiestDragon |
its set to underlay , theres no wire frame ,
so i guess thats a bug ?? |
17:23.54 |
AchiestDragon |
i think from what i know of it that the
underlay refers to the rendered image , not the wire frame , so the
frame is top with the renderd image under it , that right
? |
17:24.26 |
AchiestDragon |
it seems to work that way when its working
ok |
17:25.09 |
brlcad |
yes |
17:26.03 |
AchiestDragon |
will see if i can get it back when its
finished this ,, its 50% though a photonmap render |
17:26.34 |
brlcad |
if you turn perspective off, does it
return? |
17:27.03 |
brlcad |
the size projection of perspective often
places the wireframe in front of the clipping plane |
17:27.52 |
brlcad |
you have z-clipping on or off? |
17:28.32 |
brlcad |
(make sure it's off -- Misc menu) |
17:30.23 |
AchiestDragon |
k will try when its done this render ,,btw z
clipping is on |
17:30.32 |
AchiestDragon |
hopes its that |
17:30.58 |
brlcad |
once the render starts, it will render the
state from image start |
17:31.44 |
brlcad |
it doesn't matter what you change after that
in the view |
17:32.04 |
brlcad |
so you can turn perspective on/off or even
spin the model around, it won't affect the image being
rendered |
17:32.14 |
AchiestDragon |
k |
17:32.47 |
brlcad |
the only thing you can't change is the window
dimensions, since it will distort the framebuffer |
17:33.06 |
AchiestDragon |
k :) z clipping on / off , brings the wire
frame back |
17:36.33 |
brlcad |
yeah, so it's a matter of how large the thing
is that you're rendering |
17:37.17 |
AchiestDragon |
k ,, m35.g |
17:50.33 |
AchiestDragon |
odd its finished the raytrace but the image is
the same , ie still showing the quick render |
17:58.14 |
AchiestDragon |
maybe me |
18:03.15 |
*** join/#brlcad DTRemenak
(n=DTRemena@DHCP-170-143.caltech.edu) |
18:21.23 |
brlcad |
AchiestDragon: you said you were doing a
photonmap render of the m35? that would require a _lot_ of photons
without putting the m35 into a box |
20:20.59 |
AchiestDragon |
yes ,, but it should still show the image it
has just rendered shouldent it ??? |
20:23.25 |
AchiestDragon |
i did a render using surface normals first
this time , so i get a image that is coloured diferently , then did
a photonmap render , it has finished some time ago but the image
beeing displayed is still the coloured surface normals
one |
20:24.24 |
AchiestDragon |
is this a bug or is there a diferent output
option to turn on ?? |
20:29.05 |
AchiestDragon |
see http://www.whipy.demon.co.uk/snapshot3.png |
21:06.11 |
AchiestDragon |
ok closed the program reopened it , set the
photons to 4194304 and started , this is going to take a long time
, hope it works |
21:39.42 |
brlcad |
heh... |
21:40.12 |
brlcad |
unless you have a massive cluster, I doubt
that many photons will complete this month without putting the
truck in a box ;) |
21:41.02 |
brlcad |
hmm, that screenshot helps -- it did not
terminate correctly |
21:42.10 |
brlcad |
looks like a bug in the photon map rendering
code.. I'd file a report on it, if you dont' mind |
21:53.13 |
AchiestDragon |
k |
21:54.18 |
AchiestDragon |
no big cluster here, a its dual xeon 2Ghz
machine |
22:02.39 |
AchiestDragon |
and it only seems to be using 25% of
cpu |
22:04.11 |
brlcad |
probabbly swapping .. that many photons
require a fair bit of memory |
22:04.22 |
brlcad |
unless it's a dual-core dual |
22:04.49 |
brlcad |
or hyperthreaded which I gather it is if it's
xeons |
22:05.09 |
brlcad |
the prep stage in photon mapping hasn't been
parallelized |
22:05.18 |
AchiestDragon |
k |
22:05.21 |
brlcad |
so it's just using one cpu (one virtual of
your four) |
22:06.43 |
*** join/#brlcad DTRemenak
(n=DTRemena@DHCP-170-143.caltech.edu) |
22:10.00 |
AchiestDragon |
bug report submitted |
22:43.48 |
AchiestDragon |
opps it submitted it twice |
22:45.14 |
brlcad |
no problem, it'll get cleaned up |
22:47.58 |
pra5ad |
hey sean |
22:48.02 |
pra5ad |
where's ur singleton code |
22:52.18 |
brlcad |
pra5ad: http://ftp.brlcad.org/tmp/Singleton.h
or http://ftp.brlcad.org/tmp/Singleton2.h |
22:52.58 |
brlcad |
2 is more simple, and what I use in bz --
presumes single thread model and only default constructor
creation |
22:53.17 |
``Erik |
grumble grumble hxx grumbl |
22:53.18 |
brlcad |
the first has (mostly unimplemented) hooks for
threading and memory methods |
22:54.55 |
brlcad |
pra5ad: so to use it.. say i have a singleton
file manager, you derive off the templatized version: |
22:54.58 |
brlcad |
class FileManager : public
Singleton<FileManager> |
22:55.31 |
brlcad |
and make him a friend with himself in his
protected or private: |
22:55.33 |
brlcad |
friend class
Singleton<FileManager>; |
22:55.43 |
brlcad |
where you've also placed the
constructor/destructor |
22:57.04 |
brlcad |
initialize your singleton in a compilation
unit so that you have a handle: |
22:57.13 |
brlcad |
template <> |
22:57.15 |
brlcad |
FileManager*
Singleton<FileManager>::_instance =
(FileManager*)0; |
22:57.25 |
brlcad |
and that does it |
22:57.41 |
brlcad |
might want to create a #define to make
accessing the instance simple: |
22:57.51 |
brlcad |
#define FILEMGR
(FileManager::instance()) |
22:58.21 |
brlcad |
so then I can use
FILEMGR.lookUpFile("blah.h"); etc |