I made a default value of -1 ; +1 to correspond to a cylinder of 2m of height and diameter, making a vertical field of view of 90°. The slider for height is soft-maxed to 10m as an arbitrary value to avoid sliding the value too high quickly, but could be easily overwritten by user if needed.

I think these should be hard limits, not UI limits? Same goes for u_max and radius (that one doesn't need an upper hard limit, but it shouldn't be negative).

The cylindrical projection use same longitude as equirectangular, but use height value for longitudinal, preserving vertical lines.

We could make it clearer (through the comment) that this really is a factor relative to the cylinder radius, whatever it is. For an end user, it should be straightforward to compute physical height / physical radius.

I'm not sure if "distortion around the pole" is really self explaining, in fact the poles can't really be seen in cylindrical projection (as the topology of a cylinder doesn't allow any ray to go directly through zenith/nadir).

But this description is not really academic, maybe too much familiar, and belong maybe more to the user manual documentation than in this function?

I wonder if it would be more intuitive to use Horizontal/Vertical Field of View instead. Horizontally it is equivalent, because it's spherical projection, you can just set the FOV and rotate your camera to face the center. Vertically it is not equivalent, but I wonder how practical it would be to have asymmetric settings. Either way I prefer angle to height, because height implies that the radius is 1, which is not stated and quite arbitrary.

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?

Setting horizontal/vertical field of view in degrees could complicate certain use cases. For example, imagine a quarter cylinder that is 1.70 meters below the camera and 2.3 meters above the camera. Expressing this in angles would require a vertical field of view of approximately 126 degrees and a shift of about 0.076. This could make it more difficult to compensate for sensor fit settings (horizontal or vertical).

Not sure if we have guidelines for comment style, but I think C-style /* */ comments are preferred? Also note that the parameter here is a default (for non-Blender users of Cycles), not a limit.

I think we could more change the description to : "Projects the scene onto a virtual cylinder, where each of the horizontal lines is like equirectangular equator, while vertical line work like planar projection (where each vertical line are projection from center to a slice of the cylinder)"

I have added a cylinder radius value (as doing angle would have been a bit harder without much gain for the user in my opinion). Adding this value bring a new bug that I "solved" (an AI told me to do it, but idk exactly why) using

I'm not sure if replacing height with vertical field of view angle would be the best approach. Cylindrical projection is different from perspective projection, and its use cases tend to be more focused on applications like museum exhibitions, where values in meters are more practical.

Always bump subversion number for versioning is a decision from 01/2024, essentially because it does not cost anything, and it avoids potential confusion and issues when forgetting to move some 'unversioned' block on the next subversion bump.

It can however be used to display more than 360 degrees horizontally: scanning cameras often record a little bit more than 360 degrees so the overlapping region is easier to be stitched if light changes or something moves in that area. Multiples of 360 degrees can e.g. display a changing subject like different seasons.

Could you help me please? This is my first time here and I don't understand what I need to do to get the same kind of camera. Do I need to manually change some scripts? And on what version of Blender should I do this?

Then increment BLENDER_FILE_SUBVERSION by one in BKE_blender_version.h. (Currently it's 0, so it should be changed to 1, therefore the (bmain, 403, 1) above.

If using angles in degrees is important, perhaps a dropdown menu could be added to switch between the two modes, similar to how lens units are currently handled.

Following a request on Central cylindrical camera on, I implemented this new projection. This type of projection is often used in exhibition that leverage big curved screens.

Note that this is my very first pull request on blender code, code (especially C/C++) isn't my main activity as 3D artist, don't hesitate to correct me if I did anything wrong, or anything else.

I retained the horizontal field of view setting from equirectangular projection (with minimum/maximum values), even though a shift could compensate for a single value. This min/max approach seemed more intuitive.

This description is not informative enough, because it can also used to describe the equirectangular panoramic camera model. I can think of "Cylindrical projection similar as a rotating panoramic camera, with distortion near the poles" but not sure if it's good understandable. We should add comparison images with equirectangular projection in the manual.

You don't need to say (in degree) because if the property is set to PROP_ANGLE, a degree symbol ° is already shown in the UI.

The main thing I do not like about height is that it implicitly defines the radius to be 1m. In oder that this projection is used in a museum exhibition as the way you depicted, you would also need to add the radius as a parameter, otherwise the user still needs to do the calculation. We can also call it aspect ratio or cylinder with a radius of 1m, not sure if that's more intuitive though.

This is only a small detail, but: I'd prefer to only have the radius in the UI. Perform the division here, then only handle u/v_min/max in the rest of the Cycles code. This way, it's only computed once, instead of for every pixel and sample. A tiny difference, but might as well do it when it's easy.

@susman This change will be part of Blender 4.3, for now you can download the latest 4.3 Alpha build here https://builder.blender.org/download/daily/

This model looks quite fun! I changed the title because only the Cycles part is implemented, the EEVEE part can be added later. Also, you need to run make format.

in the DNA_camera_types.h to avoid the CUSTOMBUILD : Align struct error : Camera::runtime (starts at 500 on the native platform; 500 % 8 = 4 bytes error

In addition to that, I created a new feature request for custom camera gizmo with a mockup that would help user understand better what the camera look like.