What is 'ray marching'? *spawn

[London Geezer]

What's ray marching?

 

[Shifty Geezer]

Ray-tracing lite.

 

[VFX_Veteran]

Ray-tracing lite.

Huh? What are you talking about. It's not ray-tracing 'lite". It's more like ray-tracing 'uber'. For every ray cast, you are stepping along that ray in small steps seeing what's in shadow and what isn't -- accumulating opacity as you go. It's extremely expensive -- more so than just regular ray tracing.

 

[TomRL]

Huh? What are you talking about. It's not ray-tracing 'lite". It's more like ray-tracing 'uber'. For every ray cast, you are stepping along that ray in small steps seeing what's in shadow and what isn't -- accumulating opacity as you go. It's extremely expensive -- more so than just regular ray tracing.

The Order has Ray-tracing?

 

[iroboto]

Huh? What are you talking about. It's not ray-tracing 'lite". It's more like ray-tracing 'uber'. For every ray cast, you are stepping along that ray in small steps seeing what's in shadow and what isn't -- accumulating opacity as you go. It's extremely expensive -- more so than just regular ray tracing.

I did a quick google and this came up:

Ray casting, ray tracing and ray marching all tend to be used interchangeably as a generalists catch-all term for a rendering process which relies on computed lines of intersection, but there are subtle distinctions implied when speaking precisely.

Ray casting is a process where points of intersection with a line are computed analytically, using formulas of intersection.

Ray marching is a specific algorithm, a variant on ray casting where samples are taken down a line to test for intersections or other criteria. This is easier to implement and allows for speed optimizations via number of samples, but is not as precise even when large numbers of samples are used.

Ray tracing is a more complex series of tasks which uses ray casting and/or ray marching to compute not only the point of intersection between origin and object surface (or voxel cell etc) but which iteratively computes secondary and tertiary rays, which can be used to collect data used typically (but not exclusively) for calculation of reflected or refracted light.

 

[HTupolev]

Huh? What are you talking about. It's not ray-tracing 'lite". It's more like ray-tracing 'uber'. For every ray cast, you are stepping along that ray in small steps seeing what's in shadow and what isn't -- accumulating opacity as you go. It's extremely expensive -- more so than just regular ray tracing.

