If would likely need to track them well (not sure from this article/video if that's the case?) to be useful in that scenario...
Drawing a splodge in roughly the location (not sure if there's range info either? I doubt it if it's passive) overlaid on the video likely won't cut it...
I feel this is a little disingenuous, especially given it then says QGIS takes ~10 mins to open the same file and then doesn't give a time for ArcGIS.
As much as I have respect for QGIS and what it's capable of (especially given its price point!), it's not always that fast: I recently looked into why drawing polygons interactively was so insanely slow (with the help of perf on Linux) in QGIS, and the code was basically suffering from 'painters algorithm' and is just a really inefficient implementation with loads of redraw and 'find-nearest-point' overhead.
I wouldn't be surprised (as another example: until recent releases, Blender's OBJ format importer was similarly orders of magnitude slower than other DCC apps OBJ importers - e.g. it would take > 2 hours to import a large .obj file other apps could ingest fully in under 30 seconds) if the code path just hasn't been looked at and optimised.
Minor nitpick: Rolls-Royce military jet engines are made at Bristol (ex-Bristol Aerospace), but civilian turbines like the Trent series are made in Derby.
> On June 11th Mark Warner, the vice-chair of the Senate Intelligence Committee, said that General Joshua Rudd, who leads the National Security Agency and the Pentagon’s Cyber Command, had told him that Mythos “broke into almost all of our classified systems, not in weeks, but in hours”.
std::shared_ptrs can also (because they're implicitly for sharing) alias, so the compiler has to assume the worst and emit loads in other cases, and there's no way (unless a newer C++ version has introduced it and I haven't noticed?) to use '__restrict__' with shared ptrs.
which is effectively the bible, and has been for years (I wrote mine and moved into the VFX industry when the Second edition was still out! - I feel old now)
Yeah, passing std::shared_ptr by value in a multi-threaded setup can have a lot over overhead due to them being copied and destroyed a lot, and the fact that the atomic ref count value modifications effectively cause a write back to cache and can cause contention.
Should pass them by const refs really to avoid this.
Inverse is still 0.0 technically, but yes, there is a trick you can use with Inf and SIMD to mask them out, so Inf is sometimes used.
However, I'd just condition it for the moment.
so:
invDirX = dirX != 0.0 ? 1.0 / dirX : 0.0;
etc, etc for each dimension.
Obviously doing the != 0.0 comparison is not great, as it suffers from potential issues again (especially if you have denormals), but you can generally get away with it I've found in most cases.
JFYI: Your inverse ray direction calculation is not NaN-safe: if rays are completely axis-parallel in one dimension, so the direction value is 0.0 for that axis, you'll be doing the val / 0.0 which results in a NaN...
Also, as you're using full double/f64-precision all the time, you're leaving a fair bit of performance on the table: transcendentals (sin(), cos(), etc) in particular - can be a lot slower than when using f32, and generally double precision can be special-cased to particular areas of the renderer that need it (curve, sphere intersection, and some situations where volume scattering produces very small distances).
Yes, as long as you were happy to wait 30s for an exposure (on tripod), by 1850 (most of those photos were > 15 years later than that) there were many photos of good quality.
Look at photos of Crystal Palace in 1851 for example.
Not really, as it's only once per file system mount, whereas those Windows and MacOS files are sprinkled in most directories with images and almost every non-network drive directory respectively.
(Ex-CG/VFX renderer dev)