In My Entry to pov comp I have several function based heightfields. In the
Render of the final image I will only need to use a heightfield of around
800 by 1000 triangles but in the close ups I will need a much larger
number. Am I allowwed to change a trigger when rendering the close ups(and
the large image in the unlikely case that I win) to avoid unneccessary
parse times when redering the final image.
Peter

"Vladimir" <nomail@nomail> wrote in message 
news:web.413f47f5228b7640de2762960@news.povray.org...
> In My Entry to pov comp I have several function based heightfields. In the
> Render of the final image I will only need to use a heightfield of around
> 800 by 1000 triangles but in the close ups I will need a much larger
> number. Am I allowwed to change a trigger when rendering the close ups(and
> the large image in the unlikely case that I win) to avoid unneccessary
> parse times when redering the final image.
> Peter
>


I'm fairly certain that you cannot.  The idea of the close-ups is to make 
sure that you are creating a highly detailed picture, even at extremely high 
resolutions.  If you don't think the heightfield would look good in a 
high-resolution version, then you would have to use the same (larger) 
heightfield in both instances.

My assumption is that no one's detail view is going to look perfect at such 
an extreme resolution, so I'm not overly worried about it.  I just plan to 
make sure that it doesn't look bad, and I'm hoping for the best.

-- 
Jeremy
www.beantoad.com

news:web.413f47f5228b7640de2762960@news.povray.org...
> In My Entry to pov comp I have several function based heightfields. In the
> Render of the final image I will only need to use a heightfield of around
> 800 by 1000 triangles but in the close ups I will need a much larger
> number. Am I allowwed to change a trigger when rendering the close ups(and
> the large image in the unlikely case that I win) to avoid unneccessary
> parse times when redering the final image.

Hello

Sorry for the delay. Using my TAG Member magic cap, here's the official
answer.

- The scene code for the entire scene and the close ups should be the same,
so using different values for function based height fields is not allowed.
Choose the maximum heightfield resolution you can afford for all renders.
The close-ups must look good, but they do not have to look as good as the
submitted image (for instance, in the http://www.povcomp.com/samples/ page,
the first close up shows that the tree leaves lack definition).

- You can write in the text that the resolution can be increased if enough
ressources are available, and you can provide such "quality triggers" in the
code. That way, it will be possible to produce an even better image if
necessary.

Gilles Tran

-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

> Hello
>
> Sorry for the delay. Using my TAG Member magic cap, here's the official
> answer.
>
> - The scene code for the entire scene and the close ups should be the same,
> so using different values for function based height fields is not allowed.
> Choose the maximum heightfield resolution you can afford for all renders.
> The close-ups must look good, but they do not have to look as good as the
> submitted image (for instance, in the http://www.povcomp.com/samples/ page,
> the first close up shows that the tree leaves lack definition).
>
> - You can write in the text that the resolution can be increased if enough
> ressources are available, and you can provide such "quality triggers" in the
> code. That way, it will be possible to produce an even better image if
> necessary.

Hi
Thanks For The Replys.
I have thought of a way round my original problem by using a calculation
that will calculate the complexity of the heightfields depending on the
image size. Since the code will modify itself I think this will make it
legal. Call me a perfectionist but I dont want my zoom ins to look just ok.
How is everyone doing? my job is really getting in the way. oh for the
unemployed life...
Peter

Vladimir <nomail@nomail> wrote:
> > - The scene code for the entire scene and the close ups should be the same,
> > so using different values for function based height fields is not allowed.

> I have thought of a way round my original problem by using a calculation
> that will calculate the complexity of the heightfields depending on the
> image size. Since the code will modify itself I think this will make it
> legal.

  That sounds just like a loophole around the rule.

  (Unless "using different values for function based height fields is
not allowed" implies "except if these values are automatically calculated
from the image_width and image_height identifiers".)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

news:web.41436c92c4d0dffcae4d96190@news.povray.org...

> I have thought of a way round my original problem by using a calculation
> that will calculate the complexity of the heightfields depending on the
> image size. Since the code will modify itself I think this will make it
> legal.

Well, the idea is that the close ups are really close ups of the submitted
image, not an improvement. For instance, image-dependent height field
complexity can be tricky: it's often about adding noise, and what looks
better on a close-up may not look always look better on the large scale
image. Without a 100% matching full image and close-ups, the judges won't be
able to know how the large render, with the quality triggers turned on, will
actually look (they'll just know how the close-ups looks).

In other words, the judges must have a fair opinion of the image as it is
submitted, so I wouldn't use this trick if I were you. Otherwise, it would
be possible to make lots of things dependent on the image size and pop up in
high res only in the close ups...

In other contests, people are obliged to render the full size image so that
the judges are sure that it's of high quality for media requiring high
resolutions. However, we thought that for the POVCOMP, it would be better to
let people spend more time on conception rather than on watching pixels
crawl across the screen...

G.


-- 
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

"Gilles Tran" <gitran_nospam_@wanadoo.fr> wrote:

> news:web.41436c92c4d0dffcae4d96190@news.povray.org...
>
> submitted, so I wouldn't use this trick if I were you. Otherwise, it would
> be possible to make lots of things dependent on the image size and pop up in
> high res only in the close ups...

I can see the point you (the organizers) are making, but I'd still like to
note that the printable image will probably be rendered separately anyways
(Rules 5Biii & common sense).  In other words, a trick like

height_field { function image_width*2, image_height*2 { ... } }

would give an optimal solution, namely allowing the entrants to do the very
best their hardware allows while still providing the organizers with full
detail of the print-quality images modelling -- with everything still
re-produceable from the same source data. In fact, I could even see this as
a technical merit and a good demonstration of POV-Ray flexibility when
designing images of great complexity.

I'm not trying to say how you should run the competition, and I will gladly
comply with any rules you deem necessary.  Just pointing out that with the
versatility of the SDL, loopholes in *any* set of any rational rules are
unavoidable; and that these restrictions about print quality are, in my
opinion at least, a MINOR issue when considering that the competition is
about production of some darn amazing ray tracings.

Having said that, I hope a good picture will win!

that was basically the code I was going to use. I think I will probably stay
on the safe side If there are objections and leave this idea. hope I have
enough patience for the huge parse times though.
Peter