POV-Ray : Newsgroups : povray.general : POV-Ray v3.7.beta.10 available. Server Time
29 Jul 2024 02:29:04 EDT (-0400)
  POV-Ray v3.7.beta.10 available. (Message 1 to 2 of 2)  
From: Chris Cason
Subject: POV-Ray v3.7.beta.10 available.
Date: 19 Oct 2005 08:34:48
Message: <43563d68@news.povray.org>
POV-Ray 3.7.beta.10 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 will be replaced with a more efficient system.
  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 Radiosity support is still alpha quality.
  o No preview during radiosity pre-trace.
  o Dispersion support is alpha and there are some issues.
  o 'Pixels rendered' count during mosaic preview will be incorrect.
  o Photons do not currently work.

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

Added gamma correction support.
Add more frequent stop-checking to all render tasks.
Radiosity now works a lot better than beta.9.
Fixed some memory leaks in radiosity.
Fixed crash in some image file reads.
Improved handling of cancel render in windows version.
Fixed output filename generation logic.
Changed all internal file paths to UCS2.
Fix for using truetype in CSG.
Improved responsiveness in backend.

  Gamma Correction
  ----------------

  The way POV-Ray 3.7 handles the 'assumed_gamma' keyword has changed.
  Previously the presence of this keyword in global_settings caused a
  'possible error' warning and its presence was ignored. In addition
  no gamma correction was available in previous betas. Starting with
  beta.10 however, gamma correction is performed on both the display and
  file output, subject to the following criteria:

    o If the scene language version is set to 3.7 (or not set at all), then
      gamma correction will default to ON, with the value used being set by
      the 'display_gamma' INI file setting. Note that in previous versions of
      POV-Ray gamma correction was OFF by default but otherwise this is the
      same.

    o If the scene language version is set to earlier than 3.7, then gamma
      will be OFF by default.

    o Notwithstanding the above, if the keyword 'assumed_gamma' is present
      in the scene's global_settings, then POV will take one of the following
      actions:

        a) if "assumed_gamma 2.2" is present, gamma correction will be turned
           OFF and a warning issued. the same thing will happen if the value
           specified is not 2.2 but happens to be the default for the platform
           setting given to POV-Ray when it was compiled (e.g. Windows is 2.2).

        b) if "assumed_gamma 1.0" is present, gamma correction will be turned
           ON (if it's not already on) and in any case a warning will be issued.

        c) if a value other than the above is specified, it is ignored and a
           'possible error' message is issued.

      You will note from the above that therefore it is no longer possible to
      adjust the amount of gamma correction from a scene file. This is as
      designed since scene files should be as much as possible be platform
      independent, and the gamma of particular display hardware does not belong
      in the scene file. If you really need to specify 'assumed_gamma' you can
      do so in an INI file or on the command-line; however in those cases you
      may as well just use 'display_gamma' in its place.

      When writing file formats that support gamma specification, the inverse
      of the assumed_gamma value will be embedded in the file headers, so that
      an appropriately equipped display program can 'undo' the gamma correction
      if it is so desired. This is as per previous versions of POV-Ray.

  Frontend and Backend
  --------------------

  Note that POV-Ray uses a logical separation of frontend and backend. The
  'frontend' is that part which deals with the user-interface, locating files,
  parsing command-line options, reading INI files, and so forth. The 'backend'
  deals with parsing the scene file and doing the actual render. These two parts
  of POV-Ray communicate via a message-passing interface, even when linked into
  the one executable program.

  Whilst currently not supported, it is entirely possible to separate the front
  and back ends via for example a network interface, and have the render done
  on one machine while the user interface (and display) is on another. Knowing
  this may make it easier to understand why, for example, we are moving away
  from allowing things such as gamma correction to be specified in the scene
  file; there is no reason to assume the scene file is on the same machine as
  the image will be displayed upon, and as such the specification of gamma
  should be done in the frontend via INI or command-line options.

  There will be more changes along these lines as we prepare for the future
  transition to a fully network-capable renderer. The POV-Team will attempt
  to ease the change to the new system by doing things such as the assumed_gamma
  interpretation above, where it is possible to do so.

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

From: Mike Raiford
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 19 Oct 2005 10:00:38
Message: <43565186$1@news.povray.org>
Chris Cason wrote:

>   Whilst currently not supported, it is entirely possible to separate the front
>   and back ends via for example a network interface, and have the render done
>   on one machine while the user interface (and display) is on another. Knowing

Why did I just have visions of having a whole rack of 4-way SMP machines 
running some of the more complex renders.

So, is this to say that POV-Ray will "officially" support clusters? Or 
are you saying this opens the door for the developer community to create 
a patch to do so, such as a form of POV-Ray that would work seamlessly 
with IMP, for example?
-- 
~Mike

Things! Billions of them!


Post a reply to this message

