From ab767f0328419178ecb8123a351d9456b5d122e6 Mon Sep 17 00:00:00 2001 From: Wenzel Jakob Date: Thu, 8 May 2014 12:29:00 +0200 Subject: [PATCH] removed repeated words in the documentation --- doc/basics.tex | 2 +- doc/compiling.tex | 4 ++-- doc/development.tex | 4 ++-- doc/integrator.tex | 4 ++-- doc/python.tex | 4 ++-- src/bsdfs/plastic.cpp | 2 +- src/bsdfs/roughplastic.cpp | 4 ++-- src/emitters/envmap.cpp | 2 +- src/emitters/sky.cpp | 6 +++--- src/emitters/sun.cpp | 2 +- src/emitters/sunsky.cpp | 4 ++-- src/films/hdrfilm.cpp | 2 +- src/films/ldrfilm.cpp | 2 +- src/integrators/bdpt/bdpt.cpp | 2 +- src/integrators/photonmapper/ppm.cpp | 2 +- src/integrators/photonmapper/sppm.cpp | 2 +- src/integrators/ptracer/ptracer.cpp | 2 +- src/libcore/bitmap.cpp | 3 ++- src/samplers/hammersley.cpp | 2 +- src/shapes/hair.cpp | 2 +- src/shapes/obj.cpp | 2 +- src/shapes/ply.cpp | 2 +- src/shapes/serialized.cpp | 2 +- src/textures/wireframe.cpp | 2 +- 24 files changed, 33 insertions(+), 32 deletions(-) diff --git a/doc/basics.tex b/doc/basics.tex index 317ee923..d95057bd 100644 --- a/doc/basics.tex +++ b/doc/basics.tex @@ -86,7 +86,7 @@ $\texttt{\$}$ mitsuba -c machine1;machine2;... path-to/my-scene.xml There are two different ways in which you can access render nodes: \begin{itemize} \item\textbf{Direct}: Here, you create a direct connection to a running \code{mtssrv} instance on -another machine (\code{mtssrv} is the Mitsuba server process). From the the performance +another machine (\code{mtssrv} is the Mitsuba server process). From the performance standpoint, this approach should always be preferred over the SSH method described below when there is a choice between them. There are some disadvantages though: first, you need to manually start \code{mtssrv} on every machine you want to use. diff --git a/doc/compiling.tex b/doc/compiling.tex index 067db386..0a4b96c0 100644 --- a/doc/compiling.tex +++ b/doc/compiling.tex @@ -48,7 +48,7 @@ Visual Studio 2010 for legacy 32 bit builds. Versions XE 2012 and 2013 are known to work. \end{description} \paragraph{Mac OS:} -On Mac OS, builds can either be performed using the the XCode 4 \code{llvm-gcc} toolchain or Intel XE Composer. +On Mac OS, builds can either be performed using the XCode 4 \code{llvm-gcc} toolchain or Intel XE Composer. It is possible to target MacOS 10.6 (Snow Leopard) or 10.7 (Lion) as the oldest supported operating system release. In both cases, XCode must be installed along with the supplementary command line tools. \begin{description} @@ -57,7 +57,7 @@ In both cases, XCode must be installed along with the supplementary command line Versions XE 2012 and 2013 are known to work. \end{description} Note that the configuration files assume that XCode was -installed in the \code{/Applications} folder. They must be be manually updated +installed in the \code{/Applications} folder. They must be manually updated when this is not the case. \subsubsection{Selecting a configuration} Having chosen a configuration, copy it to the main directory and rename it to \code{config.py}, e.g.: diff --git a/doc/development.tex b/doc/development.tex index 0bb711e7..ffd9ec51 100644 --- a/doc/development.tex +++ b/doc/development.tex @@ -1,8 +1,8 @@ \part{Development guide} \label{sec:development} This chapter and the subsequent ones will provide an overview -of the the coding conventions and general architecture of Mitsuba. -You should only read them if if you wish to interface with the API +of the coding conventions and general architecture of Mitsuba. +You should only read them if you wish to interface with the API in some way (e.g. by developing your own plugins). The coding style section is only relevant if you plan to submit patches that are meant to become part of the main codebase. diff --git a/doc/integrator.tex b/doc/integrator.tex index b2742dfc..ab29ae06 100644 --- a/doc/integrator.tex +++ b/doc/integrator.tex @@ -7,7 +7,7 @@ The framework distinguishes between \emph{sampling-based} integrators and \emph{generic} ones. A sampling-based integrator is able to generate (usually unbiased) estimates of the incident radiance along a specified rays, and this is done a large number of times to render a scene. A generic integrator -is more like a black box, where no assumptions are made on how the the image is +is more like a black box, where no assumptions are made on how the image is created. For instance, the VPL renderer uses OpenGL to rasterize the scene using hardware acceleration, which certainly doesn't fit into the sampling-based pattern. For that reason, it must be implemented as a generic integrator. @@ -261,7 +261,7 @@ As you can see, we did something slightly different in the distance renderer fragment above (we called \code{RadianceQueryRecord::rayIntersect()} on the supplied parameter \code{rRec}), and the reason for this is \emph{nesting}. \subsection{Nesting} -The idea of of nesting is that sampling-based rendering techniques can be +The idea of nesting is that sampling-based rendering techniques can be embedded within each other for added flexibility: for instance, one might concoct a 1-bounce indirect rendering technique complete with irradiance caching and adaptive integration simply by writing the following diff --git a/doc/python.tex b/doc/python.tex index fd1beedd..d7482387 100644 --- a/doc/python.tex +++ b/doc/python.tex @@ -545,7 +545,7 @@ command-line executable. \subsubsection{Simultaneously rendering multiple versions of a scene} Sometimes it is useful to be able to submit multiple scenes to the rendering scheduler at the same time, e.g. when rendering on a big cluster, where one image is not enough to keep all -cores on all machines busy. This is is quite easy to do by simply launching multiple \code{RenderJob} +cores on all machines busy. This is quite easy to do by simply launching multiple \code{RenderJob} instances before issuing the \code{queue.waitLeft} call. However, things go wrong when rendering multiple versions of the \emph{same} scene simultaneously (for instance @@ -753,7 +753,7 @@ As before, some changes will be necessary to get this to run on PySide. When using this snippet, please be wary of threading-related issues; the key thing to remember is that in Qt, only the main thread is allowed to modify Qt widgets. On the other hand, rendering and logging-related callbacks will be invoked from different Mitsuba-internal threads---this means that it's not possible to e.g. -directly update the status bar message from the callback \code{finishJobEvent}. To do this, we must use +directly update the status bar message from the callback \code{finishJobEvent}. To do this, we must use Qt's \code{QueuedConnection} to communicate this event to the main thread via signals and slots. See the code that updates the status and progress bar for more detail. \begin{python} diff --git a/src/bsdfs/plastic.cpp b/src/bsdfs/plastic.cpp index b5083021..5e99fe6b 100644 --- a/src/bsdfs/plastic.cpp +++ b/src/bsdfs/plastic.cpp @@ -96,7 +96,7 @@ MTS_NAMESPACE_BEGIN * Internally, this is model simulates the interaction of light with a diffuse * base surface coated by a thin dielectric layer. This is a convenient * abstraction rather than a restriction. In other words, there are many - * materials that can be rendered with this model, even if they might not not + * materials that can be rendered with this model, even if they might not * fit this description perfectly well. * * \begin{figure}[h] diff --git a/src/bsdfs/roughplastic.cpp b/src/bsdfs/roughplastic.cpp index cc8f933d..4f48180d 100644 --- a/src/bsdfs/roughplastic.cpp +++ b/src/bsdfs/roughplastic.cpp @@ -103,13 +103,13 @@ MTS_NAMESPACE_BEGIN * interaction of light with a diffuse base surface coated by a thin dielectric * layer (where the coating layer is now \emph{rough}). This is a convenient * abstraction rather than a restriction. In other words, there are many - * materials that can be rendered with this model, even if they might not not + * materials that can be rendered with this model, even if they might not * fit this description perfectly well. * * The simplicity of this setup makes it possible to account for interesting * nonlinear effects due to internal scattering, which is controlled by * the \texttt{nonlinear} parameter. For more details, please refer to the description - * of this parameter given in the the \pluginref{plastic} plugin section + * of this parameter given in the \pluginref{plastic} plugin section * on \pluginpage{plastic}. * * diff --git a/src/emitters/envmap.cpp b/src/emitters/envmap.cpp index e2374052..f76cd905 100644 --- a/src/emitters/envmap.cpp +++ b/src/emitters/envmap.cpp @@ -80,7 +80,7 @@ MTS_NAMESPACE_BEGIN * * The implementation loads a captured illumination environment from a image in * latitude-longitude format and turns it into an infinitely distant emitter. - * The image could either be be a processed photograph or a rendering made using the + * The image could either be a processed photograph or a rendering made using the * \pluginref{spherical} sensor. The direction conventions of this transformation * are shown in (b). * The plugin can work with all types of images that are natively supported by Mitsuba diff --git a/src/emitters/sky.cpp b/src/emitters/sky.cpp index 4b15f110..28b26583 100644 --- a/src/emitters/sky.cpp +++ b/src/emitters/sky.cpp @@ -64,7 +64,7 @@ MTS_NAMESPACE_BEGIN * \parameter{resolution}{\Integer}{Specifies the horizontal resolution of the precomputed * image that is used to represent the sun environment map \default{512, i.e. 512$\times$256}} * \parameter{scale}{\Float}{ - * This parameter can be used to scale the the amount of illumination + * This parameter can be used to scale the amount of illumination * emitted by the sky emitter. \default{1} * } * \parameter{samplingWeight}{\Float}{ @@ -160,7 +160,7 @@ MTS_NAMESPACE_BEGIN * (512$\times$ 256) of the entire sky that is then forwarded to the * \pluginref{envmap} plugin---this dramatically improves rendering * performance. This resolution is generally plenty since the sky radiance - * distribution is so smooth, but it it can be adjusted manually if + * distribution is so smooth, but it can be adjusted manually if * necessary using the \code{resolution} parameter. * * Note that while the model encompasses sunrise and sunset configurations, @@ -212,7 +212,7 @@ MTS_NAMESPACE_BEGIN * \medrendering{\code{albedo}=100%}{emitter_sky_albedo_1} * \medrendering{\code{albedo}=20% green}{emitter_sky_albedo_green} * \caption{\label{fig:sky_groundalbedo}Influence - * of the ground albedo on the apperance of the sky} + * of the ground albedo on the appearance of the sky} * } */ class SkyEmitter : public Emitter { diff --git a/src/emitters/sun.cpp b/src/emitters/sun.cpp index 89222785..615dcb1c 100644 --- a/src/emitters/sun.cpp +++ b/src/emitters/sun.cpp @@ -62,7 +62,7 @@ MTS_NAMESPACE_BEGIN * \parameter{resolution}{\Integer}{Specifies the horizontal resolution of the precomputed * image that is used to represent the sun environment map \default{512, i.e. 512$\times$256}} * \parameter{scale}{\Float}{ - * This parameter can be used to scale the the amount of illumination + * This parameter can be used to scale the amount of illumination * emitted by the sun emitter. \default{1} * } * \parameter{sunRadiusScale}{\Float}{ diff --git a/src/emitters/sunsky.cpp b/src/emitters/sunsky.cpp index 37a3c35b..5def0f09 100644 --- a/src/emitters/sunsky.cpp +++ b/src/emitters/sunsky.cpp @@ -67,11 +67,11 @@ MTS_NAMESPACE_BEGIN * \parameter{resolution}{\Integer}{Specifies the horizontal resolution of the precomputed * image that is used to represent the sun environment map \default{512, i.e. 512$\times$256}} * \parameter{sunScale}{\Float}{ - * This parameter can be used to separately scale the the amount of illumination + * This parameter can be used to separately scale the amount of illumination * emitted by the sun. \default{1} * } * \parameter{skyScale}{\Float}{ - * This parameter can be used to separately scale the the amount of illumination + * This parameter can be used to separately scale the amount of illumination * emitted by the sky.\default{1} * } * \parameter{sunRadiusScale}{\Float}{ diff --git a/src/films/hdrfilm.cpp b/src/films/hdrfilm.cpp index de5bd024..6ecb20c0 100644 --- a/src/films/hdrfilm.cpp +++ b/src/films/hdrfilm.cpp @@ -155,7 +155,7 @@ MTS_NAMESPACE_BEGIN * * Apart from querying the render time, * memory usage, and other scene-related information, it is also possible - * to `paste' an existing parameter that was provided to another plugin---for instance,the + * to `paste' an existing parameter that was provided to another plugin---for instance, * the camera transform matrix would be obtained as \code{\$sensor['toWorld']}. The name of * the active integrator plugin is given by \code{\$integrator['type']}, and so on. * All of these can be mixed to build larger fragments, as following example demonstrates. diff --git a/src/films/ldrfilm.cpp b/src/films/ldrfilm.cpp index 3333af57..bf7fdfc4 100644 --- a/src/films/ldrfilm.cpp +++ b/src/films/ldrfilm.cpp @@ -48,7 +48,7 @@ MTS_NAMESPACE_BEGIN * \begin{enumerate}[(i)] * \item \code{gamma}: Exposure and gamma correction (default) * \vspace{-1mm} - * \item \code{reinhard}: Apply the the + * \item \code{reinhard}: Apply the * tonemapping technique by Reinhard et al. \cite{Reinhard2002Photographic} * followd by gamma correction. * \vspace{-4mm} diff --git a/src/integrators/bdpt/bdpt.cpp b/src/integrators/bdpt/bdpt.cpp index efba837d..6c3f6480 100644 --- a/src/integrators/bdpt/bdpt.cpp +++ b/src/integrators/bdpt/bdpt.cpp @@ -56,7 +56,7 @@ MTS_NAMESPACE_BEGIN * paths starting at the emitters and the sensor and connecting them in every possible way. * This works particularly well in closed scenes as the one shown above. Here, the unidirectional * path tracer has severe difficulties finding some of the indirect illumination paths. - * Modeled after after a scene by Eric Veach. + * Modeled after a scene by Eric Veach. * } * } * \renderings{ diff --git a/src/integrators/photonmapper/ppm.cpp b/src/integrators/photonmapper/ppm.cpp index d4e2963a..6bcd66ef 100644 --- a/src/integrators/photonmapper/ppm.cpp +++ b/src/integrators/photonmapper/ppm.cpp @@ -65,7 +65,7 @@ MTS_NAMESPACE_BEGIN * * \remarks{ * \item Due to the data dependencies of this algorithm, the parallelization is - * limited to to the local machine (i.e. cluster-wide renderings are not implemented) + * limited to the local machine (i.e. cluster-wide renderings are not implemented) * \item This integrator does not handle participating media * \item This integrator does not currently work with subsurface scattering * models. diff --git a/src/integrators/photonmapper/sppm.cpp b/src/integrators/photonmapper/sppm.cpp index 95d22f32..8b820ff3 100644 --- a/src/integrators/photonmapper/sppm.cpp +++ b/src/integrators/photonmapper/sppm.cpp @@ -63,7 +63,7 @@ MTS_NAMESPACE_BEGIN * * \remarks{ * \item Due to the data dependencies of this algorithm, the parallelization is - * limited to to the local machine (i.e. cluster-wide renderings are not implemented) + * limited to the local machine (i.e. cluster-wide renderings are not implemented) * \item This integrator does not handle participating media * \item This integrator does not currently work with subsurface scattering * models. diff --git a/src/integrators/ptracer/ptracer.cpp b/src/integrators/ptracer/ptracer.cpp index 264b2ca5..a6aa7af5 100644 --- a/src/integrators/ptracer/ptracer.cpp +++ b/src/integrators/ptracer/ptracer.cpp @@ -34,7 +34,7 @@ MTS_NAMESPACE_BEGIN * path termination criterion. \default{\code{5}} * } * \parameter{granularity}{\Integer}{ - * Specifies the work unit granularity used to parallize the the particle + * Specifies the work unit granularity used to parallize the particle * tracing task. This should be set high enough so that accumulating * partially exposed images (and potentially sending them over the network) * is not the bottleneck. diff --git a/src/libcore/bitmap.cpp b/src/libcore/bitmap.cpp index 42eb3c9b..b2d89105 100644 --- a/src/libcore/bitmap.cpp +++ b/src/libcore/bitmap.cpp @@ -2815,7 +2815,8 @@ void Bitmap::writeOpenEXR(Stream *stream) const { Imf::ChannelList &channels = header.channels(); if (!m_channelNames.empty()) { if (m_channelNames.size() != (size_t) m_channelCount) - Log(EError, "writeOpenEXR(): 'channelNames' has the wrong number of entries!"); + Log(EError, "writeOpenEXR(): 'channelNames' has the wrong number of entries (%i, expected %i)!", + (int) m_channelNames.size(), (int) m_channelCount); for (size_t i=0; i