| 00:23.47 | *** join/#brlcad IriX64 (n=IriX64@bas2-sudbury98-1178015440.dsl.bell.ca) | |
| 00:51.04 | *** join/#brlcad pacman87 (n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) | |
| 01:03.13 | ``Erik | heh, pheer ~{ ~} |
| 01:10.55 | Ralith | ? |
| 01:11.17 | Ralith | as in, the lisp format thingies? |
| 01:25.20 | ``Erik | yeah |
| 01:27.25 | Ralith | has been teaching himself lisp |
| 01:27.30 | Ralith | very fun stuff. |
| 01:28.14 | ``Erik | indeed |
| 01:28.20 | *** join/#brlcad pacman87 (n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) | |
| 01:57.18 | brlcad | howdy pacman87 |
| 01:57.42 | brlcad | ready to code yet? :) |
| 02:00.48 | *** join/#brlcad mike (n=mike@cadil21.kaist.ac.kr) | |
| 02:00.56 | Mike111 | hi all |
| 02:03.44 | brlcad | howdy Mike111 |
| 02:04.19 | Mike111 | hi brlcad; how are you? |
| 02:09.02 | Mike111 | I will have a non-brlcad model supplied (maybe as IGES or DXF). I want to change the model, that is, replace an original object (component in the model) with my own. How do I do that? |
| 02:09.16 | brlcad | i'm great, busy times but great |
| 02:09.26 | brlcad | can't wait to see how these renders turn out... |
| 02:09.50 | brlcad | Mike111: it totally depends on the supplied model and how it's structured |
| 02:10.55 | Mike111 | they model won't be a brl-cad format so there won't be a `tree' of combinations or primitives |
| 02:10.56 | brlcad | many imports come in as polygonal meshes, which suck to edit (in brl-cad) beyond affine transforms (translation/rotation/scale) and delete/duplicate/replace |
| 02:11.13 | brlcad | it may still be a collection of 'parts' |
| 02:11.34 | brlcad | if your editing intent is to replace a given part, you should be able to delete the part and replace it with your own |
| 02:12.37 | Mike111 | is there a way to automate this, if I need to do this repeatedly for the same model (try several different components) |
| 02:14.45 | ``Erik | you're asking if BRL-CAD can automatically remove regions and replace them with other (different) geometry? O.o |
| 02:15.36 | Mike111 | if I can script this operation, that is, define which part I want to remove, remove it and then attach the new part |
| 02:15.38 | brlcad | if what you're doing is identically repetitive or repetitive in some prescribed pattern, sure it could be automated |
| 02:15.51 | brlcad | heavily scriptable system |
| 02:15.59 | brlcad | pick your poison/language |
| 02:16.15 | brlcad | tcl inside mged, anything outside |
| 02:16.27 | ``Erik | plus the clone and pattern tools |
| 02:16.53 | brlcad | example scripting here: http://brlcad.org/wiki/SGI_Cube |
| 02:17.00 | Mike111 | so far I've written script which I just piped in mged (a series of mged commands) |
| 02:17.25 | Mike111 | the SGI example is good. clear to follow. |
| 02:17.51 | Mike111 | Erik: what are those? |
| 02:18.19 | ``Erik | commands inside of mged |
| 02:20.17 | brlcad | Mike111: lots of commands categorized and listed in: http://brlcad.org/w/images/5/52/MGED_Quick_Reference_Card.pdf |
| 02:20.30 | brlcad | as well as the appendix of the MGED Tutorial |
| 02:21.54 | Mike111 | Thanks. |
| 02:22.31 | Mike111 | still not clear to me how exactly do I select a part of a DXF or IGES model. |
| 02:24.14 | ``Erik | depends on how it converts |
| 02:24.40 | Mike111 | brl-cad can import these formats directly, right? |
| 02:25.14 | brlcad | yes, there's dxf-g and iges-g |
| 02:25.31 | brlcad | if they have multiple objects, they will import as multiple objects |
| 02:25.38 | brlcad | give it a try, see what it does :) |
| 02:26.31 | Mike111 | once I loaded a DXF or IGES model, how do I check its `tree'? with `ls'? |
| 02:27.33 | ``Erik | sure, or fire up the geometry viewer |
| 02:27.49 | brlcad | tops, l, ls *, tree, ... |
| 02:28.08 | brlcad | lots of ways -- Tools -> Geometry Browser will show you graphically |
| 02:29.14 | *** join/#brlcad feuerret (n=841900d2@bz.bzflag.bz) | |
| 02:30.41 | Mike111 | do you know a good GPL meshing program? |
| 02:31.05 | starseeker | you mean mesh editing or mesh conversion? |
| 02:32.45 | Mike111 | I mean meshing a model (not conversion), that is, taking a 3d model and creating a mesh (say unstructured) on the skin |
| 02:33.25 | Mike111 | Other applications (such as structural analysis) need a mesh to analyze a model |
| 02:33.28 | starseeker | um. it depends on what input data you're starting with. point cloud? CSG model? nurbs surface? |
| 02:34.42 | Mike111 | I will have a CSG model which I generate in brl-cad. |
| 02:35.14 | ``Erik | g-stl ? |
| 02:35.24 | Mike111 | Later on, I may have a model which is imported (DXF or IGES) plus a component made in brl-cad |
| 02:35.45 | Mike111 | Erik: you mean exporting the brl-cad model into stl? |
| 02:36.29 | brlcad | many of our exporters mesh on output |
| 02:36.36 | brlcad | g-dxf, g-stl, g-obj, g-nff, g-x3d, etc |
| 02:36.41 | ``Erik | plus there's an mged command called "facetize" which converts the named region to a triangle version |
| 02:37.05 | brlcad | those formats don't support CSG or implicit geometry, so we have to convert to their representation |
| 02:39.23 | brlcad | if you really want to get fancy for FEA purposes, the recommended approach would probably be to buy a Cubit license ($300 for 5-years) and use our g-sat converter which hooks to Cubit |
| 02:39.33 | brlcad | their meshing facilities are some of the best for FEA |
| 02:40.25 | brlcad | as for free, there's not really a lot of good meshers for FEA purposes that are open source, at least not that preserve solidity |
| 02:54.59 | Mike111 | the lab here used a mesh generator running on CentOS linux. |
| 02:55.16 | *** join/#brlcad Feuerret (n=841900d2@bz.bzflag.bz) | |
| 02:55.30 | Mike111 | as I understand, it needs an IGES file which `only describes the skin' (outer surface of the model) |
| 02:55.37 | Mike111 | that's what the lab users just told me |
| 02:56.58 | brlcad | yeah, iges supports a wide variety of geometry including skin-only models |
| 02:57.25 | brlcad | we call them "plate-mode bots", and such an iges should import as such iirc |
| 02:57.31 | Mike111 | can I directly export the model as `skin-only' from brl-cad or one its exporters? |
| 02:57.42 | brlcad | "bots" == "bag of triangles" |
| 02:58.07 | brlcad | we only export skin-only if it imported as skin-only |
| 02:58.41 | Mike111 | what is I create the model in brl-cad from scratch? |
| 02:58.57 | brlcad | those are solid models |
| 03:00.11 | Mike111 | so they cannot be exported as `skin-only'? |
| 03:00.32 | brlcad | a solid model that is tessellated to a bot is trivial to convert to a plate-mode bot |
| 03:00.59 | brlcad | I'm not sure I believe that you actually need skin models though, *especially* if it's for a mesher designed for FEA |
| 03:01.19 | brlcad | a general content mesher, sure |
| 03:01.26 | brlcad | but not one for analytic purposes |
| 03:01.58 | brlcad | I'd bet your lab is abusing some non-analytic mesher tool (simply because it was free and did the job) |
| 03:02.41 | brlcad | hm, looks like our iges exporter will not export plate-mode bots |
| 03:04.40 | Mike111 | what about the option you mentioned on tesselating a bot and converting it to a plate-mode bot? |
| 03:12.43 | brlcad | that's possible but it wouldn't do anything useful for you |
| 03:12.56 | brlcad | before guessing, you probably should just take a very simple test case and see how it works |
| 03:13.03 | brlcad | make a sphere |
| 03:13.11 | brlcad | export that sphere as dxf, iges, and stl |
| 03:13.25 | brlcad | see how each import into that mesh tool |
| 03:13.49 | brlcad | then try importing something, export it as dxf, iges, and stl .. see how it imports into the mesher |
| 03:14.23 | brlcad | that will answer way more questions than speculating on what is possible, our terminology, their terminology, your understanding, etc ;) |
| 03:23.43 | Mike111 | OK, I'll give it a try and take it from there. |
| 03:24.39 | brlcad | cool, please update on how it goes! |
| 03:25.41 | CIA-28 | BRL-CAD: 03brlcad * r34665 10/brlcad/trunk/ (BUGS TODO): the shaders.sh regression test case is failing due to a change in view initialization. needs to be fixed. |
| 03:26.01 | Mike111 | The Lighting tutorial is clear. Howeverm, now the link is missing from the brlcad wiki page. |
| 03:28.07 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:77.120.80.206]] with an expiry time of infinite (anonymous users only, account creation disabled): Spamming links to external sites |
| 03:28.21 | CIA-28 | BRL-CAD: 03Sean 07http://brlcad.org * r1461 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/77.120.80.206|77.120.80.206]] ([[User talk:77.120.80.206|Talk]]); changed back to last version by [[User:98.218.53.50|98.218.53.50]] |
| 03:28.27 | brlcad | fixed |
| 03:28.49 | brlcad | it's a wiki .. you can fix it if it happens again ;) |
| 03:28.59 | brlcad | just select History, see what happened |
| 03:29.14 | Mike111 | sure, thanks for the info. |
| 03:29.37 | brlcad | if you compare a revision to the previous, it'll show the changed lines. you can see in that one that someone spammed a link this morning |
| 03:30.31 | Mike111 | nasty |
| 03:31.11 | brlcad | happens |
| 03:31.17 | Mike111 | how do I place light sources in specific locations, such as in the tutorial? |
| 03:31.19 | brlcad | it's trivial to revert |
| 03:31.31 | brlcad | you create geometry, put it where you want |
| 03:31.52 | brlcad | e.g., there I created little spheres |
| 03:32.18 | brlcad | you put them in a region and mark the shader as a 'light' |
| 03:32.39 | Mike111 | so if a primitive has only the `Light' shader enable they essentially act only as light sources? |
| 03:33.06 | Mike111 | so if a primitive has only the `Light' shader enable it essentially acts only as a light source? |
| 03:33.07 | brlcad | 'only' as light sources? |
| 03:33.50 | brlcad | when you apply the light shader, it's considered a light, which means it illuminates the scene |
| 03:33.56 | brlcad | creating a light disables the default lights |
| 03:34.14 | brlcad | rather, rendering a scene with a light in it disables the defaults |
| 03:34.25 | brlcad | not just creating it, have to have it in your scene ;) |
| 03:34.35 | Mike111 | that's the -A0 setting? |
| 03:34.46 | brlcad | no, that's the ambient energy in the scene |
| 03:35.48 | brlcad | that page isn't meant to explain everything about lighting -- there's too much to cover for that short space -- it's meant to explain lighting _after_ you already understand how to create a light :) |
| 03:36.06 | brlcad | the tutorial series covers lighting iirc |
| 03:36.22 | Mike111 | you mean volume II? |
| 03:36.24 | brlcad | but basically you create geometry, apply light shader, then render |
| 03:36.50 | brlcad | II or III -- that's the series |
| 03:41.11 | Mike111 | Vol. II, p.124:"The light shader is technically complex and not discussed in this tutorial". :( |
| 03:41.11 | brlcad | make sph sph ; r light.r u sph ; mater light.r light 255 0 0 0 |
| 03:41.23 | brlcad | that will make a red spherical light |
| 03:41.34 | brlcad | so maybe it was III |
| 03:42.46 | brlcad | or not.. |
| 03:42.57 | Mike111 | I'll check later in detail. |
| 03:43.01 | brlcad | don't see a light ref |
| 03:44.45 | brlcad | http://brlcad.org/ugm2002/ShadingObjects.pdf covers it a little bit |
| 03:45.20 | brlcad | but if you run that line I gave you and then edit the object with the combination editor (then select 'shader'), you'll see the options |
| 03:45.53 | Mike111 | I was looking at these options yesterday, after reading the lighting tutorial |
| 03:47.59 | Mike111 | can you clarify what are the `fraction' and `lumens'? settings for intensity? |
| 03:55.32 | *** join/#brlcad cad21 (n=841900d2@bz.bzflag.bz) | |
| 03:55.55 | *** join/#brlcad Feuerret (n=841900d2@bz.bzflag.bz) | |
| 03:56.51 | *** join/#brlcad Feuerret (n=841900d2@bz.bzflag.bz) | |
| 03:57.11 | brlcad | ignore lumens |
| 03:57.23 | brlcad | fraction is the % contribution to the scene |
| 03:57.41 | brlcad | so if you have just one light, it contributes 100% |
| 03:57.51 | brlcad | you can make it twice as bright by making it 200% |
| 03:58.06 | *** join/#brlcad Ralith_ (n=ralith@216.162.199.202) | |
| 03:58.30 | Mike111 | so it's basically the intensity? |
| 03:58.41 | brlcad | if you have two lights with fractions 1 and 1, they'll both be contributing 100% respectively (resulting in the same 'intensity' as one light at 200%) |
| 03:58.54 | brlcad | basically, but it's balanced among all lights in your scene |
| 03:59.40 | *** join/#brlcad Feuerret (n=841900cf@bz.bzflag.bz) | |
| 03:59.40 | Mike111 | ok. what are `angle' and `target'? |
| 04:01.16 | *** join/#brlcad Feuerret2 (n=841900cf@bz.bzflag.bz) | |
| 04:01.19 | brlcad | angle is the direction the light faces |
| 04:01.27 | brlcad | er, sorry, target |
| 04:01.38 | brlcad | target is the direction |
| 04:02.05 | brlcad | angle is the angle of the light cone -- default is 180 degrees |
| 04:02.15 | brlcad | 20 degrees would make a sort of "spotlight" |
| 04:02.35 | brlcad | .1 degree would be like a laser |
| 04:02.49 | brlcad | 5 degrees like a flashlight, etc |
| 04:03.00 | Mike111 | you mean how much the light is `spread'? |
| 04:03.03 | brlcad | right |
| 04:03.37 | brlcad | they're directional by default, not omnidirectional |
| 04:03.55 | Mike111 | would 360 give an omnidirectional source? |
| 04:04.06 | brlcad | you know, I don't remember :) |
| 04:04.49 | Mike111 | 180 means the source only emits towards the `bottom'? |
| 04:05.39 | Mike111 | so that's why you need a target? to specify a direction vector around which the light `spreads'? |
| 04:12.15 | Mike111 | brlcad: sorry but I need to go now. I'm logging the chat so if you reply I'll view that later. Cheers |
| 04:14.21 | brlcad | right |
| 04:14.30 | brlcad | that's direction and the spread/angle |
| 04:39.08 | *** join/#brlcad pacman87 (n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) | |
| 04:48.02 | *** join/#brlcad pacman87 (n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) | |
| 04:48.09 | CIA-28 | BRL-CAD: 03173.57.41.37 07http://brlcad.org * r1462 10/wiki/User:Pacman87: /* About me */ |
| 04:49.45 | CIA-28 | BRL-CAD: 03173.57.41.37 07http://brlcad.org * r1463 10/wiki/User:Pacman87: /* About me */ |
| 04:54.43 | CIA-28 | BRL-CAD: 03indianlarry * r34666 10/brlcad/trunk/ (include/opennurbs_ext.h src/librt/primitives/brep/brep.cpp): |
| 04:54.43 | CIA-28 | BRL-CAD: linear approximation a lot closer, now need to get the final newton |
| 04:54.44 | CIA-28 | BRL-CAD: step working on the trims. I do see some artifacts from the tangent sign |
| 04:54.44 | CIA-28 | BRL-CAD: change in the UV horizontal(v) but as discussed that should be an easy fix, |
| 04:54.44 | CIA-28 | BRL-CAD: The hit checks (odd/even) are back on so you may see some background specks |
| 04:54.45 | CIA-28 | BRL-CAD: around edges - this seems to have cleaned up some of the odd looking behavior |
| 04:54.47 | CIA-28 | BRL-CAD: in the images BRLCAD generated (but didn't check all models) |
| 05:02.47 | *** join/#brlcad pacman87 (n=pacman87@pool-173-57-41-37.dllstx.fios.verizon.net) | |
| 07:27.01 | *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) | |
| 07:59.23 | *** join/#brlcad mafm (n=mafm@126.Red-83-45-252.dynamicIP.rima-tde.net) | |
| 09:04.50 | brlcad | indianlarry: up late eh? :) |
| 09:22.39 | Ralith | aren't we all? |
| 09:25.24 | *** join/#brlcad mafm_ (n=mafm@126.Red-83-45-252.dynamicIP.rima-tde.net) | |
| 09:33.51 | Axman6 | brlcad: do/have you done any Ada programming? (i feel i've asked you this before, so sorry if i have) |
| 10:07.19 | *** join/#brlcad _clock_ (n=_sushi_@84-72-91-14.dclient.hispeed.ch) | |
| 10:21.32 | Ralith | sleeps |
| 11:32.25 | d-lo | Mernin all! |
| 11:34.37 | *** join/#brlcad d_rossberg (n=rossberg@66.111.56.50) | |
| 11:50.30 | starseeker | indianlarry: awesome! |
| 11:51.48 | starseeker | thank you! |
| 11:53.43 | *** join/#brlcad BigAToo (n=BigAToo@nmd.sbx10200.goshein.wayport.net) | |
| 12:18.49 | starseeker | scowls at jove - where did "jove.h:431: error: conflicting types 'getline'" come from? |
| 12:39.51 | starseeker | hmm - some sort of getline definition in stdio.h... ugh |
| 13:01.01 | starseeker | disables jove building and moves on with life |
| 13:02.32 | ``Erik | svn rm ftw O.o |
| 13:04.09 | starseeker | blinks at the number of format argument complaints he's getting |
| 13:04.30 | starseeker | serves me right for updating my system - now I'll bet my gcc/automake combo is too new to work again... |
| 13:06.33 | ``Erik | eh? |
| 13:07.06 | starseeker | runs gentoo unstable, so I tend to be uncomfortable close to the "cutting edge" of gcc/autotools versions |
| 13:07.24 | ``Erik | has a feeling that the actual problem is a more strict automake and an inferior package management system that did not update all the packages that installed (now old style) m4 files? :D |
| 13:07.54 | starseeker | eh, possibly |
| 13:08.07 | starseeker | not sure how to spot that |
| 13:08.12 | ``Erik | lots of "underquoted" issues? |
| 13:08.35 | starseeker | no, more complaints about "expects unsigned int, but given long int" or some such |
| 13:08.45 | ``Erik | ohhh, type issues, n/m :) |
| 13:09.23 | ``Erik | what are your -W flags? |
| 13:09.32 | starseeker | should be default |
| 13:09.49 | ``Erik | doesn't remember default O:-) |
| 13:10.22 | starseeker | <PROTECTED> |
| 13:11.05 | starseeker | yeah, not sure |
| 13:11.18 | starseeker | isn't too concerned right now - more important that install works |
| 13:11.34 | starseeker | (me neeeeeds moooore cooores......) |
| 13:11.46 | starseeker | 40 minute builds suck |
| 13:12.17 | starseeker | guesses when Qt/Ogre installs become part of the game the time will have come to upgrade this sucker |
| 13:12.48 | _clock_ | Qt a part of brlcad install? |
| 13:13.00 | starseeker | not yet |
| 13:13.06 | starseeker | we might never put it in |
| 13:13.30 | starseeker | but Ralith is exploring combining the Qt toolkit with Ogre |
| 13:18.14 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-65.sbndin.btas.verizon.net) | |
| 13:18.19 | starseeker | hmm: http://www.newegg.com/Product/Product.aspx?Item=N82E16883107970 |
| 13:28.15 | starseeker | what on earth: /usr/bin/install: will not overwrite just-created `/usr/brlcad/share/man/man3/librle.3' with `../../../../brlcad/src/other/libutahrle/librle.3' |
| 13:29.45 | starseeker | sees duplicate entry in Makefile... how did it get there... |
| 13:33.21 | CIA-28 | BRL-CAD: 03starseeker * r34667 10/brlcad/trunk/src/other/libutahrle/Makefile.am: Remove duplicate entry for librle.3 |
| 13:36.03 | CIA-28 | BRL-CAD: 03starseeker * r34668 10/brlcad/trunk/src/adrt/libtienet/Makefile.am: Remove duplicate tienet_util.h entry |
| 13:39.24 | *** join/#brlcad SWPadnos (n=Me@dsl107.esjtvtli.sover.net) | |
| 13:39.51 | ``Erik | ponders the breakage in opennurbs |
| 13:40.08 | ``Erik | src/other/openNURBS/opennurbs_system.h:150: error: expected identifier or '(' before '/' token |
| 13:40.12 | ``Erik | line #'s must be off |
| 13:40.55 | CIA-28 | BRL-CAD: 03starseeker * r34669 10/brlcad/trunk/src/tclscripts/archer/images/Themes/Windows/Makefile.am: Remove duplicate entry for pane_collapse.png |
| 13:41.20 | starseeker | blinks |
| 13:42.44 | starseeker | ``Erik: where are you seeing that? |
| 13:42.52 | ``Erik | amd64 fbsd7 |
| 13:42.53 | starseeker | what OS I mean |
| 13:42.55 | starseeker | ah |
| 13:43.24 | ``Erik | knew what ya meant :D |
| 13:44.24 | starseeker | gets the latest nurbs raytrace of shape1.s - swwwweeeeet |
| 13:45.08 | starseeker | ok, so that was it - my toolset is suddenly picky about duplicate file listings in Makefile.am |
| 13:45.13 | starseeker | <snort> |
| 13:45.20 | starseeker | oh, well - legit errors I suppose |
| 13:45.32 | starseeker | alrightie, I'm on the road |
| 13:46.44 | d_rossberg | ``Erik: // => /* */ |
| 13:46.54 | ``Erik | yes, compiling with that |
| 13:47.08 | ``Erik | wanted the compile to finish before I commited :) |
| 13:47.57 | ``Erik | there're more of those, I'll wait until I get them all and commit 'em all at once |
| 13:48.10 | d_rossberg | isn't // already legal in C code? |
| 13:49.34 | ``Erik | it's c99 |
| 13:50.26 | ``Erik | I'm compiling with "-W -Wall -ansi -pedantic" because I'm nuts |
| 13:54.03 | ``Erik | meh, screw it, we'll just say c99 is required for opennurbs :D |
| 13:54.49 | d_rossberg | opennurbs is C++ :P |
| 13:54.59 | ``Erik | it's mostly c++, there're 2 C files in it |
| 13:55.27 | ``Erik | which is how I'm tripping that issue :) |
| 14:33.24 | CIA-28 | BRL-CAD: 03indianlarry * r34670 10/brlcad/trunk/include/opennurbs_ext.h: |
| 14:33.24 | CIA-28 | BRL-CAD: added initial curve approximation to trims, still some fuzz, haven't optimized |
| 14:33.24 | CIA-28 | BRL-CAD: merely replaced linear check for now i'm sure its slower |
| 15:29.00 | CIA-28 | BRL-CAD: 03starseeker * r34671 10/brlcad/trunk/include/opennurbs_ext.h: pass in the full uv point in the curve iteration function (not sure I'll need it but if I do this will minimize the effort to swap out different curve solver attempts) - no functionality change |
| 15:37.24 | indianlarry | starseeker: probably should have passed it in for good measure, could also use to stop iteration is v falls out of closeness (is that a word?) |
| 15:37.49 | starseeker | not sure :-) |
| 15:38.15 | starseeker | was just going to take another stab at writing a newton iterator, looks like it needs both but I'm not totally sure |
| 15:38.55 | starseeker | probably need the test of within the triangle defined by the normals and the line segment between the two end points too |
| 15:38.59 | starseeker | (ick) |
| 15:39.16 | indianlarry | sounds good i'm looking at getting rid of the horz v problem and checking a couple saw tooths |
| 15:39.40 | starseeker | cooool |
| 15:39.49 | starseeker | (lunch, back in a bit) |
| 15:40.08 | indianlarry | okay |
| 15:40.33 | indianlarry | (cigar break) |
| 16:07.14 | *** join/#brlcad madant (n=d@117.196.129.146) | |
| 16:08.06 | madant | is finally all set (sort of) .. sleepless nights here i come |
| 16:40.09 | *** join/#brlcad samrose (n=samrose@c-24-11-214-181.hsd1.mi.comcast.net) | |
| 17:04.24 | starseeker | is back |
| 17:07.32 | ``Erik | sticks his finger up his nose |
| 18:10.14 | ``Erik | heh http://www.newtechusa.com/PPI/pressroom.asp#higher |
| 18:12.00 | *** join/#brlcad hippieindamakin8 (n=hippiein@202.3.77.38) | |
| 18:17.57 | CIA-28 | BRL-CAD: 03starseeker * r34672 10/brlcad/trunk/include/opennurbs_ext.h: Add an attempt at a Newton iteration solver. Still waaay too many hard coded values chosen arbitrarily - doesn't seem to be better than Keith's initial curve approx. |
| 18:32.54 | starseeker | indianlarry: is this the kind of effect you're seeing? http://bzflag.bz/~starseeker/edge_oddness.png |
| 18:34.05 | starseeker | I'm nirting through those cracks, and I'm not seeing any failed to converge errors... not sure what to make of it |
| 18:38.07 | starseeker | fwiw, a specific example is Origin (x y z) = (28.64 19.53 23.17), Direction (x y z) = (-0.7424 -0.5198 -0.4226) |
| 18:51.31 | starseeker | that ALMOST looks like a sawtooth behavior - it doesn't seem to be a newton convergence issue, although I could be wrong. |
| 19:06.16 | indianlarry | starseeker: i found the saw tooths, looks to be my error tolerences on the bulk BBoxes |
| 19:06.52 | starseeker | nice work! |
| 19:07.58 | indianlarry | starseeker: won't need to set error so high if i get the BBoxes breaking on the Horz/Vert peaks |
| 19:08.07 | starseeker | nods |
| 19:08.28 | indianlarry | would make curve lie on inside of BBox |
| 19:10.44 | starseeker | how did you want to do that? Newton converge to find the max within the bounding box? |
| 19:10.52 | indianlarry | for sure |
| 19:12.22 | starseeker | ponders how to approach that... |
| 19:16.34 | indianlarry | not sure but at least 2d problem and brute forcing an iterative approach is doable especially in prep stage |
| 19:16.56 | indianlarry | starseeker: sorry having connection problems |
| 19:17.32 | indianlarry | starseeker: wow, now that's a saw tooth you posted |
| 19:17.50 | indianlarry | starseeker: bur yes that's what i was seeing as well |
| 19:17.51 | starseeker | that's a zoomed in sawtooth ;-) |
| 19:17.59 | starseeker | having connection problems too |
| 19:18.30 | indianlarry | starseeker: in most places things seem pretty tight |
| 19:18.43 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-65.sbndin.btas.verizon.net) | |
| 19:18.44 | starseeker | indianlarry: what about checking the tangent vectors at the start and end points? even if it is a special case, it might help |
| 19:19.18 | indianlarry | starseeker: definitely, will start there |
| 19:19.45 | indianlarry | starseeker: did brlcad try and raytrace that phone again? |
| 19:20.03 | starseeker | don't think so - let me see if I can take a stab at it |
| 19:20.21 | ``Erik | shouldn't you be enjoying scotch and a cigar instead of wanking around on irc? O.o :D *duck* |
| 19:21.10 | indianlarry | ``Erik: something sensual about working in the raw and nobody knowing... oops |
| 19:21.31 | ``Erik | wait, no one knowing? |
| 19:21.35 | ``Erik | looks for his pants O:-) |
| 19:22.55 | indianlarry | puts scitch back in cabinet |
| 19:23.11 | indianlarry | then puts scotch back in cabinet |
| 19:23.27 | starseeker | that how you can tell you've had enough? ;-) |
| 19:23.52 | indianlarry | almost ;^{o>>>>>>>>>>>>> |
| 19:25.56 | ``Erik | no, 'i' and 'o' are right next to eachother, that's the beginning of the buzz |
| 19:26.11 | ``Erik | when he spells it "astjopch", ... |
| 19:26.40 | starseeker | actually doesn't see which one is the phone... |
| 19:27.02 | indianlarry | starseeker: didn'y see it either |
| 19:27.21 | indianlarry | it is a laptop keyboard |
| 19:28.05 | brlcad | indianlarry: haha |
| 19:29.09 | CIA-28 | BRL-CAD: 03bob1961 * r34673 10/brlcad/trunk/src/ (34 files in 3 dirs): Added the p/parameter command to Archer. |
| 19:29.28 | indianlarry | brlcad: where's the phone/pda dot.g |
| 19:29.42 | brlcad | looks |
| 19:30.46 | CIA-28 | BRL-CAD: 03erikgreenwald * r34674 10/brlcad/trunk/src/adrt/libtie/ (tie.c tie_kdtree.c): Irrelevant type signing fixes. Remove unused parameters. |
| 19:35.56 | brlcad | indianlarry: hm, hm.. some good and bad news :) |
| 19:36.09 | brlcad | somethings are rendering better, some not at all any more :) |
| 19:36.18 | brlcad | it's the HTC-Magician |
| 19:36.44 | brlcad | ...which looks like wasn't uploaded! |
| 19:37.02 | starseeker | thought so |
| 19:37.34 | brlcad | going up now |
| 19:37.47 | starseeker | brlcad: is that piston.g file THE piston? |
| 19:38.03 | brlcad | nope |
| 19:38.06 | starseeker | didn't think so |
| 19:38.32 | brlcad | that was before I found it, hunted for and checked a bunch of other pistons |
| 19:38.40 | starseeker | ah |
| 19:39.05 | brlcad | huh |
| 19:39.11 | brlcad | actually the phone did upload |
| 19:39.19 | brlcad | just not showing in the listing for some reason |
| 19:39.24 | brlcad | ah, permissions |
| 19:39.34 | indianlarry | brlcad: hopefully it's an odd hit issue, noticed some elements (Pumkin text) were just single surfaces not solid |
| 19:40.41 | brlcad | indianlarry: it lists now |
| 19:40.55 | indianlarry | brlcad: thanks |
| 19:41.14 | brlcad | indianlarry: yeah, the single surfaces weren't solid so that makes sense though rendering them as a thin surface was useful/interesting |
| 19:41.27 | CIA-28 | BRL-CAD: 03erikgreenwald * r34675 10/brlcad/trunk/src/adrt/ (libtienet/load.c libtienet/load.h slave/slave.c): revert back to magic void* for now |
| 19:41.27 | brlcad | implicit plate-mode |
| 19:41.54 | starseeker | brlcad: some of the geometry in this phone is failing isValid |
| 19:42.08 | indianlarry | brlcad: just uncomment "//#define KODDHIT" in brep.cpp |
| 19:42.52 | brlcad | starseeker: I know, that's some of them |
| 19:43.15 | brlcad | indianlarry: k |
| 19:44.38 | CIA-28 | BRL-CAD: 03erikgreenwald * r34676 10/brlcad/trunk/src/libpkg/tpkg.c: I don't think ports > 65535 make much sense... |
| 19:50.00 | CIA-28 | BRL-CAD: 03erikgreenwald * r34677 10/brlcad/trunk/src/adrt/ (16 files in 7 dirs): eliminate trailing whitespace |
| 19:50.45 | starseeker | brlcad: I take it this sucker was valid geometry in Rhino? |
| 19:51.02 | brlcad | starseeker: don't know, found model |
| 19:51.14 | starseeker | ah |
| 19:51.32 | brlcad | I'd be surprised, though -- it wasn't a hobby job |
| 19:55.14 | brlcad | it's interesting to note that the iges one renders semi better with the old nurbs code |
| 19:55.21 | brlcad | sans trims |
| 20:02.11 | starseeker | brlcad: I'm wondering about our 3dm importer - this phone geometry doesn't look so hot |
| 20:02.25 | brlcad | no doubt it needs work |
| 20:02.36 | brlcad | half the examples I found failed outright or aborted mid-stream |
| 20:02.44 | brlcad | that's why I left both |
| 20:02.57 | starseeker | loaded it into Rhino and exported again - still bad geometry |
| 20:03.06 | brlcad | displays in rhino? |
| 20:03.12 | starseeker | yes |
| 20:03.52 | brlcad | so something to trace, could be that IsValid() is wrong or being used as a check incorrectly/unnecessarily |
| 20:04.13 | brlcad | didn't investigate exactly the validity it's complaining about |
| 20:04.45 | starseeker | we're sure this phone is supposed to be solid and not just a surface model? |
| 20:05.14 | brlcad | eh |
| 20:05.18 | brlcad | that was never claimed |
| 20:08.10 | brlcad | don't tell me you're just thinking of that? :) i'll say it again, those are a set of fairly *random* 3dm files. they are a random sampling of real models found around the net, obviously provoking a random set of issues across the board (import, validation, rendering, etc) |
| 20:08.45 | starseeker | well, we've been focused on correct trimming |
| 20:08.55 | starseeker | one thing at a time |
| 20:09.04 | brlcad | of course |
| 20:09.48 | brlcad | what did you expect though? |
| 20:10.08 | starseeker | thought you would reject anything not claiming to be solid ;-) |
| 20:11.34 | brlcad | well the original intent was hunting for the piston model, as I remembered it was readily available somewhere |
| 20:11.51 | brlcad | so it was more a matter of find 3dm, see what happens |
| 20:11.54 | starseeker | ah |
| 20:11.58 | starseeker | got it |
| 20:12.00 | brlcad | still a good measure of where things are at overall |
| 20:12.25 | brlcad | as those should all be well-*behaved* regardless of their structure |
| 20:13.04 | brlcad | not saying that's the priority now, or the focus, or something to worry about right now even -- that was never the intention |
| 20:14.47 | starseeker | OK :-) |
| 20:15.12 | starseeker | we (or I anyway) thought they were examples of wacked trimming behavior |
| 20:15.25 | brlcad | they very well could be |
| 20:15.32 | brlcad | some of them were clearly trimming poorly |
| 20:17.41 | starseeker | hmm: http://www.mh-aerotools.de/airfoils/cox_cad_models.htm |
| 20:19.06 | brlcad | those are pretty cool |
| 20:20.51 | brlcad | anyways, just gotta multitask the info from earlier, not to disregard/ignore but not to focus on to the point of ignoring the big picture -- just some more test cases that should be investigated (for variety of purposes) |
| 20:21.44 | brlcad | they're found models -- some of the best ways towards making the tools robust and well-behaved, e.g. has me looking through the 3dm importer to see why (most)/many failed |
| 20:22.07 | starseeker | nods |
| 20:22.23 | brlcad | as I did pretty much exactly what a user would have |
| 20:22.38 | brlcad | stashes those new 3dm's in and tests |
| 20:23.10 | CIA-28 | BRL-CAD: 03erikgreenwald * r34678 10/brlcad/trunk/src/adrt/Makefile.am: update dependancy information. |
| 20:24.20 | starseeker | that PeeWee piston is a monster |
| 20:24.25 | starseeker | 300 regions |
| 20:24.40 | starseeker | adjusts drawing routine to have a hope of eing it up |
| 20:26.02 | brlcad | awesome, black widow isn't 'too' shabby |
| 20:26.35 | brlcad | massive convergence failure reporting |
| 20:26.52 | starseeker | er, yeah - sorry about that |
| 20:26.57 | starseeker | debugging output |
| 20:27.14 | brlcad | takes a pic |
| 20:28.02 | starseeker | it very probably shouldn't be attempting to converge in most of those cases - the limit that restricts the newton converence to a domain where it "should" work is stupid simple right now |
| 20:29.17 | brlcad | http://brlcad.org/tmp/nurbs5.png |
| 20:29.47 | brlcad | that top cap is pretty interesting |
| 20:29.48 | starseeker | hah - not too bad |
| 20:30.04 | brlcad | probably just an even/odd count problem |
| 20:31.52 | brlcad | i'm really happy to see the db encoding isn't a problem |
| 20:32.23 | starseeker | how long did it take it to draw that wireframe? |
| 20:32.53 | brlcad | breaking up the 3dm into per-object objects is minimal overhead, maybe 10% |
| 20:32.56 | starseeker | 's wireframe draw was a lot slower than the raytrace - some work to do there |
| 20:32.59 | brlcad | wireframe was instant |
| 20:33.07 | starseeker | huh - odd |
| 20:33.16 | starseeker | can you do me a favor and try the PeeWee model? |
| 20:33.25 | brlcad | gettin' there |
| 20:33.27 | brlcad | going down the list |
| 20:33.47 | starseeker | ah :-) |
| 20:34.39 | brlcad | oof, Cox Olympic aborts rt :) |
| 20:35.03 | brlcad | opennurbs_curve.cpp:3172: failed assertion `false' |
| 20:35.22 | brlcad | seemed to import clean at least |
| 20:36.45 | brlcad | ah, same on Cylinder 020 |
| 20:39.17 | brlcad | peewee wireframe is also instant |
| 20:39.29 | brlcad | maybe you have your surface plotter enabled |
| 20:41.17 | brlcad | peewee crashes (not via assertion) |
| 20:41.44 | brlcad | ah, wait, there is an assertion .. just delayed logging |
| 20:43.22 | brlcad | oh, shoot.. wrong mged -- screw those last results |
| 20:44.54 | CIA-28 | BRL-CAD: 03bob1961 * r34679 10/brlcad/trunk/src/tclscripts/archer/ArcherCore.tcl: Bringing up the menu shouldn't toggle (i.e. expand/collapse) the tree. |
| 20:51.20 | brlcad | http://brlcad.org/tmp/nurbs6.png <- cox olympic |
| 20:52.00 | brlcad | http://brlcad.org/tmp/nurbs7.png <- cylinder 020 (ouch) |
| 20:54.30 | indianlarry | looks to be an GetNextDiscontinuity in the ON_Curve that will walk down and give discontinuities for derivative,tangent and curvature |
| 20:54.42 | indianlarry | could it be that easy |
| 20:54.44 | brlcad | peewee wireframe does suck now |
| 20:55.01 | starseeker | yeah, was afraid of that |
| 20:55.17 | starseeker | indianlarry: oo, that would be awesome |
| 20:55.39 | starseeker | just check if it is in the bounding box - if it is, split the box at that y value |
| 20:55.54 | starseeker | or domain value rather |
| 20:56.21 | indianlarry | it will actually give you the curve param point which is what i walk down so break at each discont |
| 20:56.44 | indianlarry | hope it works |
| 20:58.45 | brlcad | starseeker: about 4min to e, fwiw |
| 20:58.52 | brlcad | render is zippy |
| 20:59.08 | ``Erik | heh, like, cox .049 black widow? I have a couple of those at home O.o |
| 20:59.20 | ``Erik | and I think I might have a cox peewee somewhere |
| 20:59.20 | brlcad | not many warnings spewed either, but pretty wrong |
| 21:00.00 | indianlarry | i base the trim error on the length of the curve in uv and the ends of cylinder are a long linear trims |
| 21:00.07 | brlcad | http://brlcad.org/tmp/nurbs8.png <- pee wee |
| 21:01.40 | CIA-28 | BRL-CAD: 03erikgreenwald * r34680 10/brlcad/trunk/ (22 files in 6 dirs): Eliminate libtienet. |
| 21:03.19 | brlcad | http://brlcad.org/tmp/nurbs9.png <- nice! |
| 21:04.04 | CIA-28 | BRL-CAD: 03starseeker * r34681 10/brlcad/trunk/include/opennurbs_ext.h: More Newton iterator tweaking. |
| 21:08.39 | starseeker | brlcad: yeah, that's my iterative wireframe routine crapping out |
| 21:09.19 | starseeker | almost wonder if the way to go is to make an "edge tree" routine and use that... |
| 21:09.43 | brlcad | last one, tee dee, http://brlcad.org/tmp/nurbs10.png |
| 21:10.56 | brlcad | geometry with .g's uploaded for convenience (regions fixed to not have spaces so they e up) |
| 21:11.09 | starseeker | brlcad: cool, thanks! |
| 21:11.17 | brlcad | starseeker: curious, what's it iterating on? |
| 21:11.31 | brlcad | because it didn't look any different than in .4 |
| 21:11.41 | brlcad | which was instant |
| 21:11.43 | starseeker | yeah, it wouldn't |
| 21:11.54 | starseeker | shape1 does look different |
| 21:12.12 | starseeker | have you tried that one in .4 vs trunk lately? |
| 21:13.23 | starseeker | it's making sure the wireframe is "smooth" to within some multiple of the tolerance |
| 21:13.31 | starseeker | I'm sure it's not very intelligent about it |
| 21:14.08 | brlcad | I just did, that was all the reporting about them failing to render |
| 21:15.08 | brlcad | the difference in wireframes was probably there, but it certainly wasn't drastic enough to notice (on any of them) |
| 21:15.34 | starseeker | yeah, shape is kinda a worst case wireframe |
| 21:16.01 | starseeker | if it's a big model compared to tolerance, the routine does a lotta work for ziltch |
| 21:16.31 | starseeker | hmm, that might be an option, base it on some fraction of the smallest bounding box dimension... |
| 21:19.05 | CIA-28 | BRL-CAD: 03erikgreenwald * r34682 10/brlcad/trunk/src/adrt/ (4 files in 4 dirs): Eliminate libtienet. |
| 21:21.15 | brlcad | it's the same problem the other primitives have |
| 21:22.00 | brlcad | they need to be dynamic to model size and view size, levels of detail |
| 21:22.46 | brlcad | which for the most part can all be done with view size, but there are some absolute model/computation limits that it should enforce |
| 21:33.50 | brlcad | ``Erik: looks like that does a hell of a lot more that just eliminate libtienet... |
| 21:35.15 | ``Erik | there might be a little more, but big chunks were moved out of libtienet into their application dir |
| 21:35.19 | brlcad | and could ya make the commit any bigger? jeez. |
| 21:35.24 | ``Erik | hehehe |
| 21:35.26 | ``Erik | svn mv, dude |
| 21:35.29 | brlcad | bob's rubbing off on you |
| 21:35.41 | brlcad | and yeah, that sounds so wrong :) |
| 21:37.03 | ``Erik | (and I'm just getting warmed up on the horrors, mebbe I'll get to commit and run like hell for my car) |
| 21:37.04 | starseeker | brlcad: correct me if I'm wrong, but the primitive plotting routines don't currently know anything about the view, do they? |
| 21:37.28 | brlcad | starseeker: none at all, that's why it's not been simple to fix |
| 21:37.34 | starseeker | ah |
| 21:37.39 | starseeker | ok, very good |
| 21:37.39 | brlcad | requires a functab change which affects all prims |
| 21:37.55 | brlcad | I was going to get to it *after* all of the functab refactoring |
| 21:38.14 | brlcad | still have a bit of work under way to finish up there |
| 21:38.21 | starseeker | yeah, that's what I thought - fairly intrusive change |
| 21:38.45 | brlcad | gsi had a quick hack that we could adopt, but it really was a big ugly for my taste |
| 21:39.03 | starseeker | nods |
| 21:39.08 | brlcad | they implemented a hi/lo command that would toggle wireframe detail |
| 21:39.19 | starseeker | That's worth doing right, imho |
| 21:39.44 | brlcad | primitves were modified to do what they do now and an even higher-res smooth version |
| 21:39.51 | starseeker | might also help with the "use arcs as well as lines" approach? |
| 21:40.10 | brlcad | the primitives shouldn't be tessellating themselves |
| 21:40.17 | starseeker | nods |
| 21:40.24 | ``Erik | hm, 3 arcs instead of 48 lines, that'd be nifty |
| 21:40.40 | brlcad | instead of returning render segments, they should return their edges/contours/surfaces -- e.g. the brep form |
| 21:41.03 | brlcad | from the brep form, tessellate as needed based on view size |
| 21:41.52 | brlcad | they could still self plot, but even then they could return as ``Erik mentioned -- arcs/curves lines points, etc |
| 21:42.07 | brlcad | basically a crude brep form |
| 21:44.08 | ``Erik | runs for his car |
| 21:44.26 | CIA-28 | BRL-CAD: 03erikgreenwald * r34683 10/brlcad/trunk/ (13 files in 11 dirs): flatten ADRT build. |
| 21:46.16 | ``Erik | yeah, I spoze that's 'nuff breakage for one afternoon :D |
| 21:53.47 | CIA-28 | BRL-CAD: 03starseeker * r34684 10/brlcad/trunk/src/librt/primitives/brep/brep.cpp: Hack around a performance issue with the adaptive sampling drawing for NURBS - this isn't a final solution but should avoid the killer performance zones. |
| 21:55.34 | starseeker | brlcad: does that help any? |
| 21:58.18 | brlcad | yes |
| 21:58.30 | brlcad | about .5s on peewee |
| 22:00.08 | starseeker | that preserves the shape1 drawing and attempts to "recognize" when it needs to be less fine |
| 22:00.25 | starseeker | will still have bad areas of course, but might be a reasonable compromise for now |
| 22:01.10 | brlcad | cool |
| 22:03.48 | starseeker | the trick is essentially to recognize that if we have to subdivide beyond some number N times, we have an edge describing a large length compared to the tolerance and the better course is to hope that big steps are "smooth" |
| 22:04.47 | starseeker | if indianlarry's singularity trick could be applied to edges we might look for derivative changes as another tool, but it can wait until a "proper" solution is available |
| 22:04.58 | starseeker | (especially given it's a universal primitive problem at the moment) |
| 22:09.32 | starseeker | indianlarry: so far what I'm seeing suggests that the linear approximation is a Really Good approximation for trimming - with that zoom in showing sawtooth it may be that at default resolutions shape1 isn't triggering a need for the exact curve solutions |
| 22:14.30 | brlcad | nod |
| 22:41.47 | ``Erik | looks for his engines |
| 22:53.11 | ``Erik | hm, can't find 'em :/ must still be at my parents place |
| 23:25.28 | *** join/#brlcad madant_ (n=d@117.196.129.227) | |