In like-for-like purposes, not really. The equivalent "non discrete steps" approach for ray-sampled scattered volumetric lighting would be to calculate where a cast ray will intersect the next ray volume edge (instead of sample point tests to see whether you're inside or outside); the resulting data would permit results that are more precise than what Lords of the Fallen is doing.

 

[VFX_Veteran]

In like-for-like purposes, not really. The equivalent "non discrete steps" approach for ray-sampled scattered volumetric lighting would be to calculate where a cast ray will intersect the next ray volume edge (instead of sample point tests to see whether you're inside or outside); the resulting data would permit results that are more precise than what Lords of the Fallen is doing.

What are you talking about exactly? Are we discussing the Order's approach to volume lighting compared to Lords of the Fallen for which one is superior?

 

[HTupolev]

What are you talking about exactly? Are we discussing the Order's approach to volume lighting compared to Lords of the Fallen for which one is superior?

No, I'm responding to your claim that ray marching is ray tracing uber.

You argued that point by comparing sampling a bunch of points on a ray going in and out of light volumes, to calculating where a ray intersects opaque geometry. I responding by pointing out that that's not a like-for-like task; a better comparison would be with a ray-casting method that calculates where the cast ray intersects the boundaries of the light volumes.

 

[VFX_Veteran]

I did a quick google and this came up:

All brute-force volumetrics that use any kind of secondary ray tracing (i.e. finding shadows rays, indirect diffuse rays, etc..) per step is more expensive than just simple ray-tracing. Anyone who has worked with it to any degree of complexity will tell you that.

 

[VFX_Veteran]

No, I'm responding to your claim that ray marching is ray tracing uber.

You argued that point by comparing sampling a bunch of points on a ray going in and out of light volumes, to calculating where a ray intersects opaque geometry. I responding by pointing out that that's not a like-for-like task; a better comparison would be with a ray-casting method that calculates where the cast ray intersects the boundaries of the light volumes.

Ray-marching of any kind of mesh that has a volume will be more expensive than not stepping through a volume and just testing for intersections. Not sure why this is even an argument. If I took a scene that had nothing but opaque objects and ray-traced the objects, recorded the time (assuming a basic material shader on each object) and then converted all objects to volumes and marched through them, it would take longer to render the scene. Not only would you have to test for intersections but you'd have to compute the color/opacity of each step along the ray by stepping through the volume to get the overall color of that pixel. In essence, calling the shader several more times per ray.

My argument is that ray marching isn't less expensive than ray tracing so I wouldn't call it ray-tracing "lite".

 

[HTupolev]

Not only would you have to test for intersections but you'd have to compute the color/opacity of each step along the ray by stepping through the volume to get the overall color of that pixel. In essence, calling the shader several more times per ray.

If you're running something only once in the ray-cast case, then you're obviously carrying out a very different task than in the marching case. We're talking about cases where the two approach are used for similar things.

You seem to be thinking of this distinction:

We're talking about this distinction:

 

[VFX_Veteran]

If you're running something only once in the ray-cast case, then you're obviously carrying out a very different task than in the marching case. We're talking about cases where the two approach are used for similar things.

You seem to be thinking of this distinction:

We're talking about this distinction:

No. I'm not talking about the best optimal way to ray march.

I'm talking about ray marching vs ray tracing. In your drawn out examples.. ray tracing would be the upper right. Fire a ray, hit something, evaluate a shader, and return the color. Done.

I'm talking about the lower right image ( btw, you left out marching from the start to the end point for that polygon) For each step in that polygon, you'd need to reevaluate the shader for every step... you'd also have to accumulate opacity until you reach a threshold. And that's not even considering firing indirect rays to see what neighboring objects' color may contribute to that step's color. That's more expensive.

 

[HTupolev]

No. I'm not talking about the best optimal way to ray march.

I'm talking about ray marching vs ray tracing. In your drawn out examples.. ray tracing would be the upper right. Fire a ray, hit something, evaluate a shader, and return the color. Done.

Nobody here is talking about ray tracing as the full process of rendering out opaque geometry; they're talking about the ray trace itself, as in the method of calculating where a ray intersects a piece of geometry. How that technique is applied to what part of the rendering process is left unspecified in the term "ray tracing", in this conversation.

I'm talking about the lower right image ( btw, you left out marching from the start to the end point for that polygon)

I didn't leave out anything; the lower right image represents what people mean by "ray tracing" for the same task that "ray marching" would be applied in the context of this sort of volumetric lighting*. If the polygon represents a slice of a light volume, the "ray tracing" method would calculate where it enters and leaves the light volume and use that information to figure the amount of scattered light it should be seeing. Meanwhile, the left side image (top and bottom) would show something more like what Lords of the Fallen is doing with ray marching; sample regularly along the ray to see whether the ray is currently inside or outside a light volume. Same basic goal, but determining "in volume" and "outside of volume" using somewhat different techniques.

*I'm aware that LotF restricts the region of marching through a light to the region within the light's area of influence (ignoring shadowing), which is probably why you chose the bottom right as the "ray marching". Imagine instead that the overall images I made are all completely contained within the light attenuation region, and the rectangle is something like a light (or shadow, whichever) shaft from the light cutting through the plane of the image.

 

[VFX_Veteran]

I didn't leave out anything; the lower right image represents what people mean by "ray tracing" for the same task that "ray marching" would be applied in the context of this sort of volumetric lighting*.[/b] If the polygon represents a slice of a light volume, the "ray tracing" method would calculate where it enters and leaves the light volume and use that information to figure the amount of scattered light it should be seeing. Meanwhile, the left side image (top and bottom) would show something more like what Lords of the Fallen is doing with ray marching; sample regularly along the ray to see whether the ray is currently inside or outside a light volume. Same basic goal, but determining "in volume" and "outside of volume" using somewhat different techniques.

So you are talking about the techniques for light volumes in games! That's where the misunderstanding is coming from. I'm not talking about the specifics of how LoTF does their volume light implementation. I was responding to a poster that mentioned in the general sense "ray marching is ray tracing 'lite'". Taking game implementations out of the discussion, ray-marching is more expensive than just ray-tracing as you would not only have to trace a ray, but also march through a volume.

 

[HTupolev]

Taking game implementations out of the discussion

Forums > Embedded 3D Forums > Console Forums > Console Games

ray-marching is more expensive than just ray-tracing as you would not only have to trace a ray, but also march through a volume.

Which you've mostly supported as being more expensive courtesy of the sorts of tasks that you might do at each step (i.e. generate new rays based on atmospheric properties). That might make ray marching a more natural fit for more-expensive algorithms in offline renderers, but it's not a strong argument that ray marching is more expensive in and of itself.

Data structures play a big part, and sometimes traversing a spatial-sample representation (in the case of LotF, via shadow mapping) can be a cheaper way of getting satisfactory results than calculating intersections on polygons.

(Personally, I think it's way too contextual to make any sort of general quality statements. It has similarities to a frequently-domain versus time-domain discussion.)

 

[Shifty Geezer]

Forums > Embedded 3D Forums > Console Forums > Console Games

This...

Which you've mostly supported as being more expensive courtesy of the sorts of tasks that you might do at each step (i.e. generate new rays based on atmospheric properties). That might make ray marching a more natural fit for more-expensive algorithms in offline renderers, but it's not a strong argument that ray marching is more expensive in and of itself.

...and this...

Data structures play a big part, and sometimes traversing a spatial-sample representation (in the case of LotF, via shadow mapping) can be a cheaper way of getting satisfactory results than calculating intersections on polygons.

...and this!

You can do volumetric multisampled raytracing (which I suppose VFX would call Ray Marching) and accumulate any data you want. However, they are fundamentally different algorithms that approach the same spacial testing in a similar way by evaluating spacial properties along a line. Raytracing works with 'infinite' precision at the mathematically correct level, while Ray Marching breaks the ray of evaluation into discrete steps that doesn't get exact boundary tests.

For volumetric lighting at a finite resolution, ray marching makes sense (although you can also achieve the same with 3D textures/voxel data which is another way of dividing the space into smaller units of resolution), but it can't produce ray-traced images and it's categorically wrong to say Ray Marching is like Ray Tracing Uber. It's a a simplified form of tracing algorithm developed for speed that can't do the accurate surface tests Ray Tracing can.

I can only assume that VFX_Veteran has a different professional terminology to realtime graphics where Ray Marching is used for volumetrics in a way his Ray Tracing softwares aren't.

 

[upnorthsox]

Forums > Embedded 3D Forums > Console Forums > Console Games

Is that considered ray tracing or ray marching?

 

[VFX_Veteran]

Just stopped by to say that the whole argument was about semantics?

In the CGI world, I don't believe I would be wrong with the way I use the terms 'raymarching' and 'raytracing'.

If it means something else in the gaming world, I'm completely oblivious to it. But my definition shouldn't be considered inaccurate just because one works in gaming and I work in film. CGI, after all, came up with the term in the first place..

In my experience, raymarching volumes to achieve very good results has always been more expensive than raytracing itself. In this short (using Renderman), we used raymarching for the smoke on Road Runner's trail (0:33).

It took hours and hours and hours to render it alone (we split the asset out of the scene). In some shots we had to use Houdini's Mantra to render the volumes as Renderman was dog slow at ray-marching volumes at that time.

Contrast that with this shot (0:54) where most of the screen space is used up for ray-tracing reflections.. and it didn't take nearly as long.

 

[sebbbi]

You can analytically calculate ray end/start points of solid transitions (ray cast). After you know these transition points, you can ray march between them to cast secondary atmospheric rays (to account in-scatter).

 

[milk]

In this short (using Renderman), we used raymarching for the smoke on Road Runner's trail. It took hours and hours and hours to render it alone (we split the asset out of the scene). Contrast that with this shot (0:54) where most of the screen space is used up for ray-tracing reflections.. and it didn't take nearly as long.

That's like saying a car is faster than a plane because your car trip from spain to france took less time than the flight from New York to Hong Kong.
Different algorithym names do indeed carry different inferred meaning from industry to industry, but they all have an actual "pure" definition, and ray tracing, although not comonly aplied to volume rendering, is actually capable of doing that too. So given the same work load (volume rendering) which algo will perform better depends on the details of the implementation of each, and the data structure being processed. That's basically what the other guys are trying to say.