| 00:33.27 | *** join/#brlcad louipc (~louipc@archlinux/trusteduser/louipc) | |
| 00:42.09 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 03:34.32 | ``Erik | the / is a relatively safe token for splitting and we use it elsewhere to denote tokens, the comma is used in some locales as a decimal point... if we ever go gettext, could cause issue |
| 03:36.59 | bhinesley | what comma are you referring to? |
| 03:37.17 | ``Erik | (but I'm no usability expert and make it a point to avoid gui work, so'z *shrug*) |
| 03:37.28 | ``Erik | (1,4,5) as a listing of coordinate |
| 03:38.04 | bhinesley | oh, I was just interpreting the syntax in human readable form |
| 03:38.09 | bhinesley | there are no commas :) |
| 03:38.26 | ``Erik | just noting that the glyph is risky :) people who haven't done internationalization can easily miss that gotcha :) |
| 03:38.37 | bhinesley | nods |
| 03:38.40 | bhinesley | thanks |
| 03:41.24 | *** join/#brlcad epileg (~epileg@unaffiliated/epileg) | |
| 03:47.15 | ``Erik | (and vi, not vim?) |
| 03:52.36 | ``Erik | brlcad: dlo found issues in the solar system scale stuff when mocking up a ringworld as a pre-procdb issue, prolly fp fuzz around 1.5e14mm, so'z the claims in the au page may be a bit... optimistic :) |
| 03:54.07 | ``Erik | for the physics shtuff, my vote is for bullet, my research indicates that it started whupping ode a few years back |
| 04:01.18 | CIA-62 | BRL-CAD: 0399.125.86.110 07http://brlcad.org * r3006 10/wiki/User:Bhinesley: /* Who I am */ vim, not vi :) |
| 04:01.32 | bhinesley | ``Erik: ^ |
| 04:01.36 | bhinesley | :) |
| 04:02.27 | ``Erik | :D I'm a fbsd weenie and the 'default' editor is nvi, very different from vim |
| 04:03.07 | ``Erik | (default editor is a bsh, not bash, also confusing to linux folk) |
| 04:03.41 | bhinesley | I was a fbsd admin for a couple years, but that was a long time ago |
| 04:03.52 | bhinesley | (small company) |
| 04:04.47 | ``Erik | cool beans |
| 04:05.17 | ``Erik | which major? |
| 04:05.23 | bhinesley | computer science |
| 04:05.25 | bhinesley | BS |
| 04:05.36 | ``Erik | I meant fbsd major release number :) |
| 04:05.44 | bhinesley | oh jeez |
| 04:05.55 | ``Erik | I went fbsd with a 3, really embraced it at 4 |
| 04:06.21 | ``Erik | late 90's, yo |
| 04:07.04 | bhinesley | based on the release dates on wikipedia it must have been 5 for me |
| 04:07.38 | bhinesley | I was running 'stable' about 2004 or 2005 |
| 04:07.47 | ``Erik | brlcad.org is still running one of the 5 series |
| 04:08.36 | ``Erik | it's a good os, can be a bit tricky to maintain if you're not used to the *nix world |
| 04:09.34 | bhinesley | nods |
| 04:09.35 | bhinesley | I learned on it |
| 04:09.52 | ``Erik | <-- is a port maintainer for a couple dozen, has a few hundred pr's, friends with several core folk, good stuff :) |
| 04:10.11 | bhinesley | awesome |
| 04:10.29 | ``Erik | openbsd is nice, too, theo can be a dick, though |
| 04:10.36 | bhinesley | haha |
| 04:10.51 | bhinesley | never used it, myself |
| 04:11.25 | ``Erik | I've only used open in a vm, the X upgrade was a royal pain |
| 04:11.50 | ``Erik | dragonfly has some interesting ideas, that was a weird period |
| 04:12.40 | ``Erik | was around '02 I think, major philosophical differences on concurrency and smp |
| 04:13.10 | ``Erik | smelled like both sides weren't listening, just saying that the other side was wrong... was almost like congress *cough* O:-) |
| 04:13.32 | brlcad | ``Erik: how is "untested support for astronomical units and lots of room for there to be computational issues" being optimistic? |
| 04:13.35 | bhinesley | "they need to compromise!" |
| 04:14.54 | brlcad | bhinesley: not too worried about supporting FACTOR || X Y || X Y Z .. FACTOR || X Y Z are the two main use cases |
| 04:15.18 | ``Erik | brlcad: the statement that we can do it at a full sol system level, we have known issues at 2% of that |
| 04:15.31 | brlcad | or even FACTOR | [-x X] [-y Y] [-z Z] |
| 04:16.15 | brlcad | ``Erik: er, where do you see that statement? |
| 04:17.04 | bhinesley | alright. I won't worry about it, unless it's simpler to just include it. |
| 04:17.14 | brlcad | the only claim it makes is that objects at that scale can be created .. and then it caveats saying it's all untested and probably has issues |
| 04:17.34 | ``Erik | um, the celestial mechanics page says, srry |
| 04:18.41 | brlcad | even there, it just says you can accurately model the solar system to scale .. which is true, you just can't render that model |
| 04:19.15 | brlcad | and even then -- I don't know if simple ellipsoids at that scale would have an issue |
| 04:19.20 | ``Erik | dlo's experiment was a 30m thick strip at 1au and had display issues similar to ogl zbuffer fighting, *shrug* |
| 04:19.59 | brlcad | that's already changing the numbers involved substantially |
| 04:20.07 | brlcad | small detail at a massive scale, I'd expect a problem |
| 04:20.26 | brlcad | modeling the solar system is effectively no detail at a massive scale |
| 04:20.38 | ``Erik | yeah, he was trying to hand-build a niven ringworld, to preview the proc-db I started |
| 04:21.05 | brlcad | I don't see why a super massive sph wouldn't render just fine as an AU scale |
| 04:21.11 | brlcad | s/as/at/ |
| 04:21.39 | ``Erik | an ell should, I'd think |
| 04:21.45 | brlcad | the only issue might be the transformation it attempts to perform during raytracing so that the primitive is in a normal unitized position during eval |
| 04:21.55 | brlcad | that might bork the floating |
| 04:22.23 | brlcad | I've created a planet-sized ell before, no problems |
| 04:22.34 | brlcad | but only at the origina |
| 04:22.40 | ``Erik | it might be an op ordering issue that he was seeing, too *shrug* |
| 04:22.53 | ``Erik | planet sizes run quite a wide gambit |
| 04:23.08 | ``Erik | we have the earth sized planet with the star trek stuff in orbit, that works well |
| 04:23.24 | ``Erik | but a planet and local orbit is tiny compared to a solar system |
| 04:24.04 | brlcad | bhinesley: note that some objects can only be scaled uniformly, so there will have to be error checking if attempting to only scale 1 or 2 axes |
| 04:24.40 | bhinesley | I figured as much; such as a sphere |
| 04:26.03 | ``Erik | measuring in meters, I think a 64b ieee854 is around ~10 meter accuract at a pluto orbit (~50au), so mm would be 10km accuracy |
| 04:26.07 | brlcad | sphere is fine, they become ellipsoids |
| 04:26.20 | bhinesley | oh, hah |
| 04:26.24 | ``Erik | and that's straight measure, no math to increase inacuracy |
| 04:26.25 | brlcad | torus is the typical error case |
| 04:27.00 | ``Erik | tgc's can also be touchy, iirc |
| 04:27.22 | brlcad | ``Erik: which implies simulating our solar system to scale would be just fine .. 10km would be sub-sub-pixel |
| 04:28.37 | ``Erik | means I can't put a toy jeep on neptune, though :D |
| 04:29.28 | brlcad | heh |
| 04:30.22 | ``Erik | now my frame of reference... back in the late 90's, I was trying to make an xwing type game and was looking for ways to have a small craft be accurate anywhere in a solar system |
| 04:30.24 | brlcad | yeah, that'd be about *45M* km per pixel for a basic "overhead" render |
| 04:31.24 | brlcad | means earth is sub-pixel to scale too |
| 04:31.53 | brlcad | so you'd have to scale the bodies up several orders of magnitude, which might be neat in itself |
| 04:31.54 | ``Erik | for most displays, the only thing that MIGHT get a pixel for a solar system scale render ist he sun... |
| 04:32.41 | brlcad | yeah, sun is sub-pixel 1.39M km diameter |
| 04:33.12 | brlcad | three orders of magnitude would make them visible |
| 04:33.15 | ``Erik | but a 10,000 km 'tile' eliminates any surface detail in the outer bits |
| 04:35.36 | ``Erik | *shrug* at solar scales, we lose a lot of accuracy, 'sall :) |
| 04:36.18 | ``Erik | nerds who want to make ringworlds, dyson spheres, etc might be a bit upset when it doesn't quite work right |
| 04:37.29 | ``Erik | imma catch some z's, hasta manana :) |
| 04:38.52 | brlcad | nods |
| 04:38.55 | bhinesley | see ya |
| 04:39.10 | brlcad | the first units project aims to help fix the units issue better |
| 04:39.59 | brlcad | making sure the math is stable for existing prims, then maybe working on scaling zones |
| 04:41.21 | brlcad | bhinesley: curious choice of 'alter' for the command name |
| 04:41.35 | brlcad | any reason that over 'edit'? |
| 04:41.55 | bhinesley | nope, edit would be fine |
| 04:42.14 | bhinesley | alter just came to mind, and it's easy enough to change, so I went with it |
| 04:43.01 | brlcad | it's fine, just wondering if there was some underlying motivation |
| 04:43.15 | brlcad | both edit and alter are a little vague |
| 04:43.56 | brlcad | ambiguous even, since I can't edit/alter some object parameters |
| 04:45.31 | brlcad | those three subcommands are all transformations, so 'xform' would be pretty fitting too |
| 04:46.47 | bhinesley | whatever name it is, it will be "extern thename" in ged_private.h |
| 04:47.03 | bhinesley | and also, "extern thename_translate", etc |
| 04:47.30 | bhinesley | the idea is, thename_translate will be as primitive of a translate as possible |
| 04:48.01 | brlcad | you mean only as private api, not a new parent command? |
| 04:48.26 | bhinesley | if I understand you correctly: there will be both |
| 04:48.43 | brlcad | then what do you mean by "extern thename" in ged_private.h ? |
| 04:49.01 | brlcad | ged_private is for declaring non-public API (functions) |
| 04:49.28 | bhinesley | ged_thename will be public |
| 04:49.47 | brlcad | so then it goes in ged.h :) |
| 04:49.56 | bhinesley | correct |
| 04:50.21 | brlcad | okay, just confused by your prior statement |
| 04:50.21 | brlcad | 00:46 < bhinesley> whatever name it is, it will be "extern thename" in ged_private.h |
| 04:50.26 | bhinesley | there is a separate function, "thename", which is for calling internally without using argv |
| 04:50.52 | brlcad | ah, I think I might get what you're saying |
| 04:50.57 | bhinesley | ged_thename simply parses command line arguments and passes it to thename |
| 04:51.01 | brlcad | nods |
| 04:51.03 | brlcad | got it |
| 04:51.16 | bhinesley | yeah, excuse me... I'm not very good at expressing these things |
| 04:51.23 | bhinesley | (yet) |
| 04:52.14 | brlcad | funcs still only need to be declared extern in ged_private.h if they're going to be used by more than one file |
| 04:52.29 | brlcad | so if it all lives in alter.c, you're fine with simple function ordering |
| 04:53.37 | bhinesley | A command that needs to do a simple translate could call thename_translate. If it needed to do a batch translate using '.', or if it needed to use objects/distances to calculate coordinates, then it could call thename. |
| 04:53.52 | brlcad | it'd only be if you broke it out into alter.c, translate.c, rotate.c, scale.c with the latter three ged_[cmd]() funcs calling ged_alter() |
| 04:55.05 | bhinesley | okay, I'm a little confused. |
| 04:55.20 | brlcad | no worries, carry on :) |
| 04:55.44 | bhinesley | ged.h is for sharing with commands outside of libged, while ged_private.h is for sharing internally to libged only? |
| 04:56.01 | brlcad | almost |
| 04:56.37 | brlcad | ged.h is public declaration for use anywhere (inside/outside) |
| 04:57.06 | brlcad | ged_private.h is private declaration where there is internal reuse |
| 04:57.47 | brlcad | so funcs are added to ged.h when they're "published" but should only ged added to ged_private.h when they're actually used in more than one file |
| 04:57.55 | brlcad | even if they're ripe for reuse |
| 04:58.35 | bhinesley | okay |
| 04:58.50 | brlcad | not a big issue if they're declared in ged_private.h and not used in multiple places, but the decls might get removed/cleaned up down the road to keep files simple |
| 04:59.41 | bhinesley | sounds like ged_thename goes in ged.h for now, and eventually thename/thename_translate/etc may go in ged_private.h |
| 04:59.48 | brlcad | there are 400+ commands which means there could easily be 3x that many "private yet potentially reusable" internal funcs .. which wouldn't be too useful to browse through |
| 05:00.11 | brlcad | right, that's the intention at least |
| 05:00.58 | brlcad | my guy feeling is that any function prime for libged reuse probably doesn't even belong in libged |
| 05:01.07 | brlcad | begs refactoring down into librt |
| 05:01.33 | bhinesley | why does so much end up in librt? I thought it was just raytracing? |
| 05:01.37 | brlcad | aside from commands calling other commands at the libged API level |
| 05:01.47 | brlcad | librt isn't just raytracing |
| 05:02.00 | brlcad | it's the underlying geometry management |
| 05:02.09 | bhinesley | I mean, I have seen that... I just didn't understand the reasoning |
| 05:02.49 | brlcad | geometry representation, disk I/O, serialization, and ray tracing |
| 05:03.24 | brlcad | it would probably be more appropriately named "libg", except that the main reason for its existence is to shoot rays |
| 05:03.56 | bhinesley | alright, that makes sense |
| 05:04.15 | brlcad | and there is a very close relationship between the on-disk representation and the in-memory format used for ray-tracing |
| 05:04.44 | brlcad | the two are tightly coupled for performance reasons, why we can raytrace massive multi GB scenes in mere seconds |
| 05:04.53 | bhinesley | ahh |
| 05:05.42 | brlcad | we've talked about separating the two into different libraries, but it would be tricky to do cleanly API-wise |
| 05:05.53 | bhinesley | so, as you were saying: should uhh... 'thename' live in librt? |
| 05:06.28 | brlcad | if it's argc/argv style, then it still belongs in libged |
| 05:07.06 | bhinesley | well, only ged_thename is argc/argv style |
| 05:12.21 | brlcad | it depends what the command ends up looking like parameter-wise |
| 05:12.39 | brlcad | keep an eye on rt_matrix_transform() since that is the current closest-fit API call already in librt that comes to mind |
| 05:12.50 | brlcad | it's how mged applies most matrix edits now |
| 05:13.00 | brlcad | s/matrix/primitive/ |
| 05:13.37 | brlcad | through transformation matrices (with scaling, translation, and rotation components) |
| 05:18.20 | bhinesley | interesting |
| 08:10.00 | *** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) | |
| 08:36.36 | brlcad | calls it done for now |
| 08:38.56 | *** join/#brlcad Stattrav (~Stattrav@122.178.195.64) | |
| 08:38.56 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 09:34.51 | CIA-62 | BRL-CAD: 03bhinesley * r45426 10/brlcad/trunk/src/libged/alter.c: Set up the struct and flags for ged_alter and alter command argument handling. Other small cleanup/setup stuff. |
| 11:18.17 | CIA-62 | BRL-CAD: 03indianlarry * r45427 10/brlcad/trunk/include/dm.h: externalize display manager interfaces |
| 13:42.28 | *** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) | |
| 13:56.33 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 16:30.28 | *** join/#brlcad kunigami_ (~kunigami@201.53.206.27) | |
| 17:30.54 | CIA-62 | BRL-CAD: 03starseeker * r45428 10/brlcad/trunk/CMakeLists.txt: If we don't have a defined CMAKE_SIZEOF_VOID_P, assume 32 bit to be safe. |
| 17:59.24 | CIA-62 | BRL-CAD: 03erikgreenwald * r45429 10/brlcad/trunk/CMakeLists.txt: match the endif to the if |
| 18:13.20 | CIA-62 | BRL-CAD: 03r_weiss * r45430 10/brlcad/trunk/ (6 files in 3 dirs): (log message trimmed) |
| 18:13.20 | CIA-62 | BRL-CAD: Changed function nmg_model_edge_g_fuse by renaming it to nmg_edge_g_fuse and |
| 18:13.20 | CIA-62 | BRL-CAD: allowing the magic of a nmg object to be passed in instead of a pointer to a nmg |
| 18:13.20 | CIA-62 | BRL-CAD: model structure. This change allows the function to fuse edge geometry in other |
| 18:13.20 | CIA-62 | BRL-CAD: smaller nmg objects such as an nmg shell or nmg faceuse. The following files |
| 18:13.20 | CIA-62 | BRL-CAD: were changed raytrace.h nmg_simplify.c wdb_obj.c nmg_tri.c nmg_fuse.c |
| 18:13.21 | CIA-62 | BRL-CAD: nmg_bool.c. The purpose of this change is to improve performance of nmg boolean |
| 18:38.16 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 18:43.31 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 18:44.53 | *** join/#brlcad nsd (~nicholas@c-24-0-153-224.hsd1.pa.comcast.net) | |
| 19:23.54 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 19:51.40 | CIA-62 | BRL-CAD: 03r_weiss * r45431 10/brlcad/trunk/src/librt/primitives/nmg/nmg_bool.c: |
| 19:51.40 | CIA-62 | BRL-CAD: Updated function nmg_bool within file nmg_bool.c. This change removes |
| 19:51.40 | CIA-62 | BRL-CAD: unnecessary operations to improve the speed of nmg boolean operations. This |
| 19:51.40 | CIA-62 | BRL-CAD: change will increase the speed of functions such as the mged 'ev' and 'facetize' |
| 19:51.40 | CIA-62 | BRL-CAD: commands. |
| 20:29.39 | CIA-62 | BRL-CAD: 03r_weiss * r45432 10/brlcad/trunk/ (include/raytrace.h src/librt/primitives/nmg/nmg_ck.c): |
| 20:29.39 | CIA-62 | BRL-CAD: Added a new function nmg_vsshell which validates the pointer structures within a |
| 20:29.39 | CIA-62 | BRL-CAD: single nmg shell structure and all structures within. The function nmg_vshell |
| 20:29.39 | CIA-62 | BRL-CAD: was changed to call the nmg_vsshell function. The function nmg_vshell is passed |
| 20:29.39 | CIA-62 | BRL-CAD: a list of shells to validate instead of a single shell. The purpose of this |
| 20:29.39 | CIA-62 | BRL-CAD: change is to allow a single nmg shell to be validated instead of all shells |
| 20:29.40 | CIA-62 | BRL-CAD: within an nmg model. The files raytrace.h and nmg_ck.c were changed. |
| 20:36.28 | *** join/#brlcad Stattrav (~Stattrav@unaffiliated/stattrav) | |
| 21:16.57 | CIA-62 | BRL-CAD: 03r_weiss * r45433 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 21:16.58 | CIA-62 | BRL-CAD: Updated functions nmg_triangulate_model and nmg_triangulate_shell within file |
| 21:16.58 | CIA-62 | BRL-CAD: nmg_tri.c. These changes make the operations of these functions consistent so |
| 21:16.58 | CIA-62 | BRL-CAD: that the difference is only one triangulates an nmg shell and the other |
| 21:16.58 | CIA-62 | BRL-CAD: triangulates all the nmg shells within an nmg model. |
| 21:18.31 | *** join/#brlcad KimK (~Kim__@209.248.147.2.nw.nuvox.net) | |
| 21:20.56 | CIA-62 | BRL-CAD: 03bhinesley * r45434 10/brlcad/trunk/src/libged/alter.c: Added a union to store distinct command argument groupings for each command. This obsoleted some of the command-specific #define flags; I'll fix that later. Started on helper functions for building args. |
| 21:31.30 | CIA-62 | BRL-CAD: 03r_weiss * r45435 10/brlcad/trunk/src/librt/primitives/nmg/nmg_class.c: |
| 21:31.30 | CIA-62 | BRL-CAD: Fixed a bug in function class_eu_vs_s within file nmg_class.c. The mid point of |
| 21:31.30 | CIA-62 | BRL-CAD: the edge was not computed correctly. I also used points near the vertices but |
| 21:31.30 | CIA-62 | BRL-CAD: still on the edge for the fallback if the mid point can not be classified. This |
| 21:31.30 | CIA-62 | BRL-CAD: change improves the success of nmg boolean operations and can be seen when |
| 21:31.30 | CIA-62 | BRL-CAD: running, for example, the mged 'facetize' and 'ev' commands. |
| 22:14.50 | CIA-62 | BRL-CAD: 03r_weiss * r45436 10/brlcad/trunk/src/librt/primitives/nmg/nmg_tri.c: |
| 22:14.50 | CIA-62 | BRL-CAD: Updated the prototype version of the function cut_unimonotone within file |
| 22:14.50 | CIA-62 | BRL-CAD: nmg_tri.c. This is a work in progress and this change is disabled by default. |
| 22:14.50 | CIA-62 | BRL-CAD: Some code cleanup was done and the ability to reverse the direction of loopuse |
| 22:14.50 | CIA-62 | BRL-CAD: was added to correct situations after a loop cut that the direction reverses |
| 22:14.51 | CIA-62 | BRL-CAD: i.e. is cw and should be ccw. This change supports the prototype version of the |
| 22:14.52 | CIA-62 | BRL-CAD: function nmg_triangulate_fu. |
| 22:30.37 | CIA-62 | BRL-CAD: 03brlcad * r45437 10/brlcad/trunk/src/libged/ (CMakeLists.txt Makefile.am zoom/ zoom/zoom.c zoom.c): zoom becomes the guinea piggie. move it into a subdir in preparation for sorting out fully self-contained modular commands. |
| 22:31.19 | CIA-62 | BRL-CAD: 03brlcad * r45438 10/brlcad/trunk/src/libged/zoom/zoom.c: remove unnecessary headers and useless doxy file comment |
| 22:32.36 | CIA-62 | BRL-CAD: 03brlcad * r45439 10/brlcad/trunk/src/libged/zoom/zoom.c: technically, ged_private.h is no longer in this dir |
| 22:40.28 | CIA-62 | BRL-CAD: 03brlcad * r45440 10/brlcad/trunk/src/libged/ (ged_private.h vutil.c zoom/zoom.c): move _ged_do_zoom() out of vutil into zoom.c since that's the only place it's used, no longer needing private decl. rename to zoom(). |
| 22:44.03 | CIA-62 | BRL-CAD: 03brlcad * r45441 10/brlcad/trunk/src/libged/zoom/zoom.c: reduce and simplify |
| 22:44.51 | CIA-62 | BRL-CAD: 03brlcad * r45442 10/brlcad/trunk/src/libged/zoom/zoom.c: don't need a db to scale the view |
| 22:58.13 | CIA-62 | BRL-CAD: 03brlcad * r45443 10/brlcad/trunk/src/libged/zoom/zoom.c: make sure we set sf before testing its value, simplify validity to the two boundaries while treating the edge case as inside. |
| 22:59.44 | CIA-62 | BRL-CAD: 03brlcad * r45444 10/brlcad/trunk/include/vmath.h: ws |
| 23:51.16 | *** join/#brlcad mafm (~mafm@83.Red-83-54-79.dynamicIP.rima-tde.net) | |