 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hola,
I've completed a review of the v3.7 example scenes. A picture is worth a
1000 words so I've attached a pie chart showing the breakdown.
I also wrote a quick shell script to help target potential resourse
bottlenecks. I just produced this stuff so I've not had much time to think
about how to divide it up yet. Any thoughts? Finally I'm wondering if there
is a need to restate what it is we are going to be doing, image file
formats, what AA to use, etc and include it in a single document that we can
all read comment on and agree to before digging in. I'd hate to be halfway
through and find out that "Hey!!!! that's not what we agreed on!"
If I'm not stepping on any toes I'll commit to pulling togeather a mission
statement. I think this is may be the final piece before proceeding. Shout
if you don't agree!
This are the strings I looked for:
isosurface {
scattering {
radiosity {
These files have isosurfaces:
./advanced/abyss.pov
./advanced/benchmark.pov
./advanced/biscuit.pov
./advanced/isocacti.pov
./advanced/landscape.pov
./advanced/optics.pov
./incdemo/i_internal.pov
./language/trace2.pov
./objects/isosurfaces.pov
./portfolio/allobjects.pov
./portfolio/allpat1iso.pov
./portfolio/allpat2iso.pov
./textures/patterns/crackle2.pov
./textures/patterns/crackle3.pov
./textures/patterns/crackle_form.pov
These files have scattering media:
./advanced/abyss.pov
./advanced/benchmark.pov
./advanced/mediasky.pov
./advanced/optics.pov
./interior/media/galaxy.pov
./interior/media/media1.pov
./interior/media/media2.pov
./interior/media/media3.pov
The files have radiosity:
./advanced/benchmark.pov
./advanced/gaussianblob.pov
./advanced/object_pattern.pov
./animations/raddem/raddem.pov
./radiosity/patio-radio.pov
./radiosity/radiosity.pov
./radiosity/radiosity2.pov
./radiosity/radiosity3.pov
./radiosity/rad_def_test.pov
Cheers Jim
Post a reply to this message
Attachments:
Download 'scene-files.jpg' (138 KB)
Preview of image 'scene-files.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Cason wrote:
> Jim Holsenback wrote:
>> How about 1024x768 jpg?
>
> Keep in mind all of the images need to go into the distro; it would depend
> on the filesize of the combined images as to whether or not we could use
> that size. we might want to include smaller images to start off with, and
> have an alternate version of the HTML files that link to larger versions
> online. Or just include the thumbnails (presuming we use a reasonable size
> for these; e.g. 320 width) and always have the large version linked
> online.
>
> One thing I think would be nice is if we use a smaller thumbnail (e.g. 160
> width), and have a larger (e.g. 320 or even 512 pixel width) one become
> visible upon mouse hover. Full-size images would all be online in that
> case.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
