Does light particle loses energy when it hits something? 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:


Light particle can be either absorbed or reflected, depends on some probability.
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.
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.