| 00:03.56 | *** join/#brlcad thing1 (n=ric@124-169-115-200.dyn.iinet.net.au) | |
| 00:39.27 | *** join/#brlcad elite01_ (n=elite01@dslb-088-071-037-094.pools.arcor-ip.net) | |
| 00:57.17 | *** join/#brlcad Twingy (n=justin@74.92.144.217) | |
| 02:26.58 | *** join/#brlcad thing0 (n=ric@124-169-115-200.dyn.iinet.net.au) | |
| 02:29.41 | brlcad | arrives home with a quaint sigh of relaxation |
| 02:29.53 | pacman87 | wb, brlcad |
| 02:30.11 | brlcad | thanks poolio .. though it was pretty much the same temp up in NY today as here, 90-something before I left |
| 02:30.16 | brlcad | thanks pacman87 |
| 02:30.30 | pacman87 | a question on the uv mapping |
| 02:30.52 | brlcad | k |
| 02:30.58 | pacman87 | is each (u,v) point supposed to be unique? |
| 02:31.05 | brlcad | unique? |
| 02:31.28 | pacman87 | ie, if i know the (u,v) coordinate, there's exactly one (x,y,z) coordinate on the shape |
| 02:32.57 | pacman87 | because i have my base use 0<v<.25; the body uses .25<v<.75; and the top uses .75<v<1 |
| 02:34.04 | pacman87 | so if you use "s 10" on the checker, there's 5 squares on the sides |
| 02:34.05 | brlcad | an unique in the sense of there being a 1-to-1 mapping, yes that's ideal (but not strictly necessary for many modeling systems) |
| 02:35.03 | pacman87 | the rec's you used in your example have 10 checker squares on the body, and 10 on each endplate |
| 02:35.10 | brlcad | yeah |
| 02:36.05 | pacman87 | so it looks like the v coord ranges (0,1) three times; once for each face |
| 02:38.01 | brlcad | iirc, the intent is to treat the uv mapping as a volumetric mapping since these are applied as part of more complex CSG recipes |
| 02:39.16 | pacman87 | hmm? |
| 02:51.21 | *** join/#brlcad thing1 (n=ric@124-169-115-200.dyn.iinet.net.au) | |
| 02:57.01 | *** join/#brlcad thing2 (n=ric@124-169-115-200.dyn.iinet.net.au) | |
| 03:01.32 | brlcad | pacman87: i just meant that there's a variety of possible default uv mappings |
| 03:01.51 | brlcad | if we did this a lot, there'd be easier ways for users to define their own uv mappings |
| 03:01.56 | pacman87 | http://brlcad.org/tmp/hyp_pinch_checker.png |
| 03:02.08 | brlcad | as it stands, though, it's taken to be like a volumetric mapping |
| 03:02.16 | brlcad | so you get the mapping effectivley from the inside out |
| 03:02.32 | pacman87 | i switched the rotation since then, so lines up now |
| 03:02.47 | brlcad | which amounts to having the uv mapping per *surface* instead of per primitive |
| 03:03.13 | brlcad | cool |
| 03:03.16 | pacman87 | if that's the standard way of doing it, i can fix that too |
| 03:03.19 | brlcad | what was the offset? |
| 03:03.38 | pacman87 | i had x and y swithed in atan() |
| 03:03.51 | brlcad | ah, nifty |
| 03:04.05 | brlcad | i actually figured it was something intentional going on in tgc that was different |
| 03:04.16 | pacman87 | so should i switch to per-surface for UV? |
| 03:04.28 | brlcad | yeah, just so it's consistent |
| 03:04.35 | brlcad | that's how all the other primitives behave |
| 03:04.40 | poolio | brlcad: welcome home :) |
| 03:04.43 | brlcad | there is a good reason to do as you suggest |
| 03:05.08 | pacman87 | ok. the problem i though of with that is for texture mapping, if you want to specify a different top/bottom texture |
| 03:05.51 | brlcad | to have a primitive-based uv mapping that is holistic instead of per-surface, but that'd really beg changing all the primitives and that'd definitely not be backwards compatible even if it is render-only |
| 03:07.02 | brlcad | pacman87: there are other ways, you can always composite the textures or specify that a given texture map with a v range of 1/3 etc |
| 03:07.36 | brlcad | given you specify one texture per object, you'd have to composite them anyways to get perface to work |
| 03:08.11 | brlcad | poolio: danka |
| 03:08.26 | pacman87 | from what i understand, the uv coords tell which pixel to grab from the texture image |
| 03:09.04 | pacman87 | so if the same uv pair shows up on the top and the body, the same pixel will go there, right? |
| 03:09.20 | brlcad | with a 0 to 1 uv domain, yes |
| 03:09.45 | pacman87 | dont' all the primitives follow that? |
| 03:10.03 | brlcad | you specify he uv domain when you add textures, so you could set the domain to be less or more as needed |
| 03:10.11 | poolio | brlcad: so I've got sphere and right cylinder working...they don't raytrace right but I'm pretty sure they are correct. I was going to commit them but I think I'll wait til I get ell and a generalized algorithm for cylinders and just use that instead of having a whole mess of different code |
| 03:10.35 | brlcad | poolio: so then why aren't you committing anything?? |
| 03:10.48 | brlcad | there's no need to wait for committing things |
| 03:11.41 | poolio | ok...good point. commit working code and fix later :) |
| 03:11.43 | brlcad | almost never, really, even if it's incomplete or even non-functional -- so long as the state is documented and it doesn't leave the compilation in a busted state |
| 03:12.05 | brlcad | commit early, commit often |
| 03:12.13 | brlcad | for new committers, you really can't commit too frequently |
| 03:12.27 | poolio | oy vey. i need to stamp that on my forehead |
| 03:12.28 | brlcad | seriously, if it compiles and is forward progress, commit |
| 03:12.48 | brlcad | commit -m ftw |
| 03:13.37 | brlcad | svn commit -m "yay, initial brep support for spheres isn't working yet" primitives/sph/sph_brep.cpp etc |
| 03:14.38 | brlcad | then it just sort of becomes a documented "save" step in your development progress and it tells a story |
| 03:15.41 | brlcad | really likies http://brlcad.org/tmp/hyp.png ... I think that might have to go up on the wiki somewhere |
| 03:16.41 | starseeker | can upload it to the renders gallery |
| 03:16.41 | pacman87 | you couldnt' get one where the checker dont' hit the middle of the edge? |
| 03:16.52 | pacman87 | *checkers *don't |
| 03:17.18 | pacman87 | my apostrophes never end up in the right place |
| 03:17.51 | brlcad | could have, but I actually kind of like it that way |
| 03:17.57 | pacman87 | ah |
| 03:18.11 | pacman87 | well, once i fix the uv mapping, it'll be impossible ;) |
| 03:18.15 | brlcad | :) |
| 03:18.21 | poolio | brlcad: is there no longer rt_sph_internal? just rt_ell_internal? |
| 03:18.42 | pacman87 | in sph.s shp is stored as ell |
| 03:19.28 | brlcad | pacmac87, only in depth .. it should still wrap there |
| 03:19.48 | brlcad | i.e. white to white, black to black (at least for uv scale of 10) |
| 03:20.34 | starseeker | brlcad: which is preferable - gallery or wiki? |
| 03:20.39 | pacman87 | not if the top ellipse goes 0->1 and the side starts over again at 0 |
| 03:21.00 | brlcad | starseeker: depends on the purpose :) |
| 03:21.25 | brlcad | i think wiki myself, unless someone is going to make snazzy pictures of all of the primitives :) |
| 03:21.46 | brlcad | a better version of my primitives overview |
| 03:21.49 | starseeker | heh - we could make an album and stick it in with the metaballs primitive |
| 03:22.01 | starseeker | already a render of that up |
| 03:24.23 | brlcad | oh cool, I hadn't seen the GSI images were up |
| 03:25.46 | starseeker | yes, Rain did a good job with those |
| 03:27.27 | brlcad | oh, I got a database of almost 2000 polygonal models while I was up at the conference |
| 03:27.34 | brlcad | lots of fun to be had |
| 03:28.03 | starseeker | <jaw drops> |
| 03:28.14 | starseeker | what licensing terms? |
| 03:29.36 | starseeker | smacks head to get the idea of writing a docbook overview of all the primitives out of it... |
| 03:30.52 | starseeker | arrgh... |
| 03:36.33 | starseeker | ding nab it, why does that sound like fun??? |
| 03:37.51 | brlcad | it was fun to make it the first time |
| 03:38.05 | brlcad | chance to fix some things too |
| 03:38.07 | starseeker | ah - well, it's not just me at least :-) |
| 03:38.48 | starseeker | would probably go whole-hog though - equations describing primitives, key parameter descriptions and illustrations... maybe I'd better do it on my own time... |
| 03:41.47 | brlcad | welp, since he will be working on some more, if you want to add a primitives album .. that is probably better than nothing, go for it |
| 03:42.16 | starseeker | k - it'll do for a start anwyay |
| 03:42.42 | starseeker | in diagrams or renders? |
| 03:43.36 | starseeker | will stick it in renderings for now |
| 03:45.56 | brlcad | renderings |
| 03:46.27 | brlcad | the others are only in diagrams because they have labels .. diagramming what they are |
| 03:46.55 | brlcad | attempts to move the m1a1 pic so that it preserves the hit count |
| 03:47.32 | poolio | brlcad: so you'll be worrying about coding all the plotting and raytracing of the BREP shapes? :D |
| 03:48.00 | brlcad | they already plot in a simplistic form |
| 03:48.11 | brlcad | ray-tracing is what I'm working on |
| 03:48.34 | poolio | brlcad: The sphere I have plots half of an arc...that's it |
| 03:48.35 | brlcad | at least what I'm trying to work on |
| 03:48.44 | brlcad | that sounds right |
| 03:48.46 | poolio | :) |
| 03:48.54 | brlcad | really it does :) |
| 03:49.05 | poolio | The raytracing looks decent...it's been gooing for aorund 5 minutes |
| 03:49.06 | brlcad | it plots the edges of the surface(s) |
| 03:49.19 | brlcad | a sphere has just one surface |
| 03:49.19 | poolio | You have a lot of purty debugging |
| 03:49.26 | poolio | ah, makes sense |
| 03:49.56 | brlcad | the left and right u parameters meet, the top and bottom collapse to a point |
| 03:50.02 | brlcad | so you're left with one arc |
| 03:50.20 | brlcad | and a surface that sweeps out a sphere |
| 03:51.25 | poolio | Hehe, I'm still trying to fully understand the brep representation...I'm still resting on the crutches of the openNURBS fancy schmancy helper functions |
| 03:52.01 | brlcad | yeah, that might be good thing to go over on a thursday sometime |
| 03:52.16 | brlcad | ed loves to talk about that |
| 03:53.11 | poolio | yeah that'd be great :) |
| 03:53.49 | poolio | I think I also just need to read throgh some intro CAD / 3d graphics stuff. I managed to get through all of last summer knowing zip about it |
| 03:55.26 | poolio | brlcad: Is there a reason that the .cpp footers use C99 // comments? Woldn't it make more sense to keep it the same as the .c files? |
| 03:55.30 | poolio | (the headers are the same) |
| 04:03.29 | starseeker | metaballs had its rating survive when I moved it, once I enabled ratings in the target location |
| 04:03.38 | starseeker | should sleep now... |
| 04:04.53 | brlcad | ugh, gallery is such an inefficient pig of a web app |
| 04:06.16 | brlcad | poolio: no huge reason other than it being a few characters less and it distinguishes them as c++ |
| 04:06.36 | brlcad | unlike c, // has been part of c++ since before it was ratified |
| 04:06.53 | poolio | Ah ok. I was just thinking it'd be nice to keep a standard look even between C/C++ |
| 04:06.59 | brlcad | so they're not "C99" comments in that file's context as it's never compiled by a c99 compiler |
| 04:08.01 | brlcad | I don't think it needs to be enforced as one way vs the other, rather insignificant |
| 04:08.03 | poolio | brlcad: True, but coming from coding C forever, they are always C99 comments, no matter where I put them ;) |
| 04:08.05 | brlcad | if it's bothering you, go for it ;) |
| 04:08.06 | *** join/#brlcad thing0 (n=ric@124-169-115-200.dyn.iinet.net.au) | |
| 04:08.17 | poolio | Eh it's fine, I was just like //woah! |
| 04:08.41 | brlcad | fair game in the c++ files ;) |
| 04:09.20 | brlcad | I actually like the "wrapped blocks" more regardless of it being c/c++ for that footer |
| 04:09.39 | brlcad | but like I said, it just didn't matter and another project requested that footer.sh use // |
| 04:09.54 | brlcad | (template.sh uses header.sh and footer.sh) |
| 04:10.06 | brlcad | (for creating new files) |
| 04:13.41 | starseeker | Hmm... http://my.bzflag.bz/~starseeker/hyp_odd.png |
| 04:14.01 | starseeker | in test.s hyp 0 0 0 1 1 1 1 0 0 .4 .8 |
| 04:18.29 | brlcad | there have been 53k views of the gallery |
| 04:18.58 | brlcad | looks like an imae for pacman87 :) |
| 04:19.22 | brlcad | notes the my. is not needed |
| 04:21.11 | thing0 | hey brlcad |
| 04:21.17 | thing0 | how's things? |
| 04:28.19 | brlcad | howdy thing0 |
| 04:28.26 | brlcad | going great |
| 04:28.38 | brlcad | how are things down under? |
| 04:35.46 | *** join/#brlcad thing1 (n=ric@203-59-26-22.perm.iinet.net.au) | |
| 04:36.17 | brlcad | that good, eh? |
| 05:26.14 | *** part/#brlcad thing1 (n=ric@203-59-26-22.perm.iinet.net.au) | |
| 05:31.21 | *** join/#brlcad LeRuCh (n=ca546ac4@bz.bzflag.bz) | |
| 05:44.55 | *** join/#brlcad LeRuCh (n=ca546ac4@bz.bzflag.bz) | |
| 06:09.18 | LeRuCh | 05 Hello! |
| 06:36.02 | *** join/#brlcad thing0 (n=ric@124-169-237-118.dyn.iinet.net.au) | |
| 06:42.01 | *** join/#brlcad LoYH (n=7a3454a2@bz.bzflag.bz) | |
| 06:57.49 | *** join/#brlcad clock_ (n=clock@77-56-93-79.dclient.hispeed.ch) | |
| 07:03.02 | *** join/#brlcad Loy (n=7a3454a2@bz.bzflag.bz) | |
| 07:59.55 | *** join/#brlcad thing1 (n=ric@203-59-26-22.perm.iinet.net.au) | |
| 09:01.59 | *** join/#brlcad LeRuCh (n=ca546ac4@bz.bzflag.bz) | |
| 09:03.05 | *** part/#brlcad LeRuCh (n=ca546ac4@bz.bzflag.bz) | |
| 09:18.14 | *** join/#brlcad LeRuCh (n=ca546ac4@bz.bzflag.bz) | |
| 09:24.48 | *** part/#brlcad LeRuCh (n=ca546ac4@bz.bzflag.bz) | |
| 10:49.26 | *** join/#brlcad Elperion (n=Bary@p548757E1.dip.t-dialin.net) | |
| 10:49.47 | *** join/#brlcad thing0 (n=ric@124-169-237-118.dyn.iinet.net.au) | |
| 11:53.08 | *** join/#brlcad archivist (n=archivis@host81-149-119-172.in-addr.btopenworld.com) | |
| 12:15.50 | *** join/#brlcad docelic (n=docelic@78.134.204.246) | |
| 12:37.29 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-037-094.pools.arcor-ip.net) | |
| 13:35.32 | pacman87 | starseeker: i noticed that too. it's because your major axis isn't perpendicular to the height vector, and i haven't done any sanity checking to prevent that. |
| 14:54.34 | *** join/#brlcad mafm (n=mafm@elnet-111.lip.pt) | |
| 14:54.59 | mafm | allo |
| 15:44.01 | poolio | brlcad: so I don't think I have commit access...? |
| 15:49.10 | CIA-21 | BRL-CAD: 03poolio * r31341 10/brlcad/trunk/src/librt/primitives/sph/sph_brep.cpp: initial brep support for spheres, nonfunctional |
| 15:49.13 | poolio | ah neverminddd :) |
| 16:27.15 | brlcad | heh |
| 16:27.22 | brlcad | howdy mafm |
| 16:39.20 | *** join/#brlcad clock_ (n=clock@77-56-87-170.dclient.hispeed.ch) | |
| 16:47.33 | *** join/#brlcad Elperion (n=Bary@p548757E1.dip.t-dialin.net) | |
| 17:18.48 | *** join/#brlcad elite01 (n=elite01@dslb-088-071-037-094.pools.arcor-ip.net) | |
| 18:09.02 | mafm | do all the code conventions apply for the rt^3 module? |
| 18:09.56 | mafm | or are they something left from old codebases? |
| 18:25.24 | poolio | mafm: as in the C code conventions in HACKING? |
| 18:26.39 | mafm | yep |
| 18:26.48 | poolio | I don't see why they wouldn't apply :) |
| 18:27.36 | brlcad | mafm: what in particular -- for the most part yes as the intent is still to be consistent across the project |
| 18:27.53 | brlcad | and most of the conventions for C still apply to C++ |
| 18:29.01 | mafm | dunno... being a new module "cleanly" gives the opportunity to change something, without mixing conventions |
| 18:29.31 | poolio | brlcad: Is it fine if I don't bother to update Makefiles and what not for now |
| 18:30.13 | brlcad | mafm: heh, there's nothing legacy about the choice of conventions .. |
| 18:30.47 | brlcad | poolio: if you're adding new files, they should at least be added to EXTRA_DIST even if they're not added to the build |
| 18:30.53 | brlcad | so that they are included in source distribution |
| 18:30.58 | mafm | i.e. I think that people lately tends to use tabs for indentation, so it can be configured the size of a tab in different IDEs |
| 18:31.37 | brlcad | eh, I figured that was where you were probably going with that |
| 18:31.40 | brlcad | and it's just not true |
| 18:32.07 | brlcad | there are plenty of ws conventions and zealotry of preferences raging throughout projects for different styles |
| 18:32.20 | brlcad | there are at least a half dozen "exceptionally popular" styles |
| 18:32.37 | brlcad | and just about every IDE lets you configure it to suit any of them |
| 18:34.13 | brlcad | the real need in that case is to just be consistent, and to enforce that consistency |
| 18:35.15 | mafm | oki :) |
| 18:38.01 | brlcad | it's mostly just familiarity .. the more code you write in different styles, the more I think you'll find that it just really doesn't matter |
| 18:38.03 | mafm | should I modify the RtApplication and the rest of placeholder classes directly? |
| 18:38.06 | brlcad | there are tradeoffs to each |
| 18:38.53 | brlcad | I was thinking that you'd add your own directory |
| 18:38.59 | brlcad | not the rt^3 dir |
| 18:39.38 | brlcad | you can use the structure as a template or not |
| 18:39.56 | brlcad | the existing source isn't so important, it can totally change if needed |
| 18:40.53 | mafm | 3dge? :) |
| 18:41.10 | brlcad | heh |
| 18:41.20 | brlcad | if that's what you want to call it, go for it :) |
| 18:41.32 | brlcad | clever |
| 18:42.41 | mafm | just made it up now... hadn't thought of it |
| 18:43.51 | brlcad | I have had a name in mind for several years now but it's not time to start using that yet :) |
| 18:44.01 | brlcad | need the geometry engine and plugin architecture first |
| 18:44.32 | pacman87 | brlcad: what tolerance should i put on the check to see if two vectors a perpendicular? |
| 18:44.47 | pacman87 | NEAR_ZERO( VDOT( rip->hyp_H, rip->hyp_Au ), SMALL_FASTF )? |
| 18:47.28 | brlcad | RT_DOT_TOL |
| 18:48.48 | CIA-21 | BRL-CAD: 03pacman87 * r31342 10/brlcad/trunk/src/librt/primitives/hyp/hyp.c: change uv() to conform to standard practice; (u,v) coords are unique per face, not per primitive |
| 18:51.22 | pacman87 | brlcad: is there a valid reason for allowing the major axis vector to be non-perpendicular to the height? |
| 18:53.59 | brlcad | you mean the major axis of the ellipse? |
| 18:54.02 | pacman87 | yes |
| 18:54.21 | pacman87 | re: starseeker's picture |
| 18:54.58 | brlcad | unless it's actually going to act like a tgc and allow end caps be at angles, I don't see a need |
| 18:55.39 | pacman87 | ok, then my fix to starseeker's problem is to say "that's not allowed" |
| 18:55.59 | brlcad | well, if it's not allowed, it shouldn't allow one to be made |
| 18:56.11 | brlcad | with checks during in and export |
| 18:56.14 | pacman87 | right, that's my next commit :) |
| 18:56.39 | pacman87 | i haven't done any sanity checking for inputs yet |
| 18:57.22 | brlcad | now I do think that there's no need to limit the A/B ellipse vectors |
| 18:58.09 | brlcad | i.e. instead of taking input for major and then saying minor must be <= .. just take a vector and the perpendicular distance, then have the in command figure out which then is major/minor |
| 18:58.15 | brlcad | minor usability nit |
| 18:58.31 | pacman87 | ah, ok |
| 18:58.45 | brlcad | since you can obviously swap them and it'll be fine |
| 18:59.00 | pacman87 | and calculate the new major axis vector |
| 18:59.06 | brlcad | yeah |
| 19:00.43 | CIA-21 | BRL-CAD: 03pacman87 * r31343 10/brlcad/trunk/src/mged/typein.c: add check to ensure ellipse's major axis is perpendicular to the height vector when creating a hyp or ehy using 'in' |
| 19:01.15 | mafm | hmmm, what happens when you include a header when in your include path there are several with the same name? only one is inserted? |
| 19:05.19 | brlcad | first one the preprocessor encounters |
| 19:05.39 | brlcad | which is based on the -I cpp_flags/paths |
| 19:15.36 | brlcad | starseeker: is oedtmp still needed? |
| 19:15.48 | brlcad | removed the A's |
| 19:17.30 | starseeker | brlcad: opps - nope, sorry |
| 19:18.08 | starseeker | strictly speaking, oed isn't either until I figure out the xsl fun |
| 19:18.26 | starseeker | my initial attempt didn't do squat |
| 19:19.27 | starseeker | cleaned up |
| 19:19.40 | brlcad | eep |
| 19:19.45 | brlcad | was playing in oed/ |
| 19:20.00 | brlcad | oh well :) |
| 19:20.24 | mafm | what's oed? |
| 19:20.46 | brlcad | a tutorial he wrote on the oed command |
| 19:20.49 | brlcad | object editing |
| 19:20.49 | pacman87 | how do i add an '!' to my commit message? |
| 19:21.10 | brlcad | pacman87: use single quotes or the editor |
| 19:21.36 | pacman87 | single quotes around the -m message, or around the !? |
| 19:21.36 | brlcad | there's a way to escape it in a double-quoted message, but I forget exactly |
| 19:21.44 | brlcad | around the -m |
| 19:22.03 | pacman87 | ok, i tried \! earlier, and it printed both characters |
| 19:22.50 | CIA-21 | BRL-CAD: 03pacman87 * r31344 10/brlcad/trunk/src/mged/typein.c: hyp now accepts a minor axis length larger than the given major axis, and recalculates the direction of the major axis. Also includes logic fix for previous commit NEAR_ZERO -> !NEAR_ZERO |
| 19:38.53 | *** join/#brlcad thing0 (n=ric@124-169-237-118.dyn.iinet.net.au) | |
| 19:49.57 | mafm | heh, RBGui feels snappy |
| 19:55.08 | mafm | brlcad: LGPL v2.1 or v3? |
| 19:55.14 | brlcad | 2.1 |
| 19:55.47 | brlcad | should be using the same headers as for the reset of the brlcad sources |
| 19:57.34 | brlcad | if you've got things working .. there should be some commits coming soon then? :) |
| 19:59.32 | mafm | I thought that I saw the LGPLv3 flying around in the new module... it must be because of the 3 in Rt^3 :D |
| 20:00.27 | mafm | The commits yep, but I hope that you accept half-working stuff, it needs a lot of infrastructure (data files, etc) |
| 20:01.35 | mafm | do you think that "3dge" could give any problem? when compiling it was complaining because 3DGE_WHATEVER_H was not a valid name, so I changed it to __NAME__ (as it's in other files of rtgeom and the like) |
| 20:02.07 | mafm | but that made me thought if it could bring some problems in other parts as well, starting the name with a number |
| 20:02.14 | mafm | number->digit |
| 20:07.24 | pacman87 | mafm: you could try edg3 |
| 20:08.06 | brlcad | mafm: yep, half-working something is better than fully-working nothing ;) |
| 20:08.32 | pacman87 | brlcad: i've got your new and improved hyp input method coming right up :) |
| 20:08.49 | pacman87 | though it seems my uv mapping fix didn't fix everything |
| 20:08.53 | brlcad | yeah, symbols (vars, functions, etc) can't start with a number |
| 20:09.18 | brlcad | having a dir named that shouldn't be a problem |
| 20:09.24 | brlcad | nor bin target |
| 20:09.32 | brlcad | pacman87: cool :) |
| 20:09.52 | pacman87 | i just changed hyp_in(), all the internal data is still stored the same |
| 20:10.55 | mafm | maybe ge3d? geometry editor 3d? but the pun was to change the m in mged ;) |
| 20:12.04 | brlcad | heh, g3d would be interesting |
| 20:12.18 | brlcad | as mged's original name was "ged" |
| 20:12.31 | mafm | I know that dirs etc is not a problem [in modern systems], but who knows... maybe it gives problems in target names for MSVC or things like that |
| 20:12.50 | mafm | ok, so g3d be it |
| 20:13.26 | brlcad | ah, see I took it to be clever because it was 3dge -> edge -> new interface uses an explicit polygonal representation for visualization, i.e. an "edge-based" representation |
| 20:13.43 | brlcad | but the mged angle (pun intended) is clever too |
| 20:14.02 | brlcad | g3d is nice and succinct, though |
| 20:14.27 | brlcad | though there is .. http://g3d-cpp.sourceforge.net/ |
| 20:15.38 | mafm | yep, but well... that would be the g3d tool in brl-cad similar to the other gazillion ones, not a full product name I guess? |
| 20:16.08 | mafm | nowadays anything with 3d in the name is probably taken anyway :D |
| 20:16.58 | brlcad | yeah, it shouldn't matter so much just yet as it can be basically considered the internal dev name |
| 20:18.22 | mafm | well, you know how it works... in the end nobody renames just for the pain of renaming files and so on |
| 20:18.36 | brlcad | sometimes |
| 20:19.19 | mafm | and about the commits, I meant half-working because in brlcad-trunk you require people not broking things, checking performances and so on |
| 20:19.20 | brlcad | except in this case, if everything works out as planned, this is going to be the foundation for the "next-generation" editing interface that eventually replaces mged |
| 20:19.58 | brlcad | mafm: yeah, though even on trunk there is ways to do that for a project such as yours incrementally without breaking things |
| 20:20.18 | brlcad | it's a new code, so it's expected that it'll be a work in progress |
| 20:20.42 | brlcad | the breaking things applies mostly to existing code and interfaces, and not leaving the compilation in a broken state |
| 20:21.05 | brlcad | it's easy to not leave the compilation in a broken state on new files, don't compile those files :) |
| 20:27.17 | mafm | yup |
| 20:28.05 | mafm | well, I should be going home, and I only have the main.cxx in state to commit (clean, proper doxygen, etc) |
| 20:28.21 | mafm | should I commit it or wait for the test Application tomorrow? |
| 20:29.06 | pacman87 | mafm: i'm pretty sure the answer to that question is almost always 'commit now' |
| 20:29.30 | starseeker | brlcad: whoooops! sorry! |
| 20:29.58 | starseeker | brlcad: I can put it back... |
| 20:31.07 | mafm | pacman87: well, it's 3 lines worth of code...! |
| 20:31.36 | pacman87 | i've committed changes of less than three lines |
| 20:32.24 | pacman87 | and it's a good habit to get into |
| 20:33.04 | mafm | OK, I'll do |
| 20:33.31 | mafm | but this is different than regular changes... it's main() and calls a non-existing class in the repository :D |
| 20:34.57 | pacman87 | like brlcad said, don't add it to the makefile then |
| 20:35.24 | pacman87 | but hey, it's your call |
| 20:38.14 | brlcad | starseeker: too late and no matter :) |
| 20:38.47 | brlcad | mafm: it doesn't matter |
| 20:38.52 | brlcad | you sould still commit everything you have |
| 20:40.25 | brlcad | it's a hard practice for some to get used to but you will eventually appreciate it, particularly the more you get used to making incremental functional commits |
| 20:40.26 | mafm | can't commit everything, part is still application example of RBgui |
| 20:40.28 | brlcad | ~pacman87++ |
| 20:40.57 | brlcad | so? |
| 20:41.12 | mafm | copyright! |
| 20:41.34 | brlcad | you're not claiming copyright on their code |
| 20:43.30 | brlcad | at least commit the code that you've written and been working on |
| 20:43.36 | mafm | well, if you don't mind not following coding conventions, no doxygen etc, it's OK for me |
| 20:43.49 | brlcad | that's part of the "compile works, time to commit" habit |
| 20:43.59 | brlcad | heh, it's not like you're going to be done with it |
| 20:44.19 | brlcad | it's not an excuse to not do those things, you're just checkpointing |
| 20:44.48 | brlcad | so if you got, you know, hit by a bus tonight .. we'd have the last state of your efforts to continue on from :) |
| 20:45.18 | pacman87 | or if your next door neighbor sets off an EMP... |
| 20:45.37 | pacman87 | https://webspace.utexas.edu/trv82/www/hyp_rt16.png |
| 20:45.45 | mafm | yes, I get the point, and I always submit several times a day... but usually not in the case that I'm using testing applications |
| 20:46.01 | brlcad | tragic exaggeration of course, but it's all part of getting you to learn to code in "complete" steps |
| 20:46.23 | brlcad | mafm: okay, fair enough .. if you have test apps, you can leave them out |
| 20:46.38 | mafm | too late, I already made the patches :P |
| 20:46.51 | brlcad | but so far there hasn't been any commits, so it smells more of uneasy first-time commiter |
| 20:46.59 | mafm | btw, I had to diff against /dev/null |
| 20:47.05 | brlcad | huh? |
| 20:47.17 | mafm | changed the name by hand, hope that there's no problem |
| 20:47.36 | mafm | well, svn diff doesn't work, I guess that it's because of being in a new directory |
| 20:47.52 | brlcad | you have to svn add the new directory and new files first |
| 20:47.58 | mafm | (not present upstream) |
| 20:48.02 | brlcad | then they'll be in a diff |
| 20:48.42 | mafm | hmm, can I add dirs as anonymous? |
| 20:48.42 | brlcad | sure, at least I'm pretty sure |
| 20:48.42 | brlcad | that's a local operation |
| 20:48.49 | mafm | ah ok |
| 20:49.07 | brlcad | (unlike cvs where cvs adding a new dir made a commit) |
| 20:49.32 | CIA-21 | BRL-CAD: 03pacman87 * r31345 10/brlcad/trunk/src/mged/typein.c: change hyp input routine: vertex is now center of base; major/minor axes define the base size; height measures from bottom to top plate; c is now the squeeze factor for the neck, as a fraction of the base size |
| 20:50.02 | brlcad | woot! |
| 20:50.24 | brlcad | goes giddily to play with a hyp |
| 20:50.27 | CIA-21 | BRL-CAD: 03pacman87 * r31346 10/brlcad/trunk/src/librt/primitives/hyp/hyp.c: modify hyp's uv() to match with rec to produce a continuous checker pattern |
| 20:50.36 | pacman87 | now you can go have fun :) |
| 20:56.45 | mafm | sent first patches, goes to hide his head in shame :P |
| 20:57.02 | mafm | not really, going home to get some food & sleep :) |
| 20:57.13 | mafm | see you tomorrow! |
| 20:57.28 | brlcad | heh, okay! cya :) |
| 21:00.13 | brlcad | thinks it's time for a new poll |
| 22:08.30 | *** join/#brlcad dtidrow (n=dtidrow@c-69-255-182-248.hsd1.va.comcast.net) | |
| 22:50.57 | ``Erik | thinks it's time for this "code monkeys" show O.o |
| 22:53.32 | poolio | brlcad: the older poll is quite interesting...shows that a good website good lead to a lot more users IMO :) |
| 22:59.25 | brlcad | ooh, code monkeys! |
| 23:00.31 | brlcad | poolio: yeah, it is about what I expected (that 90% of our visitors are first-time visitors, along with a few first-time users) |
| 23:03.42 | ``Erik | time to impress jodi foster O.o |
| 23:08.30 | brlcad | um, hello? breasts? |
| 23:10.11 | brlcad | chock full of good quotes :) |
| 23:10.20 | ``Erik | <-- fights the urge to implement some of these games :D |
| 23:11.22 | ``Erik | the bars at te top and bottom are hilarious |
| 23:24.40 | brlcad | makes himself more comfortable |
| 23:53.55 | pacman87 | brlcad et al: how's the new hyp creation working? |
