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 |