POV-Ray 3.7.beta.9 is available from http://www.povray.org/beta/.

This beta is currently for the Windows platform only and includes standard,
SSE2, and 64-bit binaries.

---------------------------------------------------------------------------
Note: to view an original bug report, prefix the message ID with the URL
http://news.povray.org/. For example, to read <42765ef3$1@news.povray.org>,
visit http://news.povray.org/<42765ef3$1@news.povray.org>. The '<' and '>'
are optional (if using a shell you may want to omit them).
---------------------------------------------------------------------------

The following features are not yet supported but will be added prior to release
-------------------------------------------------------------------------------

  o Light and vista buffers. These may replaced with a more efficient system.
  o Ability to choose block size allocated to threads.
  o Windows rerun dialog and statistics.
  o Redirecting text message output to files.

Known issues which will be fixed
--------------------------------

  o There is an issue with media and transparency. See <42769324$1@news.povray.org>.
  o The windows editor does not always detect new files as type 'povray'.
  o In many cases speed is not as good as 3.6.
  o Photon support is not yet completed.
  o There are some differences in the way gamma correction works.
  o Radiosity support is still very alpha and there are numerous issues.
  o Dispersion support is alpha and there are some issues.
  o 'Pixels rendered' count during mosaic preview will be incorrect.

Changes between 3.7.beta.8 and 3.7.beta.9
-----------------------------------------

Fixed crash caused by resource exhaustion (too many threads); refer
  <4303d267$1@news.povray.org>.
Addressed state issue referred to in
  <web.42af2f04951c51e46a3607400@news.povray.org>.
Fixed output file reporting issue reported in
  <web.430dc75ff23d654e726bd13c0@news.povray.org>.
Fixed AA method 2 crash reported in <430358ed@news.povray.org>.
Fixed render window re-display problem.
Moved assumed_gamma to command-line or INI-file only option (causes
  warning if found in scene).
