 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <nos### [at] deletethis povrayorg> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
