Pov-ray: Newsgroups: Povray.macintosh: Update Pov-ray 3.7

3.4.1.3 AssumedGamma The assumedgamma statement specifies a dsiplay gamma for which all color literals in the scene are presumed to be pre-corrected; at the same time it also defines the working gamma space in which POV-Ray will perform all its color computations. Note: Using any value other than 1.0 will produce physically inaccurate results. Furthermore, if you decide to go for a different value for convenience, it is highly recommended to set this value to the same as your DisplayGamma. Using this parameter for artistic purposes is strongly discouraged. Note: As of POV-Ray 3.7 this keyword is considered mandatory (except in legacy scenes) and consequently enables the experimental gamma handling feature.

Future versions of POV-Ray may treat the absence of this keyword in non-legacy scenes as an error. See section for more information about gamma.

3.4.1.4 HFGray16 Grayscale output can be used to generate heightfields for use in other POV-Ray scenes, and may be specified via GrayscaleOutput=true as an INI option, or +Fxg (for output type 'x') as a command-line option. For example, +Fng for PNG and +Fpg for PPM (effectively PGM) grayscale output. By default this option is off. Note: In version 3.7 the hfgray16 keyword in the globalsettings block has been deprecated. If encountered, it has no effect on the output type and will additionally generate a warning message. With GrayscaleOutput=true, the output file will be in the form of a heightfield, with the height at any point being dependent on the brightness of the pixel.

The brightness of a pixel is calculated in the same way that color images are converted to grayscale images: height = 0.3. red + 0.59. green + 0.11. blue. Setting the GrayscaleOutput=true option will cause the preview display, if used, to be grayscale rather than color. This is to allow you to see how the heightfield will look because some file formats store heightfields in a way that is difficult to understand afterwards. See the section for a description of how POV-Ray heightfields are stored for each file type.

Caveat: Grayscale output implies the maximum bit-depth the format supports is 16, it is not valid to specify bits per color channel with 'g' (e.g. +Fng16 is not allowed, and nor for that matter is +Fn16g). If bits per channel is provided via an INI option, it is ignored. Currently PNG, and PPM are the only file formats that support grayscale output.

3.4.1.6 Charset This allows you to specify the assumed character set of all text strings. If you specify ascii only standard ASCII character codes in the range from 0 to 127 are valid. You can easily find a table of ASCII characters on the internet. The option utf8 is a special Unicode text encoding and it allows you to specify characters of nearly all languages in use today.

We suggest you use a text editor with the capability to export text to UTF8 to generate input files. You can find more information, including tables with codes of valid characters on the The last possible option is to use a system specific character set. For details about the sys character set option refer to the platform specific documentation.

3.4.2.1 Placing the Camera The POV-Ray camera has 9 different models and they are as follows:. Each of which uses a different projection method to project the scene onto your screen. Regardless of the projection type all cameras use location, right, up, direction, and other keywords to determine the location and orientation of the camera. The type keywords and these four vectors fully define the camera. All other camera modifiers adjust how the camera does its job. The meaning of these vectors and other modifiers differ with the projection type used.

A more detailed explanation of the camera types follows later. In the sub-sections which follows, we explain how to place and orient the camera by the use of these four vectors and the sky and lookat modifiers. You may wish to refer to the illustration of the perspective camera below as you read about these vectors. Basic (default) camera geometry. 3.4.2.1.3 Angles The angle keyword followed by a float expression specifies the (horizontal) viewing angle in degrees of the camera used. Even though it is possible to use the direction vector to determine the viewing angle for the perspective camera it is much easier to use the angle keyword.

When you specify the angle, POV-Ray adjusts the length of the direction vector accordingly. The formula used is directionlength = 0.5.

rightlength / tan(angle / 2) where rightlength is the length of the right vector. You should therefore specify the direction and right vectors before the angle keyword. The right vector is explained in the next section. There is no limitation to the viewing angle except for the perspective projection. If you choose viewing angles larger than 360 degrees you will see repeated images of the scene (the way the repetition takes place depends on the camera). This might be useful for special effects.

