I'll be working on getting a beta 26 out sometime in the next few days, no
guarantees since - as always - real life comes first, but hopefully it'll
be up by early next week.

If you folks would like to summarise what you consider to be the most
important outstanding issues, I'll see which of those I can tackle in the
time I have.

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> If you folks would like to summarise what you consider to be the most
> important outstanding issues, I'll see which of those I can tackle in the
> time I have.

  I'm not exactly sure what is the status of the gamma correction
handling in POV-Ray 3.7, but I think it's a bit of a problem that by
default it produces images with a very significantly different gamma
correction than POV-Ray 3.6. This means that many old scenes will
render rather differently in 3.7 than they did in previous versions.
IMO the default behaviour could be consistent with the old versions.

  Btw, what is the status of the antialiasing issues? Did someone
develop a command-line option to choose which type color clipping
should be used with antialiasing?
  I still think that the default antialiasing behavior should be the
same as with POV-Ray 3.5. It produced the better looking result in
the vast majority of cases.

-- 
                                                          - Warp

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I'll be working on getting a beta 26 out sometime in the next few days, no
> guarantees since - as always - real life comes first, but hopefully it'll
> be up by early next week.
>
> If you folks would like to summarise what you consider to be the most
> important outstanding issues, I'll see which of those I can tackle in the
> time I have.
>
> -- Chris

I would be happy if the team concentrate energies to improve the radiosity:
From beta page:

> o Radiosity support is still alpha quality.
> o No preview during radiosity pre-trace.

Thanks Chris.

Post a reply to this message

Le Fri, 18 Apr 2008 07:21:27 +1000, Chris Cason a modifié des petits
morceaux de l'univers pour nous faire lire :

> If you folks would like to summarise what you consider to be the most
> important outstanding issues, I'll see which of those I can tackle in
> the time I have.

For the unix/linux source code:

Incorporation of the workaround, at least, of thread starting race 
condition. (better would be a clean solution, if possible)
[issue on gentoo amd64 here, workaround in discussion seems ok for me, at 
least working]

Fix or avoidance of what looks like a random dead lock when displaying 
the render window (Initial display of empty window, no move. On Gentoo 
amd64, local X11, mouse event seems to unlock, at least with a click, but 
that's cumbersome for animation rendering at night; On RedHat ES 5 Xeon 
quad core, remote X11, the dead lock does not react to anything once the 
black render window has been shown. Yet another race condition ?)

The UA features/delta from 3.6, if it could be fixed, would be great. 
(ok, I did not check that, it's just there is a complain and 
intellectually it bother me...)

That's all for important things.




Not so important for 26: the man page, please... 

The time computation/statistics seems bogus (single core/quad-core) or 
need re-interpretation, but I do not care.

Post a reply to this message

Chris Cason wrote:
> I'll be working on getting a beta 26 out sometime in the next few days, no
> guarantees since - as always - real life comes first, but hopefully it'll
> be up by early next week.
> 
> If you folks would like to summarise what you consider to be the most
> important outstanding issues, I'll see which of those I can tackle in the
> time I have.
> 
> -- Chris


It would be nice to see a new version soon, but don't rush it :)

Here are some issues I would like to see resolved in the near future:

1) Lost transformations under certain circumstances. Usually happens 
when unioned, clipped_by objects are transformed with either transform{} 
or Point_At_Trans(). Other conditions produce bad results as well. I can 
make a more detailed post about this if necessary.

2) Radiosity and mesh objects aren't playing together very well.

I can't think of anything else at the moment.

Sam

Post a reply to this message

stbenge wrote:
> I can't think of anything else at the moment.
> 
> Sam

I Just found another bug. POV isn't producing actual 16-bit grayscale 
images... the output looks and behaves exactly like a regular 8-bit 
grayscale.

Sam

Post a reply to this message

> 1) Lost transformations under certain circumstances. Usually happens 
> when unioned, clipped_by objects are transformed with either transform{} 
> or Point_At_Trans(). Other conditions produce bad results as well. I can 
> make a more detailed post about this if necessary.

Test cases is what they surely need :)

Post a reply to this message

stbenge wrote:

> I Just found another bug. POV isn't producing actual 16-bit grayscale 
> images... the output looks and behaves exactly like a regular 8-bit 
> grayscale.

I can confirm this (although I tried only with beta24, but according
to the changelog that shouldn't have any impact). However, I did not
get 8-bit grayscale, just regular color (with hf_gray_16 and +FN),
both in the render window and the PNG file.

Post a reply to this message

All the issues related to radiosity, of course: radiosity itself, radiosity 
with meshes, radiosity preview.

Thanks,
Zoly

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:4807bf57@news.povray.org...
> I'll be working on getting a beta 26 out sometime in the next few days, no
> guarantees since - as always - real life comes first, but hopefully it'll
> be up by early next week.
>
> If you folks would like to summarise what you consider to be the most
> important outstanding issues, I'll see which of those I can tackle in the
> time I have.
>
> -- Chris

Post a reply to this message

Chris Cason wrote:

> If you folks would like to summarise what you consider to be the most
> important outstanding issues, I'll see which of those I can tackle in the
> time I have.

Did anyone try to reproduce the effect that 3.7 seems to be
significantly slower (read: more than any reasonable overhead)
on some single core systems (in my case: P4 2.6 WinXP)? This is
of course not urgent for beta26, but if the final version has
the same behavior, it will seriously deter some people from
using the new version. I realize the real benefit of 3.7 is
for multi-core systems, but it suppose it is also in your
interest that all users work with the newest version.

For examples, rendering the sample advanced/abyss.pov with
640x480 AA 0.3 took about 3 minutes with 3.6 on my system,
but 9 minutes with 3.7 in the SSE2 version using thread
count 1.

Yes, I realize this image requires a different aspect ratio,
noted this too late, but shouldn't be relevant here ;)

I was a bit surprised by this result myself; last time I
used a simpler test scene and only had a slowdown of 1.5.
I even downloaded beta25 to verify it, but the results were
similar to beta24 (actually, beta24 took about 10 minutes).

And BTW, having to set the thread count to 1 manually
after each startup is really annoying (although a thread
count of 2 doesn't cause much overhead when the render is
slow anyway, but for quick test renders which should be
done in a few seconds this can cause a factor of 2).

Post a reply to this message