Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding absorption #177

Open
yakir12 opened this issue Nov 6, 2018 · 4 comments
Open

Adding absorption #177

yakir12 opened this issue Nov 6, 2018 · 4 comments

Comments

@yakir12
Copy link

yakir12 commented Nov 6, 2018

Obstacles will have to have a absorption index, or a complex refractive index with an absorption coefficient. They'll affect the intensity property of the Photon particle. Particles will need to therefore "die" following a probability depending on their intensity.


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@Datseris
Copy link
Member

Datseris commented Nov 6, 2018

Have a look at the function escapetime. Here is how you can do what you already want, without implimenting anything new:

Define high level function absorption(p, bd, t, a, idx) with idx a vector of indices of the obstacles that perform absorbsion and a a vector of the absorbsion each collision with obstacle i does.

Loop in time while calling bounce! . After each bounce check if i in idx and if yes remove absorpsion a[i] from some initial counter.

Is this enough or not? What is the scope of the issue, what is the intended application? If it is the "time until the particle dies" then the above covers that.

@yakir12
Copy link
Author

yakir12 commented Nov 6, 2018

If it is the "time until the particle dies"

It is not. The application is that every obstacle absorbs some of the energy of every photon. And that affects the amount of energy the photon will "give" to the retina when it passes through it. So to me it seems like it should be an intrinsic property of the photon and obstacles and not a value we keep track of in a specific function. It would mean that people will use that function and only that function for any kind of ray tracing. This might be fine but sounds forced, instead of giving the photon and obstacles their natural properties.

But, look, this functionality is heavily coupled to the splitting behavior I mentioned before. Where a particle spawns an additional particle every time it hits an obstacle: splitting and absorption are possible only if the particle has energy. So unless we implement energy first then there's no point in absorption (or splitting).

@Datseris
Copy link
Member

Datseris commented Nov 6, 2018

Alright, we have to open up an issue about Photon particle then, before continuing this.

@Datseris
Copy link
Member

Datseris commented Nov 6, 2018

Here is my suggestion: why don't we start with the Photon thing: just implement the particle, nothing else. No Retinas, no "obstacle absorption property" or anything else. Just the Photon type. Then, we will see how many things are already possible without adding nothing new. I bet there will be many things that will be possible.

EDIT: please open an issue to discuss the design and implementation of Phonon before actually putting in work. It will help tremendously. List the properties you want and the functionality you want this object to support and then we can think about how.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants