 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
POV-Ray 3.7.beta.11c 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.10 and 3.7.beta.11c
--------------------------------------------
No core bugs have been fixed. This release extends the expiration time
to the start of April 2006 and provides a new render window feature.
Render Window
-------------
The new render window mode is only available on Windows 2000 or later.
The presence of this code may case the beta to be unable to load on
Windows 9x systems; if this occurs it will be fixed in the next beta.
Note that we have not tested this new code on a Windows 2000 system,
so we can't comment on how well it will work on those systems.
To activate the new render window, open the 'Render Window' sub-menu in
the 'Options' menu, and select the 'Use New-style Render Window' entry.
The new render window is designed to help users get around the issue of
the render window getting in the way when doing edit/render/fix cycles.
It supports a 'transparency' mode that is in effect two things: both
optical transparency (or more specifically translucency), and input
transparency (more specifically, the Windows WS_EX_TRANSPARENT style).
'Input transparency' means that the window is transparent to input -
so if you move your mouse over it or attempt to click on it, the mouse
messages are in fact sent to whatever is underneath the window. In
effect therefore it is as if the window were not there - even if you
can still see it.
The effect of this is that, coupled with translucency, you can both
see what is under the window (e.g. the POV-Ray editor), and also work
with it (typing or selecting with the mouse, etc).
'Input Transparency' is enabled whenever you set the translucency of
the render window to 25% or more (see below). At settings less than
this, the render window will behave more or less as normal (though
without some of the features of the classic render window, such as the
ability to be de-coupled from the main window such that it does not
get hidden when the main window is minimized).
To set the translucency of the render window, either rotate your mouse
wheel when the render window has focus (this is the preferred method),
or alternatively right-click on the window's title bar and choose a
setting from the context menu that is provided.
When the render window has input focus, translucency is removed and it
becomes opaque. It will switch back once another window gets focus, or
if you adjust the translucency using one of the above methods.
If you want to work with input transparency, it is important that you
understand that this means you can't work with the render window in
the manner you are accustomed to, since of course the window will pass
input to the application below it. To allow for interaction with the
window in this circumstance, we have added a feature whereby hovering
the mouse over the render window's caption for a short time, or clicking
on the title bar, will activate the window, make it opaque, and allow
input to be processed normally.
(Of course the ability to click on the caption means that it's not
completely input transparent, and we might disable this feature later
if the hover feature works out well).
You will know if your mouse is over the appropriate area of the window
since the cursor will turn to a hourglass shape during the 'hover' time.
Provided that the window is left in input transparency mode, if you
move your mouse out of the window for a short time, it will automatically
snap back into its former translucent mode.
You can tell if the window is in input transparency mode by looking for
a '[T]' at the start of the render window caption. If present, then it's
going to pass input to the application underneath it. While adjusting
the translucency with the mouse wheel, the caption will display the new
translucency setting and, if appropriate, a comment that the window has
switched to passing input. (Recall however that this doesn't kick in
until you switch focus to another window).
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
Chris Cason wrote :
> POV-Ray 3.7.beta.11c is available from http://www.povray.org/beta/.
>
> This beta is currently for the Windows platform only and includes stand
ard,
> SSE2, and 64-bit binaries.
That's a shame that POVRay beta is only available for Windows. My policy
as a developer is to support Linux and MacOSX platforms ... I do regret
that the POVTeam has the exact opposed policy :( Who benefit from it ?
Regards,
-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
Chris Cason a écrit :
> POV-Ray 3.7.beta.11c is available from http://www.povray.org/beta/.
>
> This beta is currently for the Windows platform only and includes stand
ard,
> SSE2, and 64-bit binaries.
That's a shame that POVRay beta is only available for Windows. My policy
as a developer is to support Linux and MacOSX platforms ... I do regret
that the POVTeam has the exact opposed policy :( Who benefit from it ?
Regards,
-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Be glad they're releasing anything at all, for starters. If they were
being paid, they might be obligated to do certain things. But they're
not. Got a problem with it? Write your own raytracer.
--
Tim Cook
http://home.bellsouth.net/p/PWP-empyrean
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois LE COAT wrote:
> That's a shame that POVRay beta is only available for Windows. My policy
> as a developer is to support Linux and MacOSX platforms ... I do regret
> that the POVTeam has the exact opposed policy :(
The majority of beta testers has always been on Windows (as the majority of
users of POV-Ray are on Windows). It takes a lot of time to prepare every
beta, and it takes even more time supporting it.
I also think it has not escaped your (or at least most of the people around
here) attention that currently the POV-Team members' time for POV-Ray is
very limited, having already caused delays of 3.7 beta development and bug
fixing, due to mention real-life limitations. As such, there simply has been
no time yet to create a Mac or Linux beta version as there are more urgent
core code bugs to be fixed and features to be completed.
> Who benefit from it ?
The Mac and Linux users benefit the most, because once they get a beta, they
will have a very solid beta already because the Windows users will have
found the majority of bugs.
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
From: Francois LE COAT
Subject: Re: POV-Ray v3.7.beta.11c available.
Date: 5 Feb 2006 12:30:46
Message: <43e63646@news.povray.org>
|
|
|
| |
| |
|
|
Hi Tim,
Tim Cook wrote :
> Be glad they're releasing anything at all, for starters. If they were
> being paid, they might be obligated to do certain things. But they're
> not. Got a problem with it? Write your own raytracer.
I'm not speaking about my personal interest, but about general policy.
I'm supporting POV for more than 10 years now. Specially on ATARI
platforms. Do you know that Windows is *the* latest non Unix OS ?
Why should it be promoted rather than any other OS ?
Regards,
-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois LE COAT wrote:
> Why should it be promoted rather than any other OS ?
Market share.
--
Darren New / San Diego, CA, USA (PST)
Crate & Barrel -
Furnishing Video Games Since 1962!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Cook wrote:
> Be glad they're releasing anything at all, for starters. If they were
> being paid, they might be obligated to do certain things. But they're
> not. Got a problem with it? Write your own raytracer.
That's actually quite misleading. POV-Ray is open to everyone
interested to use and improve it. The fact that the beta is currently
only available for a single platform does not mean you can't get
involved with improving POV-Ray when on a different platform.
And just to once again make this clear (although it has been mentioned
several times already): The 3.7 beta is not yet near being ready for
production use.
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.imagico.de/ (Last updated 31 Oct. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:43e6098f@news.povray.org Chris Cason wrote:
> The new render window is designed to help users get around the issue
> of the render window getting in the way when doing edit/render/fix
> cycles.
Nice feature, thanks Chris.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <ing### [at] tag povrayorg> wrote in message
news:Xns9761CFADD3F36seed7@news.povray.org...
> in news:43e6098f@news.povray.org Chris Cason wrote:
>
>> The new render window
>
> Nice feature
Definitely. I'll second that thankyou.
If I may suggest something... it might be best to leave it opaque initially
even when set to shift to semi-transparent, that way it could be seen
normally when a render is started. I'm thinking this because it might make
test renders difficult to see correctly, also if intended to let it finish
without further editing, Otherwise the setting, or placement of cursor
(lacking a scroll wheel), needs changing in the menu to keep opacity for
those situations so it just makes more sense to me that it be opaque at the
onset of a render and only be semi-transparent thereafter when focusing on
the editor at some time.
Bob Hughes
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois LE COAT wrote:
> Hi Tim,
>
> Tim Cook wrote :
>> Be glad they're releasing anything at all, for starters. If they were
>> being paid, they might be obligated to do certain things. But they're
>> not. Got a problem with it? Write your own raytracer.
>
> I'm not speaking about my personal interest, but about general policy.
> I'm supporting POV for more than 10 years now. Specially on ATARI
> platforms. Do you know that Windows is *the* latest non Unix OS ?
> Why should it be promoted rather than any other OS ?
>
> Regards,
>
> -- François LE COAT
> Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
> http://eureka.atari.org
It's not being promoted. The POV-Team is focusing on fixing bugs
related to the new feature (multithreading). To minimize distractions
from this, they have decided to focus on a single platform for the
development.
They could do source releases and focus on implementing the changes only
in the generic code versions; however, due to past experiences the
POV-Team has decided that time-limited binaries better suit their needs
(and the community's).
Since they must do a binary release, on a single platform, they simply
chose the platform with the greatest number of users.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Francois LE COAT" <lec### [at] atariorg> wrote in message
news:43e62a8f$1@news.povray.org...
> Hi,
>
> Chris Cason a écrit :
> > POV-Ray 3.7.beta.11c 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.
>
> That's a shame that POVRay beta is only available for Windows. My policy
> as a developer is to support Linux and MacOSX platforms ... I do regret
> that the POVTeam has the exact opposed policy :( Who benefit from it ?
POV-Ray is well-known for its multiple platform support. The overhead involved
in producing a compile for each platform that POV-Ray supports for each beta
release would be extreme, and is unnecessary for the testing process.
By restricting testing to just one platform it benefits the POV Team, as less
time is wasted producing various compiles every time a new beta is released,
which allows the development to progress more quickly, which ultimately benefits
all POV-Ray users. So in answer to your question regarding who benefits: all
POV-Ray users benefit in the end.
Lance.
thezone - thezone.firewave.com.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Lance Birch <-> wrote:
> POV-Ray is well-known for its multiple platform support. The overhead involved
> in producing a compile for each platform that POV-Ray supports for each beta
> release would be extreme, and is unnecessary for the testing process.
It's not just a question of compilation: Frontends need to be created
for each platform. Not a trivial task.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:43e8be8f@news.povray.org...
> Lance Birch <-> wrote:
> > POV-Ray is well-known for its multiple platform support. The overhead
involved
> > in producing a compile for each platform that POV-Ray supports for each beta
> > release would be extreme, and is unnecessary for the testing process.
>
> It's not just a question of compilation: Frontends need to be created
> for each platform. Not a trivial task.
Definitely. I'm simplifying things greatly - there is so much to do to create
each platform's release. I was just noting the time overhead involved for each
revision of the beta if you were to create one for each platform... compiling
for each platform (as it is, there are three compiles; 32-bit/32-bit
SSE2/64-bit), compressing the various platform compiles with their documentation
into separate archives, updating the website with the multiple platform compiles
and no doubt writing notes for each, and so on. It would probably take 5 times
as long just to organise the compiles for the revisions and get them on the
website, let alone the actual development involved. One release is complex
enough, and for the purposes of testing and debugging the new internals one
platform is all that is required (and choosing the platform with the largest
beta tester user base is common sense).
People seem to have forgotten this is a beta.
Lance.
thezone - thezone.firewave.com.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
Lance Birch wrote :
> "Warp" wrote :
>> Lance Birch wrote:
>>> POV-Ray is well-known for its multiple platform support. The overhea
d involved
>>> in producing a compile for each platform that POV-Ray supports for ea
ch beta
>>> release would be extreme, and is unnecessary for the testing process.
>> It's not just a question of compilation: Frontends need to be create
d
>> for each platform. Not a trivial task.
>
> Definitely. I'm simplifying things greatly - there is so much to do to
create
> each platform's release. I was just noting the time overhead involved
for each
> revision of the beta if you were to create one for each platform... com
piling
> for each platform (as it is, there are three compiles; 32-bit/32-bit
> SSE2/64-bit), compressing the various platform compiles with their docu
mentation
> into separate archives, updating the website with the multiple platform
compiles
> and no doubt writing notes for each, and so on. It would probably take
5 times
> as long just to organise the compiles for the revisions and get them on
the
> website, let alone the actual development involved. One release is com
plex
> enough, and for the purposes of testing and debugging the new internals
one
> platform is all that is required (and choosing the platform with the la
rgest
> beta tester user base is common sense).
>
> People seem to have forgotten this is a beta.
I understand that a platform must be chosen to propose a beta version.
Otherwise it may be rather difficult to manage releases ... But why
is Windows chosen, knowing that it is the only OS that is non Unix ?
I can understand that there's much more beta testers under Windows,
because this system has a commercial dominant position. But this system
is also non compatible with every others !
If another system had been chosen, it would have been the best way to
port to others, and to have a representative implementation. You know
that POSIX threads are common to really a great amount of systems, if
it was the point ... Computing farms are running Unix systems ...
Windows is the worst choice to experiment a beta version. I always
personally ported POV starting from Linux sources anyway.
That's why I'm speaking of the way to "promote" Windows, which
sounds me to be the worst choice.
Regards,
-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois LE COAT wrote:
> Hi,
>
> Lance Birch wrote :
>> People seem to have forgotten this is a beta.
>
> I understand that a platform must be chosen to propose a beta version.
> Otherwise it may be rather difficult to manage releases ... But why
> is Windows chosen, knowing that it is the only OS that is non Unix ?
Why do you worship Unix?
> I can understand that there's much more beta testers under Windows,
You just answered your above question.
> because this system has a commercial dominant position. But this system
> is also non compatible with every others !
Excuse me, but can you take a binary compiled for Mac OS X and run it
under Linux? Can you even run it under Yellow Dog Linux (compiled
specifically for the G5)? Can you run a Linux x86 binary and run it
under Sparc Solaris?
All of these systems are incompatible with all the others.
> If another system had been chosen, it would have been the best way to
> port to others, and to have a representative implementation.
Nobody is porting the betas to other systems, so this is a moot point.
Once the code base has stabilized, then the release of various ports
will begin.
Besides, all that is needed for a "representative implementation", would
be a representative sample of all POV users... the majority of which run
Windows...
> You know
> that POSIX threads are common to really a great amount of systems, if
> it was the point ...
Irrelevant...
> Computing farms are running Unix systems ...
... also irrelevant...
> Windows is the worst choice to experiment a beta version.
Why? The most users are on Windows.
> I always
> personally ported POV starting from Linux sources anyway.
What you do or do not do has no effect on the POV-Team.
> That's why I'm speaking of the way to "promote" Windows, which
> sounds me to be the worst choice.
They aren't "promoting" windows. If they were to say, "POV-Ray only
runs on Windows because it's the best OS out there!" then that would be
promoting Windows. Instead, they're saying, "We are releasing a buggy
and incomplete version of POV-Ray for testing purposes only on the
system which most POV-Ray users operate on." Hardly promotional
material, that.
>
> Regards,
Salutations,
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
From: Francois LE COAT
Subject: Re: POV-Ray v3.7.beta.11c available.
Date: 7 Feb 2006 14:40:43
Message: <43e8f7bb@news.povray.org>
|
|
|
| |
| |
|
|
Hi,
You're against Unices ... But it is the present evolution of OSes !
Are you experienced ?
Regards,
-- François LE COAT
Author of Eureka 2.12 (2D Graph Describer, 3D Modeller)
http://eureka.atari.org
Chambers wrote :
> Francois LE COAT wrote:
>> Lance Birch wrote :
>>> People seem to have forgotten this is a beta.
>>
>> I understand that a platform must be chosen to propose a beta version.
>> Otherwise it may be rather difficult to manage releases ... But why
>> is Windows chosen, knowing that it is the only OS that is non Unix ?
>
> Why do you worship Unix?
>
>> I can understand that there's much more beta testers under Windows,
>
> You just answered your above question.
>
>> because this system has a commercial dominant position. But this syste
m
>> is also non compatible with every others !
>
> Excuse me, but can you take a binary compiled for Mac OS X and run it
> under Linux? Can you even run it under Yellow Dog Linux (compiled
> specifically for the G5)? Can you run a Linux x86 binary and run it
> under Sparc Solaris?
>
> All of these systems are incompatible with all the others.
>
>> If another system had been chosen, it would have been the best way to
>> port to others, and to have a representative implementation.
>
> Nobody is porting the betas to other systems, so this is a moot point.
> Once the code base has stabilized, then the release of various ports
> will begin.
>
> Besides, all that is needed for a "representative implementation", woul
d
> be a representative sample of all POV users... the majority of which ru
n
> Windows...
>
>> You know
>> that POSIX threads are common to really a great amount of systems, if
>> it was the point ...
>
> Irrelevant...
>
>> Computing farms are running Unix systems ...
>
> ... also irrelevant...
>
>> Windows is the worst choice to experiment a beta version.
>
> Why? The most users are on Windows.
>
>> I always
>> personally ported POV starting from Linux sources anyway.
>
> What you do or do not do has no effect on the POV-Team.
>
>> That's why I'm speaking of the way to "promote" Windows, which
>> sounds me to be the worst choice.
>
> They aren't "promoting" windows. If they were to say, "POV-Ray only
> runs on Windows because it's the best OS out there!" then that would be
> promoting Windows. Instead, they're saying, "We are releasing a buggy
> and incomplete version of POV-Ray for testing purposes only on the
> system which most POV-Ray users operate on." Hardly promotional
> material, that.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois LE COAT wrote:
> Hi,
>
> You're against Unices ...
Show me one single quote where I am against Unices.
> But it is the present evolution of OSes !
Feel free to send me an email (at bdc### [at] yahoocom) explaining why
you believe this. However, this discussion is rapidly becoming
inappropriate for this newsgroup.
Again, the POV-Team has released a buggy and incomplete version of
POV-Ray, for testing purposes only, on the platform which most POV-Ray
users run. When the new code has stabilized and is ready for general
use, then it will be released on a variety of platforms.
> Are you experienced ?
Only with my wife, I saved myself for her.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "Francois LE COAT" <lec### [at] atariorg> wrote in message
news:43e8ea5d$1@news.povray.org...
> Hi,
>
> Lance Birch wrote :
> > "Warp" wrote :
> >> Lance Birch wrote:
> >>> POV-Ray is well-known for its multiple platform support. The overhead
involved
> >>> in producing a compile for each platform that POV-Ray supports for each
beta
> >>> release would be extreme, and is unnecessary for the testing process.
> >> It's not just a question of compilation: Frontends need to be created
> >> for each platform. Not a trivial task.
> >
> > Definitely. I'm simplifying things greatly - there is so much to do to
create
> > each platform's release. I was just noting the time overhead involved for
each
> > revision of the beta if you were to create one for each platform...
compiling
> > for each platform (as it is, there are three compiles; 32-bit/32-bit
> > SSE2/64-bit), compressing the various platform compiles with their
documentation
> > into separate archives, updating the website with the multiple platform
compiles
> > and no doubt writing notes for each, and so on. It would probably take 5
times
> > as long just to organise the compiles for the revisions and get them on the
> > website, let alone the actual development involved. One release is complex
> > enough, and for the purposes of testing and debugging the new internals one
> > platform is all that is required (and choosing the platform with the largest
> > beta tester user base is common sense).
> >
> > People seem to have forgotten this is a beta.
>
> I understand that a platform must be chosen to propose a beta version.
> Otherwise it may be rather difficult to manage releases ... But why
> is Windows chosen, knowing that it is the only OS that is non Unix ?
I have already answered this, but as Chambers has pointed out you have also
answered it:
> I can understand that there's much more beta testers under Windows,
Exactly. There are more beta testers on Windows, therefore it makes sense to
release the beta compile for Windows. That is the end of the story.
> because this system has a commercial dominant position. But this system
> is also non compatible with every others !
>
> If another system had been chosen, it would have been the best way to
> port to others, and to have a representative implementation. You know
There is no source released for the beta, so it can't be ported to anything.
> that POSIX threads are common to really a great amount of systems, if
> it was the point ... Computing farms are running Unix systems ...
What does that have to do with this test release?
> Windows is the worst choice to experiment a beta version. I always
That is incorrect. As you said, "there's much more beta testers under Windows".
> personally ported POV starting from Linux sources anyway.
There is no source available for the beta, so this is irrelevant.
> That's why I'm speaking of the way to "promote" Windows, which
> sounds me to be the worst choice.
You are mistaken. There is no "promotion" of Windows. The simple fact is that
it has the largest tester user base and therefore is the platform of choice for
the beta test compiles. There is no point releasing a test version on a
platform where there are fewer testers. To choose to release a test compile for
a platform that doesn't have as many testers as another platform makes
absolutely no sense.
Lance.
thezone - thezone.firewave.com.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Francois LE COAT wrote:
> Otherwise it may be rather difficult to manage releases ... But why
> is Windows chosen
The answer is simple: apart from the other reasons quoted in this thread,
the simple fact is that most of the work in making POV smp-compatible was
done by two persons - myself and Thorsten. I develop mostly under Windows,
and Thorsten on the Macintosh. So it was a choice between those two as to
which platform got the beta (and not even that really, since even today
the Mac frontend isn't completely finished).
The way the POV-Ray backend communicates with the frontend has undergone
significant changes and it was decided that it was best to work out the
problems on one platform rather than inflict the fairly fluid state of the
interface on our volunteer unix developers.
There is no 'conspiracy' against unix users, it is simply pragmatism,
nothing else. Once our unix developers are happy with the state of the
code I am sure they will release a unix build.
At this point I think this thread should end as it is not achieving any
positive purpose.
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
...
> The presence of this code may case the beta to be unable to load on
> Windows 9x systems; if this occurs it will be fixed in the next beta.
...
Windows 98se reports
The PVENGINE.EXE file is linked to missing export
USER32.DLL:SetLayeredWindowAttributes
under this popup window is another
C:\Program Files\POV-Ray for windows v3.6\bin\pvengine.exe
A device attached to the system is not functioning
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all!
About the new "transparency" mode of the render window...
*Once minimized, the "new-style render window" can't be brought back.
Specifically: it gets minimized in the lower-left corner of the Pov window,
it remains (visually) translucent, it reacts as transparent to mouse clicks,
hitting "Hide/Show" doesn't restore it either...
*Resizing the "new-style render window" resizes its contents to fit. Thus,
an option to restore original size would be useful. Otherwise, it's
impossible to judge if the jagginess in the picture if from a faulty AA
setting or from the resizing...
Thanks!
(Windows XP home edition SP2, Athlon XP 2800+, 1Go RAM)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"JYR" <jre### [at] videotronca> wrote in message
news:web.43f36c0e9d47dd89a86cbced0@news.povray.org...
> Hi all!
> About the new "transparency" mode of the render window...
> *Once minimized, the "new-style render window" can't be brought back.
> Specifically: it gets minimized in the lower-left corner of the Pov window,
> it remains (visually) translucent, it reacts as transparent to mouse clicks,
> hitting "Hide/Show" doesn't restore it either...
> *Resizing the "new-style render window" resizes its contents to fit. Thus,
> an option to restore original size would be useful. Otherwise, it's
> impossible to judge if the jagginess in the picture if from a faulty AA
> setting or from the resizing...
Also the new render window's title seems to initially be set as "100% complete"
and then go back to "0% complete" once the rendering actually starts. Just a
minor thing :)
Lance.
thezone - thezone.firewave.com.au
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