From: Chris Cason
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 19 Oct 2005 17:50:24
Message: <4356bfa0@news.povray.org>
Mike Raiford wrote:
> So, is this to say that POV-Ray will "officially" support clusters? Or 
> are you saying this opens the door for the developer community to create 
> a patch to do so, such as a form of POV-Ray that would work seamlessly 
> with IMP, for example?

At the moment we are concentrating on making sure the infrastructure exists
internally to allow us to separate the concept of user interface and renderer
which originally had a one-to-one relationship. That is, for each scene file
being parsed there was exactly one user interface (even if command-line), and
for each sucessfully-parsed scene file there was exactly one render started,
after which the parsed data was deleted from memory.

Since implementing the SMP support required us to basically rip the code
apart and bolt it back together again without the use of the literally
hundreds of global variables and other bits of writable shared data which
wouldn't work with multiple threads, we took the opportunity to implement
what is known as the 'document/view' model (this is what is used by many MDI
programs based on MFC, though of course our code has nothing to do with that
other than sharing the concept).

With respect to the doc/view concept, a parsed scene is a 'document' and a
render is a 'view'. The 'document' is everything in the scene except the
camera settings, and the 'view' is the camera settings, output resolution,
output file type, gamma correction, and so forth. Each document and view has
its own internal identifier and the POV-Ray code uses these ID's when
communicating between the front and back ends of the codebase. When a scene
is succesfully parsed the frontend is told about it, and it then using that
ID creates a view and subsequently asks the backend to render that view.

The parse and render stages are therefore now quite distinct and in
particular the render requires an explicit command from the frontend
referencing the parsed scene's ID to kick off the actual tracing.

What this also implies should now be clear: a parsed scene ('document') is a
separate object that has its own lifetime. It does not automatically vanish
once a render is successful; we have to explicitly delete it. And also that
you can have more than one render ('view') of a document from different
camera positions without re-parsing the scene. And furthermore you can have
more than one document in memory at once and be rendering one or several
views of those documents at any given time (presuming you have the resources
and CPU horsepower to make it practical).

There are still a few restrictions in the backend code making a simultaneous
multi-scene render impractical but the code as a whole already works exactly
as I have described.

You may note therefore - since the frontend and backend have the concept of
"document id's" - that this meshes in nicely with the ability of a frontend
to be in a different *place* than the backend. We don't pass pointers around
between the user-interface and renderer anymore, we refer to resources in a
more abstract way. Coupled with the fact that we use message-passing
interface that is not sensitive to the local machine's word size or
endianness, the ability to have remote renders just comes naturally.

However (and yes there is a however), we currently have no user-interface
support for this and don't plan on adding it anytime in the near future as
we're busy with the core code. Plus there's no transport (e.g. tcp) or
authentication support written yet.

Getting back to your original question: as you can see it's clear that
network support could be implemented by someone else. However I feel that
it is best done by us because (a) I don't want a raft of incompatible network
implementations out there, and (b) properly thought-out authentication and
security is essential if we want this to take off. We don't want to see POV
get a bad security reputation because someone somewhere does a quick network
port that ends up compromising someone's hardware.

If a group of sufficiently dedicated users wanted to get together and help
hammer out implementation details for networked rendering then I'd be willing
to listen.

Now that's a long reply to a simple question but in the process at least I've
publicly put into hardcopy some of the logic behind the rather large changes
that have been made to POV-Ray 3.7 (and perhaps now some will understand why
each beta takes so long - there's really a huge amount of infrastructure work
in there that we have to deal with and finish, totally apart from the actual
rendering bugs).

-- Chris


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 19 Oct 2005 21:53:17
Message: <4356f88d$1@news.povray.org>
Chris Cason wrote:
> what is known as the 'document/view' model

Also, in the early days commonly known as model-view-controller concept 
(whereas the controller is not directly mentioned in modern paradigms, it is 
assumed to be part of the view).  The model really is the "model" aka scene 
in POV-Ray, the view is the frontend, actually two views, the rendered image 
and the scene source.  Ideally the text editor would also allow direct 
control over the image view (a WYSIWYG paradigm), but of course in POV-Ray 
that isn't possible (Moray gets close to that though afaics) as the parser 
is in between :-)

As Chris mentions, the complexities in the code POV-Ray are now mostly 
hammered out, but the real topic is to get it in a nice, still easy to use 
GUI.  Hiding the complexities of distributed computers is not trivial, in 
particular to do it right, and if possible the first time is really difficult.

Another benefit Chris did not mention explicitly is that finally we can have 
the GUIs evolve at a different rate than the rendering core. Previously 
extending the GUI always required rather complicated render core changes if 
the GUI needed new data.  Now we can just say that if a message passes data 
from the backend and a particular piece of information is not there, well, 
we don't display it, while before it meant a different internal call 
structure with different parameters and a whole mess.

