In D9329#231508, @Sergey Sharybin (sergey) wrote:

Is great that you are helping!
Just need to find a way how to keep it in a clear way. Usually such things are done as a feedback on the existing patch. Simply because then one should only apply/review thing in one place. Sometimes multiple people are working on the same patch, and then the way it is done is via commandeer and arc patch --update D<number>. But such things better have heads up :)

Is great that you are helping!
Just need to find a way how to keep it in a clear way. Usually such things are done as a feedback on the existing patch. Simply because then one should only apply/review thing in one place. Sometimes multiple people are working on the same patch, and then the way it is done is via commandeer and arc patch --update D<number>. But such things better have heads up :)

In D9329#231394, @Sergey Sharybin (sergey) wrote:

But what is confusing is why is this done as a patch on top of a non-committed patch, rather than an interface suggestion in D9294?

The interface I like, and it's something what matches our discussion on blender-chat. The Libmv's API should use fully configurable flags.

@Campbell Barton (campbellbarton) Since the task is quite large, it will be divided into several stages. The first one can be seen here D9291

@Ivan Perevala (ivpe) could you leave a brief note saying why this is abandoned?

@Brecht Van Lommel (brecht) Yes, you are right. I slightly corrected the previous comment as it meant the question of whether this would be a better solution than what is now / you suggested. Sometimes my knowledge of English is ...
I also invite @Jeroen Bakker (jbakker) and @Campbell Barton (campbellbarton) to discuss, of course, when you have free time.

"It was decided" sounded rather definitive, I wanted to clarify that reviewers might disagree with that decision, but you're aware of that so it's fine.

In T81662#1037854, @Brecht Van Lommel (brecht) wrote:

Be aware that design decisions need to be approved by reviewers and module owners. So you can of course to implement it however you want, but it's won't necessarily be accepted that way.

Can you clarify this point? @Ivan Perevala (ivpe) definitely can’t make own decision on final design. And If you know any plans in upcoming changes in this module please share them to Ivan.
If someone already working on refactoring this area in Blender and that code can interfere with that refactoring, we definitely need to bear in mind that upcoming changes to make this work usable in them too.
But if there is no plans for near future, and no Blender foundation coder[s] assigned to that tasks, Ivan as independent coder can only add new feature with maximal compatibility with existing code and current blender user experience.
Also sorry, English is not native for us, and ultimate word “decision” just mean, opinion that such way is more usable. :)

Be aware that design decisions need to be approved by reviewers and module owners. So you can of course to implement it however you want, but it's won't necessarily be accepted that way.

I think it is worth immediately showing the pros and purpose of the current implementation, so far without the intended changes

@Brecht Van Lommel (brecht) ,
Me and @Vlad Kuzmin (Ssh4) have thoroughly discussed the possibilities offered by you.

@Brecht Van Lommel (brecht) I got your point, now I will do some refactor of code and update task description (looks like from scratch))

In T81662#1037188, @Ivan Perevala (ivpe) wrote:

This feature was at one time in the addon, from the earliest versions. Actually, the direction of the viewer was compared with the direction of the cameras and the closest of the co-directional ones was chosen. However, this idea had to be abandoned because, in fact, no one used it. It was replaced by another, the list was simply sorted by the direction of the cameras in space, but alas, this method is quite narrowly focused for photogrammetrists who use the camera rig

@Brecht Van Lommel (brecht)
Definitely for this moment camera projection is not so usable without preview.
And @Ivan Perevala (ivpe) have this Milestone 3 Preview.
Only issue that Camera Projection can be used without preview. But have preview without camera projection implemented have no reason. So this is only matter of priority.
And for this moment when code for camera projection is working, and we can brush up UX for this tool.

@Brecht Van Lommel (brecht)

In terms of usability, from what I can tell from the video there is no way to preview the projection before you paint, which makes it hard to set it up correctly. And users need to manually sync between brush data and scene or motion tracking data.

In terms of usability, from what I can tell from the video there is no way to preview the projection before you paint, which makes it hard to set it up correctly. And users need to manually sync between brush data and scene or motion tracking data.

• Aspect/Skew parameters math for mode "Distort"

A clear description of the basic principles of camera projection implementation using the simplest examples:
https://youtu.be/s93T72LeRv0

• Merge branch 'master' into draw-projector
• Update Bind Images operator report system

• Updated texture interaction

• Merge branch 'master' into draw-projector
• Cleanup, updated comments according to guidelines

• Updated Bind Images operator for texture workflow support.
• Image pointer replaced with texture pointer, large change
• Improved textures / objects id user counting

• Refactor, replacing image ptr with texture ptr