| 01:25.24 | *** join/#brlcad archivist (~archivist@host81-149-189-98.in-addr.btopenworld.com) | |
| 02:48.28 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 07:41.03 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 13:00.12 | CIA-63 | BRL-CAD: 03tbrowder2 * r46850 10/brlcad/trunk/doc/docbook/lessons/es/mged03_utilizar_comando_in.xml: remove period from title |
| 13:10.30 | CIA-63 | BRL-CAD: 03tbrowder2 * r46851 10/brlcad/trunk/doc/docbook/books/en/BRL-CAD_Tutorial_Series-VolumeIV.xml: add missing title |
| 14:15.41 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) | |
| 14:42.31 | ``Erik | (union (difference s1 s2) s3) <-- that looks keen to me :D |
| 14:52.00 | CIA-63 | BRL-CAD: 03bob1961 * r46852 10/brlcad/trunk/ (13 files in 5 dirs): |
| 14:52.00 | CIA-63 | BRL-CAD: Changed the way dm-ogl and dm-wgl were handling zclipping (i.e. setting a value |
| 14:52.00 | CIA-63 | BRL-CAD: in the GL_MODELVIEW matrix). This adversely affected lighting if the window |
| 14:52.00 | CIA-63 | BRL-CAD: bounds were relatively big and was noticeable when viewing geometry in shaded |
| 14:52.00 | CIA-63 | BRL-CAD: mode. Added GUI components in Archer to control the front and back zclipping |
| 14:52.00 | CIA-63 | BRL-CAD: planes. |
| 14:54.15 | *** join/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 15:10.14 | brlcad | ``Erik: heh, that adds potentially an order of magnitude to the processing time parsing those expressions |
| 15:10.48 | brlcad | especially nasty for expressions with more than a dozen operations (which is VERY common) |
| 15:12.29 | ``Erik | (define-symbol-macro + union) |
| 15:13.25 | brlcad | then it's back to the same issue of what to use for union and intersection :) |
| 15:14.20 | ``Erik | but but but lisp is magic fairy dust that makes everything right! :D |
| 15:53.33 | CIA-63 | BRL-CAD: 03bob1961 * r46853 10/brlcad/trunk/src/libtclcad/tclcad_obj.c: Don't need the extra call to go_draw() in the interlay section of go_refresh_draw(). |
| 16:42.05 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 18:20.51 | CIA-63 | BRL-CAD: 03r_weiss * r46854 10/brlcad/trunk/src/conv/g-vrml.c: |
| 18:20.52 | CIA-63 | BRL-CAD: Updated the 'g-vrml' converter. Corrected some bugs in the count of regions |
| 18:20.52 | CIA-63 | BRL-CAD: converted and regions attempted. Also added a count of the number of failed due |
| 18:20.52 | CIA-63 | BRL-CAD: to bombs. Changed the logic so that if errors occur during conversion, the |
| 18:20.52 | CIA-63 | BRL-CAD: conversion will continue and at the end report the number of errors. |
| 18:33.22 | CIA-63 | BRL-CAD: 03bob1961 * r46855 10/brlcad/trunk/src/libdm/dm-wgl.c: Fix a cut-n-paste error. |
| 18:33.37 | *** join/#brlcad abhi2011 (~chatzilla@x033197.its-s.tudelft.nl) | |
| 19:41.56 | abhi2011 | is there a macro for testing if a floating point value is exactly 0 |
| 19:42.00 | abhi2011 | not just near 0 |
| 19:42.14 | abhi2011 | or is fabs(f) == 0 the only option |
| 20:05.01 | brlcad | abhi2011: there is no way you can portably guarantee that a floating point value is exactly 0 |
| 20:05.34 | brlcad | relying on that usually implies a flaw in the math/logic that doesn't account for the actual nature of floating point math |
| 20:06.58 | brlcad | fabs(f) == 0 isn't necessarily reliable either (and doesn't address the issue of wanting to rely on zeroness) |
| 20:08.19 | abhi2011 | well I want to check if the passed mass is 0 |
| 20:08.22 | abhi2011 | by the user |
| 20:08.54 | brlcad | so check with ZERO(), what's the issue? |
| 20:09.16 | abhi2011 | ok, there is a line about it not being recommended in the comments |
| 20:10.15 | brlcad | well it's not recommended, but it's certainly better than trying to fake it with things like fabs(f) == 0 :) |
| 20:10.32 | abhi2011 | yup, stuck that into the code now |
| 20:10.51 | brlcad | the issue is that you haven't defined how close to zero you have to be |
| 20:11.07 | abhi2011 | yeah, the epsilon |
| 20:11.14 | brlcad | that's why it recommends against it (instead favoring NEAR_ZERO() with the tolerance defined) |
| 20:11.32 | brlcad | is 0.0000000000000000001 "close enough"? |
| 20:11.54 | brlcad | how about 6 zeros, 3 zeros, 1 zero? .. |
| 20:12.05 | abhi2011 | ok, hehe yeah, bullet wroks with sngle point precision so it should be :P |
| 20:12.50 | brlcad | ZERO() still uses a tolerance |
| 20:13.12 | abhi2011 | yes it used near_zero(), well i think the less than and greater than comparisons should be fine |
| 20:13.27 | abhi2011 | for the == stuff ZERO() is good enuf |
| 20:13.30 | brlcad | it just uses a hard-coded platform-varying tolerance that should roughly equate to "roughly as precise as this hardware is capable of being" .. |
| 20:13.38 | abhi2011 | ah nice |
| 20:13.43 | brlcad | which is often not what the math actually affords, that makes it dangerous |
| 20:14.52 | brlcad | the hardware may be capable of 1e-40, but if you take a square root of something a few times, or use single precision, or pass through print specifiers, or divide, or ... you might end up with a "zero" 1e-7 |
| 20:15.02 | brlcad | and ZERO() will be false |
| 20:17.43 | brlcad | if bullet uses single precision (really? wtf..) |
| 20:17.55 | brlcad | then you should probably define your tolerance |
| 20:18.15 | brlcad | single precision is much looser than most hardware is cabable of ... |
| 20:19.01 | brlcad | I'd suggest something like 0.001 |
| 20:19.23 | brlcad | that's roughly sqrt(FLT_EPSILON) |
| 20:20.15 | brlcad | 0.0005 if you want to be consistent with the rest of BRL-CAD |
| 20:21.17 | abhi2011 | ok |
| 20:21.25 | abhi2011 | yes, bullet can be set to double precision |
| 20:22.00 | brlcad | that'd probably be better as a default |
| 20:22.15 | brlcad | maybe have a -f fast flag that will use single precision instead |
| 20:23.20 | abhi2011 | right ok, btw if 0.0005 is default , there should be a constant that defines it |
| 20:24.25 | abhi2011 | will have a look at vmath.h |
| 20:25.08 | abhi2011 | hmm ok FLT_EPSILON & DBL_EPSILON |
| 20:48.23 | CIA-63 | BRL-CAD: 03abhi2011 * r46856 10/brlcad/trunk/src/libged/simulate/ (simphysics.cpp simulate.c simulate.h): |
| 20:48.23 | CIA-63 | BRL-CAD: modified simulation code to persist velocities between each simulation step Now |
| 20:48.23 | CIA-63 | BRL-CAD: bullet does a single step of simulation and saves the state of rigid bodies as |
| 20:48.23 | CIA-63 | BRL-CAD: well as updates the transforms in the dbthis will allow rt to shoot rays in the |
| 20:48.23 | CIA-63 | BRL-CAD: updated model |
| 21:02.08 | brlcad | abhi2011: it's not a constant globally defined for that tolerance, each application defines the tolerance |
| 21:02.43 | brlcad | in your case, you're running as a libged command, so you can just use whatever tolerance is presently set |
| 21:02.49 | brlcad | ``Erik: http://brlcad.org/tmp/rtvstie.png |
| 21:03.26 | brlcad | lots of off-by-many on that center poly |
| 21:05.08 | brlcad | abhi2011: ged_wdbp->tol->dist is there the current tolerance should be stashed |
| 21:26.31 | *** join/#brlcad abhi2011 (~chatzilla@ip170-79-211-87.adsl2.static.versatel.nl) | |
| 22:01.20 | *** join/#brlcad alex_joni (~alex_joni@emc/board-of-directors/alexjoni) | |
| 22:33.52 | *** part/#brlcad n_reed (~molto_cre@BZ.BZFLAG.BZ) | |
| 22:55.06 | CIA-63 | BRL-CAD: 03abhi2011 * r46857 10/brlcad/trunk/src/libged/simulate/simulate.c: fixed a crash due to usage of memory before mallocing it |
| 23:31.32 | *** join/#brlcad sparrW (~kvirc@pdpc/supporter/active/sparr) | |
| 23:47.56 | brlcad | 277MB step file churning away... giggity |