Fixed focal blur problem.

  Render block size
  -----------------

  You now have the ability to specify the render block size via either an
  INI-style option ("Render_Block_Size=n") or on the command-line ("+BSn"),
  where 'n' is an integer larger than or equal to 4. This represents the
  edge size of the square used to distribute work to the render threads,
  and thus the number of pixels in each block will be n squared.

  The default value is 32. If you specify a value that is greater than the
  larger of the width or height of the image being rendered, it is clipped
  to that value.

  Note that using render block sizes of less than eight can impact performance,
  particularly on large images that render quickly, as it significantly
  increases the amount of message traffic between the render backend and the
  graphical frontend (which communicate using a shared-memory queue).

  Editor
  ------

  A few changes have been made to the editor in the hope of avoiding the
  error that some users get when it attempts to open a file that has been
  removed from the disk. We have not been able to replicate this error
  ourselves (the code was already designed to handle this situation) so we
  have added some extra checks. The net result of this is that when a file
  no longer exists, instead of opening a blank file, the edit session for
  that file will instead be discarded.

  Additionally we have improved the handling of modified files during active
  application changes; now, you should never get more than one message box
  displayed at any one time (which previously could happen if you switched
  focus multiple times).

  Dispersion
  ----------

  Dispersion has been added back, however this is still mostly untested.
  There will be numerous issues with this; we would appreciate help in
  identifying what they are and where they may lie (i.e. reports that
  'dispersion doesn't work properly' with no additional information will
  not be of much help).

  Radiosity
  ---------

  Radiosity has been re-enabled. Currently it is limited to a single thread
  and has some issues. As stated for dispersion, we would appreciate assistance
  in determining where individual issues lie and what influences them.

  Multi-thread support will be added later, once the radiosity code settles
  down and is functioning as expected in single-thread mode.

  Mosaic Preview
  --------------

  Mosaic preview now works again. The same issue as mentioned in the above
  section on render block size apply; we don't recommend using an end preview
  size of less than 8. Note that unless you specify an end preview size the
  code will default to using +ep2, so it is strongly recommended that you
  do provide it.

  Be aware that when using mosaic preview, the count of rendered pixels shown
  in the status bar will be wrong. This will be fixed later.

  Improved handling of large render sizes
  ---------------------------------------

  Handling of large renders (e.g. 10,000 x 5,000 pixels) has been improved.
  Previously the intermediate data structure used to store rendered pixels
  was held in RAM. On windows it is now stored in a virtual-memory backed
  file which maps to the swap file. This means that your swap file needs to
  have at least enough free space to store this file at the start of a render.
  For reference, the amount of room needed is roughly 20 bytes per pixel, so
  the above example 10,000 x 5,000 pixel image would need one gigabyte in the
  swap file.

  One other issue to be aware of is that, on windows, there has to be enough
  contiguous virtual address space available to hold the file. This can be a
  problem since by default many Win32 systems only provide each process a total
  of two gigabytes of address space, which is then divided up amongst the
  exe and its various DLL's, the local heap, stack, and so forth. Additionally
  some Win9x versions (at the least Windows 95) will only allow a maximum of
  one gigabyte to be mapped in this way, and that is divided up amongst other
  resources as well.

  Therefore it is entirely possible that even if you have sufficient swap space
  the allocation of the memory mapped file will fail, at least for win32 users
  (win64 won't have this problem). We are working to fix this limitation by
  moving to a less efficient but more reliable file-based solution.

  One final note: please be aware that the Windows process manager will add the
  amount of virtual memory mapped by a process in this way to its total memory
  statistics. Please don't assume that the figure reported by Windows is
  necessarily the amount of physical RAM being used.

Changes between 3.7.beta.7 and 3.7.beta.8
-----------------------------------------

AA buffering restored; AA should be as efficient as version 3.6 now.
Fixed major problem in crackle when using more than one thread.
Reverted to older version of Intel compiler to avoid some optimization bugs.
Added HDR file support (RGBE, as used in Radiance).
Added EXR file support using OpenEXR library (http://www.openexr.org/).
Fixed animation clock jump issue.

  HDR Support
  -----------

  As of this beta POV-Ray now supports two HDR formats for input and output.
  Firstly, .HDR files (as used in Radiance), and secondly, .EXR files (see
  www.openexr.org).

  The OpenEXR format is currently supported in basic form; no options can be
  set and we do not store any additional data such as a thumbnail or camera
  transform. We will add options later on. The EXR reading code should handle
  any valid EXR file, while the writing code currently only creates RGBA data
  in Half format.

  The EXR support is based on OpenEXR (http://www.openexr.org/) from ILM, who
  use it internally for all their film production. The format is flexible; we
  recommend anyone interested in HDR read the introduction that can be found
  at http://www.openexr.com/TechnicalIntroduction.pdf.

  Also at the above site you can obtain a HDR image viewer and a Photoshop
  plugin (Windows and Macintosh) that reads and writes EXR files.

  Please note that POV-Ray does not gamma-adjust the HDR or EXR files; they
  are stored with a gamma of 1.0. The OpenEXR viewer assumes a gamma of 2.2
  so the images will look washed out. The Photoshop plugin allows you to set
  the gamma to 1.0 on loading and thus will work as expected.

  To use HDR input, use file type 'hdr' in your SDL. To write a HDR file,
  specify '+fh'. For EXR use 'exr' and '+fe'.

Changes between 3.7.beta.6 and 3.7.beta.7
-----------------------------------------

New thread-safe random number generator added.
Continue trace support added. See below for details.
Animation support added.
Made render cancellation more responsive when large numbers of threads are
  in use.
Fixed most wrapping problems in windows message display.

  Continue Trace Support
  ----------------------

  The continue trace support has completely changed from the method used by
  past versions of POV-Ray. Previously, various means of attempting to detect
  the rendered and non-rendered portions of an output image file were used to
  determine where to resume rendering, and the pre-rendered portion of the
  image was read from the partially-written output file.

  As of POV 3.7, *no output file is written until the render is complete*.
  It is vital to remember this if you depended on having a partial image
  written for some reason other than POV's internal use. Instead of a image
  file, POV will (providing image file output is turned on) write a render
  state file, which has a name based on the output image file name. For
  example, if POV would write 'sphere.png' as the output file, the render
  state file would be called 'sphere.png.pov-state'.

  This render state file contains the raw floating-point image data that is
  generated by POV, including filter and transmit. It will later on also
  contain other information such as all render options, etc. The data itself
  is stored in an internal format that we may document at a later stage.

  If a render if sucessful, the render state file is deleted and the output
  file written. Note that this order will be changed (the state file should
  not be deleted until the image is written, in case the write fails). We may
  give the option of preserving the state file at some future point.

  If a render is started with the +C option (continue trace), POV will first
  check to see if the output image exists and is of non-zero length. If so
  the render will be skipped. Note that no attempt is (currently) made to
  sanity-check the file to ensure it is a valid image file or of appropriate
  format or size.

  If the output file does not exist, POV will then look for the render state
  file. If found it does a basic sanity check on it then loads the data in it
  and proceeds to render the unrendered portion of the image.

  It is very important to note that the data is stored in the state file in
  'blocks' (the same size as the render blocks that were used when the first
  part of the image was rendered). The size of render blocks can change if
  image resolution changes. Currently the continue code does NOT check for
  this and will simply load what is there. If the render size has changed
  sufficiently enough to change the block size when you run a continued trace
  it is almost guaranteed that you will not get what you expect.

Changes between 3.7.beta.5a and 3.7.beta.6
------------------------------------------

Fixed quadric bounding problem.
Fixed CSG merge problem.
Made numerous other changes to speed up code, should be closer to v3.6.1 now.

Changes between 3.7.beta.5 and 3.7.beta.5a
------------------------------------------

Fixed bug reported in <428de855@news.povray.org> re:sunsethf.pov.
Worked around SMP bug in trace related to lighting code altering lightsources
  during render.

Changes between 3.7.beta.4 and 3.7.beta.5
-----------------------------------------

Fixed a photon building issue that caused progressive slowdown.
Fixed scattering media problem reported in <427ca163@news.povray.org>.
  (This also fixes <427c0121@news.povray.org>).
Parser now honors Split_Unions and Remove_Bounds options.
Fixed lathe artifacts bug reported in <427c0f95@news.povray.org>.
Fixed no_image and no_reflection issues reported in
  <427c1900@news.povray.org>.
Fixed area light orient issue reported in <427c14ef@news.povray.org>.
Fixed issue where a new clip statement would overwrite a previous one rather
  than appending to it.
Fixed speed issue with quadrics by reverting to old bbox calculation method.
Fixed a swathe of memory leaks.

Changes between 3.7.beta.3 and 3.7.beta.4
-----------------------------------------

Fixed indexed PNG alpha problem reported in <42765ef3$1@news.povray.org>.
Fix area light problem reported in <427a3fa5$1@news.povray.org>.
Fixed crash during trace of lathe reported in <42796797@news.povray.org>.
Improved handling of cancel/pause render.
Fixed max_trace_level calculation and display (see
  <42769105@news.povray.org>).
Fixed image memory leak.
Fixed speed issues reported in <42769f6d@news.povray.org>.
Fixed shadow problem mentioned in <42769f6d@news.povray.org>.
Fixed sphere_sweep bug reported in <42773e51@news.povray.org>.
Fixed 'inverting pre-declared union' crash reported in
  <42769b59@news.povray.org>.
Fixed focal blur issue.
Fixed omnimax camera bug reported in <42775c1b$1@news.povray.org>, plus
  several other related camera issues.
Fixed facets pattern crash reported in <42773fab$1@news.povray.org>.

Changes between 3.7.beta.2 and 3.7.beta.3
-----------------------------------------

Partial render (start col/row etc) now works
Fixed CSG merge issue reported in <42645c3b@news.povray.org>.
Added warning and better progress reporting to photons.
Some hollow media fixes.
Re-enabled alpha display in render window for windows port.
Fixed alpha bug reported in <web.426402d627a031d914107e060@news.povray.org>
Fixed no_image bug from <web.426402d627a031d914107e060@news.povray.org>
Changed default bounding threshold back to 3 as per v3.6.
Fixed alpha inversion bug in BMP, Targa, and PNG file reading/writing.
Fixed crash mentioned in <42689685@news.povray.org>.
Fixed noise generator default issue reported in <426898db@news.povray.org>.
Fixed irid problem reported in <42680b39@news.povray.org>.
Fix for area light problem from Massimo Valentini.
Made quick_colour work as it should.

Changes between 3.7.beta.1 and 3.7.beta.2
-----------------------------------------

CSG should now work properly
Problem with too many recursions when rendering shadows fixed
I/O restrictions should now work
Fixed recursion bug in renderer
Initialise photon variables
Restore ability to open error file in editor (note: column number not always
  correct).
Fixes no-display crash
Fixes image closing bug
Tweak to some radiosity local vars
Fixes rendering area bug
Fixes AA method 2 brightness issue
Add output file type '+FB' (bmp).
Add 'bmp' token to parser.
Fix for BMP reading.
File output defaults to on.
Fix render quality options output.
Change references to 'CPU(s)' to 'thread(s)'.
Update render time output to include fractional seconds.
Fix crash reported in <4263125b@news.povray.org> and one related bug.

Intentional changes for POV-Ray 3.7
-----------------------------------

The version directive and command-line setting no longer provide compati-
bility  with most rendering bugs in versions prior to POV-Ray 3.5. However,
compatibility with the scene language is provided for scenes as old as POV-
Ray 1.0 just as in all previous versions of POV-Ray. Nevertheless, we
strongly recommend you update scenes at least to POV-Ray 3.5 syntax if you
plan to use them in future versions of POV-Ray.

This version uses multi-threaded rendering by default. The ability to render
in more than one thread is primarily of use to those users who have SMP
machines (i.e. more than one CPU). There have been reports of benefits for
users of hyperthreading systems, particularly with higher thread counts (e.g.
16 threads).

You can render in only one thread by using the '/THREADS 1' switch in the
Windows version. Note that parsing and photon building will only use one
thread no matter how many are specified. However photon scenes will benefit
from multiple threads once photon building has completed.

Post a reply to this message

Note: to ensure you are using the new editor DLL, please copy it to your
<3.6 installdir>\bin directory (but backup the old DLL first). It is not
necessary for the EXE to be in this directory, but the DLL should be.

-- Chris

Post a reply to this message

Chris Cason <43291fd2@news.povray.org> Thursday 15 of September 2005 09:16

> This beta is currently for the Windows platform only and includes
> standard, SSE2, and 64-bit binaries.

Perhaps any chances for releasing linux binary as well?

-- 
Rafa� Maj

Post a reply to this message

Hey hey hey... lots of new features switched back on. :-)

Unfortunately, my PC exploded last night, so I can't help in the testing 
effort. :-(

Post a reply to this message

Raf256 <spa### [at] raf256cominvalid> wrote:
> Perhaps any chances for releasing linux binary as well?

  AFAIK the unix frontend (or is it backend; I have never really
understood these terms... :P ) is still being worked on. I'm sure
that when the major developement of the core renderer stabilishes
then beta binaries for other platforms will also be made available.

-- 
                                                          - Warp

Post a reply to this message

Chris Cason wrote:
> Note: to ensure you are using the new editor DLL, please copy it to your
> <3.6 installdir>\bin directory (but backup the old DLL first). It is not
> necessary for the EXE to be in this directory, but the DLL should be.
> 
> -- Chris

One question: b9 seems to complain about the assumed_gamma setting in 
the scene files. I know to look right a lot of scenes requre their own 
assumed_gamma setting, now it needs to be on the command line?

Since it does require a command line option, enlighten me on what it is?

-- 
~Mike

Things! Billions of them!

Post a reply to this message

Chris Cason wrote:

>   Radiosity
>   ---------
> 
>   Radiosity has been re-enabled. Currently it is limited to a single thread
>   and has some issues. As stated for dispersion, we would appreciate assistance
>   in determining where individual issues lie and what influences them.
> 
>   Multi-thread support will be added later, once the radiosity code settles
>   down and is functioning as expected in single-thread mode.

No "radiosity mosaic", now?

This tripped me up a bit. (thinking POV-Ray had hung)

-- 
~Mike

Things! Billions of them!

Post a reply to this message

Mike Raiford wrote:
> No "radiosity mosaic", now?
> 
> This tripped me up a bit. (thinking POV-Ray had hung)

No, no progress reporting for that yet.

	Thorsten

Post a reply to this message

Raf256 wrote:
> Perhaps any chances for releasing linux binary as well?

This really has been answered more than once now in this group!!!  But as 
usual, Raf256 cannot be expected to read old messages and has to ask again :-(

	Thorsten

Post a reply to this message

Mike Raiford wrote:
> One question: b9 seems to complain about the assumed_gamma setting in 
> the scene files. I know to look write a lot of scenes requre their own 
> assumed_gamma setting, now it needs to be on the command line?

Yes, and if you really need to play with assumed_gamma, you are actually 
using it for something it isn't supposed to be used for (adjusting the 
brightness of a scene).  There will be other mechanisms for doing that 
eventually (also on the command-line though).

In case you are wondering why this (and a few other) changes are necessary, 
it has to do with the division of work between the various parts inside 
POV-Ray.  Now that we have a clear structure (in POV-Ray 3.7) various logic 
problems surface that simply did not matter before (where everybody was just 
getting their data where they wanted).  Essentially this setting and a few 
others should never have been in the scene file for this reason, but nobody 
noticed back when it was added.  Over time more patches added things to the 
global settings that they should have been command-line settings as well. 
So now we clean it us.  The upside is, this will make developing newer 
versions of POV-Ray a lot easier and faster because the chance to cause a 
bug by some minor change that some other end of the code depends on its a 
whole lot smaller.

> Since it does require a command line option, enlighten me on what it is?

The same one it used to be in the scene file ;-)

	Thorsten

Post a reply to this message

Thorsten Froehlich wrote:
> Mike Raiford wrote:
> 
>> One question: b9 seems to complain about the assumed_gamma setting in 
>> the scene files. I know to look write a lot of scenes requre their own 
>> assumed_gamma setting, now it needs to be on the command line?
> 
> 
> Yes, and if you really need to play with assumed_gamma, you are actually 
> using it for something it isn't supposed to be used for (adjusting the 
> brightness of a scene).  There will be other mechanisms for doing that 
> eventually (also on the command-line though).

Wow. Glad you made sense of what I wrote (I think I was short on 
caffiene at the time ;). Yes, this is what I was using it for, mainly in 
radiosity scenes it seems to bring out the shadows a bit more. A better 
alternative to this might be something like the tone-mapping patch in 
MegaPOV (I don't know if it is technically feasable, given your 
explanations of the assumed_gamma issue)

Anyway, I was wondering, becuase it seemed like the assumed_gamma 
commandline option wasn't having an effect.

> In case you are wondering why this (and a few other) changes are 
> necessary, it has to do with the division of work between the various 
> parts inside POV-Ray.  Now that we have a clear structure (in POV-Ray 
> 3.7) various logic problems surface that simply did not matter before 
> (where everybody was just getting their data where they wanted).  
> Essentially this setting and a few others should never have been in the 
> scene file for this reason, but nobody noticed back when it was added.  
> Over time more patches added things to the global settings that they 
> should have been command-line settings as well. So now we clean it us.  
> The upside is, this will make developing newer versions of POV-Ray a lot 
> easier and faster because the chance to cause a bug by some minor change 
> that some other end of the code depends on its a whole lot smaller.
> 

In the end, I think this will be very positive for the program, this 
seems to be what is making this such a long beta cycle and breaking so 
many things.

-- 
~Mike

Things! Billions of them!

Post a reply to this message

Mike Raiford wrote:
> Anyway, I was wondering, becuase it seemed like the assumed_gamma 
> commandline option wasn't having an effect.

It won't yet, that part isn't implemented yet.  With gamma the only thing 
that changed was the warning message between beta 8 and beta 9, the frontend 
doesn't make any use of gamma yet.

> In the end, I think this will be very positive for the program, this 
> seems to be what is making this such a long beta cycle and breaking so 
> many things.

Well, the beta cycle for POV-Ray 3.5 was well over half a year with iirc 18 
public releases.  So we are within the usual timeframe I suppose :-)

	Thorsten