The spherical camera has the option to also specify a vertical angle. If not specified it defaults to the horizontal angle/2 For example if you render an image with a 2:1 aspect ratio and map it to a sphere using spherical mapping, it will recreate the scene. Another use is to map it onto an object and if you specify transformations for the object before the texture, say in an animation, it will look like reflections of the environment (sometimes called environment mapping). 3.4.2.1.4 The Direction Vector You will probably not need to explicitly specify or change the camera direction vector but it is described here in case you do. It tells POV-Ray the initial direction to point the camera before moving it with the lookat or rotate vectors (the default value is direction). It may also be used to control the (horizontal) field of view with some types of projection. The length of the vector determines the distance of the viewing plane from the camera's location.

A shorter direction vector gives a wider view while a longer vector zooms in for close-ups. In early versions of POV-Ray, this was the only way to adjust field of view.

However zooming should now be done using the easier to use angle keyword. If you are using the ultrawideangle, panoramic, or cylindrical projection you should use a unit length direction vector to avoid strange results. The length of the direction vector does not matter when using the orthographic, fisheye, or omnimax projection types. 3.4.2.1.5 Up and Right Vectors The primary purpose of the up and right vectors is to tell POV-Ray the relative height and width of the view screen.

The default values are: right 4/3.x up y In the default perspective camera, these two vectors also define the initial plane of the view screen before moving it with the lookat or rotate vectors. The length of the right vector (together with the direction vector) may also be used to control the (horizontal) field of view with some types of projection. The lookat modifier changes both the up and right vectors. The angle calculation depends on the right vector. Most camera types treat the up and right vectors the same as the perspective type.

However several make special use of them. In the orthographic projection: The lengths of the up and right vectors set the size of the viewing window regardless of the direction vector length, which is not used by the orthographic camera.

When using cylindrical projection: types 1 and 3, the axis of the cylinder lies along the up vector and the width is determined by the length of right vector or it may be overridden with the angle vector. In type 3 the up vector determines how many units high the image is. For example if you have up 4.y on a camera at the origin. Only points from y=2 to y=-2 are visible. All viewing rays are perpendicular to the y-axis.

For type 2 and 4, the cylinder lies along the right vector. Viewing rays for type 4 are perpendicular to the right vector.

Note: The up, right, and direction vectors should always remain perpendicular to each other or the image will be distorted. If this is not the case a warning message will be printed.

The vista buffer will not work for non-perpendicular camera vectors. 3.4.2.2.1 Perspective projection The perspective keyword specifies the default perspective camera which simulates the classic pinhole camera. The horizontal viewing angle is either determined by the ratio between the length of the direction vector and the length of the right vector or by the optional keyword angle, which is the preferred way. The viewing angle has to be larger than 0 degrees and smaller than 180 degrees. The perspective projection diagram A perspective camera sample image Note: The angle keyword can be used as long as less than 180 degrees.

It recomputes the length of right and up vectors using direction. The proper aspect ratio between the up and right vectors is maintained. 3.4.2.2.2 Orthographic projection The orthographic camera offers two modes of operation: The pure orthographic projection.

This projection uses parallel camera rays to create an image of the scene. The area of view is determined by the lengths of the right and up vectors. One of these has to be specified, they are not taken from the default camera. If omitted the second method of the camera is used. If, in a perspective camera, you replace the perspective keyword by orthographic and leave all other parameters the same, you will get an orthographic view with the same image area, i.e. The size of the image is the same. The same can be achieved by adding the angle keyword to an orthographic camera.

A value for the angle is optional. So this second mode is active if no up and right are within the camera statement, or when the angle keyword is within the camera statement. You should be aware though that the visible parts of the scene change when switching from perspective to orthographic view. As long as all objects of interest are near the lookat point they will be still visible if the orthographic camera is used. Objects farther away may get out of view while nearer objects will stay in view.

If objects are too close to the camera location they may disappear. Too close here means, behind the orthographic camera projection plane (the plane that goes through the location point). The orthographic projection diagram An orthographic camera sample image Note: The length of direction is irrelevant unless angle is used. The lengths of up and right define the dimensions of the view. Vmware fusion for mac download. The angle keyword can be used, as long as less than 180. It will override the length of the right and up vectors (the aspect ratio between up and right will be kept nevertheless) with a scope of a perspective camera having the same direction and angle.

3.4.2.2.3.2 Distribution Type This float parameter controls how pixels are assigned to faces as documented below:. distribution #0 This method allows single or multiple rays per pixel, with the ray number for that pixel allocated to each mesh in turn. The index into the meshes is the ray number, where rays per pixel is greater than one, and the index into the selected mesh is the pixel number within the output image. If there is no face at that pixel position, the resulting output pixel is unaffected. You must supply at least as many meshes as rays per pixel. Each pixel is shot rays per pixel times, and the results averaged. Any ray that does not correspond with a face (i.e.

