
Ray-Strips: A Compact Mesh Representation for Interactive Ray Tracing (2007) [pdf] - all2
http://gamma.cs.unc.edu/RS/paper_rt07.pdf
======
all2
The important bits can be found at the end of the paper;

> 6.2 Analysis and Limitations

> The results above show that Ray-Strips are an efficient representation for
> our tested complex benchmarks. In practice, the memory improvements gained
> from using Ray-Strips are highly dependent on finding sufficiently long
> triangle strips to build the hierarchy on. Obviously, this makes our
> approach unsuitable for models without any mesh connectivity (e.g. without
> any shared vertices). In that case, the Ray-Strip representation shown in
> Section 4 becomes an indexed triangle list with a standard BVH (just with
> the addition on the 2-byte header storing the triangle count) and
> performance gains are lost. However, the memory overhead added is only very
> small.Therefore, it is unlikely that there will be a significant performance
> loss compared to using an indexed triangle list to start with.

> Our current implementation uses the stripification library Stripe[0], which
> was designed for rasterization and unlike many newer approaches works on
> general meshes without limitations on the input. Since the computed strips
> can be sub-optimal for ray tracing,it should be quite possible to further
> improve the performance of our approaches by designing a stripification
> algorithm that chooses strips based on ray tracing criteria.

> As presented in Section 3 and 4, our system uses a BVH with axis-aligned
> bounding boxes as the high-level hierarchy, but is important to note that in
> principle any acceleration structure can be used for the Ray-Strips. We find
> that a BVH usually provides a reasonable compromise between rendering speed,
> flexibility and ease of use. It is also easily updateable so that dynamic
> scenes can be handled efficiently. If maximum performance for a static scene
> is desired, a kd-tree may be a better choice and might reduce the memory
> footprint slightly. Note that Ray-Strips can be updated in the same manner
> as BVHs, but have the limitation that mesh connectivity cannot change in the
> animation, e.g. objects cannot “break”.

[0] I can't find this anywhere on the internet. Here is the DOI for the IEEE
paper cited (which does not mention this library), DOI:
10.1109/VISUAL.1996.568125

~~~
carterschonwald
heres a random search result that is code that cites that paper for its own
strip generation

[https://github.com/zeux/meshoptimizer/blob/master/src/stripi...](https://github.com/zeux/meshoptimizer/blob/master/src/stripifier.cpp)

source: went to [https://sci-hub.tw/10.1109/VISUAL.1996.568125](https://sci-
hub.tw/10.1109/VISUAL.1996.568125)

then searched one of the author names + github

paper title and authors are Optimizing Triangle Strips for Fast Rendering
Francine Evans Steven Skiena Amitabh Varshney

------
Derek_MK
A sort of ELI5 on this for those that may not be familiar with any of this:

Ray tracing algorithms require checking to see if a ray will intersect with
objects in a scene. This takes a LOT of time, and if you want this to be
_interactive_ ray tracing (e.g. in a game, where you need a frame drawn in a
very short time), you have to find ways to reduce the number of objects you're
comparing the ray against.

A lot of the time this includes culling algorithms, which essentially give you
very quick ways to say that a number of objects have literally no way of being
intersected by a ray, so you can ignore them. There's also things like
bounding volume hierarchies (BVHs), which says things like, if a ray doesn't
intersect with a given massive invisible cube that contains objects, then it
can't possibly intersect things contained in that cube.

This is a bit different of a solution. If I'm understanding it right, this
involves simplifying the representation of the objects themselves, so that
something that was once a lot of triangles to be checked individually, can now
be checked as one object. This means that a) you don't have to check for as
many intersections, and b) it uses a lot less memory.

~~~
Jasper_
There's also the huge issue of computing the material shading once you've
intersected the triangles. Rasterization has the convenient property that all
pixels in the draw are coherent with the same material. That isn't true with
raytracing, especially diffuse materials where the rays scatter everywhere. So
your texture lookups are much more random compared to rasterization. This is
why Disney's Hyperion added "ray sorting", to bring back some memory coherency
to the problem. The current approaches to real-time raytracing, like NVIDIA's
RTX, do not have ray sorting.

The benchmarks on scenes I have seen have shown that triangle intersection is
only 5-10% of the time spent, with shading and texture bandwidth being the
rest. So I'm skeptical that accelerated geometry tests will solve the
raytracing problem.

~~~
berkut
Not quite the full picture...

Yes, rays bouncing off diffuse/glossy surfaces (incoherent rays) do mean
texture accesses are much more random, but at the same time it means you can
approximate them very easily, by loading much lower mipmap levels, or even
switching to a "constant" overall colour after a certain number of bounces.

Whilst Hyperion does utilise ray sorting due to this, it was also due to
Disney's insistence on using PTex for their texture mapping (instead of using
UVs), which itself requires highly coherent texturing points to be performant.

Other CG/VFX companies are using pathtracing without ray sorting with Arnold,
and many others are using Renderman RIS which does a limited amount of Ray
batch sorting, but that pretty much tails off after 2/3 bounces, and you're
left with ray/shading batches of 1, so Renderman's implementation of ray /
shading point sorting is much more limited.

Whilst it is true that in some cases, ray / primitive / BVH intersection
proportion of overall render time is as low as 5-10%, it's more normally in
the 15-40% range, but this obviously depends on scene complexity and shading
complexity. And this is for high-end VFX with highly complex materials: For
interactive rendering where you could bake down a lot of materials to single
maps (or even primvar mesh vertex attributes like Manuka does), the shading
overhead would be a lot less.

------
aphextim
A little bit off topic but I recently saw something regarding a Ray-tracing
engine built inside of the game Factorio.

Check it out here -
[https://www.youtube.com/watch?v=7lVAFcDX4eM](https://www.youtube.com/watch?v=7lVAFcDX4eM)

~~~
pixelpoet
The Factorio guys are just down the road from us at Corona Renderer (a top ray
tracing engine) in Prague, I guess we should hang out and talk ray tracing
sometime :)

------
geuszb
This was 2007. Is this used in production these days? If not, what else is
used instead?

~~~
gmueckl
Most systems that I am aware of use a plain BVH. Memory requirements for the
acceleration structure are not that much of a concern in most cases. Memory
hogs typically are (in descending order) volumetric data (smoke/fire/...),
textures and only then geometry. And because a BVH leaf node typically
contains a few triangles, the BVH itself is always smaller than the geometry
data.

------
melling
More raytracing resources:

[https://github.com/melling/ComputerGraphics/blob/master/ray_...](https://github.com/melling/ComputerGraphics/blob/master/ray_tracing.md)

------
srib
I wonder if any of this is implemented in OpenVDB[0]?

[0] [https://www.openvdb.org/](https://www.openvdb.org/)

~~~
gmueckl
No, OpenVDB solves the completely unrelated problem of keeping huge volume
data sets in memory for efficient monte carlo sampling. This ray strip paper
deals with tiangulated surface meshes, which are completely unrelated data
structures in an unrelated domain (2d surfaces embedded in a 2d domain versus
a discretely, regularly sampled 3d function).

------
tntn
(2007)

~~~
all2
Fixed.

