<p>Both of your two proposed solutions are valid, with different properties. Which you choose is purely a design issue. The difference is that your probabilistic rays/particles (1) don't need to store their energy: they all have the same amount of energy, so you can just count particles to sum the energy. Your partial particles (2) need to store an energy so you can split them up.</p>

<p>The advantage of 1 is that each ray is smaller. Also, it's easy to keep track of where the energy ended up, because you can use the intersections where the ray was dropped.</p>

<p>Because you're only reflecting or discarding rays, the number of in-flight rays will decrease with each bounce, so you might find it harder to keep batches of rays together for better SIMD or parallel performance.</p>

<p>Also, because you're probabilistically discarding rays, you'll get a lot more noise in your results for the same number of rays.</p>

<p>The second solution is closer to a traditional ray-tracer, so you may find it easier to use existing algorithms and code. You can use fewer primary rays, and the number of rays in each batch is constant at first (but gets worse when the brightnesses start to reach zero).</p>

<p>It's also a lot more efficient to track multiple frequencies this way. If you give each ray a spectrum or RGB energies, the material can have a different effect on different colours without you having to fire multiple batches of rays (duplicating the ray intersection work).</p>

<p>On the other hand, you'll need a second data structure to count up where energy was absorbed, if you want to track that.</p>

<p>In your place, I'd probably use the second solution, but it depends on what other software you're trying to integrate with e.g. an existing ray-tracing library or photon representation, and what you need to do with the output/results.</p>

CC BY-SA 3.0
2015-11-13T16:50:33.490Z
2015-11-13T16:50:33.490Z
Dan Hulme
<p>I have some material which I want to represent as a collection of spheres (atoms) and a particle of light (photon). I'm firing this particle and checking for the collision against atoms. What should happen if collision occurs? I see two possible solutions:</p>

<ol>
<li>Light particle can be either absorbed or reflected, depends on some probability.</li>
<li>Light particle reflected, but loses some part of it's energy. When the energy is zero, particle is absorbed.</li>
</ol>

<p>Update: I want to see the general behavior of the particle. The particle itself I want to simulate as a ray. Also I want to simulate a variety of materials - I think small spheres placed near each other can lead to specular material. Big spheres placed far from each other can lead to Lambertian material and subsurface scattering. The light transport is nor stochastic nor full valuated - a ray after collision will reflect correctly, not randomly. In the end I want to see the number of photons reflected, transmitted, scattered and their direction.</p>

CC BY-SA 3.0
2015-11-06T15:45:31.220Z
There are many possibilities, so you should describe more:

- What kind of material you aim at (basic Lambertian, or mirror specular  + glossy specular + multi-transparent layers + diffuse + subsurface scattering ?)

- What paradigm of "light particule" you want to stick with (monochromatic photons, polychromatic photons, chuck of light ray) 

- What paradigm of "light transport algorithm" you want to stick with (from pure stochastic with each basic behavior in 0/1, to full valuated).
Fabrice NEYRET
CC BY-SA 3.0
2015-11-06T16:29:05.437Z
@FabriceNEYRET I updated the post. But what do you mean under monochromatic photons, polychromatic photons, full valuated light transport algorithm?
nikitablack
CC BY-SA 3.0
2015-11-06T16:37:54.630Z
a monochromatic photon (i.e. a "real photon") die or not, but cannot fade. a polychromatic photon is a bag of synchronized photon, each can have his own fate.  "full valued" means that you transport the faded amount of energy (i.e. the optical geometry flux) rather than throwing coins to either absorb or reflect unfaded.
Fabrice NEYRET
<lighting><material>
Does light particle loses energy when it hits something?
nikitablack
# Does light particle loses energy when it hits something?

(Asked by: username_0 on 2015-11-06)

I have some material which I want to represent as a collection of spheres (atoms) and a particle of light (photon). I'm firing this particle and checking for the collision against atoms. What should happen if collision occurs? I see two possible solutions:

1. Light particle can be either absorbed or reflected, depends on some probability.
2. Light particle reflected, but loses some part of it's energy. When the energy is zero, particle is absorbed.

Update: I want to see the general behavior of the particle. The particle itself I want to simulate as a ray. Also I want to simulate a variety of materials - I think small spheres placed near each other can lead to specular material. Big spheres placed far from each other can lead to Lambertian material and subsurface scattering. The light transport is nor stochastic nor full valuated - a ray after collision will reflect correctly, not randomly. In the end I want to see the number of photons reflected, transmitted, scattered and their direction.

**Tags:** lighting, material

> **Comments:**
> **username_1**: There are many possibilities, so you should describe more:  - What kind of material you aim at (basic Lambertian, or mirror specular  + glossy specular + multi-transparent layers + diffuse + subsurface scattering ?)  - What paradigm of "light particule" you want to stick with (monochromatic photons, polychromatic photons, chuck of light ray)   - What paradigm of "light transport algorithm" you want to stick with (from pure stochastic with each basic behavior in 0/1, to full valuated).  
> **username_0**: @username_1 I updated the post. But what do you mean under monochromatic photons, polychromatic photons, full valuated light transport algorithm?  
> **username_1**: a monochromatic photon (i.e. a "real photon") die or not, but cannot fade. a polychromatic photon is a bag of synchronized photon, each can have his own fate.  "full valued" means that you transport the faded amount of energy (i.e. the optical geometry flux) rather than throwing coins to either absorb or reflect unfaded.  

---

## 1 answers

### Answer by username_2 on 2015-11-13. Score: 3 | Accepted answer

Both of your two proposed solutions are valid, with different properties. Which you choose is purely a design issue. The difference is that your probabilistic rays/particles (1) don't need to store their energy: they all have the same amount of energy, so you can just count particles to sum the energy. Your partial particles (2) need to store an energy so you can split them up.

The advantage of 1 is that each ray is smaller. Also, it's easy to keep track of where the energy ended up, because you can use the intersections where the ray was dropped.

Because you're only reflecting or discarding rays, the number of in-flight rays will decrease with each bounce, so you might find it harder to keep batches of rays together for better SIMD or parallel performance.

Also, because you're probabilistically discarding rays, you'll get a lot more noise in your results for the same number of rays.

The second solution is closer to a traditional ray-tracer, so you may find it easier to use existing algorithms and code. You can use fewer primary rays, and the number of rays in each batch is constant at first (but gets worse when the brightnesses start to reach zero).

It's also a lot more efficient to track multiple frequencies this way. If you give each ray a spectrum or RGB energies, the material can have a different effect on different colours without you having to fire multiple batches of rays (duplicating the ray intersection work).

On the other hand, you'll need a second data structure to count up where energy was absorbed, if you want to track that.

In your place, I'd probably use the second solution, but it depends on what other software you're trying to integrate with e.g. an existing ray-tracing library or photon representation, and what you need to do with the output/results.


---