The pixel number is greater than or equal to the face count) does not affect the resulting pixel color. Generally, it would be expected that the number of faces in each mesh is the same, but this is not a requirement.

Keep in mind that a ray that is not associated with a face is not the same thing as a ray that is but that, when shot, hits nothing. The latter will return a pixel (even if it is transparent or the background color), whereas the former causes the ray to not be shot in the first place; hence, it is not included in the calculation of the average for the pixel. Using multiple rays per pixel is useful for generating anti-aliasing (since standard AA won't work) or for special effects such as focal blur, motion blur, and so forth, with each additional mesh specified in the camera representing a slightly different camera position.

Note: It is legal to use transformations on meshes specified in the camera body, hence it's possible to obtain basic anti-aliasing by using a single mesh multiple times, with subsequent ones jittered slightly from the first combined with a suitable rays per pixel count. distribution #1 This method allows both multiple rays per pixel and summing of meshes, in other words the faces of all the supplied meshes are logically summed together as if they were one single mesh. In this mode, if you specify more than one ray per pixel, the second ray for a given pixel will go to the face at (width.

height. raynumber) + pixelnumber, where raynumber is the count of rays shot into a specific pixel.

If the calculated face index exceeds the total number of faces for all the meshes, no ray is shot. The primary use for this summing method is convenience in generation of the meshes, as some modelers slow down to an irritating extent with very large meshes. Using distribution #1 allows these to be split up.

distribution #2 Distribution method 2 is a horizontal array of sub-cameras, one per mesh (i.e. Like method #0, it does not sum meshes).

The image is divided horizontally into #nummeshes blocks, with the first mesh listed being the left-most camera, and the last being the right-most. The most obvious use of this would be with two meshes to generate a stereo camera arrangement.

In this mode, you can (currently) only have a single ray per pixel. distribution #3 This method will reverse-map the face from the UV co-ordinates.

Currently, only a single ray per pixel is supported, however, unlike the preceding methods, standard AA and jitter will work. This method is particularly useful for texture baking and resolution-independent mesh cameras, but requires that the mesh have a UV map supplied with it. You can use the smooth modifier to allow interpolation of the normals at the vertices.

This allows for use of UV mapped meshes as cameras with the benefit of not being resolution dependent, unlike the other distributions. The interpolation is identical to that used for smoothtriangles. If used for texture baking, the generated image may have visible seams when applied back to the mesh, this can be mitigated. Also, depending on the way the original UV map was set up, using AA may produce incorrect pixels on the outside edge of the generated maps. 3.4.2.2.3.3 Max Distance This is an optional floating-point value which, if greater than EPSILON (a very small value used internally for comparisons with 0), will be used as the limit for the length of any rays cast. Objects at a distance greater than this from the ray origin will not be intersected by the ray. The primary use for this parameter is to allow a mesh camera to 'probe' a scene in order to determine whether or not a given location contains a visible object.

Two examples would be a camera that divides the scene into slices for use in 3d printing or to generate an STL file, and a camera that divides the scene into cubes to generate voxel information. In both cases, some external means of processing the generated image into a useful form would be required. It should be kept in mind that this method of determining spatial information is not guaranteed to generate an accurate result, as it is entirely possible for a ray to miss an object that is within its section of the scene, should that object have features that are smaller than the resolution of the mesh being used. In other words, it is (literally) hit and miss. This issue is conceptually similar to aliasing in a normal render. It is left as an exercise for the reader to come up with means of generating pixel information that carries useful information, given the lack of light sources within the interior of an opaque object (hint: try ambient). 3.4.2.2.3.5 About the Location Vector With this special camera, location doesn't affect where the camera is placed per se (that information is on the mesh object itself), but is used to move the origin of the ray off the face, along the normal of that face.

This would typically be done for texture baking or illumination calculation scenes where the camera mesh is also instantiated into the scene, usually only a tiny amount of displacement is needed. The X and Y for location is not currently used, and the Z always refers to the normal of the face, rather than the real Z direction in the scene. 3.4.2.2.3.7 The Smooth Modifier This optional parameter is only useful with distribution #3, and will cause the ray direction to be interpolated according to the same rules as are applied to smooth triangles. For this to work, the mesh must have provided a normal for each vertex. Note: See the sample scene files located in scenes/camera/meshcamera/ for additional usages and other samples of mesh cameras. There are also some useful macros to assist in generating and processing meshes for use as cameras.

