| 00:32.06 | CIA-37 | BRL-CAD: 03n_reed * r35284 10/brlcad/trunk/src/libdm/dm-rtgl.c: scaling normals to maintain accurate lighting |
| 01:44.19 | *** join/#brlcad LarsG (n=lars@dial208-99.dialup.nus.edu.sg) | |
| 01:44.28 | *** part/#brlcad LarsG (n=lars@dial208-99.dialup.nus.edu.sg) | |
| 02:17.46 | *** join/#brlcad mike111 (n=mike@cadil21.kaist.ac.kr) | |
| 02:18.08 | mike111 | hi all |
| 03:09.08 | brlcad | hello |
| 03:15.39 | mike111 | hi brclad, how r u? |
| 03:21.02 | brlcad | i'm doing great |
| 03:21.20 | brlcad | at least better than last week ;) |
| 03:21.30 | mike111 | that's good :) . |
| 03:22.37 | mike111 | Does g-stl accept any other units than mm or inches? |
| 03:22.51 | Axman6 | brlcad: problems last week? |
| 03:36.53 | brlcad | mike111: no, the intent there is really just to provide a metric or standard file, not really unit support |
| 03:37.11 | brlcad | Axman6: no matter, just issues |
| 03:37.29 | Axman6 | well, i hope they're all sorted :) |
| 03:37.42 | brlcad | not yet, but hopefully |
| 03:37.44 | mike111 | I thought so. I've got a model in meters, but g-stl exports in mm so the model becomes 1000 larger |
| 03:38.36 | brlcad | mike111: you can set the units in mged before running g-stl and it'll fix that |
| 03:38.50 | brlcad | then set it back |
| 03:39.31 | mike111 | not sure what you mean. I build the model in m units. |
| 03:39.44 | brlcad | I know |
| 03:39.51 | brlcad | i mean if you open the .g file, type |
| 03:40.15 | brlcad | 'units mm', run g-stl, then back to mged and run 'units m' .. it should work fine |
| 03:41.33 | mike111 | if I built the model in meters and then switch to mm mged doesn't scale the model to keep the original size (before units changed)? |
| 03:42.15 | brlcad | nope |
| 03:42.38 | brlcad | the units command just sets the working units, what you want to work with |
| 03:43.00 | mike111 | but sometimes it is easier to work with different units on the same model. |
| 03:43.40 | brlcad | exactly why you can work in mm for a while, switch to 'in' for a particular set of parts, back to "m", put in in a scene being modeling in "ft", etc... |
| 03:43.44 | mike111 | from what you're saying I need to convert everything to the same units otherwise mged will scale the entire model everytime I switch units |
| 03:43.55 | brlcad | no no no |
| 03:44.13 | brlcad | i'm saying you need to run the "units" command |
| 03:44.14 | brlcad | run it |
| 03:44.17 | brlcad | see what it does |
| 03:44.21 | brlcad | it doesn't scale |
| 03:44.28 | brlcad | it just sets the working units |
| 03:45.24 | brlcad | so if you made a 1000x1000x1000 box with "units mm" (the default) .. then type "units m", it'll display as 1x1x1 |
| 03:45.50 | mike111 | then g-stl would still convert an object of 1m length to 1000mm example |
| 03:45.52 | brlcad | which is to say that it didn't scale anything, just changed the working units such that when asked to display that box (which already exists), it displays using those working units |
| 03:46.07 | brlcad | smacks forehead |
| 03:46.13 | brlcad | you're still not getting it :) |
| 03:46.20 | brlcad | set the units to mm |
| 03:46.31 | brlcad | then what you have is exactly what g-stl is assuming you have |
| 03:46.49 | brlcad | no scaling |
| 03:46.55 | brlcad | just different presentation of values |
| 03:47.33 | brlcad | re-read what I suggested and try it: 'units mm', run g-stl, then back to mged and run 'units m' |
| 03:47.45 | mike111 | sure. I'll try that later. |
| 03:47.54 | brlcad | check the value of your objects, you'll see they don't change |
| 03:47.59 | brlcad | they just display with whatever units you set |
| 03:48.13 | mike111 | another question: what's the difference between `sca' and `oscale'? |
| 03:48.15 | brlcad | g-stl doesn't really care about units, it just looks at the value |
| 03:49.30 | brlcad | history, subtle differences -- no practical difference |
| 03:49.51 | brlcad | oscale is intended to be used with object-edit mode, which only applies to combinations |
| 03:51.56 | mike111 | I'm using `sca' with oed, but the manual also mentions `oscale'. |
| 03:52.55 | brlcad | oscale should go away |
| 03:53.23 | mike111 | thanks for clarifying that. :) |
| 04:27.23 | *** join/#brlcad MinstrlGypsy (n=IriX64@bas2-sudbury98-1177593187.dsl.bell.ca) | |
| 05:28.29 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 05:28.29 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 05:28.50 | *** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net) [NETSPLIT VICTIM] | |
| 05:28.50 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT VICTIM] | |
| 05:28.50 | *** join/#brlcad b0ef (n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT VICTIM] | |
| 08:26.41 | CIA-37 | BRL-CAD: 03ralith * r35285 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Fixed reception of keyboard input. |
| 08:40.49 | CIA-37 | BRL-CAD: 03ralith * r35286 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Less emphatic keyboard focus; no longer breaks everything else. |
| 08:45.27 | CIA-37 | BRL-CAD: 03ralith * r35287 10/rt^3/trunk/src/g3d/MainWindow.cxx: Focus render area on application startup, making keyboard camera control work immediately. |
| 08:52.30 | CIA-37 | BRL-CAD: 03ralith * r35288 10/rt^3/trunk/src/g3d/OgreGLWidget.cxx: Reordered constructor initializers and dropped an argument name to quell warnings. |
| 08:55.10 | CIA-37 | BRL-CAD: 03ralith * r35289 10/rt^3/trunk/src/g3d/ (OgreGLWidget.cxx OgreGLWidget.h): Dropped unnecessary cruft left over from past attempts to get the Ogre GL context correctly resized. |
| 09:10.33 | CIA-37 | BRL-CAD: 03ralith * r35290 10/rt^3/trunk/src/g3d/ (CameraMode.cxx CameraMode.h): Replaced broken vertical rotation limits with smooth wraparound. |
| 09:16.01 | CIA-37 | BRL-CAD: 03ralith * r35291 10/rt^3/trunk/src/g3d/CameraModeBlender.cxx: Added rotation limit fix to CameraModeBlender, including changes to prevent horizontal rotation overflow. |
| 09:21.12 | CIA-37 | BRL-CAD: 03ralith * r35292 10/rt^3/trunk/src/g3d/ (4 files): Applied rotation limit/overflow fix to CameraModeMGED and cleaned up earlier tweaks. |
| 09:24.33 | CIA-37 | BRL-CAD: 03ralith * r35293 10/rt^3/trunk/src/g3d/CameraMode.cxx: Added a forgotten but all-important negation that prevents circularIncrement from becoming incredibly overenthusiastic. |
| 09:26.31 | CIA-37 | BRL-CAD: 03ralith * r35294 10/rt^3/trunk/src/g3d/CameraMode.cxx: Doubled correctional offsets in circularIncrement to prevent pervasive view jumping. |
| 09:29.48 | Ralith | that's weird. |
| 09:30.17 | Ralith | the view jumps a ton when vertical rotation crosses Ï/2 |
| 09:39.10 | Ralith | +/- pi/2, that is |
| 09:41.17 | CIA-37 | BRL-CAD: 03Briannew220 07http://brlcad.org * r1583 10/wiki/Main_Page: /* BRL-CAD Wiki */ |
| 09:44.16 | CIA-37 | BRL-CAD: 03ralith * r35295 10/rt^3/trunk/src/g3d/CameraMode.cxx: Simplified some code in the continuing effort to remove the viewjump at a vertical rotation of +/-pi/2 |
| 09:59.47 | Ralith | hm |
| 10:26.09 | *** join/#brlcad PrezKennedyII (i=Matthew@whitecalf.net) [NETSPLIT VICTIM] | |
| 10:26.09 | *** join/#brlcad Ralith (n=ralith@216.162.199.202) [NETSPLIT VICTIM] | |
| 10:26.09 | *** join/#brlcad b0ef (n=b0ef@084202026157.customer.alfanett.no) [NETSPLIT VICTIM] | |
| 10:37.58 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 10:37.58 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 11:18.04 | *** join/#brlcad mafm (n=mafm@74.Red-83-42-152.dynamicIP.rima-tde.net) | |
| 11:28.58 | CIA-37 | BRL-CAD: 03Dloman 07http://brlcad.org * r1584 10/wiki/Main_Page: Bloody spammers :/ |
| 11:31.06 | d-lo_ | Mernin all. |
| 11:40.45 | d-lo | Spammer are stupid. Does anyone really pay attention to spam anyways? |
| 11:43.52 | archivist | yes all the wiki cleaners |
| 11:44.25 | archivist | lock the main page down |
| 11:45.43 | archivist | on my wiki I protect any spammed pages,to stop the buggers from using the same page again |
| 11:46.17 | d-lo | well, the brlcad wiki isn't mine to admin :) |
| 11:48.49 | Ralith | sup d-lo! |
| 11:48.53 | Ralith | I actually caught you! |
| 11:48.55 | Ralith | :D |
| 11:50.03 | d-lo | hides. |
| 11:50.16 | d-lo | Thing are going well I see :) |
| 11:50.29 | Ralith | reasonably. |
| 11:50.46 | Ralith | it's a shame the OpenGL embedding thing didn't work out as well as planned. |
| 11:50.55 | Ralith | but, fortunately, it should be hard to tell the difference. |
| 11:51.09 | Ralith | and there is yet hope for getting it working later on. |
| 11:51.27 | d-lo | Perhaps in time, after a few iterations, you (or someone) will find the key to making the embedded openGL approach work. |
| 11:51.44 | Ralith | I can't work out what's going on with the camera angle such that it flips around every time yaw hits +/- pi/2 though :/ |
| 11:52.05 | Ralith | cleaned up mafm's camera code a good bit looking for it, but no luck yet. |
| 11:52.21 | d-lo | I had a thought this weekend: Since pictures speak a thousand words, why don't you start dropping a medium-rez SS or two on your wiki status log ;) |
| 11:52.41 | Ralith | yeah, I'll do that |
| 11:53.00 | Ralith | about right when I get around to catching up on the log messages themselves >_> |
| 11:53.05 | d-lo | as for the camera, how are you controlling it? |
| 11:53.15 | Ralith | I was able to reuse all mafm's camera control code, fortunately |
| 11:53.28 | Ralith | just had to swap out the OIS related code for its Qt equivalents |
| 11:54.03 | Ralith | and just tonight I fixed keyboard input, so camera control works exactly the same as in original g3d; three selectable modes which each interpret kb/mouse input differently. |
| 11:54.04 | d-lo | good deal. But even after that swap, there are still that eqn problem? |
| 11:54.10 | Ralith | eqn? |
| 11:54.14 | d-lo | equation |
| 11:54.17 | Ralith | O.o |
| 11:54.18 | Ralith | wat? |
| 11:54.26 | d-lo | <PROTECTED> |
| 11:54.38 | Ralith | yeah |
| 11:54.46 | Ralith | that's something that was always in mafm's code |
| 11:55.04 | d-lo | so are you feeding the camera an angle? |
| 11:55.13 | Ralith | I thought I knew what was causing it (there was some arbitrary limits and weird math and special handling of yaw) but scrapping all that didn't help. |
| 11:56.02 | Ralith | uh, lemme check the code |
| 11:56.16 | d-lo | CameraManager ? |
| 11:56.54 | Ralith | no, not using that |
| 11:56.55 | Ralith | CameraMode |
| 11:57.15 | Ralith | looks like we're passing a SceneNode to OgreCamera::setPosition |
| 11:57.47 | Ralith | lemme see if there's a less indirect approach to that. |
| 11:59.36 | Ralith | okay, got something. |
| 11:59.55 | d-lo | Side note: curious. There is a definition for a Vector in the CameraMode class. Pretty sure thats been defined somewhere in the orge suite. :) |
| 12:00.06 | Ralith | not to mention in BRL-CAD. |
| 12:00.10 | Ralith | it's a low priority cleanup issue. |
| 12:00.20 | d-lo | i figured :) |
| 12:02.46 | Ralith | this is weird |
| 12:03.05 | Ralith | it's like mafm wasn't expecting the camera to track it's own position/orientation O.o |
| 12:04.18 | Ralith | oh, I think I see why; rotation *around* a point. |
| 12:04.48 | d-lo | are you referring to the fields inside CameraMode? |
| 12:05.11 | Ralith | no, the complexity of the code from L134-L168 |
| 12:05.45 | Ralith | still, I'm pretty sure there's a cleaner way to do this... |
| 12:07.03 | d-lo | ah, okay. Yeah, the code that is executed once _actionPan is checked against SimpleVector(0,0,0). |
| 12:07.11 | d-lo | *agreed* |
| 12:07.40 | d-lo | I think a breakout of that code into more logical internal functions would pretty much solve the problem. |
| 12:08.38 | d-lo | outside of the Camera pan issue, how else are things going? |
| 12:08.51 | Ralith | I dunno, it's pretty tempting to rework a good chunk of the class from the conceptual level |
| 12:09.05 | Ralith | get it proper support for continuous/instantaneous forms of all movements |
| 12:09.17 | Ralith | pretty good; Qt's a pleasure to work with |
| 12:09.30 | d-lo | I say go for it, depending on how long it will take. |
| 12:09.33 | Ralith | I'm pretty close to strapping mafm's command system into the GUI |
| 12:09.37 | d-lo | Qt = goodness :) |
| 12:09.39 | Ralith | shouldn't be long, unless the math trips me up |
| 12:09.40 | Ralith | yeah |
| 12:09.46 | Ralith | I didn't have that high expectations going in |
| 12:09.51 | Ralith | but DAMN it makes things convenient. |
| 12:10.15 | Ralith | the UI designer app's great, too, and cmake's solid support for the whole stack tops things off nicely. |
| 12:10.37 | Ralith | being able to go from the designer to code and then easily access that code from the implementation is great. |
| 12:13.29 | d-lo | Now, are you sucking in the UI file through cmake directly? |
| 12:13.33 | Ralith | yep |
| 12:13.39 | d-lo | nice. |
| 12:13.55 | Ralith | you edit the UI file, cmake notes the edit time change and reruns uic before the next build. |
| 12:14.03 | d-lo | I was messing around with QT a while ago and the Designer used to have a 'generate code' function... I think they took that out :/ |
| 12:14.04 | Ralith | metaobject handling is the same. |
| 12:14.12 | Ralith | they moved it into a separate tool |
| 12:14.19 | Ralith | now you just run 'uic blah.ui' |
| 12:14.26 | Ralith | and get ui_blah.h |
| 12:15.32 | Ralith | perhaps the most encouraging part of working with Qt was how easy it seems to be to create specialized widgets |
| 12:15.44 | Ralith | as you might've noticed, I made the primitive console its own widget |
| 12:15.53 | Ralith | *very* straightforward |
| 12:16.02 | Ralith | and the doc's are a dream, too. |
| 12:16.07 | Ralith | docs're* |
| 12:18.03 | d-lo | Good stuff man. I gotta get workin now :/ Keep up the good work. You've got good momentum, keep it up :) |
| 12:18.22 | Ralith | kk |
| 12:18.27 | Ralith | seeya next time I'm up way too late ^^ |
| 12:18.48 | d-lo | hah, late == early :) |
| 12:26.52 | CIA-37 | BRL-CAD: 03ralith * r35296 10/rt^3/trunk/src/g3d/ (5 files): Initial attempt at re-integrating command support. Uncertain success. |
| 13:22.46 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) | |
| 13:49.28 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) | |
| 14:05.23 | mafm | d-lo: the Vector definition probably it's just a storage of x and y values, not a full blown class with operations and stuff |
| 14:07.26 | mafm | about the strangeness (180 degree turn) it happens when looking from zenithal view or something |
| 14:07.52 | mafm | due to something like the value of the function (cos, sin, whatever) changing sign |
| 14:09.06 | mafm | you can add a simple check to avoid that artifact if you want, but IIRC the must-have camera modes (mged and blender) were working mostly as expected |
| 14:09.29 | mafm | probably with some advanced functionality missing |
| 14:09.43 | mafm | but well, it's just a matter of extending it |
| 14:10.12 | mafm | other camera modes (orbital/continuous) were a bonus |
| 14:15.38 | CIA-37 | BRL-CAD: 03bob1961 * r35297 10/brlcad/trunk/ (9 files in 4 dirs): These changes get kill, killall, killtree and killrefs working with undo in Archer. |
| 14:25.05 | *** join/#brlcad BigAToo (n=BigAToo@host-69-95-46-65.spr.choiceone.net) | |
| 14:55.28 | *** join/#brlcad samrose (n=samrose@adsl-99-147-180-206.dsl.lgtpmi.sbcglobal.net) | |
| 14:59.14 | d-lo | mafm: I figured that SimpleVector was a 'quick n dirty,' just was wondering why it hadn't been replaced yet, thats all :) And its a full 3D vector. |
| 15:02.37 | CIA-37 | BRL-CAD: 03irpguardian * r35298 10/brlcad/trunk/src/proc-db/human.c: |
| 15:02.38 | CIA-37 | BRL-CAD: Corrected a problem with bounding boxes being placed on the wrong side of the body |
| 15:02.40 | CIA-37 | BRL-CAD: when being made. |
| 15:04.50 | mafm | d-lo: well yes, it's 3d, but it's only storage with 1 operation: http://brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/src/g3d/CameraMode.h?revision=35292&view=markup |
| 15:04.59 | mafm | not nearly as complex as Ogre's |
| 15:05.28 | d-lo | right :) I get that :) |
| 15:05.31 | mafm | maybe I hadn't used brlcad includes by then |
| 15:07.01 | d-lo | no big deal. I was just skimming over the code and noticed that. |
| 15:09.03 | mafm | what I mean is that the idea is to have a lightweight way to pass 3 float coordinates for panning and the like contained in one class (parameter), instead of having to instantiate a full vector class with all of the associated operations |
| 15:47.11 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 15:47.58 | CIA-37 | BRL-CAD: 03n_reed * r35299 10/brlcad/trunk/ (include/dm-rtgl.h src/libdm/dm-rtgl.c): sorting points by color for faster OpenGL drawing |
| 16:43.52 | CIA-37 | BRL-CAD: 03IRPGuardian 07http://brlcad.org * r1585 10/wiki/Main_Page: |
| 16:57.00 | CIA-37 | BRL-CAD: 03IRPGuardian 07http://brlcad.org * r1586 10/wiki/User:IRPGuardian: |
| 16:59.11 | CIA-37 | BRL-CAD: 03brlcad * r35300 10/brlcad/trunk/ (5 files in 5 dirs): |
| 16:59.13 | CIA-37 | BRL-CAD: improve the opengl header tests (which were not working correctly on Mac OS X |
| 16:59.15 | CIA-37 | BRL-CAD: 10.4) to go through AC_CHECK_HEADER instead of being custom AC_COMPILE_IFELSE |
| 16:59.17 | CIA-37 | BRL-CAD: tests. opengl functionality tests occur later on. set GL_CPPFLAGS instead of |
| 16:59.19 | CIA-37 | BRL-CAD: GL_CFLAGS for the header search paths to be consistent/pedantic. |
| 17:04.39 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) | |
| 17:52.50 | CIA-37 | BRL-CAD: 03jdoliner * r35301 10/brlcad/trunk/src/proc-db/surfaceintersect.cpp: Added functionality to find starting points for curve intersections |
| 18:04.35 | CIA-37 | BRL-CAD: 03bob1961 * r35302 10/brlcad/trunk/src/libged/get_obj_bounds.c: Fixed a small memory leak. |
| 18:58.59 | CIA-37 | BRL-CAD: 03brlcad * r35303 10/brlcad/trunk/TODO: unpush rears its head once again, now with an sf tracker (2826720 from victor). additional thought is to allow object creation as part of the unpush in order to retain matrix-less parents. |
| 19:01.52 | CIA-37 | BRL-CAD: 03brlcad * r35304 10/brlcad/trunk/TODO: |
| 19:01.58 | CIA-37 | BRL-CAD: another repeat offender, the ability to really easily checkpoint/backup a .g |
| 19:02.06 | CIA-37 | BRL-CAD: file while editing it via some sort of archive/backup command. something near |
| 19:02.14 | CIA-37 | BRL-CAD: equivalent to an external cp file.g /path/to/backup/dir/file_20100427_021800.g |
| 19:02.18 | CIA-37 | BRL-CAD: with automatic date and timestamping. |
| 19:04.27 | CIA-37 | BRL-CAD: 03brlcad * r35305 10/brlcad/trunk/TODO: consider option to reid/remat/edcodes and potentially others to ignore negative regions |
| 19:04.37 | *** join/#brlcad ornitorrincos (n=ilcra198@archlinux/trusteduser/ornitorrincos) | |
| 19:27.33 | CIA-37 | BRL-CAD: 03brlcad * r35306 10/brlcad/trunk/TODO: add file input support to mv/mvall commands so you can feed them mapping files. this relates to sf request 2827957 |
| 19:29.30 | CIA-37 | BRL-CAD: 03bob1961 * r35307 10/brlcad/trunk/src/librt/prep.c: The rt_prep_parallel routine was returning without releasing RT_SEM_RESULTS in a few places. This was causing a hang in Cliff's bbsize. |
| 19:31.59 | CIA-37 | BRL-CAD: 03starseeker * r35308 10/brlcad/trunk/NEWS: Add Bob's rt_prep_parallel fix to news file. |
| 19:34.52 | brlcad | that's not exactly a user news line |
| 19:35.25 | brlcad | should be worded from the user's perspective, not the code |
| 19:36.11 | starseeker | ok |
| 19:37.26 | CIA-37 | BRL-CAD: 03starseeker * r35309 10/brlcad/trunk/NEWS: Tweak news file. |
| 19:39.20 | brlcad | ah, and that clarifies even more.. :) not a news line |
| 19:39.28 | brlcad | pre-release bug catch |
| 19:42.22 | starseeker | so, no news item? |
| 19:42.33 | starseeker | make_bb would also have triggered it |
| 19:42.57 | brlcad | yeah, then it's a fix for make_bb |
| 19:43.11 | brlcad | remember the last commit comment is the one that gets pulled for the report |
| 19:43.51 | CIA-37 | BRL-CAD: 03starseeker * r35310 10/brlcad/trunk/NEWS: Tweak news file some more. |
| 19:43.57 | starseeker | oh, whoops |
| 19:43.59 | brlcad | ah yeah, the "expand capabilities" line is another |
| 19:44.37 | brlcad | not user visible until it's released, and that is encompassed by the first line |
| 19:45.02 | starseeker | ok, I'll clear it |
| 19:45.47 | CIA-37 | BRL-CAD: 03starseeker * r35311 10/brlcad/trunk/NEWS: bbsize is already mentioned as a new command, don't need extra NEWS line. |
| 19:53.48 | CIA-37 | BRL-CAD: 03irpguardian * r35312 10/brlcad/trunk/src/proc-db/human.c: |
| 19:53.51 | CIA-37 | BRL-CAD: Human model mostly fits into bounding boxes when in the standing position now. |
| 19:53.53 | CIA-37 | BRL-CAD: Rotation matrix is still throwing things off when limbs are moved, causing bounding |
| 19:53.55 | CIA-37 | BRL-CAD: boxes to be rotated around some other point other than the point center. |
| 20:13.11 | *** join/#brlcad ChanServ (ChanServ@services.) | |
| 20:13.11 | *** mode/#brlcad [+o ChanServ] by irc.freenode.net | |
| 20:13.15 | CIA-37 | BRL-CAD: 03erikgreenwald * r35313 10/brlcad/trunk/src/libdm/Makefile.am: move DM_RTGL_* into the WITH_OPENGL block. |
| 20:23.36 | Ralith | mafm: there's no overhead to additional member functions. |
| 20:24.08 | Ralith | you could use the most advanced linalg class available, and if its data was just three coords it'd be just as lightweight :P |
| 20:24.38 | Ralith | mafm: and yeah, all the camera modes basically work great; I just want to have it *completely* working. |
| 20:27.03 | Ralith | mafm: and yeah, it happens precisely on the zenith, or its reflection around the horizontal plane. Any tips as to *where* the simple check goes? I've fiddled around in several places to no avail. |
| 20:59.08 | CIA-37 | BRL-CAD: 03n_reed * r35314 10/brlcad/trunk/ (include/dm-rtgl.h src/libdm/dm-rtgl.c): starting to add support for point heirarchy |
| 20:59.43 | brlcad | ack.. moved DM_RTGL on me |
| 20:59.48 | brlcad | no wunda |
| 20:59.50 | ``Erik | mwahaha |
| 21:00.21 | ``Erik | two of my primary builders weren't seeing GL, so I was getting slews of unresolved symbol glEnable() etc |
| 21:01.06 | brlcad | he accidentally committed it enabled for about a day, probably stale build |
| 21:01.35 | brlcad | i just finished adding a proper --enable-rtgl option for it, was mid-testing |
| 21:02.00 | ``Erik | full autogen cycle didn't pick it up *shrug* but coulda been stale... |
| 21:02.18 | *** join/#brlcad BigAToo (n=BigAToo@pool-96-230-124-27.sbndin.btas.verizon.net) | |
| 21:02.38 | ``Erik | has done so much nonproductive bs crap today, was itching to get a build so he could code again O.o |
| 21:02.55 | ``Erik | fix email access, catch up on email, fill out paperwork and forms out the wazoo, etc |
| 21:09.32 | ``Erik | mmm, finally, a good debugging stack. *sigh* |
| 21:12.12 | Ralith | brlcad: wait, where's OpenGL come in on rtgl? |
| 21:12.17 | Ralith | I thought it was just the raytracer? |
| 21:12.32 | mafm | Ralith: I think that when you create an object of type Blah vs Vector3, the amount of memory that you reserve is different, and things like that |
| 21:12.44 | brlcad | Ralith: it's both |
| 21:12.51 | Ralith | mafm: no, not if it's just a matter of additional member functions. |
| 21:12.56 | brlcad | it uses raytracing to find the surfaces, then uses opengl to display them |
| 21:13.00 | Ralith | brlcad: oh, cool! |
| 21:13.15 | mafm | in this case maybe Ogre::Vector3 doesn't inherit from other classes and so on, but still, you have to include the file and all of it's includes, and you spend more time compiling every time |
| 21:13.50 | Ralith | mafm: building an include file doesn't take much time, and chances are it's already included somewhere else anyway. |
| 21:14.09 | Ralith | not to say that you did badly there or anything |
| 21:14.12 | Ralith | but just fyi. |
| 21:14.21 | Ralith | brlcad: how far along is it? |
| 21:14.33 | brlcad | pretty far, it looks awesome |
| 21:14.37 | Ralith | :D |
| 21:14.52 | Ralith | after SoC I'd like to have a go at stapling it onto g3d |
| 21:15.08 | Ralith | not sure how it'd be made to interact with ogre, though |
| 21:15.36 | brlcad | it'll be a little tricky, but interesting idea |
| 21:15.47 | brlcad | it might be easier to merely staple libdm into g3d |
| 21:15.54 | brlcad | as it is a dm interface |
| 21:16.10 | brlcad | i.e. it'd be a different 3d view renderer instead of ogre |
| 21:16.17 | Ralith | that would be pretty easy. |
| 21:16.30 | Ralith | judging from past experience wrt. adding new Qt widgets |
| 21:16.53 | mafm | well, I decreased compiling times by more than 50% in many projects (not mine) just by removing includes |
| 21:16.57 | mafm | your mileage may vary |
| 21:17.29 | Ralith | I guess the challenge would really be how to keep all the displays sync'd |
| 21:17.41 | mafm | http://www.brlcad.svn.sourceforge.net/viewvc/brlcad/rt^3/trunk/src/g3d/CameraMode.cxx?revision=35295&view=markup -> the camera thingy is here in vertical rotation, IIRC |
| 21:17.41 | Ralith | such that you can swap from one to another and still have all the same stuff visible, same perspective, etc. |
| 21:17.56 | Ralith | mafm: yeah, I know it's in there, but *where* in there? |
| 21:17.58 | brlcad | Ralith: you wouldn't use ogre, you'd use libdm instead of ogre |
| 21:18.02 | brlcad | different render manager |
| 21:18.03 | mafm | when passing some limit pi/2, or 0, or something like that |
| 21:18.03 | Ralith | brlcad: yes, I know |
| 21:18.24 | Ralith | wait |
| 21:18.39 | Ralith | brlcad: so to get Ogre, I'd just write a libdm interface for Ogre? |
| 21:18.54 | Ralith | mafm: no, I already scrapped all that with some code that handles overflow and wraps properly. |
| 21:20.17 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 21:21.15 | mafm | c (3.141592/2.0+0.01) |
| 21:21.17 | mafm | -.008 |
| 21:21.18 | mafm | c (3.141592/2.0-0.01) |
| 21:21.20 | mafm | .011 |
| 21:21.31 | Ralith | ? |
| 21:21.36 | mafm | I think that when changes sign, the direction of the vector changes |
| 21:21.46 | Ralith | when what changes sign? |
| 21:21.49 | Ralith | the direction of what vector? |
| 21:21.51 | mafm | so it looks backwards instead of forwar |
| 21:22.05 | brlcad | Ralith: you still seem to be missing the "libdm instead of ogre" part ;) |
| 21:22.14 | Ralith | brlcad: so, scrapping Ogre entirely? |
| 21:22.19 | brlcad | not scrapping |
| 21:22.32 | Ralith | you were regaling me the other day with how valuable Ogre's optimizations would be O.o |
| 21:22.33 | brlcad | i'm saying you could make it a build-time option to use libdm or use ogre |
| 21:22.37 | Ralith | oh. |
| 21:22.39 | Ralith | that's no fun :P |
| 21:22.41 | brlcad | if you use libdm, you got classic mged displays |
| 21:22.48 | Ralith | rtgl's no classic display |
| 21:22.49 | brlcad | if you use ogre, you get the new stuff |
| 21:23.04 | brlcad | it is in the sense that it's just another libdm interface |
| 21:23.09 | brlcad | you do one, you have them all |
| 21:23.13 | brlcad | it's a pretty simple interface |
| 21:23.20 | mafm | Ralith: do you understand how the camera mode class works, in general? |
| 21:23.28 | Ralith | brlcad: I guess a compiletime option would be acceptable until the BREP-based solution shows up, then? |
| 21:23.35 | Ralith | which could be integrated with Ogre properly? |
| 21:23.41 | Ralith | mafm: I'm pretty sure I do |
| 21:23.48 | brlcad | Ralith: you could certainly integrate what's there with ogre |
| 21:23.55 | brlcad | it just is kinda funky that way |
| 21:24.07 | Ralith | brlcad: I could? Ogre doesn't seem to take well to manual OpenGL calls. |
| 21:24.19 | mafm | the camera is in some point in an sphere of variable radius around the target |
| 21:24.25 | brlcad | so don't make manual opengl calls .. and I think that was more something you were doing wrong :) |
| 21:24.48 | Ralith | probably, but the point stands that it's outside what Ogre's designed to accept. |
| 21:25.09 | mafm | <PROTECTED> |
| 21:25.20 | brlcad | it's not, ogre has point-cloud visualization -- just don't know if it'd perform nearly as well as what it's doing by hand |
| 21:25.35 | brlcad | it basically is just a massive point cloud getting generated |
| 21:25.46 | Ralith | it doesn't wrap a surface around it? |
| 21:25.55 | brlcad | still, it'd be way more useful to integrate libdm instead of ogre, even better to have both run-time toggleable |
| 21:26.12 | Ralith | that's what I was thinking of originally :P |
| 21:26.24 | brlcad | that's not what you said |
| 21:26.27 | Ralith | it would probably be pretty easy to do so, if, as I mentioned, the state tracking could be worked out. |
| 21:26.32 | brlcad | that doesn't involve putting libdm *into* ogre still |
| 21:26.47 | brlcad | it doesn't involve ogre at all really, just swaps between one or the other |
| 21:26.47 | Ralith | that's also not what I said :P |
| 21:27.00 | brlcad | 17:18 < Ralith> brlcad: so to get Ogre, I'd just write a libdm interface for Ogre? |
| 21:27.11 | Ralith | brlcad: as in, have Ogre be a libdm *client* |
| 21:27.18 | Ralith | in the same position as rtgl. |
| 21:27.32 | Ralith | but I was actually referring to before that confusion. |
| 21:27.41 | brlcad | that would defeat most of the benefits ogre brings to the table |
| 21:27.46 | Ralith | ah. |
| 21:28.26 | brlcad | it'd work fine if you had some concept of an abstract graphics display class with one specialization using ogre and another using libdm |
| 21:28.40 | *** join/#brlcad Patmcc19_ (n=chatzill@71-223-63-106.phnx.qwest.net) | |
| 21:28.57 | Ralith | yeah |
| 21:29.00 | Ralith | thus that being where the work lies. |
| 21:36.27 | Ralith | brlcad: how far along is the brep stuff, anyway? |
| 21:41.50 | *** join/#brlcad samrose (n=samrose@c-24-11-185-57.hsd1.mi.comcast.net) | |
| 21:44.26 | Ralith | pokes mafm |
| 21:45.10 | Ralith | mafm: calling lookAt gives the camera a set of coordinates; negative values just mean negative coords. |
| 21:45.13 | *** join/#brlcad jdoliner (n=jdoliner@c-68-51-75-169.hsd1.il.comcast.net) | |
| 21:45.32 | Ralith | mafm: the place the camera's looking at shouldn't even modified by the yaw. |
| 21:46.41 | Ralith | and if the camera was looking backwards, it wouldn't be able to see the object :P |
| 21:47.05 | mafm | I never managed to grasp the meaning of yaw, etc |
| 21:47.13 | mafm | but imagine that your head is the camera |
| 21:47.46 | mafm | when you're behind an object almost at the zenith, and you cross the zenith, your head would be heading downwards |
| 21:48.48 | mafm | what this camera/head does is to rotate, so your head is always up |
| 21:48.48 | CIA-37 | BRL-CAD: 03ralith * r35315 10/rt^3/trunk/src/g3d/ (CameraMode.cxx Console.cxx Console.h): Another apparently effectless simplification of CameraMode and failed attempt to enable console signalling. |
| 21:48.48 | Ralith | mafm: ahhhh. |
| 21:48.48 | Ralith | that makes sense! |
| 21:48.48 | Ralith | thanks. |
| 21:48.48 | Ralith | it modifies the roll. |
| 21:48.48 | mafm | when you pass the zenith you rotate, so the head continues to be "upright" instead of heading downwards |
| 21:48.58 | Ralith | I guess... that's actually desired behavior then, isn't it O.o |
| 21:49.20 | mafm | it was, yes |
| 21:49.28 | Ralith | not always, though |
| 21:49.32 | Ralith | it's certainly not how blender handles things |
| 21:49.36 | mafm | the orbital mode was "invented" by me, didn't try to emulate any other program |
| 21:49.44 | Ralith | this isn't orbital mode |
| 21:49.46 | Ralith | this is *all* modes |
| 21:50.04 | Ralith | (I do love how smooth the view moves in orbital, though ^^) |
| 21:50.31 | mafm | well, let's say that I started with orbital since it's the more comprehensive |
| 21:50.39 | Ralith | nods |
| 21:50.45 | Ralith | I'll twiddle things and see where it goes |
| 21:50.46 | mafm | I didn't care of that weird thing at that point |
| 21:51.02 | mafm | but it turns out that it's a bit strange when happens for the rest of the modes |
| 21:51.06 | Ralith | now that I understand *why* it's doing that, at least conceptually, I should be able to ferret it out. |
| 21:51.28 | mafm | I mean, it's not designed to be specifically at that way, just that I didn't bothered changing it |
| 21:51.32 | Ralith | yeah |
| 21:52.56 | mafm | and IIRC was in one of the parameters of rotation (horz or vert) in the transition at the zenith |
| 21:53.10 | Ralith | parameters of rotation? |
| 21:53.45 | mafm | horzRot, vertRot |
| 21:54.09 | mafm | the variables which hold the position of the camera, having center as base |
| 21:54.36 | Ralith | those are floats; they don't have parameters... |
| 21:55.31 | mafm | well, the right word for you would be "orbital/spherical coordinates", instead of parameters :D |
| 21:55.41 | CIA-37 | BRL-CAD: 03ralith * r35316 10/rt^3/trunk/src/g3d/ (Console.cxx Console.h): Working command input! :D |
| 21:55.52 | Ralith | mafm: oh, you mean "it occurs when vertRot passes the zenith?" |
| 21:55.56 | Ralith | yeah, I noticed that |
| 21:55.57 | Ralith | that is |
| 21:56.01 | Ralith | I noticed the magic value |
| 21:56.05 | Ralith | didn't realize its significance |
| 21:56.46 | mafm | yes, something like that |
| 21:57.22 | mafm | so the check would be to detect the transition and modify the resulting value |
| 21:57.59 | mafm | "when Blah was almost at zenith in past frame and now is past zenith, do whatever" |
| 21:58.55 | Ralith | well, that would have to refer to M_PI |
| 21:59.08 | mafm | maybe you don't have to save state between frames, just compare if the past value of the variable plus delta is bigger than 2*pi, or so |
| 21:59.24 | Ralith | and the only remaining references to M_PI are ones I've already vetted :/ |
| 22:08.19 | mafm | I think that part of the problem is that some coordinate varies between 0 and pi, another between -pi and pi |
| 22:08.22 | mafm | http://en.wikipedia.org/wiki/Spherical_coordinates#Definition |
| 22:08.23 | CIA-37 | BRL-CAD: 03irpguardian * r35317 10/brlcad/trunk/src/proc-db/human.c: Added shoulder joints to bounding box list, giving a (nearly) fully boxed model when standing. |
| 22:08.56 | Ralith | mafm: as far as I can see, I've standardized everything to +/-pi |
| 22:10.13 | mafm | I can't really remember the specifics |
| 22:10.26 | Ralith | no worries, I'll work it out |
| 22:10.32 | mafm | :) |
| 22:10.38 | Ralith | while you're hereâ |
| 22:10.59 | CIA-37 | BRL-CAD: 03ralith * r35318 10/rt^3/trunk/src/g3d/Console.cxx: Added history to the console. |
| 22:11.14 | Ralith | where does the text output used in the original console come from? |
| 22:11.20 | Ralith | it looks like logger output |
| 22:12.13 | Ralith | hm. looks like Logger::attach |
| 22:12.37 | Ralith | which is ObserverSubject::attach? |
| 22:12.52 | Ralith | yep |
| 22:14.47 | mafm | the console was observing the log, yep |
| 22:14.56 | mafm | so you can see things in both places |
| 22:15.17 | Ralith | kk, cool |
| 22:32.50 | Ralith | argh |
| 22:32.55 | Ralith | I hate iterating over STL containers holding const values |
| 22:32.58 | Ralith | I can never get it right :| |
| 22:46.32 | CIA-37 | BRL-CAD: 03brlcad * r35319 10/brlcad/trunk/ (configure.ac src/libdm/Makefile.am src/mged/Makefile.am): (log message trimmed) |
| 22:46.35 | CIA-37 | BRL-CAD: add a proper --enable-rtgl flag to configure that will enable/disable |
| 22:46.39 | CIA-37 | BRL-CAD: compilation of the new rtgl dm interface. it's still tied to opengl (which is |
| 22:46.41 | CIA-37 | BRL-CAD: presently defaulted off), so you have to specify --with-opengl too. |
| 22:46.45 | CIA-37 | BRL-CAD: intentionally did not assign aliases or add to enable-all as a) it's still under |
| 22:46.49 | CIA-37 | BRL-CAD: development, b) it needs more work at least to not hang drawing, and c) there |
| 22:46.53 | CIA-37 | BRL-CAD: still needs to be a way to turn all the dm/fb's on/off consistently with |
| 22:57.24 | CIA-37 | BRL-CAD: 03ralith * r35320 10/rt^3/trunk/src/g3d/ (Console.cxx Console.h OgreGLWidget.cxx): Working, but backwards, log messages in console output. |
| 22:59.55 | CIA-37 | BRL-CAD: 03ralith * r35321 10/rt^3/trunk/src/g3d/Console.cxx: Flipped console message ordering the right way around. |
| 23:02.07 | Ralith | woo |
| 23:02.11 | Ralith | fully functional console :D |
| 23:16.44 | ``Erik | surprisingly easy, huh? |
| 23:21.24 | CIA-37 | BRL-CAD: 03ralith * r35322 10/rt^3/trunk/src/g3d/ (7 files): Dropped some no-longer-relevant code held over from RBGui usage. |
| 23:22.22 | Ralith | ``Erik: yep; mafm's existing command/logging stuff was put together solidly, and Qt is, too, so it was pretty straightforward to glue them together. |
| 23:25.50 | Ralith | G3D has now been completely uncrufted :D |
| 23:25.58 | ``Erik | completely? O.o |
| 23:26.00 | Ralith | oh wait |
| 23:26.01 | Ralith | not quite |
| 23:26.40 | Ralith | there we go. |
| 23:26.48 | Ralith | NOW it's been fully uncrufted. |
| 23:27.05 | CIA-37 | BRL-CAD: 03ralith * r35323 10/rt^3/trunk/src/g3d/ (14 files): Dropped remaining RBGui code and cleaned out CMakeLists. |
| 23:27.07 | Ralith | ^^ |
| 23:34.28 | CIA-37 | BRL-CAD: 03ralith * r35324 10/rt^3/trunk/src/g3d/Commands.h: Removed command reliant on outdated code. |
| 23:45.25 | CIA-37 | BRL-CAD: 03ralith * r35325 10/rt^3/trunk/src/g3d/MainWindow.cxx: Wired the dropdown setting change signal to the ogreView's setFocus slot so the user doesn't have to keep clicking on the render area. |