Post a reply to this message

One thing I neglected to mention is that radiosity save/load isn't
implemented at the moment, so please don't be surprised if it doesn't
work ...

-- Chris

Post a reply to this message

Moving assumed_gamma out of the scene file is going to be a very good thing. 
I was glad to read that in changes.txt.

I thought, right away, that the idea is to make it less of an image tweak 
and more of a display adjustment like it was intended for. In other words, 
it probably got overused or abused where it was. Prior to version 3.6 I was 
often unconcerned with what affect I was doing to the scene file and its 
render as to any global sense. Global meaning other computers not just 
global to a rendered scene.

I must be thinking of MegaPOV about some sort of contrast adjustments on the 
scene renders. Seemed like someone here mentioned replacing assumed_gamma 
with a way to do that instead, but I don't find anything said of it.

Of course, I realize now, this official change is likely to be only a gamma 
code remake and not a feature addition at the same time.

Post a reply to this message

> Essentially this setting and a few
> others should never have been in the scene file for this reason

I don't understand this (for assumed_gamma only).

I do understand that assumed_gamma was never meant to be used for adjusting
the brightness of a scene.

However, I thought its purpose was to let the artist say, "when I made this
image, I assumed the viewer had a gamma of x." That's an important
assumption that affects the appearance of the colors the artist chose. In
that way, it is strongly linked to the scene (and so should be stored in the
scene file).