3.4.2.2.4 Fisheye projection This is a spherical projection. The viewing angle is specified by the angle keyword. An angle of 180 degrees creates the 'standard' fisheye while an angle of 360 degrees creates a super-fisheye or 'I-see-everything-view'. If you use this projection you should get a circular image. If this is not the case, i.e. You get an elliptical image, you should read. The fisheye projection diagram A fisheye camera sample image Note: The length of the direction, up and right vectors are irrelevant.

The angle keyword is the important setting. 3.4.2.2.5 Ultra wide angle projection The ultra wide angle projection is somewhat similar to the fisheye, but it projects the image onto a rectangle instead of a circle. The viewing angle can be specified by using the angle keyword. The aspect ratio of the lengths of the up/right vectors are used to provide the vertical angle from the horizontal angle, so that the ratio of vertical angle on horizontal angle is identical to the ratio of the length of up on length of right. When the ratio is one, a square is wrapped on a quartic surface defined as follows: x 2+y 2+z 2 = x 2y 2 + 1 The section where z=0 is a square, the section where x=0 or y=0 is a circle, and the sections parallel to x=0 or y=0 are ellipses. When the ratio is not one, the bigger angle obviously gets wrapped further. When the angle reaches 180, the border meets the square section.

The angle can be greater than 180, in that case, when both (vertical and horizontal) angles are greater than 180, the parts around the corners of the square section will be wrapped more than once. The classical usage (using an angle of 360) but with a up/right ratio of 1/2 up 10.y and right 20.x will keep the top of the image as the zenith, and the bottom of the image as the nadir, avoiding perception issues and giving a full 360 degree view. The ultra wide angle projection diagram An ultra wide angle sample image. 3.4.2.2.7 Panoramic projection This projection is called 'cylindrical equirectangular projection'.

Povray Newsgroups Povray.macintosh Update Povray 3.7

It overcomes the degeneration problem of the perspective projection if the viewing angle approaches 180 degrees. It uses a type of cylindrical projection to be able to use viewing angles larger than 180 degrees with a tolerable lateral-stretching distortion. The angle keyword is used to determine the viewing angle. The panoramic projection diagram A panoramic camera sample image Note: The angle keyword is irrelevant. The relative length of direction, up and right vectors are important as they define the lengths of the 3 axis of the ellipsoid. With identical length and orthogonal vectors (both strongly recommended, unless used on purpose), it's identical to a spherical camera with angle 180,90. 3.4.2.2.8 Cylindrical projection Using this projection the scene is projected onto a cylinder.

There are four different types of cylindrical projections depending on the orientation of the cylinder and the position of the viewpoint. An integer value in the range 1 to 4 must follow the cylinder keyword. The viewing angle and the length of the up or right vector determine the dimensions of the camera and the visible image. The characteristics of different types are as follows:.

vertical cylinder, fixed viewpoint. horizontal cylinder, fixed viewpoint. vertical cylinder, viewpoint moves along the cylinder's axis.

horizontal cylinder, viewpoint moves along the cylinder's axis The type 1 cylindrical projection diagram A type 1 cylindrical camera sample image The type 2 cylindrical projection diagram A type 2 cylindrical camera sample image The type 3 cylindrical projection diagram A type 3 cylindrical camera sample image The type 4 cylindrical projection diagram A type 4 cylindrical camera sample image. 3.4.3.1 Atmospheric Media Atmospheric effects such as fog, dust, haze, or visible gas may be simulated by a media statement specified in the scene but not attached to any object. All areas not inside a non-hollow object in the entire scene. A very simple approach to add fog to a scene is explained in the section however this kind of fog does not interact with any light sources like does. It will not show light beams or other effects and is therefore not very realistic.

Povray Newsgroups Povray.macintosh Update Povray 3.7 Linux

The atmosphere media effect overcomes some of the fog's limitations by calculating the interaction between light and the particles in the atmosphere using volume sampling. Thus shafts of light beams will become visible and objects will cast shadows onto smoke or fog. Note: POV-Ray cannot sample media along an infinitely long ray. The ray must be finite in order to be possible to sample. This means that sampling media is only possible for rays that hit an object, so no atmospheric media will show up against the background or skysphere.

