POV-Ray : Newsgroups : povray.general : mesh camera for UV-mapping output : Re: mesh camera for UV-mapping output Server Time
19 Apr 2024 17:12:56 EDT (-0400)
  Re: mesh camera for UV-mapping output  
From: William F Pokorny
Date: 13 Nov 2022 03:25:21
Message: <6370a9f1$1@news.povray.org>
On 11/12/22 09:19, And wrote:
> I have just tried interpolation, when using 'closest(no interpolation)', or
> 'linear', or any other option it introduce an artifact line. The seams is narrow
> but sharp when using 'closest', a little wider when using interpolation(my
> example image using 'linear').
> -------------------------------------------------------------
>> - What happens if you generate your map image with a higher resolution
>> mesh than that to which you map in the actual render? It might be too,
>> higher resolution image maps (denser mesh camera), help.
>> - Have you tried rendering at different output resolutions to see how
>> any seams might change? (Rendering large and shrinking a help?)
> When I generate a 2048x2048 (higher resolution texture image) then applied,
> compared to the 1024x1024(first one of this thread), its artifact seams looks
> smaller but still exist.

Thanks for the info. On the 2x scale up; I'm wondering if we might not 
get better results still with a non-integer multiple in size for the map 
image - say 1.7x or 2.5x.

Are you always using AA for these test renders? If so/when, which 
method? (In v3.7/v3.8 there is in method 1 some bias down and to the 

You're using a version of UberPOV. I remembered on rolling out of bed 
this morning that at some point after v3.7, Christoph corrected a long 
standing ~half pixel offset in how the AA ray sampling was getting done 
(I think just for method 2, but my memory is fuzzy). There was initially 
a bug in this fix causing issues with AA results in general which 
persisted for 2-3 months of releases. I have no idea where your release 
of UberPOV falls relative to this AA work and the later fix for the bug 
introduced with the initial fix.

Aside: My povr branch supports method 2 AA with 'big jitter (>1.0)' and 
jitter which is again random (v3.6 and prior like). With it one can 
sample in a 'non-shrinking to grid way' with controllable bleed in 
sampling into adjacent pixels. This 'big jitter' feature likely can help 
hide the seam artifact (as with artifacts in general).

The existing v3.7/v3.8 fixed/repeatable jitter method has some 
unfortunate bias issues making it different, but often no better, than 
no jitter at all. Details exist in a post somewhere on the newsgroups.

Anyhow, if using AA, have you tried running with and without jitter on?

Bill P.

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.