deleted mistaken msg
Congrats. You got quite an interesting project going on here.
Have you considered joining forces with creator of “Photographer” addon? IMHO both could finely complement each other.
PS
PM-ed you on Discord.
@burnin Thanks!
I remember when he’s addon came out a couple of years ago, seems like he has made an extension of the default blender camera, while I’m making a separate lens system with nodes, so I don’t think the setups will be compatible, at least not the lens effects 
@Indecom4000 Here is a quick bloom test:
4 Likes
Your lens shader could easily be implemented in Photographer for users that would want to use more advanced lens rendition (at the cost of rendering times).
I am currently using simple plane shapes to create bokeh and optical vignetting for instance, these could be replaced with your shader.
Having said that, it’s up to you to decide if you prefer to develop your own addon and sell it. I do feel a bit sad for the community that we end up with a lot of addons with overlapped features, but that’s the double edged sword of the addon marketplace. I totally understand that getting paid for your hard work is also what drives innovation. Feel free to reach out to me if you would want to discuss it further.
Having played with the new ray portal node, it did seem that lens shaders would not work with default focus properties, which is why I put my research on hold, because that would mean creating a whole code branch for all the focus tools to work with lens shaders. And to be fair, I don’t have time for it.
6 Likes
It would be awesome if you guys can work something out!
1 Like
I’m not. I’d rather have multiple add-ons that do the same thing different ways than only have the option of one add-on which does a lot of other things I don’t want/does things in a way I am not a fan of, or to go without.
Redundancy is an important feature of the marketplace, not a double edged sword. Never be sad about the freedom to choose.
1 Like
As @chafouin said, my system is not necessarily an easy thing to implement due to how the systems work. My setup uses the ray portal plane as the censor position, so the camera is in orthographic mode focused on the censor plane. I do have a solution for the focus distance, using only a distance value to focus. But it would not be a straight forward implementation for it to work. It would take some time, I can imagine that you have a lot of code that needs to be rewritten.
Correct me if I’m wrong but I don’t think our target groups would overlap ether. My system is angled towards simulating physically accurate lenses, valuing realism over a unbiased result. But Photographer is a more unbiased approach that achieve realistic results without comprising speed (at least in terms of lens optics and bokeh shapes), it also includes a whole lot of other tools to make the render pipeline easier.
I agree with @Jvry, the Photographer addon is a completly different system compared to mine, of course we could cooperate and add everything into a single addon, but that would complicate things, price, developing time etc. I think we sould treat it as two separate camera approaches, because that’s what it is. Also, as blender devs comes up with new tools and improvements its inevitable that different tools will show up with different approaches.
That being said I’m open too discuss it 
Add me on discord: heinzelnisse#5900
1 Like
Not sad about the freedom to choose (although some people don’t have that freedom because they simply can’t afford it). But when you use an addon that fits your workflow but lacks that new fancy feature. And you have to pay for another addon to get that feature, except that it’s not compatible at all with the other add-on, what do you do?
No overlap of features, your lens shaders would simply work as a replacement of my simpler lens bokeh, but for instance your lens shaders won’t work with multiple camera setups from Photographer, unless we collaborate to make it compatible (or I just look at your code / content and make it work with Photographer, hoping you don’t change the setup too often)
1 Like
At that point I think it means that the addon itself should have been broken down to different parts. IMHO Modularizing addons into it’s atomic-ish form allows it to stay closer to vanilla blender and thus requires less overhead from other addon developers to support it.
(eg. Photographer is a camera manager and a camera effects addon, that could have been split into two, the task of managing cameras and it’s properties // the task of assigning effects)
You also have to pay for major updates from addons right? From the developer’s perspective they want to eat. From the user’s perspective, it’s a new feature set that they have to pay for, regardless if it’s the same or a different addon.
Also, if the addon is broken down into it’s atomic features, it becomes a buffet for users, thus actually making it more affordable for those who only need feature X and not Y.
My suggestion would be to make it generalized instead of tighly coupled to one solution, allowing for further expansion of user works. That or document some kind of expected nodes/values that Photographer fetches.
We are completely derailing @Heinzelnisse topic so I’ll just answer to you here but we should move to Photographer’s thread if you want to continue the discussion.
You don’t have to use all the features, they are all behind toggles.
It would have a been a lot more complicated to modularize each feature that concern Cameras since the Manager needs to know of each of them. Not saying it is not possible, but there are a lot of dependencies, and I’m also not a programmer.
I would agree that the Lightmixer could have been a separate addon, but it is part of a whole Physically based lighting workflow, it is moot to use correct light intensities without correct camera exposure.
Please read my earlier comment, I am absolutely not against paying devs (I’m one of them, how ironic would it be) and I said that this revenue is also what drives innovation and makes Blender my favorite tool that improves at the speed of light. The problem here is absolutely not that you have to pay for it, but that the customer ends up with an addon that they can’t make use of.
How can Photographer expect new nodes and values of an addon that doesn’t exists yet? Each addon creates their own set of properties, their own classes, I cannot know of them before they exist, unless there is a collaboration between the addon developers.
3 Likes
No problem that it got a bit derailed, interesting to hear your thoughts about the subject
I think I’ll keep developing this as a standalone system, I don’t want to complicate the production right now while I’m discovering and figuring out how to do things. Maybe if it gets enough attention and if many people want it to be merged we can find a solution for combining the two setups, but for now, I just want to keep it as a fun side project
1 Like
Found a way to guide rays to compensate for f-stop change, this will improve the rendertime and eliminate the exposure change (can easily be added back) when changing the aperture size.
Here is a visualization of what I’m doing:
With a small aperture on the left side most of the rays will miss, by guiding the rays towards the aperture opening I can eliminate nearly all the ray misses, much more efficient than only changing the aperture size.
Needs some custom tweaking per lens to compensate for focus change etc., but it seems to work fine.
6 Likes
Been working on the addon lately, programming and designing the UI. I’ve decided to have two “layouts”, one with the basic settings, and one where all the settings is exposed. This will hopefully make it easy and less intimidating to use for starters, but also usable for more advance users who wants to explore all the settings.
Simple layout:
Advanced layout:
Had to redesign the main lens setup, I can now just plot in the lens patent instead of building and connecting one lens at the time. I also store each lens in a .txt file that is loaded and ingested by the addon. This will make sharing, creating and distributing lenses easy.
Also remade the schematic viewer(got the basics up and running). The 3D OSL shader is unfortunately too big of a hassle to implement only using blender nodes, so I decided to settle for a 2D version.
10 Likes
Took a little break (ish) during holidays but now I’m back with the development
Did a lot of code and node rewriting, when changing a lens or changing to the schematic mode I’m now automatically rebuilding most of the node network. Had some issues with reaching the max node count and long material compile times, especially when rendering the lens rays. Rebuilding the lens nodes will eliminate this issues since were not having a lot of unused nodes in the material. I also added the a ray visualization and the option to isolate single lenses in the schematics:
Added support for distort and anamorph emulation, this is an estimation and not physical accurate.
Original render with the 85mm Canon Serenar:
Squeeze factor added:
Adjusting bokeh aspect ratio:
Adding extra lens distortion:
Barrel and pincushion distortion:
Added support of V number (abbe number), this is set pr lens element. It is only a approximation but the wave folding seems to work more or less correctly. Here you can see the 50mm Jupiter-3 lens with a noticeable yellow bokeh outline:
Real photo:
Added UI for lens creation:
7 Likes
Added support for custom Aperture Image and lens Dirt Image.
Here is a typical Aperture Image:
I plan to add some basic aperture shapes that comes with the addon, those can be embedded in the lenses when you create them, they will cover the most common shapes found in lenses, like this thing:
Note that the Aperture Image should not have dirt in it, since its located inside the lens. That’s when the Lens Dirt Image comes in handy, this will add dirt on the front of the lens.
Saying this any texture can be used for artistic effects:
Color correction modes is really convenient to not darken the image when applying a texture:
White Color Sum:
This will average the output pixel values to be {0.7854.0.7854.0.7854}, overall color and brightness of the render will not shift
Intensity Sum:
Average pixel Intensity is equal to 0.7854, overall color will shift but the brightness stays the same
Why 0.7854? The default aperture is round, but an image texture is squared. So if we have a perfect circle as Aperture Image we can replicate the default aperture calculations:
The overall circle coverage is 78.54%. If we want our custom image to match the default aperture opening in terms of how much light we let through we just have to set the average pixel intensity to be 0.7854.
4 Likes
Wow…impressive work!
1 Like
Just wanted to make a quick video showing the current progress of the addon. It feels like im 98% done now but the last 2% is taking quite a long time to finish.
Been mostly working on bug fixes and general UI stuff, using the lens outside my little test area has been crucial to finding bugs and finding how to best design the UI for real use cases. It’s not always obvious what kind of features that’s missing or would come in handy before you try to use the product.
I also had to rewrite a lot of stuff and change the node network due to things not working as expected, had to do a complete rewrite of the ray guiding system due to a bug in the aperture placement 
Anyways, here is the video:
12 Likes
This is fantastic. Loving the look of it!
2 Likes
Eagerly awaiting the release of your addon, looking great 
1 Like