Volumetric light

[JosLeys]

What method is used in M3D to realize VL?

[Sockratease]

What method is used in M3D to realize VL?

I have no idea, but if I know Jesse - it's in the ReadMe file enclosed with the program   

[Jesse]

What method is used in M3D to realize VL?

I tried to find the origin post where the lightmap method was presented, but eben with sitesearch on a big searchengine does not helped  

But the basic method is simple:
Precalculate a lightmap for a positional light as example.  Store the maximal distance of rays from the lightsource until they hit an object in a spherical map or in 6 sides of a boxmap (just what you like to, you only have to cover the directions to the scene you have to test later).
In the usual raymarcheer you test then for each raysteps (use substeps to get a better resolution) if the light is visible by testing if the stored distance is bigger then the actual distance to the current rayposition and add then the light amount.

For global lights i make a rotationmatrix from the light angles and define a center point of the current scene.
Then one map is calculated with an offset towards the center according to the [x,y] map position and towards the light to start the lightray marching.  The maximum ray distance with offset subtracted is then stored to the map.
On usual raymarching the center is subtracted from the actual position and this vector is rotated.
One vector component can be directly used for distance comparison, the other orthogonal components are multiplied to get from scene size to the map size, beeing the pixel coords for the map to get the max distance.

[Jesse]

I have no idea, but if I know Jesse - it's in the ReadMe file enclosed with the program   

No, but i want to spend some more time to the readme in future, also to list all the useful links to this forum that are getting lost that fast...

[JosLeys]

Here is what I think is a cheaper alternative:

Define a spotlight with a source point, a direction vector and an angle to define the cone of light projected by this spotlight.
For every ray it is not too difficult to find the intersection points (if any) with the cone of light. (be careful to only take those points on the cone on the side of the direction vector)

As the light in the cone may be partly shadowed, take n reference points on the ray equally spaced between the two intersection points, and run the DE algorithm starting from the spotlight source in the direction of the reference point on the ray. If we reach the point there is no obstruction, and that point on the ray earns 1 'point'. If none of the n points on the ray experience any obstruction, we have a total score of n. This normally is very cheap to calculate, just stop the ray marching if we get further than the reference point on the ray.

We then blend the colour of the endpoint of the main ray (from the viewpoint) with the colour of the light, taking into account the score that we just obtained for the ray in question.

A possible way to do this is :
define k=1-exp(0.25*(tcone1-tcone2)*score/n) where tcone1 and tcone2 are the distances on the ray to the intersection points (tcone2>tcone1)

Then blend the colours : if k=1 you get the light colour, if k=0 you get the colour of the ray's endpoint, (so no change).

Here's an example :

[Jesse]

Here is what I think is a cheaper alternative:

Define a spotlight with a source point, a direction vector and an angle to define the cone of light projected by this spotlight.
For every ray it is not too difficult to find the intersection points (if any) with the cone of light. (be careful to only take those points on the cone on the side of the direction vector)

Yes, a spotlight would have the advantage of a small cone, so you would only need to calculate fewer rays, and/or you can get a high resolution with a relative small map.

As the light in the cone may be partly shadowed, take n reference points on the ray equally spaced between the two intersection points, and run the DE algorithm starting from the spotlight source in the direction of the reference point on the ray. If we reach the point there is no obstruction, and that point on the ray earns 1 'point'. If none of the n points on the ray experience any obstruction, we have a total score of n. This normally is very cheap to calculate, just stop the ray marching if we get further than the reference point on the ray.

But this is the great advantage of maps, once you have calculated the distances from the lightsource, you don't need to do any further steps, just compare the distance to the light to the one stored in the map! (the map position is given by the angle to the light)
This way you calculate only one ray for every direction of light send out by the source.

[JosLeys]

Well, I have no map to calculate and store, which I presume takes time also, does it not?

Forgot to mention that I'm using Ultrafractal for all this.

[Jesse]

Well, I have no map to calculate and store, which I presume takes time also, does it not?

Of course, the overall rendering time inclusive map calculation is about 2 to 3 times higher then without volumetric fog.
I think this is still quite fast.  What is the time difference in your image about?

Forgot to mention that I'm using Ultrafractal for all this.

Ok, without prestoring option this map-method is not possible.
With good DE's you might skip some raysteps when all DE's towards the lightsource exceeds the limit for the next step...
it would depend on the actual scene if this improves the speed much.

[JosLeys]

The image I posted took about 3 seconds without the volumetric spotlight, and 20 secs when I add the spotlight with n=20, so checking for obstruction on 20 points on every ray when it passes through the light cone. For n=5 the time goes down to about 12 secs.
I'll have to read up on how to do your light map as it appears very efficient.