The only thing that should be able to change when the image is rendered on a
different computer is the display gamma, so that when POV-Ray does its gamma
correction, the render displayed on the screen appears the same as it did to
the artist on his own screen. Allowing the renderer to change the
assumed_gamma - that is, to change an assumption the artist based his colors
off of - will cause the final image to look different.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Slime wrote:
>>Essentially this setting and a few
>>others should never have been in the scene file for this reason
> 
> I don't understand this (for assumed_gamma only).
> 
> I do understand that assumed_gamma was never meant to be used for adjusting
> the brightness of a scene.
> 
> However, I thought its purpose was to let the artist say, "when I made this
> image, I assumed the viewer had a gamma of x." That's an important
> assumption that affects the appearance of the colors the artist chose. In
> that way, it is strongly linked to the scene (and so should be stored in the
> scene file).

Well, yes and no.  You might know, the gamma factor POV-Ray uses internally 
is simply assumed-gamma divided by display-gamma.  So what assumed-gamma is 
really good for is tweaking display-gamma.  Of course, as you argue, that is 
specifically what it is designed for.  The main problem is that it is not 
what it gets used for.  To make proper use of it, you first need a proper 
display-gamma.  The chance that you have to tools (an external measurement 
device or a pre-calibrated screen) is extremely unlikely.  So you cannot get 
a truly accurate display-gamma.  Consequently, what do you do?  You tweak 
assumed-gamma because that is what you can easily change on a scene by scene 
basis.

