That’s a good suggestion. Maybe the light quality info can be used to color the output image. Might also be possible to have a sample image and modify it to see what the impact of the CRI or TM30 does to it.
1 Thank
Crazy how good AI tools have gotten for this kind of stuff. Thanks for putting that together!
Would be awesome to get to something like that. Something like this would be relatively simple to build for formula-based estimates, but it’s much more difficult for a fully ray-traced model. To have it update in real time, the hardware requirements would be astronomical, even by 2030 standards!
We discussed using progressive caching in an online app for the hardware bottleneck earlier. Maybe there are some (significant) optimizations to make it run faster, or perhaps a hybrid UI that uses simpler formulas for unseen permutations and cached data for ones that have already been done.
Will have to give it some thought.
Well this is the brute force solution…
I would say a 2D slice is sufficient
And thre are many symmetry axis in the beam even with a square emitter you only have to calculate 1/8 and then “mirror” copy it.
Lots of potential for optimization.
they did this and it is highly misleading.
It is not Possible to “simulate” how a picture would look like under a light with given CRI/TM30 (if you don’t have a Hyper spectral image as a source)
True. A FEA is by definition a brute force solver.
Breaking it down into 2D slices around the center would definitely make it much faster to process, but then it becomes a different thing. The reason for using an FEA over simpler approximations is that it is much better at modeling complex multivariate systems and produces near photorealistic results with the given input.
The main issue here is that a 2D approximation around the central axis doesn’t have a good way to model out of plane, oblique rays, which is most of them. On big reflectors with small emitters, it’s not a big deal. but when you have small reflectors with relatively large emitters, the effect is much bigger.
The effect of these out of plane, oblique rays is that they define the transition between the hotspot, corona and spill. With a 2D model, you end up with sharp delineations, like in the mock-up you shared. Perhaps it’s possible to model the transition formulaically, but I’m too dumb and lazy to figure that out.
I’m not opposed to building something like that, but it’s worth noting that the output would not be the same.
Fair point on the simulated image. I would guess that on the site, they assume that the light source for the image is an ideal light source. In reality, it’s not. Probably good directional info as a “fun” thing, but yea, I see your point.
3 Thanks
Waht is Perfect?
and
We would still not know the spectral reflectance of the pigments or the objects in the photo.
For example, something that looks yellow could reflect a combination of red and green wavelengths, or it could reflect only yellow light at 589 nm, or both.
If it reflects only 589 nm and your light source is an RGB LED that does not emit this wavelength, it will appear black.
On the other hand, if it reflects only red and green wavelengths and your light source is a sodium lamp or a yellow LED, it will also appear black. In other words, yellow light could be illuminating a brightly yellow object, yet the object would still appear dark because its reflectance spectrum does not overlap with the illumination spectrum.
These are extreme examples, but they illustrate why this approach does not make sense when the source is an RGB image.
Oh just to go from Linear to “perceived brightness(and color)” is a whole other can of worms.
1 Thank
Makes sense. It would have to assume that the colors in the images are only made up of single wavelengths because there’s no way to tell the ratios. I would expect real world objects rarely just reflect a single wavelength, so they would look off. Either way, sounds like it would be out of scope for this project.
Linear still counts as photorealistic 
. I apply the ACES filmic tone mapping curve and a gamma correction for the monitor. Looks good enough to me after blinding shining lights in my office. Easy enough to adjust later if need be.
1 Thank
You may be tired of ideas by now, but just one more: by assigning small roughness values to OP one can simulate imperfect smooth reflectors (there is always light beyond spill). Would it make sense to add ‘roughness’ parameter to the front lens to mimick diffusion films, dust and the like?
1 Thank
Possible do a web version of this ? nice concept
2 Thanks
Ideas are great!
I can include a surface roughness factor to the SMO reflector. Effectively a microscopic OP effect.
A diffusion film would both absorb and scatter the light. If I’m thinking about it correctly, it would be a reduction in transmissivity and a blurring on all of the light leaving the front. There’s also an effect that the angle has on the scattering and absorption. I can add that too in the next build.
1 Thank
Thanks! That’s a popular request. Currently trying to figure out the best way to implement that.
1 Thank
Would reducing the iterations by an order of magnitude or two - as a relatively quick low-res result, to be replaced in the cache by hi-res computed in the background later - help or even work at all?
But then you probably thought about it already…
1 Thank
Sorry for not responding on Reddit. Just had a chance to try out this simulator–wow this is a fantastic tool! I have no doubts about the technical accuracy of the simulation, and just have a few suggestions about (mostly) presentation.
-
It would be extremely helpful to have an index/glossary of ALL terms and definitions. The ReadMe file already contains lots of good info, but some important definitions (e.g., hotspot/corona being defined by fraction of peak intensity) are left implicit, or require scrolling through the code to find the relevant annotations. I recognize that writing this up would entail a lot of work, but might be worthwhile to improve usability by folks who are less physics- or computer-savvy.
-
Whenever I boot up the app, the window extends beyond my screen and requires dragging to access the full-screen button, which reduces the window size enough to fit inside my screen. Additionally, the graphic within the window is quite scrunched-up and unreadable–the only way for me to see the data was to request that the output be saved. It would be nice if the app could automatically fit to the user’s screen, or offer the option for the user to adjust window size.
- The existing cutoffs for hotspot/corona do not seem to agree well with human perception. Here’s the central beam of a S2+ SFT25R, with the darker circles indicating the hotspot/corona and corona/spill cutoffs computed by the program; corresponding points are marked in red in the plot.
It looks like both cutoffs are much too wide, and I would instead suggest cutoffs of 0.9 for the hotspot, and 0.1 for the corona, which would be closer to the green marks in the plot.
The underlying issue really is that a multiplicative cutoff doesn’t provide a physically sensible way to define the corona/spill boundary. To see this, suppose that one defines a cutoff at 0.01x peak intensity. Then, consider a very floody setup where the reflector is barely (just a few times) bigger than the emitter. Almost the entire spill beam has more than 0.01x the peak intensity, and would thus be marked as corona!
- This is a question rather than a suggestion: when simulating the B35AM in a S2+ smooth reflector, I got a beam with a pronounced hole in the center, surrounded by a very bright ring. Is this an artifact of the FEA, or a feature of the modeling? The real-world B35AM does make the same dark hole due to gaps between the 4 dies, but such a hole is not surrounded by a bright ring.
2 Thanks
Indeed. Another complication is that many physical laws are dimension-dependent: for example, intensity scales with the area of the reflector in 3D, but only scales with length in 2D. Thus, if you dilate the reflector 2x, you’d see a 4x intensity boost in 3D, but only 2x in 2D.
I’ve actually written a calculator that explicitly computes the beam profile in a 2D setup, and there are substantial differences in how the beams look. In particular, the much-brighter spill is due to the difference in scaling mentioned above, and the sharper corona-spill transition (plus faster-falling hotspot) is due to absence of oblique, out-of-plane rays.
Fortunately, many relevant attributes (such as peak intensity) are easily calculable without computing the whole beam profile, and some features (e.g., hotspot and corona boundaries) can be defined in a dimension-invariant way.
1 Thank
When you’re at it, please, please get 50 mm 3° one for the M21K :-). Easier to cut straight…
2 Thanks
It can be useful to add models of today popular flashlights.
As for TIR and glass, probably there is a way to make approximations for this parameter, in case you’ll get real examples of light spots.
1 Thank
Some very interesting ideas here!
Maybe not quite progressive caching, but there certainly are ways to save some computation by taking advantage of the self-similarity of the setup. For example: if one LED+reflector combination is just a scaled-up copy of another, you know that the beam profile doesn’t change. If the LED is made brighter/dimmer, the beam profile doesn’t change. If you have already simulated one LED in a reflector, then simulating a slightly bigger LED in the reflector should require computing just the extra area, taking advantage of earlier work.
Formulas are hard because physically sensible ones are extremely complex, and therefore hard to discover and interpret. One must simplify them and sacrifice some accuracy, which is what I did in the math underlying @six7’s website. In particular, I used a few data points to manually pin down some numerical constants in the over-simplified formulas.
Maybe a sensible approach is to just collect a lot of data in the form of, say, (reflector parameters, beam parameters), and try to have AI do some sort of nonlinear regression to detect a pattern. I’m sure that it would find some formula that is not physically correct, but serves as an extremely good approximation to the correct relation. Even a piecewise-linear interpolation among the data points would be good enough for the purposes of most users.
All good. Thanks for the suggestions!
-
Absolutely. I’ll update it with the next release. There’s been a bunch of updates and the documentation is out of date. Definitely shouldn’t need to sift through the codebase to know what everything means
-
This is something I’ve been meaning to address. The default window size is 1800 x 1000 pixels (just under 1080p) and scaling is terrible. I need to come up with a better way of fitting everything. I’m thinking a way to fix this would be to create a tab for the setup and another for the results. This way I’m not trying to fit everything on a single page.
-
Good point. Currently, the hotspot is the point at 50% intensity and the corona is the point where the reflected light drops to 1%. There’s a setting for the threshold buried deep in the settings. I think I’ll add a the formulaic calculation of hotspot and corona and add a toggle to display it on the plot. Maybe set the multiplicative threshold as a slider to play around for visualization or something.
-
What your seeing is aliasing. It’s an artifact of lowish resolution and high LES to reflector size ratio. The way to get rid of it is to reduce the wall grid resolution (no, this won’t speed up processing ) or increase the emitter resolution. Maybe I can add an automated test for this to give a warning when aliasing is detected.
This is the effect of emitter resolution on the S2+ and B35AM:
16x16 grid at 0.1 degree angular resolution with a wall grid of 128x128 (default is 512x512).
Fixes aliasing. Wallshot looks blocky and you lose some detail on the hotspot to corona transition.
16x16 emitter grid at 0.05 degrees angular resolution, default wall grid of 512x512.
This is what you saw. Weird hole in the middle and candela is way overestimated:
32x32 at 0.05 degrees. Better but still some ripples at the top:
64x64 at 0.05 degrees, and increasing the wall resolution to 1024x1024.
I feel like this is the sweet spot if you have an nVidia GPU. Not sure if this is doable on CPU. Maybe 30+ minutes or more.
128x128 at 0.05 degrees. Not much difference, diminishing returns.
196x196 at 0.05 degrees 2048x2048 wall resolution.
You see aliasing in the spill from the fine wall grid.
196x196 at 0.02 degrees.
Very smooth. Maybe useful if you’re doing some science experiment but not that different from 64x64 @ 0.05 degrees. This will take weeks on CPU.
1 Thank
That’s a possibility. I can reduce the resolution a lot more and can speed it up quite a bit, but the output ends up looking like this:
Not too bad as a thumbnail but it’s ugly zoomed in. Don’t know if that’s super useful for people.
2 Thanks
I like having fingers. I’ll get one with my next order.
1 Thank
Would be awesome to have as many flashlights as possible on there. I added all the ones I could measure or find the dimensions. If anyone has any other measurements or dimensions, I would be happy to add them.
There might be! Will look into it further when I start building that part out.