00:35.35 |
*** join/#brlcad cad430
(~db9f524d@bz.bzflag.bz) |
03:50.58 |
*** join/#brlcad brlcad
(~brlcad@brlcad.bronze.supporter.pdpc) [NETSPLIT
VICTIM] |
03:50.58 |
*** join/#brlcad archivist
(~archivist@host217-35-103-47.in-addr.btopenworld.com) [NETSPLIT
VICTIM] |
03:50.58 |
*** mode/#brlcad [+o brlcad]
by irc.freenode.net |
03:54.09 |
*** join/#brlcad
TheLastSpartan (guu@myth.gibbscam.com) |
05:58.45 |
*** join/#brlcad CIA-3
(~CIA@flapjack.navi.cx) |
06:00.57 |
*** join/#brlcad d_rossberg
(~c28bf505@bz.bzflag.bz) |
09:35.57 |
*** join/#brlcad clock-
(~clock@183.45.203.62.cust.bluewin.ch) |
10:17.01 |
clock- |
hello |
10:22.43 |
d_rossberg |
Hi |
10:33.46 |
clock- |
Does rtweight work in 7.2.6 for you? |
10:33.57 |
clock- |
For me it stops in infinite loop spewing out
this: |
10:34.15 |
clock- |
error parsing line 21742 of density
file. |
10:34.15 |
clock- |
0 args recognized instead of 3 |
10:34.18 |
clock- |
error parsing line 21742 of density
file. |
10:34.18 |
clock- |
0 args recognized instead of 3 |
10:34.29 |
clock- |
Where the number constantly increased (sorry
accidentally pasted twice) |
10:34.35 |
clock- |
Although 7.2.2 worked OK on this. |
11:20.45 |
d_rossberg |
i've never used rtweight |
11:22.51 |
d_rossberg |
but there were made changes in reading
.density between 7.2.2 and 7.2.4 |
11:24.27 |
d_rossberg |
also the error message you mentioned was
introduced in version 7.2.4 |
11:29.28 |
d_rossberg |
e.g., every line has to contain 3 entries
(fscanf has to return 3, in your case it's 2) |
11:31.37 |
d_rossberg |
sorry, it's 0, of course |
11:35.24 |
CIA-3 |
BRL-CAD: 03brlcad * 10brlcad/sh/make_dmg.sh:
reorder the applescript and add an update and secondary method to
attempt to force the window bounds and position |
11:39.11 |
CIA-3 |
BRL-CAD: 03brlcad *
10brlcad/misc/macosx/Resources/ (ReadMe.rtfd/TXT.rtf
Welcome.rtfd/TXT.rtf): update version to 7.3.0 |
13:07.48 |
clock- |
The content of the file: |
13:07.50 |
clock- |
1 7.7641 Mild Steel |
13:07.50 |
clock- |
2 1.522 Manufactured Rubber |
13:07.50 |
clock- |
3 2.579 Window Glass |
13:07.50 |
clock- |
4 8.920 Copper |
13:07.52 |
clock- |
5 2.700 Aluminium |
13:07.55 |
clock- |
I see 3 entries. |
13:08.27 |
clock- |
d_rossberg: and my file doesn't contain line
number 10000 :) |
14:00.40 |
d_rossberg |
clock: what's the first line number it
complains about? (sorry, i was out of my office for a
while) |
14:05.54 |
d_rossberg |
clock-: if it's number 1 try to concatenate
the second and third entry, i.e. "1 7.7641Mild Steel"
etc. |
14:07.45 |
d_rossberg |
the format string for fscanf is "%d
%f%s" |
14:08.15 |
d_rossberg |
maybe there should be a space between %f and
%s |
14:12.14 |
clock- |
d_rossberg: It's number 1 |
14:13.04 |
clock- |
d_rossberg: concatenated, and does the
same. |
14:13.12 |
clock- |
1 7.7641Mild Steel |
14:22.16 |
d_rossberg |
good ... er ... bad |
14:23.50 |
d_rossberg |
i'll test it on an example ... |
14:30.03 |
d_rossberg |
OK, i've tested it and i could reproduce your
problem |
14:30.38 |
d_rossberg |
try Mild_Steel, Manufactired_Rubber,
etc. |
14:47.37 |
brlcad |
clock-: there is very little error checking on
the .density file |
14:51.26 |
brlcad |
clock-: can you paste the file somewhere? it
could very well be something simple like a trailing empty
newline |
14:51.51 |
brlcad |
there shouldn't be any empty lines or it will
not parse correctly |
14:53.34 |
brlcad |
spaces in the material name should be fine,
the %s catches everything after the number with any whitespace
separating |
14:54.08 |
brlcad |
that might be a tab required between the %d
and the %f .. I'd have to check |
14:54.55 |
brlcad |
hmm.. not a tab |
14:55.28 |
d_rossberg |
the problem is: fscanf("%s") !=
fgets |
14:57.26 |
d_rossberg |
%s: String, up to first white-space character
(according to MSDN) |
14:57.46 |
brlcad |
hmm |
14:57.49 |
archivist |
it might be more sensible for the string to be
quoted |
14:57.51 |
brlcad |
didn't used to be fscanf.. |
14:58.09 |
clock- |
brlcad: btw - the day before yesterday we have
been talking about Mike Muus |
14:58.22 |
clock- |
brlcad: yesterday I was riding a tram and it
crashed with a truck :) |
14:58.36 |
brlcad |
eek |
14:58.59 |
brlcad |
ahh, looks like lbutler recently changed the
.density file parsing.. |
14:59.00 |
clock- |
brlcad: one has to be careful here. Swiss are
precise people, especially precise when it comes to targetting a
tram with a truck. |
14:59.20 |
brlcad |
heh |
14:59.36 |
clock- |
brlcad: it happened in the very historic
centre of Zurich, and the truck was Swiss (Thurgau) |
14:59.46 |
brlcad |
well, to be precise, Mike's last name is Muuss
;) |
14:59.54 |
clock- |
Aha, Muuss |
15:01.20 |
clock- |
brlcad: I have been living in Prague for 25
years and nothing like that happened to me - and I have been going
to university every day by a tram through the centre, for several
years. |
15:01.35 |
clock- |
brlcad: and after 6 months in Switzerland,
bang- :) |
15:01.37 |
brlcad |
d_rossberg: sure enough.. it used to be
(void)fgets( buf, BUFSIZ, densityfp ); |
15:01.47 |
brlcad |
looks like an inadvertent bug
injected |
15:02.29 |
clock- |
Is it allowed to have whitespace contained in
"Mild Steel"? |
15:02.45 |
d_rossberg |
7.2.2: yes, 7.2.4: no |
15:02.48 |
brlcad |
clock-: it's good that you're at least well
enough to be able to walk and talk about it |
15:03.11 |
clock- |
brlcad: actually, it looked like nothing
happened to anyone. The people just all walked out |
15:03.21 |
brlcad |
lucky |
15:03.32 |
clock- |
(after I opened the door with emergency
opening. The tram driver obviously even didn |
15:03.59 |
clock- |
t have the basic training that if something
like that happens, he has to open the door because the truck's
tanks can be leaking and could ignite, and fry the people
inside). |
15:04.08 |
clock- |
Only a while after I walked out, the driver
opened the doors. |
15:04.59 |
clock- |
brlcad: however 3 consecutive windows of the
tram were de-glassed where the truck hit. |
15:05.32 |
clock- |
brlcad: hmm, after replacing Mild Steel with
Mild_Steel, it seems to work :) |
15:06.19 |
brlcad |
i'll see if I can make a fix for that later
today (unless d_rossberg beats me to it) ;) |
15:06.25 |
clock- |
brlcad: does BRL-CAD support also modelling
tram and truck crashes? |
15:06.47 |
d_rossberg |
i'll try to fix it today |
15:06.48 |
brlcad |
you mean automatic collision
deformation? |
15:06.51 |
clock- |
Material #15
Mildly_Hardened_Passenger_That_Regularly_Attends_Fitness_Room |
15:07.24 |
clock- |
brlcad: what is automatic collision
deformation? |
15:07.49 |
brlcad |
the ability to impose a physical deformation
on an object and utilize it's material properties |
15:08.01 |
brlcad |
so, for example .. I have a model of a
building and a truck |
15:08.15 |
clock- |
Material #16
Old_Lady_That_Dies_From_Cardiac_Arrest_Just_From_Seeing_The_Truck_Approaching |
15:08.26 |
brlcad |
I push the truck into the building and have it
automatically deform both or either the truck/building |
15:08.46 |
clock- |
brlcad: is this possible in software at
all? |
15:08.58 |
brlcad |
yes, it's possible |
15:09.04 |
brlcad |
it's not easy, but it's possible to
implement |
15:09.15 |
clock- |
brlcad: btw have you seen the Sandia National
Laboratory tests with propelling rail engine and airplane motor
against 5m thick concrete wall? |
15:09.17 |
brlcad |
we don't currently have that ability |
15:09.19 |
clock- |
That was wonderful :) |
15:09.30 |
clock- |
Rail engine -> didn't notice (just fell out
of the track) |
15:09.37 |
clock- |
airplane motor -> vaporized |
15:10.06 |
brlcad |
no, I haven't but it sounds like other tests I
might have seen :) |
15:10.54 |
clock- |
brlcad: which ones? (unless this is an
information kept secret to keep Axil Of Evil invading the U. S.
A.)? |
15:11.26 |
clock- |
(everyone who's not with us is against us!
(Especially when it comes to breaking the Geneve
conventions)) |
15:12.12 |
brlcad |
oh, all sorts |
15:12.45 |
archivist |
they ran a train with a nuclear flask into
something in the uk |
15:14.40 |
brlcad |
ooh, interesting talk |
15:14.46 |
clock- |
archivist: nuclear flask? |
15:14.50 |
brlcad |
implicit surfaces for complex shapes |
15:15.36 |
archivist |
yes its used for moving nuclear rod/wast by
rail |
15:15.47 |
clock- |
aha. |
15:15.54 |
clock- |
And did it stay together? |
15:16.34 |
clock- |
I have seen the pictures of hardened nuclear
lava flowing from steam pipes of Chernobyl reactor. |
15:16.58 |
archivist |
yes it was a pr success |
15:17.01 |
clock- |
The guy at gamma spectroscope workplace in
Prague said it was 500 times normal background that day - and
Prague is waaay away from Chernobyl. |
15:19.17 |
clock- |
Actualy about the distance as Italy |
15:20.35 |
clock- |
brlcad: why did you strive for brlcad being
opensource? |
15:29.24 |
brlcad |
why? |
15:29.37 |
brlcad |
why not? |
15:29.46 |
brlcad |
there are many reasons actually |
15:30.47 |
brlcad |
there are the traditional selfish reasons of
getting improvements to BRL-CAD from a larger community of
users/developers, but the main reasons are for BRL-CAD's own
sake |
15:31.16 |
brlcad |
I believe that it's a great CAD package in
many ways with tremendous capability and possibilities for
improvement |
15:32.18 |
brlcad |
those improvements are very hard to realize or
justify in a research or even commercial environment often, being
open source lets the tool improve and adjust more rapidly to the
community at large |
15:33.09 |
brlcad |
we've always distributed source, but it was a
real pain to actually get and use .. now it's very simple to get it
and slowly becoming even more easier to use |
15:50.18 |
CIA-3 |
BRL-CAD: 03d_rossberg *
10brlcad/src/rt/viewweight.c: read the names from .density until
new-line |
15:50.32 |
brlcad |
heh, yep, beat me to it :) |
15:51.14 |
d_rossberg |
with the same solution? |
15:51.33 |
brlcad |
nope |
15:51.45 |
brlcad |
I was reverting it back to fgets with extra
error checking |
15:52.22 |
brlcad |
how portable is that %[^]? |
15:52.51 |
d_rossberg |
i found it in MSDN and tested it on Debian 3.1
(sarge) |
15:54.20 |
d_rossberg |
the problem with fgets is: a return of 0
doesn't mean neccessary an error |
15:54.27 |
brlcad |
I think the common name can probably be made
completely optional .. i'll have to give it a test here |
15:54.43 |
brlcad |
yeah, that's fine |
15:54.55 |
brlcad |
the name can be auto-generated for 0
returns |
15:55.13 |
brlcad |
I believe that was part of the original idea
too |
15:56.23 |
d_rossberg |
i think, if a line contains no name, the fgets
in the old solution has read the next line |
15:56.57 |
brlcad |
fgets is supposed to stop at a newline and
include the newline |
15:57.24 |
brlcad |
so it 'should' be "\n" though that's what I'm
testing now |
15:58.28 |
d_rossberg |
that's right, but if fscanf reads the whole
line (because of the missing name) fgets will start on the next
line (and makes it a name) |
16:00.12 |
brlcad |
hmm, okay |
16:03.22 |
brlcad |
then I shall leave it alone ;) |
16:03.52 |
d_rossberg |
at least until the next problem ;-) |
16:03.58 |
brlcad |
yep |
16:04.44 |
brlcad |
i might add a check for i == 2 |
16:40.54 |
CIA-3 |
BRL-CAD: 03d_rossberg * 10brlcad/NEWS: fixed
.density file parser bug in rtweight |
16:40.58 |
clock- |
what happens when I set material to 0 instead
of default 1? |
16:41.21 |
clock- |
Will it be taken as weightless? |
16:41.37 |
brlcad |
no |
16:41.44 |
brlcad |
it's just a table lookup |
16:42.39 |
brlcad |
so a zero material just correlates to the
material of type 0 in the density file |
16:43.16 |
brlcad |
theoretically, you can use any non-negative
number up to 32k, after 7.2.4 or up to 100 pre 7.2.4 |
18:25.40 |
brlcad |
~translate de en Feierabend |
18:25.56 |
brlcad |
cool |
18:35.02 |
clock- |
~translate de en unschuldig |
18:35.17 |
clock- |
~translate de en Schaffhausen |
18:35.25 |
clock- |
;-) |
18:35.31 |
clock- |
~translate de en Zurich |
18:35.54 |
clock- |
~translate de en Feuerverzinkerei |
18:36.07 |
clock- |
~translate de en
Aluminiuminimumimunitaet |
18:36.17 |
clock- |
~translate de en verzinken |
18:36.30 |
clock- |
~translate de en verzinnen |
18:36.43 |
clock- |
~translate de en verzinntes |
18:36.53 |
clock- |
~translate de en Stahlblech |
18:37.10 |
clock- |
~translate en de tin |
18:37.16 |
clock- |
~translate en de can |
18:37.22 |
clock- |
~translate en de box |
18:37.39 |
clock- |
~translate de en verzinntes
Stahlblechkasten |
18:38.02 |
clock- |
wow, finally I can replace the annoying
"tinned steel tin tin" in Ronja :) |
18:39.42 |
*** join/#brlcad AllenHarvey
(~8cb91c2a@66.111.56.50) |
18:40.17 |
AllenHarvey |
Hello, I am having a major problem with the
database format of BRLCAD 7.2 and would like some
assistance |
18:40.52 |
AllenHarvey |
I am using an application that was written
with BRLCAD 4.4 in mind and can only read the older database
format. |
18:41.04 |
AllenHarvey |
is there a tool to convert from the new format
to the old format? |
18:41.19 |
AllenHarvey |
or is there a way to obtain a key for an
brlcad 4.4? |
18:49.10 |
brlcad |
hello AllenHarvey |
18:50.21 |
brlcad |
AllenHarvey: there is a tool, though I'd
highly recommend against going backwards |
18:50.53 |
brlcad |
you're very likely to break geometry or
otherwise loose information going from the v5 database spec to the
v4 database spec |
18:51.20 |
brlcad |
well, maybe not break geometry, but definitely
might loose geometry |
18:52.20 |
AllenHarvey |
what tool is that? |
18:53.00 |
brlcad |
what's the application, if I may
ask? |
18:53.06 |
AllenHarvey |
MEVA 6.1.2 |
18:54.07 |
brlcad |
ahh |
18:54.20 |
brlcad |
I've been working on upgrading MEVA to use the
v5 format |
18:54.34 |
AllenHarvey |
You told me that once before
actually |
18:55.00 |
AllenHarvey |
but with them converting their program to
windows, i don't think they are in a hurry to upgrade their
brlcad |
18:55.04 |
brlcad |
heh, ok .. sorry, senility ;) |
18:55.19 |
AllenHarvey |
actually, i have no clue how they are handling
that issue with their next upgrade |
18:55.31 |
brlcad |
actually, they are very interested -- talked
to them a couple times since I last talked to you |
18:55.40 |
AllenHarvey |
good good |
18:56.03 |
AllenHarvey |
I wonder if they never knew brl-cad had
advanced quite a bit |
18:56.04 |
brlcad |
the larger issue is that they're merging MEVA
into another larger framework |
18:56.12 |
AllenHarvey |
what framework is that? |
18:56.43 |
brlcad |
the name escapes me right this
second |
18:57.02 |
AllenHarvey |
does this mean that meva will become part of a
larger application and not be it's own fully stand alone
application |
18:57.43 |
brlcad |
I can't speak with any authority, but that was
my personal take on it |
18:57.57 |
AllenHarvey |
by the way, I have only been able to get ahold
of David Watts when it comes to MEVA, the 2 main developers have
ignored everyone of my emails. I even made contact with an analyst
who works with them |
18:58.01 |
brlcad |
part of the .. *argl* .. something
Framework |
18:58.05 |
AllenHarvey |
and she told them to contact me but still
haven't |
18:58.51 |
AllenHarvey |
in any case, is there a way you can provide
with me a key to brlcad 4.4 or the utility to downgrade the
database? |
19:00.14 |
brlcad |
I can do the latter, though I'll actually have
to read the source to remember |
19:00.18 |
brlcad |
gimme a sec |
19:00.27 |
AllenHarvey |
no problem, thanks |
19:03.11 |
brlcad |
got it? |
19:03.20 |
AllenHarvey |
let me check |
19:03.30 |
AllenHarvey |
you emailed it, correc? |
19:03.37 |
AllenHarvey |
if so, i haven't received it yet |
19:03.48 |
brlcad |
no no |
19:03.51 |
brlcad |
other irc window |
19:07.38 |
brlcad |
clock-: I'm actually not so positive about
setting the material id to 0 now -- did you try it? |
19:07.54 |
clock- |
brlcad: yes. |
19:08.02 |
clock- |
2.80319e+272 kg is not right, I guess
:) |
19:08.14 |
clock- |
We don't have enough matter in the universe
for that :) |
19:09.11 |
clock- |
brlcad: is it possible to make some program
generate ASCII programs for mged which would put them into .g
database and this way automatically generate e.g. a 3D model of
printed circuit board with all the holes and tracks? |
19:09.24 |
clock- |
brlcad: what should I do to make it not
count? |
19:10.29 |
clock- |
brlcad: what -> how |
19:11.48 |
clock- |
brlcad: how -> what. Multiple brain errors
detected in a row. Press RESET to continue or any other key to
reset. |
19:15.12 |
clock- |
hm the e+267 doesn't seem to be caused by
material id 0 |
19:17.48 |
archivist |
hmm pcb dexign progs output drill table has
all the hole onfo for a pcb,and the gerber output has track info,
height and shape was crap when i last used a pcb prog in
anger |
19:18.31 |
clock- |
Problem: http://ronja.twibright.com/3d/ |
19:18.47 |
clock- |
The two bottommost consoles report both the
same mass 4.26886e+267 kg |
19:19.00 |
clock- |
I tried BRL-CAD 7.2.2 and 7.2.6 and both have
the same problem. |
19:19.07 |
clock- |
.density file is the link at the
bottom. |
19:21.06 |
clock- |
Is this my fault or is BRL-CAD
broken? |
20:08.03 |
*** join/#brlcad ibot
(ibot@apt.bot.TimRiker.active.supporter.pdpc) |
20:08.03 |
*** topic/#brlcad is http://brlcad.org/ || BRL-CAD is now Open
Source! || Release 7.2.6 is now posted (20050612) || Several will
be at Siggraph 2005, BoF meeting on Monday 11am-12noon || 'brlcad'
is attending the 2005 International Conference on Shapes and Solids
(Jun 13-17) |
20:13.05 |
*** join/#brlcad clock-_
(~clock@39.46.77.83.cust.bluewin.ch) |
20:26.49 |
brlcad |
clock-_: i've seen the e+272 problem, I was
debugging it earlier |
20:26.57 |
brlcad |
it's basically using a density of -1 |
20:28.10 |
brlcad |
it's a bug that's observed with an empty
.density too |
20:28.57 |
brlcad |
it's rarely ever encountered as those material
IDs are actually relatively "standaradized" across historical
use |
20:29.20 |
brlcad |
e.g. id 1 is always steel, there is no id
0 |
20:37.05 |
*** join/#brlcad clock-
(~clock@39.46.77.83.cust.bluewin.ch) |
21:44.59 |
CIA-3 |
BRL-CAD: 03brlcad *
10brlcad/regress/Makefile.am: add weight.sh to the EXTRA_DIST list
so that it's added to source distributions and so users will be
able to run the test suite.. I swear I commited this
already |