So assumed-gamma makes sense, right? Wrong! ;-)  What you did with this use 
of assumed-gamma is exactly what it is not for because all you do is alter 
the brightness on a scene by scene basis, while still using the exact same 
display and display-gamma.  So, what you get is indeed some kind of 
brightness adjustment, but that isn't what assumed-gamma is for.  Yet, that 
is what you effectively used it for, without really doing so consciously.

So, if you think about it, what good is assumed-gamma for once you adjusted 
display-gamma to your screen?  Basically, nothing that has to do with gamma! 
:-)

Thus, while we still provide it mainly for backward compatibility as far as 
possible (you can render old scenes without changing your display-gamma), to 
adjust brightness we will provide a more flexible and more suitable mechanism.

I realise this is a huge change.  Still, it is one we had to make for a 
"better future".

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> I realise this is a huge change.  Still, it is one we had to make for a 
> "better future".

  Will POV-Ray include a way to modify the rendered pixels in the scene file
with eg. a user-defined function?

-- 
                                                          - Warp

Post a reply to this message

> You tweak
> assumed-gamma because that is what you can easily change on a scene by
scene
> basis.


I'm sure a lot of people do this, but I wouldn't be surprised to hear of
someone who had used assumed_gamma properly. For instance, if I had
discovered assumed_gamma one day and decided I should use it, I would have
set assumed_gamma 1.8 (for instance) in all my old scenes (since I had
developed them assuming the viewer had the same gamma my screen did), and
then used assumed_gamma 1 in all my new scenes. If I also set
display_gamma=1.8 in povray.ini, my old scenes wouldn't change, and my new
scenes would be rendered properly for anyone else who had their
display_gamma set.