Another way of being able to sample media is using spotlights, because in this case the ray is not infinite, as it is sampled only inside the spotlight cone. With you will be able to create the best results because their cone of light will become visible. Pointlights can be used to create effects like street lights in fog. Lights can be made to not interact with the atmosphere by adding mediainteraction off to the light source. They can be used to increase the overall light level of the scene to make it look more realistic.

Complete details on media are given in the section. Earlier versions of POV-Ray used an atmosphere statement for atmospheric effects but that system was incompatible with the old object halo system. So atmosphere has been eliminated and replaced with a simpler and more powerful media feature. The user now only has to learn one media system for either atmospheric or object use. If you only want media effects in a particular area, you should use object media rather than only relying upon the media pattern. In general it will be faster and more accurate because it only calculates inside the constraining object. Note: The atmosphere feature will not work if the camera is inside a non-hollow object (see the section for a detailed explanation).

March 29, 2006 Texel has released a, an Anim8or.an8 to POV-Ray convertor. March 26, 2006 A host of new and updated render farm solutions for POV-Ray have recently been released, including:., with a new installer and bug fixes., a Knoppix-based live Linux system for easily building computing grids includes POV-Ray with a web interface., the $1/CPU-hour computing farm, hosts POV-Ray as a sample application. March 26, 2006. Christoph Hormann has announced a new site, showcasing realistic Earth surface renderings made using POV-Ray. Meanwhile, a step by step tutorial explaining the process of has been published by PerFnurt.

March 26, 2006 POV-Ray user has a of abstract animations, six of which are created in POV-Ray. The DVD is also in the USA. March 26, 2006 has created, an application that creates from the PCB layout design program. This allows the 2D layouts of circuit boards from Eagle to be rendered as full 3D circuit board models in POV-Ray, complete with capacitors, connectors, ICs, resistors, etc. March 26, 2006 Version 1.5 of the standalone 3D polygon modeler, is now available. Rheingold3D sports integration with POV-Ray for rendering and import, with this latest release including. February 16, 2006 (beta), a 'graphical programming environment' for VST instruments, can be to create animations.

February 16, 2006 ('Yet Another POV-Ray Modeller') reaches version 0.4.5 with support for new polyline and plane objects and storing parts of scenes as reusable models., an archive of colour gradients for cartography, technical illustration and design, now includes gradients in POV-Ray colormap format. February 05, 2006 The mathematical surface modeller is, adding new Deformer/Builder tools.

December 11, 2005 There is now a page available which sets out some information regarding the evolution of the POV-Ray codebase into what it is today. It particularly pays attention to the issue of formal assignment of usage rights by developers (past and present) to the POV-Ray project. The generation of this information is the result of a long-term effort and the co-operation of a considerable number of contributors to the codebase. The team sincerely thanks all concerned!

Pov-ray Newsgroups Povray.macintosh Update Pov-ray 3.7.0

November 30, 2005 (for Linux), an advanced terrain heightfield editor for POV-Ray, has been updated to fix an options file issue. November 29, 2005. (development version) has been released and now includes OpenGL support. has undergone, bringing it to version 3.8.18., an Anim8or to POV-Ray converter, is now available with several bugs fixed. November 28, 2005 A new release of the GNOME modeler for POV-Ray, is available, featuring a new Python plugin interface, improved GUI and many bug fixes. October 08, 2005 Version 1.5a of the is now available with. September 26, 2005 POV-Ray v3.7.beta.9 (windows platforms only, includes AMD64) is available from our page.

New in this revision is restored support for mosaic preview, dispersion and radiosity, the ability to specify render block size, and improved handling of large renders, plus numerous other bugfixes and improvements. POV-Ray 3.7 is a significant update to the 3.x series as it supports SMP (including dual-core processors such as those from AMD and Intel).

September 15, 2005. 1.2.1 has been released,. 3.8.14 is now available with bug fixes and improved performance and memory management. Tim Nikias releases new (example available ). (Yet Another POV-Ray Modeller) version 0.4, a modeller for the X Windowing System, has been released, introducing support for spline objects and fixing several small bugs September 12, 2005 POV-Ray v3.7.beta.8 (windows platforms only, includes AMD64) is available from.

New in this revision is support for the HDR and EXR file formats, faster AA method 2, fixed crackle, and numerous other minor changes. POV-Ray 3.7 is a significant update to the 3.x series as it supports SMP (including dual-core processors such as those from AMD and Intel).