| 02:05.38 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 02:16.51 | *** join/#brlcad abhi2011 (~chatzilla@117.200.84.170) |
| 05:29.26 | CIA-109 | BRL-CAD: 03abhi2011 * r47438 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simulate.h): Cleaned up some redundant code and completed contact point generation logic. |
| 06:45.02 | *** join/#brlcad abhi2011 (~chatzilla@117.200.92.33) |
| 07:44.22 | CIA-109 | BRL-CAD: 03abhi2011 * r47439 10/brlcad/trunk/src/libged/simulate/ (simrt.c simrt.h simulate.c simulate.h): Fixing some bugs in the contact generation logic. |
| 09:15.33 | CIA-109 | BRL-CAD: 03Johnjones 07http://brlcad.org * r3226 10/wiki/Main_Page: minor edit |
| 09:17.38 | *** join/#brlcad abhi2011 (~chatzilla@2002:6ee3:d46a::6ee3:d46a) |
| 12:56.34 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r3227 10/wiki/Main_Page: Reverted edits by [[Special:Contributions/Johnjones|Johnjones]] ([[User talk:Johnjones|Talk]]); changed back to last version by [[User:Sean|Sean]] |
| 12:56.37 | CIA-109 | BRL-CAD: 03Sean 07http://brlcad.org * r0 10/wiki/Special:Log/block: blocked [[User:Johnjones]] with an expiry time of infinite (account creation disabled, e-mail blocked): Spamming links to external sites |
| 13:25.55 | *** join/#brlcad jordisayol (~jordisayo@unaffiliated/jordisayol) |
| 13:51.28 | *** join/#brlcad abhi2011 (~chatzilla@117.200.88.67) |
| 14:00.23 | abhi2011 | finally, the box-box case seems to be working : http://imageshack.us/photo/my-images/407/force.png/ |
| 14:00.30 | abhi2011 | one box falling on another |
| 14:01.02 | abhi2011 | this is using contact points, normals, and penetration depth only(all 3 got using raytracing) |
| 14:01.31 | abhi2011 | except for the normal which is simply the velocity direction |
| 14:02.05 | abhi2011 | of whichever body, Bulletr considers to be body B in a colliding pair |
| 14:02.22 | abhi2011 | s/Bulletr/Bullet |
| 14:04.38 | abhi2011 | will try dropping a sphere now and check if the manifold is generated at the correct point on its surface |
| 14:13.07 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3228 10/wiki/User:Abhijit: /* Log : Nov 5th */ |
| 14:15.37 | brlcad | abhi2011: that is totall awesome :) |
| 14:16.04 | abhi2011 | woops, bad screen shoot :P |
| 14:16.17 | abhi2011 | *shot |
| 14:17.21 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3229 10/wiki/User:Abhijit: /* Log */ |
| 14:19.03 | abhi2011 | so the linear velocity approach you suggested , helps avoid a lot of raytracing and thus each iteration is much faster |
| 14:19.57 | abhi2011 | a slowdown is evident only when a big box falls directly on an even larger box, in which cased the contact region is quite large and a large number of rays need to be shot |
| 14:21.07 | abhi2011 | it can be optimized however by shooting rays inwards from the periphery of the overlap region and as soon as about 4 points are got, the density of the rays can be reduced (for shooting near the inner regions etc) |
| 14:21.23 | abhi2011 | maybe it can be yet be optimized to real time :) |
| 14:33.14 | brlcad | should be possible -- the biggest time is going to be prep setup |
| 14:34.48 | brlcad | without prep, you could shoot 100000 rays and still remain interactive on most models |
| 14:35.54 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3230 10/wiki/User:Abhijit: /* Log */ |
| 14:36.28 | abhi2011 | so you mean, I should not prep ? |
| 14:37.01 | abhi2011 | since the bounding box function will work without prep |
| 14:37.09 | brlcad | you have to prep :) |
| 14:37.17 | abhi2011 | oh hmm :P |
| 14:37.25 | brlcad | well, you have to prep to shoot rays |
| 14:37.33 | abhi2011 | yeah for rt , have to prep |
| 14:37.40 | brlcad | if the boxes don't even overlap, then definitely .. don't prep, don't shoot rays :) |
| 14:37.51 | abhi2011 | yes |
| 14:39.01 | abhi2011 | if the boxes move even by a millimeter, there is no way to update a tiny part of the model saved for raytracing, (after prep ) ? |
| 14:39.33 | abhi2011 | so like, if anything moves, the raytracing process needs to be done all over again ? |
| 14:41.07 | abhi2011 | I do that currently, but was wondering if its at all possible to modify a part of the model and then prep only that part (after the whole scene is prepped, but something has moved - in the next physics iteration, )which would be faster |
| 14:43.20 | CIA-109 | BRL-CAD: 03Abhi2011 07http://brlcad.org * r3231 10/wiki/User:Abhijit: /* Log Nov 5th, more info */ |
| 14:43.54 | brlcad | yeah, we've talked about adding support for cache objects but it's a fairly complex subject |
| 14:44.03 | abhi2011 | ok |
| 14:44.28 | brlcad | you'd have to cache per object and have some way to quickly determine whether a cache is invalid and for even medium-sized objects, it's almost faster to just reprep |
| 14:44.30 | abhi2011 | possible a warm start kind of thing, rather than a complete cold start from scratch each time |
| 14:44.47 | abhi2011 | oh ok |
| 14:45.04 | brlcad | the dominant time is setting up the spatial partitioning, which does have to change with every change to the scene |
| 14:45.29 | abhi2011 | but will it change drastically for millimeter scale movements |
| 14:45.42 | brlcad | no way to know |
| 14:45.50 | abhi2011 | ok |
| 14:46.04 | brlcad | if it pops into a different cell, it could be a drastic change to the spatial partitioning |
| 14:46.14 | abhi2011 | yeah |
| 14:46.31 | brlcad | would have to employ a completely different spatial partitioning algorithm, something more tuned for incremental updates |
| 14:46.52 | abhi2011 | ok |
| 14:47.03 | brlcad | generally don't perform as well for static scenes, but they can be updated more quickly ... |
| 14:47.07 | brlcad | something maybe for down the road |
| 14:47.25 | abhi2011 | yes :) |
| 14:47.29 | brlcad | but I suspect cpus will be faster before that happens to the point that it won't matter or some other solution will present itself ;) |
| 14:47.40 | abhi2011 | hehe yeah , true |
| 14:48.05 | brlcad | that new power7 server I was playing with earlier in the week was impressive, giving about 512x512 at 30fps |
| 14:48.22 | brlcad | 30fps raytraced :) |
| 14:48.40 | abhi2011 | oh wow |
| 14:49.00 | abhi2011 | 64 cores you said ? |
| 14:49.11 | brlcad | not the fastest I've seen, and you can get a WHOLE lot faster with polygonal models, but for full shotline (solid) raytracing, that's pretty impressive |
| 14:49.27 | abhi2011 | ok |
| 14:49.36 | brlcad | yeah, 64 cores |
| 14:49.39 | abhi2011 | how many solid were there in the scene |
| 14:50.30 | brlcad | technically I believe it's 8 cpus with 2 cores per cpu and 4 asynchronous threads per core |
| 14:50.59 | abhi2011 | ok |
| 14:51.15 | brlcad | so not much faster than the fastest workstation you can already buy today |
| 14:52.14 | brlcad | maybe a dozen solids, it wasn't a huge model, but even a complex model with a few thousand regions (and thousands of prims) was >10fps iirc |
| 14:52.42 | abhi2011 | oh , thats pretty cool :) |
| 14:52.46 | abhi2011 | <PROTECTED> |
| 14:52.50 | abhi2011 | caustic rt i think |
| 14:53.07 | abhi2011 | on FPGAs |
| 14:53.12 | brlcad | yeah, there's a bunch of them |
| 14:54.00 | brlcad | the stats become completely different when you only consider triangle mesh models, and even further still only consider making pretty pictures (i.e., first hit only) |
| 14:54.26 | brlcad | both things that *substantially* make things faster, but aren't practical for analysis or solid ray tracing |
| 15:57.37 | starseeker | ponders trying to get his hands on an IBM T221 |
| 17:17.37 | starseeker | ``Erik: know anything about how to hook up a T221 to a modern machine? |
| 17:31.22 | cvds_ | is there an easy way to combine rpp with 2 arb6 in between ? |
| 20:07.03 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.159) |
| 20:51.00 | *** join/#brlcad abhi2011 (~chatzilla@117.200.80.107) |
