| 06:29.32 | *** join/#brlcad tom_ (n=chatzill@mmds-216-19-44-150.sqpk.az.commspeed.net) | |
| 06:34.48 | *** join/#brlcad tom___ (n=tom@mmds-216-19-44-150.sqpk.az.commspeed.net) | |
| 07:29.35 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) | |
| 10:35.10 | *** join/#brlcad elite01 (n=elite01@dslc-082-082-086-187.pools.arcor-ip.net) | |
| 14:49.49 | *** join/#brlcad butti (n=butti@e178080133.adsl.alicedsl.de) | |
| 15:19.46 | *** join/#brlcad minute-ssh (n=MinuteEl@bz.bzflag.bz) | |
| 16:51.53 | *** join/#brlcad waterpie (n=waterpie@athedsl-336989.home.otenet.gr) | |
| 16:52.15 | waterpie | hi all |
| 16:55.28 | waterpie | q: i have no knowledge of brlcad. i just want to convert an iges file to eg dxf. i try "iges-g -3 -o f3.g f.iges" and then "g-dxf -o f3.dxf f3.g" but does nothing. it seems that it misses a "sample-object" at the end, but i have no idea what it is/how to make it. any help pls? |
| 17:06.56 | brlcad | when you do g-dxf, you have to tell it what object(s) to convert |
| 17:07.10 | brlcad | when you did iges-g, it created at least one object for you |
| 17:07.18 | brlcad | run mged -c f3.g tops |
| 17:07.31 | brlcad | that should list the top-level objects, you can then use that name for g-dxf |
| 17:14.15 | waterpie | brlcad: mged -c f3.g tops --> _GLOBAL running: g-dxf -o f3.dxf f3.g _GLOBAL --> _GLOBAL is not a drawable database object 0 triangles written |
| 17:14.42 | brlcad | yeah _GLOBAL is not a geometry object |
| 17:14.48 | brlcad | is there no other object listed? |
| 17:15.07 | waterpie | no |
| 17:15.28 | brlcad | then there wasn't any geometry detected/converted during iges-g |
| 17:15.45 | brlcad | it should have said in the output that there were 0 objects converted |
| 17:15.59 | brlcad | can you pastebin the output from iges-g? |
| 17:16.02 | brlcad | ~pastebin |
| 17:16.03 | ibot | [pastebin] a place to paste your stuff without flooding the channel - try http://pastebin.ca, or http://channels.debian.net/paste, or http://rafb.net/paste/, or http://pastebin.com is usually painfully too slow and unresponsive to use, use one of the other pastebin sites, or dpaste.com is a very nice pastebin as well |
| 17:16.12 | brlcad | er |
| 17:16.15 | brlcad | ~bzpaste |
| 17:16.20 | brlcad | ~bzpastebin |
| 17:16.20 | ibot | somebody said bzpastebin was http://pastebin.bzflag.bz a place to put large chunks of text to not flood a channel |
| 17:16.29 | brlcad | yeah, there |
| 17:19.07 | waterpie | http://pastebin.bzflag.bz/d4b57b251 |
| 17:21.10 | brlcad | ah, several 'issues' |
| 17:21.59 | brlcad | "Unrecognized IGES version" for starters, meaning that solidworks is probably exporting one of the newer iges formats, but it still finds 1001 entities, so should be fine for conversion |
| 17:22.07 | brlcad | but at the bottom it says the problem |
| 17:22.31 | brlcad | it contains spline surfaces, so you need the -n option |
| 17:23.06 | brlcad | either -n or -t |
| 17:23.18 | brlcad | try both, should get different results |
| 17:24.01 | waterpie | it is either or. each one looses the info of the other? |
| 17:24.23 | brlcad | yeah, not both |
| 17:24.43 | brlcad | it's not so much that it looses information moreso than it tries a different conversion approach |
| 17:25.28 | *** join/#brlcad Z80-Boy (n=clock@zux221-122-143.adsl.green.ch) | |
| 17:25.32 | brlcad | just about every format conversion looses information of some type, it's really rare that *something* doesn' change |
| 17:26.01 | waterpie | -t core dumps |
| 17:26.20 | brlcad | hm, that's not a good sign |
| 17:26.57 | brlcad | can you paste the fin_assembly.igs somewhere where I can test it? |
| 17:27.04 | brlcad | s/paste/post/ |
| 17:32.34 | waterpie | i give up. i will try to get the file in different format in the first place. |
| 17:32.40 | waterpie | thanks for your help |
| 18:15.08 | *** join/#brlcad yukonbob (n=yukonbob@CPE001125477e9c-CM0011e6be27b1.cpe.net.cable.rogers.com) | |
| 18:18.55 | yukonbob | hello, cadheads |
| 18:58.32 | louipc | damned vampires |
| 19:14.45 | yukonbob | halloween coming early for you louipc? |
| 19:16.39 | louipc | they don't only come out on halloween |
| 20:19.05 | *** join/#brlcad elite01_ (n=elite01@dslb-088-070-021-212.pools.arcor-ip.net) | |
| 20:43.51 | *** join/#brlcad elite01_ (n=elite01@dslb-088-070-022-044.pools.arcor-ip.net) | |
| 20:47.01 | *** join/#brlcad elite01__ (n=elite01@dslb-088-070-008-095.pools.arcor-ip.net) | |
| 21:11.48 | *** join/#brlcad IriX64 (n=mariodot@bas2-sudbury98-1177871835.dsl.bell.ca) | |
| 21:34.18 | *** join/#brlcad yukonbob (n=yukonbob@CPE001125477e9c-CM0011e6be27b1.cpe.net.cable.rogers.com) | |
| 22:05.21 | starseeker | brlcad: Is the facetizer part of the converter? |
| 22:05.30 | brlcad | it's part of a lot of the converter |
| 22:05.41 | brlcad | it's what turns a given model into a set of polygons |
| 22:06.15 | brlcad | not so much heavy math as an utter slew of logic |
| 22:06.27 | starseeker | ah |
| 22:06.30 | brlcad | euler operations on meshes, dealing with floating point arithmetic |
| 22:06.49 | brlcad | tons of O(n^2) and O(n^3) algorithms |
| 22:06.58 | brlcad | some that are worse.. |
| 22:07.10 | brlcad | it's the nature of the problem, it's np-complete to start with |
| 22:07.29 | starseeker | Oh, OK - so it's not the "well, this one is easier to implement" effect? |
| 22:07.33 | brlcad | aside from the practicle aspects of dealing with floating point and modeling issues |
| 22:07.43 | brlcad | oh no, not at all |
| 22:08.12 | brlcad | it's actually not a bad approach, just exceptionally hard to implement well as you're already starting from a degraded state |
| 22:08.33 | starseeker | Are the major formats at least well documented, or is it kind of a CAD version of the MS Word effect? |
| 22:09.02 | brlcad | it's not really a format, it's the core "how do you deal with solid geometry in a mesh format" |
| 22:09.11 | starseeker | Oh, OK. |
| 22:09.25 | brlcad | at least, the "format" is just a "boundary representation" |
| 22:09.40 | brlcad | there are some choices there, whether it be something like brl-cad's n-manifold geometry |
| 22:09.48 | brlcad | or winged edge data structures, or others |
| 22:10.16 | brlcad | but the base problem is "give me a mesh of this object that is guaranteed to be solid geometry" .. and that turns out to being a pretty hard problem |
| 22:10.33 | starseeker | Oh, OK. |
| 22:10.37 | brlcad | especially with floating point math and "unclean" geometry that you always encounter |
| 22:11.43 | starseeker | Can you help by doing related/derivative dimensions? (I.e. "this length is always exactly 2x the length of this" - not sure what the technical term would be) |
| 22:13.35 | brlcad | there is some book-keeping you can do, but you very quickly/often end up with a situation where code-wise you don't really know the intent, so either case for A or B can be wrong |
| 22:14.03 | brlcad | that would be a dimensioning constraint |
| 22:14.33 | brlcad | you still are trying to make a mesh, and all you have to go with is a mess of polygon soup |
| 22:14.49 | brlcad | a closed mesh |
| 22:15.14 | starseeker | Hmm |
| 22:15.24 | starseeker | nasty |
| 22:15.30 | brlcad | most of content packages (e.g. blender) can get away with a lot of the mesh operations because they rarely ever have to ensure closure, just how it looks |
| 22:16.04 | starseeker | So as long as the imperfection there is "non-visual" on some scale, it doesn't matter? |
| 22:16.30 | brlcad | anyways, that's one of the reasons for wanting b-rep support at our primitive level, and b-rep csg operations |
| 22:16.41 | starseeker | right |
| 22:17.22 | brlcad | that would let us retain the topological structure all the way up to the point that the mesh itself is created, and can then be directly done given the already evaluated surfaces instead of evaluating csg on mesh after mesh |
| 22:18.34 | starseeker | Elegant. |
| 22:19.22 | starseeker | How disruptive is primitive b-rep support? |
| 22:19.36 | brlcad | disruptive? |
| 22:19.44 | brlcad | not at all |
| 22:19.50 | brlcad | just an entirely different paradigm :) |
| 22:20.02 | starseeker | So it can be added without disturbing too much of the existing code? |
| 22:20.03 | brlcad | some of the work is already complete, massive undertaking |
| 22:20.06 | brlcad | oh yeah |
| 22:20.08 | brlcad | easily |
| 22:20.13 | brlcad | some of it's already there |
| 22:20.15 | starseeker | Cool - that helps |
| 22:20.31 | brlcad | for maybe three or four of the primtiives, plus the entire brep/nurbs representation support is pretty much done |
| 22:20.49 | starseeker | cool! |
| 22:21.03 | brlcad | so have to add the rest of the primitives, then work on csg evaluation of brep on brep and work on fast brep tessellation |
| 22:21.28 | brlcad | those three pieces done, then we have clean facetization of any csg model as well as things like opengl shaded displays |
| 22:22.13 | starseeker | Nice! |
| 22:24.41 | starseeker | Naive question - the existence of brep at a primitive level - how does that make the core logic of model -> mesh simpler? Would it mean that models would have to be rebuilt with the new primitive or would the conversion of old primitives to brep be less expensive? |
| 22:25.55 | starseeker | IriX64: Dare we ask? |
| 22:26.07 | IriX64 | vista64 :) |
| 22:26.54 | IriX64 | heh i haven't tossed my cookies .... yet :) |
| 22:27.22 | starseeker | Sooo... does BRL-CAD work on it? ;-) |
| 22:27.40 | IriX64 | yes actually more to come on that :) |
| 22:28.43 | IriX64 | brlcad=busy man |
| 22:29.14 | starseeker | Heh - one dumb question too many I guess |
| 22:29.36 | IriX64 | no such thing as dumb question if i don't know the answer someone else does said somebody to me |
| 22:31.31 | starseeker | The thought skittered through my brain that the fundamental problem of converting shapes to meshes has to be solved somewhere - maybe std. primitive -> brep -> mesh is cleaner theoretically than std. primitive -> mesh? |
| 22:43.25 | yukonbob | starseeker: yesterday (?) I posted some diffs that might help you w/ running tcl/tk 8.4; (it was you that was interested in this, right? With ebuilds?) |
| 22:43.33 | louipc | hmm I don't know why I'd want to change a csg model to brep |
| 22:44.21 | IriX64 | http://www.irix32.spaces.live.com/photos/brlcaddoesvista64 and also /vista64 :) |
| 22:45.02 | starseeker | yukonbob: Not me per-say - Gentoo devs would probably like it, but I'm OK with using the internal one |
| 22:45.26 | IriX64 | well the brlcad albumn :) |
| 22:45.43 | louipc | starseeker: no ebuilds for tcl8.5a? |
| 22:46.29 | starseeker | louipc: They are but they are "masked" meaning they are unstable |
| 22:46.53 | starseeker | BRL-CAD isn't unstable, so I would prefer not to rely on an unstable ebuild when it is merged (IF it is merged... grumble...) |
| 22:47.23 | starseeker | yukonbob: I think I saw some of that - how extensive are the diffs? |
| 22:47.33 | louipc | I think they're only classified as unstable because it's alpha |
| 22:47.54 | starseeker | louipc: Right, but that doesn't change it unfortunately - we would need a stable 8.5 |
| 22:48.09 | louipc | unless you use tcl for other things I bet it's ok to install them seperately |
| 22:48.35 | starseeker | yukonbob: I already need to patch once for tcl, so patching to work with 8.4 actually isn't impossible |
| 22:48.36 | louipc | brl-cad is distributing the tcl8.5a though |
| 22:49.10 | starseeker | louipc: Right. That's my preference, but it seems to give some of the devs hives... |
| 22:49.21 | louipc | same as you get anywhere else |
| 22:49.32 | louipc | eg. in the 8.5a ebuild |
| 22:50.05 | louipc | you should try it though ;) |
| 22:50.07 | starseeker | Once we install into /opt all the nasty problems go away. To me that seems to be the obvious way to go - if we end up having to have a binary install it would go there anyway... |
| 22:50.22 | louipc | yeap opt helps |
| 22:50.36 | starseeker | yukonbob: Still here? |
| 22:50.46 | louipc | but there's no use having tcl installed twice hah |
| 22:50.53 | starseeker | That's their thinking |
| 22:51.04 | louipc | but there isn't... |
| 22:51.41 | starseeker | I suppose, but it's simpler to just have brlcad install exactly what it needs and we don't have to argue about the mask on tcl 8.5... |
| 22:51.44 | louipc | did it not work with 8.5a installed separately? |
| 22:51.49 | starseeker | probably it does |
| 22:51.58 | starseeker | I can try it |
| 22:52.30 | louipc | yeah I would |
| 22:52.58 | starseeker | hard drives are so cheap today the simpler solution appeals though |
| 22:53.40 | louipc | not to me, and probably a lot of other folks :P |
| 22:54.05 | starseeker | So I've noticed. |
| 22:54.22 | starseeker | All I need to do is install it, and the rest should follow. |
| 22:54.59 | starseeker | The ebuild actually doesn't specify one way or the other, so if you install tcl 8.5 it SHOULD work. |
| 22:55.49 | louipc | yeah true the config will pick it up |
| 22:56.41 | starseeker | Putting tcl and tk in the package.keywords file didn't bump the upgrades - they must be hard masked |
| 22:57.16 | starseeker | Yep - hard masked in /usr/portage/profiles/package.mask |
| 22:59.58 | yukonbob | louipc: re: unstable -- there still seems to be legitimate issues around 8.5 that would be "unstable"... which is why it's still beta (not alpha anymore)... but that said, it's got some new work under the hood that won't be proven stable until it's more widely deployed/tested... so in that case, basing a product (ie: brl-cad) on it is a bit risky... |
| 23:00.49 | starseeker | Generally I don't mess with something that is hard masked - it's a bit of a pain and oftentimes risky |
| 23:01.33 | louipc | yeah brl-cad already uses it though hehe |
| 23:02.02 | starseeker | yukonbob: Are the patches still online somewhere? Maybe including those patches will push brl-cad into the acceptable category |
| 23:04.19 | yukonbob | starseeker: I posted them in pastebin.bzflag.bz -- my build env is pkgsrc on netbsd, so w/i that framework (and setting up working dependencies, configs for the env), the mods I made swap-out 8.6 for tcl/tk for 8.4 (there is no tcl/tk 8.6), and I also completely remove itcl, itk, urt, and a few others where I can properly modularize the build and use itcl packages, urt packages, etc., etc. |
| 23:06.10 | louipc | yeah I have to make itcl, itk, etc packages |
| 23:06.37 | louipc | tcl extensions are kinda odd |
| 23:06.55 | yukonbob | louipc: that's the smart way to go -- that way you can manage it w/ your package tools... |
| 23:07.14 | louipc | (the way you're supposed to keep sources, build-stubs) |
| 23:07.15 | yukonbob | rather than having it as a non-defined "lump" that's part of a bigger install (brlcad). |
| 23:07.37 | louipc | yukonbob: yea it's ideal |
| 23:07.52 | louipc | even brlcad can be broken up into a few |
| 23:07.55 | yukonbob | http://pastebin.bzflag.bz/m2121d14e |
| 23:08.35 | yukonbob | <PROTECTED> |
| 23:08.47 | louipc | mged, librt, rt, conv, ... |
| 23:09.08 | yukonbob | http://pastebin.bzflag.bz/meb2598chttp://pastebin.bzflag.bz/meb2598c |
| 23:09.13 | yukonbob | http://pastebin.bzflag.bz/meb2598c |
| 23:10.05 | starseeker | yukonbob: Thanks! |
| 23:10.13 | yukonbob | (last one gets rid of bwish, which I don't use, and I'm experimenting w/ setting up a loadable lib for plain-jane tclsh/wish, rather than "another" wish client... |
| 23:10.16 | yukonbob | ) |
| 23:10.28 | yukonbob | starseeker: np -- hope you find something useful. |
| 23:15.59 | yukonbob | I use pkgs for libpng, urt (Utah Raster Toolkit), tcl, tk, incr tcl (itcl/itk), blt, and tkimg. configure is instructed to not build included copies, and I also disable jove, because I just use whatever my favourite already-installed editor is... |