 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nicolas Alvarez wrote:
> Do the same as for the Insert menu. Put small images in the package and have
> an automatic way to re-render them at a bigger size.
I could, but I suspect that 99% of people wouldn't bother (and/or wouldn't
know). Most would, I feel, rather just point and click, even if that
involves pulling down the images from the internet. (We could provide a
downloadable set of the large images at the same site).
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nice work!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> This are the strings I looked for:
> isosurface {
> scattering {
> radiosity {
I think you place too much trust in consistent coding
style here ;) e.g., in 3.6, the following scenes use
"radiosity{" without a space:
advanced\balcony\balcony.pov(67)
advanced\blocks\stackerday.pov(40)
advanced\blocks\stackernight.pov(41)
radiosity\cornell.pov
and there may be more using the prettier way (troll troll)
of opening the curly brace on the next line ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers nous illumina en ce 2008-07-26 15:47 -->
> Sabrina Kilian wrote:
>> The last thing we need to agree on might be an ideal image format to
>> test with. I'm not familiar with the technical differences between
>> Targa and PNG, could anyone else chime in if we might notice certain
>> differences that appear in one or the other, or at certain bit depths?
>
> Either is OK, as both are lossless formats (ie, they should result in
> the exact same image).
>
> ...Chambers
The main difference between TGA and PNG, is that TGA is normaly not compressed
while PNG is a lossless compressed format.
--
Alain
-------------------------------------------------
I bet exercise equipment would be a lot more expensive if we had evolved from
starfish.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> Nicolas Alvarez wrote:
>> Do the same as for the Insert menu. Put small images in the package and
>> have an automatic way to re-render them at a bigger size.
>
> I could, but I suspect that 99% of people wouldn't bother (and/or wouldn't
> know). Most would, I feel, rather just point and click, even if that
> involves pulling down the images from the internet. (We could provide a
> downloadable set of the large images at the same site).
What if it renders from the last in the list, downloads from the first in
the list, and calls it done when they meet in the middle? That way it'd
fully use both network and CPU resources :)
Bonus points for ordering the list by render time : file size ratio
(download the slowest to render, render the slow to download).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Chris Cason" <del### [at] deletethistoo povrayorg> wrote in
message news:488f0949@news.povray.org...
> Nice work!
Thanks .....
I've also had a poke around some of the examples and I have some questions.
It seems the biggest issue is going to be the assumed_gamma handling change
in v3.7. If I'm understanding correctly if the parser sees the inclusion of
that keyword it basically spits out a warning and handles gamma correction
based on what you have in resolution.ini. Is that correct? So there's no way
to compare a before and after image. I used isocacti as a test case and saw
no visual difference in the image with assumed_gamma and with it commented
out.
Another thing I looked at was some of the animation examples. Some examples
had ini files and started clocking through and produced a series of images.
Do we want to run through the entire animation, and produce a mov. I have QT
pro to do that if that's the case. (I'm sure there are other apps for this)
but QT is what I'm comfortable with.
I've reread through this thread and it still seems that there is no
consensus on image file format and size. Whats the best approach here?
Produce a full sized image and just scale for the thumbnails, or two
separate runs.
What kind of timeframe are we working against here ..... by the end of the
beta cycle and before v3.7 final release?
I'm sure there are one or two more issues that I've not hit upon.
Stephen/Sabrina .... you guys have been mostly silent. What kind of initial
issues have you seen? I really think it's important to get as many of the
issues as we can out in the open before formulating a test plan. If I'm off
base on this please speak up. I'm flexible and have no problem being pointed
in the right direction.
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christian Froeschlin" <chr### [at] chrfrde> wrote in message
news:488f283f@news.povray.org...
> Jim Holsenback wrote:
>
>> This are the strings I looked for:
>> isosurface {
>> scattering {
>> radiosity {
>
> I think you place too much trust in consistent coding
> style here ;) e.g., in 3.6, the following scenes use
> "radiosity{" without a space:
>
oooo .... good point. perhaps just looking for the keyword (no brace) would
be better.
> advanced\balcony\balcony.pov(67)
> advanced\blocks\stackerday.pov(40)
> advanced\blocks\stackernight.pov(41)
> radiosity\cornell.pov
easy enough to change the script I used to hunt for these occurances. i'll
see if the count changes by much. maybe I should be looking for photons
keyword as well.
>
> and there may be more using the prettier way (troll troll)
> of opening the curly brace on the next line ;)
i think omitting the brace might give a better snapshot of whats out there
..... a ballpark estime anyway
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jim Holsenback" <jho### [at] hotmailcom> wrote:
....
> I'm sure there are one or two more issues that I've not hit upon.
> Stephen/Sabrina .... you guys have been mostly silent. What kind of initial
> issues have you seen? I really think it's important to get as many of the
> issues as we can out in the open before formulating a test plan. If I'm off
> base on this please speak up. I'm flexible and have no problem being pointed
> in the right direction.
My current understanding is:
~Stage one: Identify included content that no longer produces the same result in
3.7 as the version it was made for. Update files to reflect; removal of #version
if possible, and removal of version 3.5/3.6 in comments.
~Stage two: Update/remove/new content and the way it's presented to the end
user.
Stage one is the level I signed up for, Stage two is interesting but only as an
observer.
If you could group the files into managable chunks, I'll start reporting back my
findings;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"StephenS" <nomail@nomail> wrote in message
news:web.4890749415676239b586e7830@news.povray.org...
> My current understanding is:
> ~Stage one: Identify included content that no longer produces the same
> result in
> 3.7 as the version it was made for. Update files to reflect; removal of
> #version
> if possible, and removal of version 3.5/3.6 in comments.
> ~Stage two: Update/remove/new content and the way it's presented to the
> end
> user.
> Stage one is the level I signed up for, Stage two is interesting but only
> as an
> observer.
> If you could group the files into managable chunks, I'll start reporting
> back my
> findings;)
Last evening I reviewed about two dozen files from various locations.
Without fail assumed_gamma was the prevailing issue. Several files had
version 3.1 brands. There was one or two files that had noticeable blocks of
code commented out. I also noticed that some but not all source files had
ini files. I think this a great feature that we might use in the process of
producing the final quality images for the distribution. Stephens comments
and one other limiting factor for me (dial-up) leads me to believe that
there may be a better way to approach this project. The whole thing depends
on Chris having a machine that has enough free cycles to crank out the final
product, so I will be brief.
Divide the source files into four chunks. Three for the review team, one
left over for whoever gets done first. While that's going on there needs to
be a decision made about final image quality, size, and format. Every source
final gets an ini file with the agreed upon render options. See if we might
be able to leverage off what Christoph did with the MegaPov examples. The
testing on our end will just involve branding a version if necessary, making
sure any parser warnings are resolved, and seeing that the image does indeed
render. No worries about quality and size as the images will just be
discarded. Upload the cleaned up source and ini files, and batch them up for
processing.
Cheers
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jim Holsenback wrote:
> It seems the biggest issue is going to be the assumed_gamma handling change
> in v3.7. If I'm understanding correctly if the parser sees the inclusion of
> that keyword it basically spits out a warning and handles gamma correction
> based on what you have in resolution.ini. Is that correct? So there's no way
It's a little more complicated than that: best to read the release notes
regarding that (I'll paste the relevant section in a followup to this message).
> Another thing I looked at was some of the animation examples. Some examples
> had ini files and started clocking through and produced a series of images.
> Do we want to run through the entire animation, and produce a mov. I have QT
I don't think this is necessary, just a single still would do.
> I've reread through this thread and it still seems that there is no
> consensus on image file format and size. Whats the best approach here?
> Produce a full sized image and just scale for the thumbnails, or two
> separate runs.
Scaling to thumbnails is fairly easy, so I'd recommend that. For full-size
images you could render at a width of, say, 768, with the height being
whatever that scales to with the aspect ratio taken into account.
> What kind of timeframe are we working against here ..... by the end of the
> beta cycle and before v3.7 final release?
No specific time other than that obviously we have to get it done before we
release :). It would be nice to have the updated scenes in the betas sooner
than later.
One other suggestion: when leaving a #version in the scene file, it might
be good to add a comment above it that says e.g. "minimum POV-Ray version
needed to render this scene", or something like that.
thanks,
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