So what if there are people out there who have done just this? I'm worried
you're removing an important feature because some people use it wrong.

Given the purpose of the feature, and how its meaning is linked to the
scene, I think it would make more sense to remove it entirely than make it a
command-line option. If it's still available, people might still abuse it,
so the only people who suffer are the ones who used it properly in the first
place.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Rendering scenes\advanced\abyss.pov gives, once again, an image with
a black background, not light cyan as should be.

-- 
                                                          - Warp

Post a reply to this message

Bob Hughes wrote:
> 
> I must be thinking of MegaPOV about some sort of contrast adjustments on the 
> scene renders. Seemed like someone here mentioned replacing assumed_gamma 
> with a way to do that instead, but I don't find anything said of it.

Since the MegaPOV tone mapping has been brought up in this context i 
like to point out a few things.

The tone mapping patch primarily allows to apply color adjustments prior 
to antialiasing (although it allows to specify them for post-aa as well) 
which can be useful for high quality results with more-than-subtle 
nonlinear adjustments.  This has been discussed in depth and no need to 
bring this up again.  The patch can be used to do exactly what 
assumed_gamma does (both before and after aa at your decision) and there 
is a macro in tone_mapping.inc (Gamma_Correct()) that does exactly this.

The display_gamma/assumed_gamma distinction does only make sense if 
assumed_gamma can be set in the scene file (and in this case there is no 
real point to restrict it to a gamma factor).  Without this two distinct 
gamma factors are confusing and should be replaced by a single one (for 
which both display_gamma and assumed_gamma would be misleading names).