In fact, this design process did start with POV-Ray 3.5 already, and it has 
been making smaller steps with every release of POV-Ray since then.  Now 
with POV-ray 3.7 all these internal changes for the message-driven control 
that have been going on for five years now finally show results and 
*improvements* for users.  Especially for POV-Ray 3.6 a lot was done already 
in cleaning up the early 3.5 implementation of this.  So anybody who had a 
look at the 3.6 or 3.5 source code and thought "Why do they do all this 
complicated message passing abstraction just to turn it into text again ten 
calls down the call chain ?" has their answer - it was of tremendous help to 
get clean SMP support working to some extend within less than one month!

Nevertheless, as you can see, doing proper and clean SMP support is a 
massive task and nothing a simple patch could ever have established (the 
existing patches for distributed rendering just run multiple copies of 
POV-Ray and duplicate *all* scene data).  In the end, we will probably have 
"invested" two full-time developer years into getting the POV-Ray 3.7 core 
to do SMP, and that doesn't even include any new features or the GUI frontends!

	Thorsten


Post a reply to this message

From: pan
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 20 Oct 2005 12:28:32
Message: <4357c5b0@news.povray.org>
"Chris Cason" <nos### [at] deletethispovrayorg> wrote in message
news:4356bfa0@news.povray.org...
>
> What this also implies should now be clear: a parsed scene ('document') is
a
> separate object that has its own lifetime. It does not automatically
vanish
> once a render is successful; we have to explicitly delete it. And also
that
> you can have more than one render ('view') of a document from different
> camera positions without re-parsing the scene. And furthermore you can
have
> more than one document in memory at once and be rendering one or several
> views of those documents at any given time (presuming you have the
resources
> and CPU horsepower to make it practical).
>

Does this mean that a parsed scene object will exist that might one day be
saveable to disk that might later be reloaded and rerendered with a
different
view with no need for reparsing?

Pan


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 20 Oct 2005 14:41:45
Message: <4357e4e9$1@news.povray.org>
pan wrote:
> Does this mean that a parsed scene object will exist that might one day be
> saveable to disk that might later be reloaded and rerendered with a
> different view with no need for reparsing?

A "parsed scene object" always has and always will exist.  The scene 
structure has to be in memory to be rendered, POV-Ray always worked this 
way.  This has nothing to do with the ancient - and useless, dig in 
povray.programming around 1998 to 2000, there is more than one thread about 
this there - binary scene file "idea".  To summarise thsoe discussions, a 
"binary" scene file format would not make loading a scene faster, nor offer 
any other benefit compared to the paser as it is.

Either way, the changes in POV-Ray 3.7 having nothing to do with the parser 
in the first place anyway.

	Thorsten


Post a reply to this message

From: Mike Raiford
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 20 Oct 2005 15:41:51
Message: <4357f2ff$1@news.povray.org>
Thorsten Froehlich wrote:

> about this there - binary scene file "idea".  To summarise thsoe 
> discussions, a "binary" scene file format would not make loading a scene 
> faster, nor offer any other benefit compared to the paser as it is.


It could fill up a significantly larger area of storage for some scenes, 
though :)

Sorry, I couldn't resist.

-- 
~Mike

Things! Billions of them!


Post a reply to this message

From: Warp
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 21 Oct 2005 04:20:55
Message: <4358a4e7@news.povray.org>
abyss.pov is still rendering incorrectly (ie. with a black background).

  I also noticed that stackergold.pov takes 10 times longer to parse
with pov3.7beta10 than it takes with pov3.6.1 (21 seconds vs 2 seconds
in my computer).

-- 
                                                          - Warp


Post a reply to this message

From: Chris Cason
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 22 Oct 2005 03:54:39
Message: <4359f03f@news.povray.org>
Warp wrote:
>   abyss.pov is still rendering incorrectly (ie. with a black background).

Noted, thanks, this has still to be addressed.

>   I also noticed that stackergold.pov takes 10 times longer to parse
> with pov3.7beta10 than it takes with pov3.6.1 (21 seconds vs 2 seconds
> in my computer).

Good find, thanks ... this is caused by the fact that as of this beta each
attempt to open a file causes a call to the frontend that has to be replied
to (the frontend controls locating files and granting access permission, and
in the long term - once support is added - can even send the file contents to
the backend via POVMS).

Obviously this has to be made more efficient; for some reason  the results
aren't being cached though they are supposed to be (stackergold's use of
macros causes a lot of file access).

-- Chris


Post a reply to this message

From: Rangifer
Subject: Re: POV-Ray v3.7.beta.10 available.
Date: 23 Oct 2005 05:21:46
Message: <435b562a$1@news.povray.org>
Chris Cason wrote:
> POV-Ray 3.7.beta.10 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.

And for some reason also beta 9..

-r


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.