Christoph

-- 
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/

Post a reply to this message

Slime wrote:
> I'm sure a lot of people do this, but I wouldn't be surprised to hear of
> someone who had used assumed_gamma properly. For instance, if I had
> discovered assumed_gamma one day and decided I should use it, I would have
> set assumed_gamma 1.8 (for instance) in all my old scenes (since I had
> developed them assuming the viewer had the same gamma my screen did), and
> then used assumed_gamma 1 in all my new scenes. If I also set
> display_gamma=1.8 in povray.ini, my old scenes wouldn't change, and my new
> scenes would be rendered properly for anyone else who had their
> display_gamma set.

This logic won't fly, I am afraid.  In this case all you do is fix the 
incorrect use of assumed-gamma in the old scenes (because you had an 
incorrectly set display-gamma).  And it would be easier to do in an INI file 
then because you would only have to supply one "old scenes" INI file.

As pointed out, there really should be only one gamma setting, not two.

	Thorsten

Post a reply to this message

Thorsten Froehlich <43296e79$1@news.povray.org> Thursday 15 of September
2005 14:52

> This really has been answered more than once now in this group!!!  But as
> usual, Raf256 cannot be expected to read old messages and has to ask again
> :-(

No, I didnt noticed the follow-up-to until now...

-- 
Rafa� Maj

Post a reply to this message

Chris Cason <nos### [at] deletethispovrayorg> wrote:
>   o Radiosity support is still very alpha and there are numerous issues.


Hi all! I've started fooling around with radiosity and... not that i want to
sound rude to our beloved developing team, but i can't seem to get anything
sensible when radiosity is on, even in the simplest situations.

For instance, a red box over a plain plane (which can be thought of as a
beta version of the rsocp) leads to the results posted in pbtb. I don't
know the insides of Povray, but i'd say that currently the radiosity
samples are not distributed randomly in all directions of space, but rather
chosen following a wicked kind of reflection.

The sphere case is yet weirder, a cap of the sphere looks like it's been
bumped in.

I tried to play with:
- count: Seems to do nothing at all.
- error_bound: does have an effect, the lower, the sharper the image.
- recursion_limit: does **strongly** slow down the rendering, much more than
in 3.6.1a.
- pretrace_end: the lower, the smoother the results, as expected.

Well, i'm willing to keep testing and identifying... but maybe i'd need
pointers from experienced beta testers. Thanks!

JYR

Post a reply to this message

JYR wrote:
>>  o Radiosity support is still very alpha and there are numerous issues.
> 
> Hi all! I've started fooling around with radiosity and... not that i want to
> sound rude to our beloved developing team, but i can't seem to get anything
> sensible when radiosity is on, even in the simplest situations.
<snip>
> Well, i'm willing to keep testing and identifying... but maybe i'd need
> pointers from experienced beta testers. Thanks!

As we said, it is in an alpha state, and does not really work in many, many 
cases.  We had to release a new beta but radiosity just needed a tiny bit 
more work than we had time for to get those things worked out.  A new beta 
will appear in a few days or so and add the corrctions we were working on. 
This is a beta test and we marked radiosity as in an alpha state, so what 
you report is expected and the simplest thing is to not waste your time on 
it when you notice it doesn't work for you until we say we think we have 
worked out the major known problems.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> As we said, it is in an alpha state,
Point well taken Thorsten, thanks for your detailed and explanatory answer.
As a non-developper myself, i didn't exactly know what to expect from a
"very alpha" feature.

> the simplest thing is to not waste your time on it
.... and i'll quit wasting yours, by the way!!! :)

JYR

Post a reply to this message

I've just run the source you posted through the current code, which has had a
number of fixes put into it since beta.9 was released, and it now renders
identically to version 3.6 ... the radiosity really needed fixing before we
released beta 9 but I didn't want to let the old one expire without a new
beta being released.

I'll post a beta 9a shortly with the fixed radiosity.

-- Chris

Post a reply to this message